4 ms·

I work in a company that writes almost everything in Perl, and as a result I have personally written tens of thousands of lines of the stuff, and I maintain and

I work in a company that writes almost everything in Perl, and as a result I have personally written tens of thousands of lines of the stuff, and I maintain and debug several times that amount. This code is used for everything from serving web pages to interacting with carrier SMS-C to number crunching. So believe me, Perl is definitely the devil I know. That being said, the only advice I can offer you is unsolicited: don't learn Perl. Perl is a very powerful language in a lot of ways and in its day it was the only game in town for serious rapid development. It is fundamentally broken in a lot of ways though, and unlearning the brain damage that you will get from becoming a Perl expert could take a very long time (it has taken me years). I won't launch into a diatribe about these language characteristics unless you ask me to, but do not doubt that I could. People talk a lot about how great CPAN is, and it does have a certain charm, but it is ultimately more trouble than it is worth. There are CPAN modules for everything, but just as often as not they are flawed or buggy or too limited and you don't realize this until you've sunk a considerable amount of time into the problem. Just the other day a colleague wasted an afternoon trying to get LWP::Parallel to work as advertised before realizing that it could not be done. Perl is great for building prototypes, but when you go to deploy the stuff you realize that DBI fundamentally can't do connection pooling in the way you want, and mod_perl has an execution lifecycle that can only be described as 'whacky' (depending on how you include your handler modules, sometimes mod_perl will simply stop evaluating your module when it reaches an error, leaving your symbol table partially filled in with no error warning), and once you've used a couple of CPAN modules they'll all invite their friends and those friends will invite their friends and pretty soon your Apache children are using 15-50 megabytes of _unshared_ memory each. Yeah that's right, the interpreter goes and touches a bunch of pages of Perl 'code' post-fork and blows the COW and now all your RAM is belong to mod_perl. It's really cool when an 8-way Xeon server with 16GB of RAM can only handle a couple of hundred req/s before it starts faulting and crashing Apache children on malloc. Do yourself a favor and use Ruby instead. Ruby is so much like Perl that you can almost call it a dialect, but just not quite as broken. Pretty broken still, but not nearly so broken as Perl. It has all of Perl's good characteristics and only most of its bad ones. And if the availability of libraries, or the lack of decent threading or other deployment characteristics bother you, then use JRuby which is now basically the fastest production Ruby and can call into all of the Java libraries (which _can_ do connection pooling in the way that you want). Personally I prefer Common Lisp and Rhino but you can't go too wrong with JRuby. If you go the Perl route you will definitely come to regret it.

mullr 19y ago
Truer words were never spoken. This is from one who once frequented perlmonks.org and thought himself great for doing so. I'm thankfully past that stage in my life. I encourage others to skip over it entirely.
aneesh 19y ago
Two things are certain in life: every language has its pluses and minuses, and every person has an opinion. There are lots of things perl is bad at, but it has a lot of strengths, especially if you work in the biological space. I also know several successful internet startups that run on perl, so I have to disagree with benreesman's advice to not learn perl. Is it good for everything? No. (and no language is)
- benreesman 19y ago
  If there are libraries for doing biological computation written in Perl that do not have available bindings for other languages then that would constitute a reasonable excuse for using Perl. This would be just as true if the library was only available 1990s Visual Basic, and is just as irrelevant a factor in the assessment of a language as a whole. Beyond the availability of some particular piece of code (in my case the tens or hundreds of thousands of lines of legacy systems that I lack the resources to replace) there is literally no excuse for using Perl or for inflicting its insanity on another hapless generation of web programmers. All of Perl's admirable qualities (convenient object-literal notation, first-class functions, correct Scheme-style lexical scoping, powerful and seamless regular expressions, convenient string processing and Unix integration) are available in other languages. All of them, period. Many of these languages do not share Perl's unforgivable faults (sigils to dereference variable namespaces, contexts, typeglobs, references, dismal error handling facilities, confusing and nonstandard object facilities). The only way to use Perl to build a large system is to lean on Conway's methodology, which consists of a book that reads like an airtight indictment of Perl by one of its chief implementors and a collection of CPAN modules that demonstrate a brilliant mind with a perverse allegiance to a cult-like cause. Do sensible class hierarchies without Class::Std, I dare you. Do reasonable try-catch-finally exception semantics without Error.pm, I dare you. try { ... } otherwise { ... } finally { ... }; # works try { ... } otherwise { ... } finally { ... } # no trailing semicolon, oops I just clobbered your next statement and produced a catastrophic failure that even an experienced hacker could stare at for hours without seeing It only takes about two hours reading 'Perl Best Practices' to realize that it's a brilliant book, written by a brilliant mind to attempt to make Perl a workable language for building large systems. It's a shame because he comes so close, but it turns out you can't rewire a language like Perl with libraries alone, even if only because you can't compel others to use them. Perl is a language for expert hackers only, no one else should be allowed near it. And even expert hackers are working harder than they need to because there is a constant intellectual tax on the inconsistency of the language. It only offers a little bit more power than Python, and actually less than Ruby at a much higher cost. There is no excuse for Perl in the 21st century, and you clearly have not spent time trying to use it to build large and complex systems or else you would feel the same outrage that I do than anyone would continue to contemplate it.

