perlmeditation
tilly
A co-worker threw a very interesting piece of
[http://www.paulgraham.com/avg.html|Lisp
advocacy] at me. It is an interesting paper and I
think that people should read it before reading the
rest of what I have to say.<P>
<READMORE>
Needless to say, I have been thinking about it.<P>
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.<P>
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]
[http://perl.plover.com/book/announce/04|lists] one of Paul
Graham's [http://www.paulgraham.com/onlisp.html|books] as
research for an [http://perl.plover.com/book/|upcoming
book]. So it is no surprise that Paul Graham argues for
Lisp. What interests me is how he does it.<P>
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.<P>
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.<P>
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.<P>
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.<P>
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.<P>
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...