|go ahead... be a heretic|
Paul Graham, of Lisp fame, has a fascinating article about technology choices. While this article is targeting Lisp programmers, many of the points are (as usual) very applicable to Perl.
He points out what should be obvious, but still needs to be clarified for many: all languages are not created equal. We love Perl, so we know that's true :) He says some nice things about Perl. In fact, many of his articles mention Perl. While he is definitely a Lisp advocate, I think there is no question that he considers Perl to be preferable alternative to bloated, static languages. He also takes some time to swipe at Design Patterns (he states that patterns in his programs suggest to him that he is using abstractions that aren't powerful enough).
What was particularly interesting to me was his side-by-side language comparisons of generating an accumulator. Specifically, using a closure to do so. He listed Lisp first, but I'll start with Perl:
And in Lisp:
Rather that just drool-n-paste all of his code samples, you should go out and read his article. His Python examples show that this is a bit clumsy in the language due to Python's incomplete support of lexical variables (to be fair, I don't know enough Python to comment on that). What was really fascinating, though, was his pointing out that this particular problem cannot be easily solved in many, perhaps most, languages. Most languages won't allow you to return a function. Further, if the language doesn't allow lexical scope, then a returning a function wouldn't do you any good.
He did show an example of how to accomplish similar functionality in Java, but Java's strong typing gets in the way. You would have to overload the method with a separate method for every data type! (take that, you strong typing advocates :)
This is where I think it's interesting for Perl hackers. Yes, our language doesn't have a large corporation backing it. Our language doesn't necessarily have the prestige of many others. But when push comes to shove, if you need something done, Perl is often a fantastic choice. Paul Graham points out that if another language requires 3 times as much code, coding a similar feature will take three times as long. Actually, I think he's mistaken here. Development time, IMHO, does not scale linearly with the size of the program. I don't have any statistics handy (anyone, anyone, Bueller?), so this is only a suspicion, but the longer your program, the more bugs you're going to have. This will slow development time even more. When you're competing with someone else and they're using bloated technologies, this is another example of a clear potential win for Perl.
Let's assume that you are company A, using Perl, and company B uses another language whose programs typically are three times as long as Perl programs. Let's also assume, generously, that this means that development time for them is three times longer. They've just spent six months adding a new feature and touting it to the press. You've decided that you want it, you only take two months to add it. You spend six months adding a new feature. If they decide they want it, it will take them a year and a half to get it. By that time, you've left them in the dust.
So, the next time some PHB says "use Foo to program in", ask him or her what would be done with the extra budget money if you could use Perl.
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.