I largely, but not entirely agree. However I think that there is a lesson here for anyone who likes any language that they find makes them uncommonly productive.

For those who don't know, Paul Graham is a highly regarded Lisp hacker. How respected? Well put it this way. He is good enough that Dominus lists one of Paul Graham's books as research for an upcoming book. So it is no surprise that Paul Graham argues for Lisp. What interests me is how he does it.

His basic argument is that when you are running a program on a server, you get a lot of flexibility about what language you use. You can control what is installed. It is (relatively) easy to make changes. So pick the language which you can get the most done with. And then he proceeds to argue that that language is Lisp.

I will accept that for him that language is Lisp. I am willing to accept for the sake of argument that Lisp really is a more productive language in some absolute sense. But I can argue that his argument applies for many languages. And, given a different person, you might come up with a different language. Including Perl.

The key is what you can be productive in. His claim for Lisp is that a great Lisp hacker can program Lisp in a much more efficient way than you can program other languages. This is a wonderful argument for great Lisp hackers. And it is a neat argument for learning Lisp. But if you are not right now a great Lisp hacker, it isn't a good argument to run out right now and convert everything to Lisp.

Now what does Perl have going for it? Well among other things it has a pretty good set of features, it has a large and supportive community to help people get better, and it has CPAN. In other words Perl has a lot of ways to help people who are not already great Perl programmers to be productive, ways to help them become better at Perl, and useful tools to help people who are good at Perl to be productive.

Sure, for Paul Graham, Lisp may be the most productive language to work in. However even he, in describing what companies he was most concerned about competing with, gave Perl and Python respect. And even his Lisp-oriented company wrote a back-office manager largely in Perl.

So choose what is most productive for you now. And go out of your way to learn new ways of thinking so you can choose the best tools as time goes by. That includes learning other languages, including Lisp. (The learning of which will make you better at languages you already know, like Perl.) But if you read Paul's paper, and like it, then make your own mind up about what will be the most productive language for you...