[Catalyst] Re: Why I chose Perl and Catalyst

[A. Pagaltzis]

* Hermida, Leandro <Leandro.Hermida at fmi.ch> [2007-02-13 15:35]:
> It seems that a lot of people (including my boss) think that
> Perl cannot compete when one is trying to do "enterprise"
> applications. In some ways (please tell me if I am wrong) it
> might be true because Perl exhibits very few rules and
> standards and very little built-in control over how you write
> your code when compared to the Java and C# paradigm, syntax and
> compilation rules. This seems to make it much more difficult
> when writing very modular, reusable OO code in a distributed
> team of developers.

It only seems so. My experience is that bad Java code tends to
suffer from bloated OO designs with too much indirection and a
lot of pretzel logic in the distribution of responsibilities in
the pieces of the code. Bad Perl code tends to be underdesigned,
hackish and repetitive.

In other words, braindamaged Perl code looks braindamaged.
Braindamaged Java code looks tidy. The braindamage hides in
higher levels of the design. In my opinion, that’s an argument
*against* Java, not one in its favour.

Cleaning up a braindamaged Java codebase tends to be a job of
“compacting” it: re-coupling responsibilities that got spread
too far, removing indirections, generally moving things closer
together.

Cleaning up a braindamaged Perl codebase tends to be a job of
“building it up”: replacing hacks with longer, simpler code that
is easier to reuse, and then pulling out commonly repeated
operations into functions/methods.

Funnily enough, you often end up with less Perl code than before,
just as with Java, but if you do it right, there will be *much*
less Perl code than Java code in the end. I don’t know if this
makes sense but let me try to put it this way: cleaning up Java
simply makes it denser and proportionately smaller so it’s about
as “heavy” as before; cleaning up Perl makes it less dense, but
cuts away a lot of code, so the result is “lighter” than before.

And in the end, once you have a clean, well-designed codebase,
Perl is much easier to follow than Java because there is so much
less red tape. It’s just much faster to read clean Perl because
it gets straight to the point. This tends to be a *HUGE* boon
when debugging – particularly when the bug turns out to be
someone else’s (like the framework’s) and you have to dive into
their codebase.

----

Another point that is sometimes brought up is that you need
static type checking for “enterprise” software because dynamic
typing is just too weak. This is actually wrong; static type
checking buys you a lot less than many people think. If you write
good tests, you will catch far more bugs than a Java compiler
could spot due to mismatched declarations. And what would you
know – since dynamic typing makes it easier to write code, it
also makes it easier to write tests.

----

Lastly, performance. Well, the perl VM is pretty fast. It’s no
JIT; for raw number crunching, Perl is slow. However, you
probably do not need to do raw number crunching, and if you only
need to do it some of it, you can use things like PDL to make
Perl go fast. (If you need to do a lot of number crunching, then
yes, you’re probably better off with a language where you can get
closer to the metal.)

But for web apps, that is all beside the point. The way you make
web apps respond fast is by throwing lots of cheap reverse proxy
boxes at them. The way you make a web app serve individual
requests more quickly is by adding logic to the app to cache as
many partial render results as possible.

Notice anything? Yep: this has nothing to do with the language.
In other words, Perl and Java “scale” equally well, because
whether you use one or the other does not have any effect on the
reliable approaches for scaling and accelerating web apps.

Btw, adding do-it-yourself caching logic to the app itself in
arbitrary places is easier in Perl than Java (because of dynamic
typing).

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>