perlmeditation
Ovid
<p>Paul Graham, of Lisp fame, has [http://www.paulgraham.com/icad.html|a
fascinating article] about technology choices. While this article is targeting
Lisp programmers, many of the points are (as usual) very applicable to
Perl.</p>
<p>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).</p>
<p>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:</p>
<code>
sub foo {
my ($n) = @_;
sub {$n += shift}
}
</code>
<p>And in Lisp:</p>
<code>
(defun foo(n)
(lambda (i) (incf n i)))
</code>
<p>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.</p>
<p>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 <em>for every data type</em>! (take <strong>that</strong>, you strong typing advocates :)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Cheers,<br />
<a href="/index.pl?node=Ovid&lastnode_id=1072">Ovid</a></p>
<p><small>Join the <a href="http://setiathome.ssl.berkeley.edu/stats/team/team_86606.html">Perlmonks Setiathome Group</a> or just click on the the link and check out our stats.</small></p>