> The perl developers greatly underestimated the importance of syntactic sugar and familiarity.

I don't think that's the case. The problem is that the generation of tools that have stuff in common with perl (awk, sed, shell) are completely unfamiliar to programmers which started programming in the last 15 years, compared to those that started 30 years ago.

Look at how much boilerplate code you need in Perl 5 to create a class versus C++/Java's simple class MyClass { }

You need to assign to a variable named @ISA, you need to return 1; at the bottom of the file. And 'public' members have to be listed in the EXPORT variable.

It is really funny that Perl 5 OO need more boilerplate code than Java!

A small correction there, you aren't making them public by putting them in EXPORT. What you're doing is actually using another module to munge the namespace that used your class. In fact by default all functions defined in a package that is used as a class are public by default.

And here's the boiler plate for more modern perl:

    package MyClass;
    use Moose;
    1;

You can define properties of the class using has 'property'; This will setup any accessors and also handle initializing them in the constructor that's created for you by default.

Why do you need to return 1 though? That seems pretty ridiculous.

Because that's how [require](http://p3rl.org/require) works:

> to indicate successful execution of any initialization code

Other dynamic languages have problems with "half"-loaded code. This mechanism is a defense against that.

It has uses. Sometimes you can also use it to write code that runs like a script if called in script mode (what some people are calling a modulino. If you really hate it there's a number of packages on CPAN to make it disappear.

Also new versions of Perl allow you to define a package scope and skip the '1;' Most Perl programmers don't use this yet since the benefit is very small and the cost is losing some back compatibility. Maybe in a few years it will be more common:

package MyApp::Web { ... }

Like a lot of things in Perl it has a use that might not be immediately evident. Its also possible a more elegant solution could have been found as well. Generally when I write real code I never notice it (the 1; is drowned out by docs and real code.

Technically, you don't need to return 1; you need to return a truthy value. The string "Perl syntax is dumb and hateful" works just as well.

What? I'm not a PERL programmer - I used it a bit before it grew OO features, roughly at the same time I used Turbo Pascal, so really long ago. Yet, in these examples: http://stackoverflow.com/questions/1037312/how-do-i-create-a... I see no boilerplate you speak of. If you look at this http://stackoverflow.com/questions/1037312/how-do-i-create-a... answer you'll see comparison to C++, which isn't exactly in the favour of the latter in terms of conciseness.

And then, even if it was true and you really needed to "add public methods to EXPORT variable" that's no different than modern JavaScript, right? That's how modules work in JS. Having to "return" something at the end of a module is a requirement in Lua, too - again, it's just how the module system works.

Anyway, I don't know PERL, but knowing many other languages I find your claims suspicious. It reads as if you were a recent Java convert who tries to rationalize his decision to leave PERL or something like that.

"public static void" is more boilerplate per method than Perl has per module.

You know, that's actually really insightful. I never bothered to learn awk, sed and shell because Perl did it all under one roof. I can only imagine moving from that mess to Perl must have seemed like a revelation to those that came before me, while Perl 5 to Perl 6 is less obvious.