So, dear OP, good luck writing your large-scale multithreaded high-performance distributed applications using Perl.
And BTW, I do use Perl quite a bit and I really like it, for certain tasks. But I'd never make these kinds of comparisons.
Erm... He didn't? He said:
"While so much of the shiny-chasing buzz in the micro-ISV startup built-it-and-they-will-fund world seems to chase Clojure and Node.js and app-in-a-page tricks, Perl 5 continues to be my workhorse."
No comment on the reliability (or otherwise) of Clojure.
And much as I love Clojure - there's an element of truth there. Lots of folk using it because it's the new-and-shiny rather than it being necessarily the best solution. I know I've binned some Clojure stuff that would have been fun for me - because adding the JVM to the mix in production wouldn't have helped us actually get stuff done.
(and while it's an unfair comparison - since it's a vastly younger language - the transition to 1.3 wasn't fun for many folk :-)
How do you know what is in people's head? I assert that lots of folk are using perl because it's comfortable to them rather than it being the best solution.
So demands of a software project in the real world are very different than the academia. Although you can argue that Lisp is far more a better language than Perl, based on some parameters you wish to evaluate. Others might have totally different parameters, for example in terms of mere usability and pace of getting things done, Perl will fare better than Lisp.
While evaluating two technologies it is really important to define the parameters you wish to evaluate them upon. Without that we are just comparing Apples and Oranges and then arguing that nutrition on one isn't better than the other. Unless we define who needs an Apple and who needs an Orange for what reasons, we won't be able to say which is better than what for what purposes.
There fore comfort is really a subjective term. For a professor sitting in a university with endless time at his disposal Lisp will make the perfect and most comfortable language. But me sitting on P1 ticket assigned to me, and given 45 minutes to provide with solution has no other option but to use Perl. In other news I just have a weekend to hack up a automation or produce a quick prototype. You know what language I'm going to use, Its Perl.
Not because I hate Lisp or I'm uncomfortable. Its just there is no other option.
As somebody who loves both Lisp and Perl I'd probably say you'd be as productive (unless you were sitting in a domain that one language or the other was a better fit for). Well - apart from CPAN and the testing infrastructure. And the editor/IDE support is worse unless you're already an emacs person... but those are just coz Clojure is young.
I'm thoroughly sick of the Lisp == academic == hard myth. It's just nonsense. I've taught newbie devs Lisp and Perl in the past and both groups seem to take it on at about the same pace.
No,
And this is probably the reason why Lisp never took off post the appearance of C based languages. This is also why there are so many languages, because there are that many use cases for them. Denying the existence of a problem doesn't offer a solution. I can build anything quickly merely by using CPAN modules, I can manipulate strings and do all the text magic real quickly in Perl. That's not the same case with Lisp.
What you are saying is something like this. One guy wants reach from point A to B. He can either run or go in a car. You can argue that if he practices enough he can run as fast as the car, sure he can. But there is 0 logic in subjecting your legs to that kind of a torture, while all you need to learn is how to drive a car.
Now don't tell me that going from point A to B itself is wrong and he should be going to C instead.
You did read the very next sentence when I talked about my abandoning one Clojure solution for exactly this reason?
I love Clojure to death. It's excellent. But there are lots of folk like me who are just gasping to go play with production Lisp when other solutions would probably be better.
Not saying there aren't many great real-world uses for Clojure. Look at the stuff Datomic are doing for example... but I see lots of folk (myself included) spending two weeks tweaking Clojure stuff, dealing with warm-up timing issues for the JVM, etc. when we should probably just chuck something together with Sinatra and get the job done :-)
I assert that lots of folk are using perl because it's comfortable to them rather than it being the best solution.
Agreed. Sorry if I seemed to imply otherwise.
I have written all of what you describe: large-scale multithreaded high-performance distributed applications using Perl.
When necessary I have written perlXS bindings to C routines, but this is surprisingly infrequent. Most high performance system interfaces are exposed to Perl in an efficient manner. I've had Perl processes with tens of gigs memory resident. I have written non-blocking state machines in Perl which serviced (or served) over 100k connections in parallel. Which have run on over 100k machines at once. I have worked on huge modular, multi-team undertakings in Perl. The single caveat is that separate processes and explicitly shared memory is the parallelism tool of choice with Perl.
Luck wasn't a part of any of this. Perl will scale quite well, and if you think it doesn't you likely have a few things to learn about what the language/platform can do.
Your point about these comparisons being dubious (paraphrasing) is perfectly valid, by the way.