* Hermida, Leandro <[EMAIL PROTECTED]> [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/> _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