mullr 19y ago

Truer words were never spoken. This is from one who once frequented perlmonks.org and thought himself great for doing so. I'm thankfully past that stage in my life. I encourage others to skip over it entirely.

aneesh 19y ago

Two things are certain in life: every language has its pluses and minuses, and every person has an opinion. There are lots of things perl is bad at, but it has a lot of strengths, especially if you work in the biological space. I also know several successful internet startups that run on perl, so I have to disagree with benreesman's advice to not learn perl. Is it good for everything? No. (and no language is)

benreesman 19y ago
If there are libraries for doing biological computation written in Perl that do not have available bindings for other languages then that would constitute a reasonable excuse for using Perl. This would be just as true if the library was only available 1990s Visual Basic, and is just as irrelevant a factor in the assessment of a language as a whole. Beyond the availability of some particular piece of code (in my case the tens or hundreds of thousands of lines of legacy systems that I lack the resources to replace) there is literally no excuse for using Perl or for inflicting its insanity on another hapless generation of web programmers. All of Perl's admirable qualities (convenient object-literal notation, first-class functions, correct Scheme-style lexical scoping, powerful and seamless regular expressions, convenient string processing and Unix integration) are available in other languages. All of them, period. Many of these languages do not share Perl's unforgivable faults (sigils to dereference variable namespaces, contexts, typeglobs, references, dismal error handling facilities, confusing and nonstandard object facilities). The only way to use Perl to build a large system is to lean on Conway's methodology, which consists of a book that reads like an airtight indictment of Perl by one of its chief implementors and a collection of CPAN modules that demonstrate a brilliant mind with a perverse allegiance to a cult-like cause. Do sensible class hierarchies without Class::Std, I dare you. Do reasonable try-catch-finally exception semantics without Error.pm, I dare you. try { ... } otherwise { ... } finally { ... }; # works try { ... } otherwise { ... } finally { ... } # no trailing semicolon, oops I just clobbered your next statement and produced a catastrophic failure that even an experienced hacker could stare at for hours without seeing It only takes about two hours reading 'Perl Best Practices' to realize that it's a brilliant book, written by a brilliant mind to attempt to make Perl a workable language for building large systems. It's a shame because he comes so close, but it turns out you can't rewire a language like Perl with libraries alone, even if only because you can't compel others to use them. Perl is a language for expert hackers only, no one else should be allowed near it. And even expert hackers are working harder than they need to because there is a constant intellectual tax on the inconsistency of the language. It only offers a little bit more power than Python, and actually less than Ruby at a much higher cost. There is no excuse for Perl in the 21st century, and you clearly have not spent time trying to use it to build large and complex systems or else you would feel the same outrage that I do than anyone would continue to contemplate it.