The article points out that Perl can read and execute COBOL if it's configured properly, which is neat, but ... what's the point of saying "this is written in Perl" is it's actually written in COBOL and running on the Perl interpreter? This reminds me a little bit of the JVM. There are dozens of languages that can be converted to JVM bytecode, but only one of them is Java.
Anyway, Perl's endless configurability is a mark against it, in my opinion. When I read Java or C++ or whatever, I have to wrap my head around what the developer intends to do, but the syntax is always the same. With Perl, you not only have to figure out what the developer intended, but what the developer told Perl the syntax is supposed to mean in this particular scenario. That's a big part of why Perl is considered a "write-only" language.
racket has managed to do that while delivering a pretty damn good language too. i'm long-term optimistic about perl6.
That is how the string literal and regex sub-languages work in Perl 6.
Frankly while that is a nice feature, and makes it easy to test bug fixes to the compiler using the REPL, I don't think that it is the best selling point. Mostly because it is only used by a handful of modules currently, and most users of those modules don't care how they work.
I think it is better to say that Perl 6 is a rather flat language. Once you learn a feature, you can use it everywhere. For example there are languages that have special syntax for use in list slicing, whereas it isn't special in Perl 6. (instead you can use a lambda to do more complex slicing)
What this means is if you see a construct that you've already seen, but it is used in a place you didn't think it would work, you can pretty much guess immediately how it works. For example an <code>if</code> block can be parameterized using the exact same syntax as parameterizing the block of a <code>for</code> loop. Which is useful so that you don't have to create a temporary variable, or call the same method twice. (It isn't all that useful when using the comparison operators which only return True or False though)
The most oft heard complaint among people who are adept at Perl 6, is about having to go back to another language. I think the main reason for this is Perl 6 bends to your will, and other languages bend you to it's will.
I think Python would be so much better. These languages are almost the same technically, but Python has the better syntax and better errors.
(ok I just realise it hasn't the same support for lambdas but they just make me think of node.js style anyway...)
Don't want to start another tiresome thread about LISP syntax, but I'm one of those people who prefer C style expressions - as long as no heavy higher-level functional programming is required, for which I by now see almost no practical use at all.
As a funny quip, Larry Wall referred to LISP looks as "oatmeal with fingerclips mixed in".
Because RPerl does exactly this and works with both Perl5 and Perl6 thanks to its own Perl11 philosophy (Perl5 + Perl6 = Perl11).
Basically it translates a medium-magic subset of Perl 5 into C/C++ using Inline::C and Inline::CPP.
Kotlin is my latest fetish. I haven't played around with its JS transpiler yet, or it's native builds, but I'm cautiously hopeful.