I appreciate your sentiment and don't think it's "stupid complaints or nonsense" but I think you're accidentally adding FUD to the pile and stirring in wishful thinking.

#2, If Perl 5 was *ever* fast to develop in, it still is. None of the dev environments has gone away. The language and supported libraries have steadily improved, so I'd argue it's faster now than it ever was. E.g., you'll never have to roll an object system again with everything from Class::Accessor to Moose just waiting for you. And you still have the benefit of run time compilation which doesn't feel very academic when testing code every time you add a new line or two.

#3, you're talking about typing, I think. I guess it's an issue. It seems to come up a lot. I've never had a problem when I had to deal with it, with say an XML-transport to an API. There is no shortage of tools to check type manually. It might be a pain now and then but I think it would be more painful to have to deal with it in every single variable in every single piece of code.

Ruby has a great reputation. I've barely ever played with it so I'm speaking from some ignorance, still, it has many weaknesses compared to Perl 5; not universally available, slower, no native utf8, not good for systems hacking (one liners), gems < CPAN.

Others have gone after the Perl is dying meme with various job charts and such lately. It's obviously false. I chose to work with nothing but Perl 5 years ago and have not had any trouble getting jobs and even having my choice. I got a new offer out of the blue yesterday for example but like my current gig quite well.

And finally, Perl 6 - don't hold your breath. I am still looking forward to it but I stopped being excited about it a couple of years ago which was already a few years after it was started. Some of the recent buttressing of Perl 5 with stuff like Catalyst, C3, and Moose have made it easy to forget that Perl 6 felt like an immediate need in 2001. Great when it arrives, but I have a feeling that even after it does (if it ever does), it will be a couple of years before I'll move to it from Perl 5 anyway.

There are many questionable statements here, but the one I will address at the moment is the relation you draw between the complexity of the grammar (specifically you speak of "the more operators") the slower the language. That is simply not true.

Operators are nothing more that first class methods (or functions, depending on the paradigm). First class means that they have their own syntax.

The compiler might have to do a little bit more work parsing a complex grammar, but this has little to do with execution speed. For instance, the worst case scenario is Perl5/CGI where the application needs to be compiled for each request served. Even in this environment, perl5 is plenty fast for more needs. Options like modperl and perl6 (which can be compiled) eliminate this overhead.

Regardless, once compiled the number of operators a language supports has nothing to do with runtime performance. All operators (just like all methods) get boiled down to a set of simple instructions. For instance, the Standard Java Library as of version 1.6 has over 4000 public classes (and who knows how many private ones). There may be dozes to hundreds of methods per class. None of this makes Java slow (I wrote a Sudoku solver in high-level java that solved 14-given 17-given sudokus (some of the hardest) in under 500 microseconds each).

Perl is fast because it has 10 years of optimizations behind it. Ruby is not as fast because it simply doesn't. Update: Sorry, that should have been 10 years more. Ruby is about 12 years old, perl is just over 21.

Perl is fast because it has 10 years of optimizations behind it. Ruby is not as fast because it simply doesn't.

Ruby is a couple of months older than Java.

Ruby is a couple of months older than Java.

Java has a lot more money behind it though.

I do find it amusing that Perl has gone from being a relatively slow language (when I first started using it about 10 years ago), to a relatively fast one. The relation in question being to the other languages that are commonly used for similar domains.

I agree with your points, but must correct you on one point of terminology. A "first-class function" (or method) is almost exactly the opposite of one that has its own syntax! First-class functions are functions that can be assigned to variables, passed around as parameters, created or destroyed at runtime, etc.

I doubt whether complicate grammar of Perl 6 will lead to pretty slower speed of execution.

If you profile it and find a slow spot, I'll do my best to optimize it.

An unqualified all Ruby is clearer is questionable, but I don't think saying that there is some Ruby which is easier to read than equivalent Perl is at all questionable.

For instance (heh) given $instance->member( $new_value ) vs instance.member = new_value, the Ruby is more apparently an assignment. Similarly "smarter" instances for built-in classes make for more succinct code in places (array.sort_by { |x| x.abs } vs the equivalent Schwartzian transform).

(Then again judging from the post there could be an English barrier here and "all Ruby" wasn't the claim they meant to make.)

The cake is a lie.
The cake is a lie.
The cake is a lie.

Hmm. Eye of the beholder, I guess. To me, it looks like the Ruby code is trying to redefine the method instance.member() while the Perl code is perfectly clear.

For the accessor example, you can make it obvious that the Perl is an assignment by giving the method an unambiguous name:

$instance->set_member( $new_value );

That takes care of any functional advantage the Ruby syntax might have; anything else is a matter of personal taste. (I won't suggest using an lvalue accessor because AIUI that's not as expressive as the Ruby, though it can provide identical syntax for simple cases.)

As for the sorting example --

use Sort::Key 'keysort'; # or ukeysort, for optimisation freaks
@array = keysort { abs } @array;
[download]

is not significantly more complicated than the Ruby.

(Shrug...)

Have we somehow magically lost sight of the fact that Perl is nothing-more (and nothing-less) than a tool?

Perl ... Ruby ... PHP ... all of 'em ... are they really so amazingly different? I don't think so. And maybe, just maybe, we should “leave it at that.”

I happen to be both a tool-user (by profession, as we all are) and, in one particular fragment of our field, a tool-maker. Did I know what I was doing, ten-odd years ago? Heck, no. Did I “do it right?” Yes and know. If I had it to do all over ... sure. If you had given me ten-odd years of magical foresight, I would have done a great many things differently. (I would have, for instance, picked the right six numbers at the Lottery, and I'd be living in own Jamaica right now...)

But ... there comes a point when “a worthy tool” can no longer be viewed in isolation. When people start building things with “your” tool, and they start selling those things for money, well, the game has quite-permanently changed. It can never stop, and it can never go back.

Yes, there was indeed a time when COBOL was “shiny and new.” Those days of punched-card innocence have long since become entirely irrelevant. Perl is in much the same situation. Ditto Ruby and PHP, and whatever-the-heck comes after all of them.