Monday, May 12, 2008

Things I Hate About You #1: Perl

An interview question we used to use to separate the posers from the folks who knew their stuff was "Name three things you dislike about Java". The idea is that if you've seriously worked with a language, you've run into several things about it that drive you nuts, but if you've just poked at it a bit, you're likely to spout a few superficial things like "'s slow..."

So, I'm going to work through this for a few programming languages. Today's victim: Perl.

  1. Perl 6 - An interesting comparison: Python 2.0 was released about 3 months after Perl 6 was first announced. In that time, Python has released 6 versions (2.0 to 2.5), announced Python 3.0, and released 5 alpha versions of Python 3.0 with a scheduled release of 3.0 in September. Perl has released a few partial versions, has a partly-written virtual machine, and no planned release date. To be honest, Perl 6 reminds me of everything I've heard and seen about ALGOL 68 - a Byzantine language spec that tried to be all things to all people, with the end result of killing off the parent language (ALGOL 60). The best result we're likely to see out of Perl 6 is the backports into the Perl 5 project, but it took far, far too long for folks to realize that Perl 6 itself was a dead end and begin reviving Perl 5.
  2. CPAN - CPAN is a great idea: a single repository for user-contributed modules with a handy front-end and dependency-handling. Unfortunately, both of those systems fail. As a single repository, it's great...until you try to actually find anything in it. Say, hypothetically, that you wish to read a CSV file. And so you go to CPAN and search for CSV...and get 261 results. Which do you use? There's a small amount of guidance now, with ratings and reviews starting to show up...this is a vast improvement over before, where you had literally no indication, but it's just a start. (And CSV is a small example; try XML, which has a FAQ list just about finding which one of 14 XML modules is the right one. A search for XML finds 3522 matching modules.) As a front-end, it's also great...until you run into a mandatory upgrade of some sort. Fortunately, they seem to have fixed the issue where it would try to upgrade Perl on you...
  3. Non-Obviousness - There are a lot of cases where what Perl is doing is extremely not obvious to anyone who hasn't spent a lot of time programming Perl. (I've commented elsewhere that Perl is an extremely difficult language to be an expert in, because it's got so many odd edge cases.) Basically, Perl tries to guess the right thing for you...this is great when it guesses right. When it guesses wrong, tracking down the problem is a major pain. Examples include autovivification, scalar context vs. list context, true/false vs. defined vs. exists... There are also a lot of cases where Perl is egregiously Different for no readily apparent reason. (break/continue vs. last/next, switch vs. given - especially egregious since the 'given' statement needs to be activated with "use 'switch'") And let's not even get started on the punctuation variables. A lot of these things are hacks nested upon hacks, where the 'obvious' original use wasn't as obvious as they thought and a new addition had to be made for cases outside the original plan. (Example: lists cannot contain lists. Solution: references. So now you've got all the fun of C pointer manipulation.)
Several of these could be expanded out further. Now, in practice - I like Perl, and I'm reasonably good at it. (I can't consider myself an expert, though - still too many odd edge cases I don't know about yet.) But...well, there's a reason I'm trying to do quick hacks in Python now. (Python's list of problems is coming later this week.)


chromatic said...

Guido was discussing Python 3000 as far back as 2001. It's still not out yet.

Please note two things. First, Python 3000 is a very modest change from Python 2.x. There's no comparison between Python 3000 and Perl 6 in terms of change, growth, and rethinking, and Python 3000 has been in planning or development for almost as long as Perl 6.

Oh, and Guido's getting Googlebucks to work on Python 3000. Money buys time.

You should also compare releases of Perl 5.x with Python 2.x. In the time since the announcement of Perl 6, there have been eleven stable releases of Perl 5.x.

I actually agree about finding the right module on the CPAN sometimes. People tend to ask on PerlMonks or other places for recommendations.

As for non-obviousness, many of the issues you complain about relate directly to design principles of Perl 5. For example, list flattening has everything to do with list context. As well, parentheses never create a list. Commas do.

Some of those decisions turned out to be wrong, but that's why there's Perl 6.

Brad J (Kazrak) said...

Python 3000 has been discussed for a while, yes; it's natural to talk about where to go next. The proposal for Python 3000 - a good equivalent to the initial proposal for Perl 6 - didn't come out until 2006, though. And, yes, Python 3000 isn't as ambitious an overhaul as Perl 6. But the Perl 6 overhaul has made Perl stagnant for many years - there were over five years between 5.8 and 5.10, and while there were bugfix releases in the middle, they were (by and large) bugfixes. (It is worth noting that the PEP for Python 3000 is newer than Perl 5.8.8, the last stable release before last December's 5.10.0 release.) If you'd like to compare point-releases, then Python has put out 27 releases in that time frame compared to Perl's 11.

Perl was basically stagnant for many years, and is finally starting to come out of it. I personally think Perl 6 is the cause -- that it's suffering from a bad case of kitchen-sink syndrome, and why work on Perl 5 when Perl 6 is coming up Real Soon Now, but Perl 6 isn't at a point where I can work on it yet, and so on. (Perhaps that's just an outsider's perspective on it.) I really am frightened by the comparisons to Algol 68; I truly enjoy Perl for the uses where it's a good choice, and I'm afraid that Perl 6 will kill it. (Perl 5.10 has helped calm that fear somewhat.)

Beyond that - it's worth noting that all languages have flaws. (Tomorrow, I'll probably give the things I hate about Java. Python will probably come up on Wednesday, although, to be honest, I'm not sure my Python ability is solid enough to give three really good problems.) As I said at the beginning of the post - if you can't find three things about the language that you don't like, then you haven't seriously worked with it. I'm curious what others would choose.

chromatic said...

Hey, Larry and I both sat in on a talk from Guido about Python 3000 in either late 2003 or 2004. You're going to have trouble convincing me that (the very modest) Python 3000 has existed in plan or in deed for any less time than Perl 6.

Kudos to the Python hackers for getting closer to their goals in the same time period... but it's disingenuous to pretend that the scope of their goals resembles the scope of the goals for Perl 6 in any fashion, and it's downright unfair to compare the progress of well-funded developers against volunteers carving out free time.

Similarly, calling Perl 5 "stagnant" from 2000 through 2008 or even 2002 through 2008 requires ignoring plenty of evolution which took place -- by design -- outside of p5p. I'm leaving plenty of things off the list, but how about dozens (if not hundreds) of testing modules which all play nicely together in the same process, Inline, PPI, Perl::Critic, Moose, Catalyst, Devel::Cover, DBIx::Class, and so on?

The Python philosophy has long had twin goals of "There should be one obvious way to do it" and "Batteries included", so it's no surprise that there's a huge push toward coalescence. Perl takes a different approach, so it should be little surprise that evolution and revolution happens in Perl outside of the core.

I could also mention the fanatical devotion toward backwards compatibility on p5p which means that, for example, Perl 5.004 or 5.005 was a valid deployment target for a lot of places... but if you still think Perl 6 sucked away a lot of the life and energy and even necessity to release new versions of Perl 5, I suggest you browse the p5p archives for a while.