|Don't ask to ask, just ask|
I don't want to sound too harsh, but this criticism is misguided. OK, so he and a friend have problems understanding the Apocalypses. So do I. So do a lot of people. However, when I read Exegeses, all of a sudden, things make sense. The only reason I don't feel comfortable with Perl 6 is that I am not (yet) regularly programming in it. When people start to use it regularly, they'll appreciate its power. It solves many of the problems that are hampering Perl 5's acceptance.
He also points out that it's not backwards compatible with Perl 5. Ignoring the Ponie project for a moment, I have to ask "so what?" I can't put a Ferrari's motor in a Ford Pinto. That doesn't mean that there's something fundamentally wrong with Ferrari's. If all you need is a Pinto, fine. Drive the Pinto. If you need a Ferrari, a Pinto won't cut it. I work on large scale systems that frequently butt up against the limitations of Perl. A Ferrari would be very handy.
If Ponie pans out, Shlomi Fish is dead wrong about backwards compatibility. If Ponie doesn't pan out, we can think "Perl 6 is to Perl 5 what C# is to Java." (Only more so and without the proprietary platform issues.)
And let's take a look at the comparison code snippet he produced (minus the curious formatting):
He states the the Perl 6 is "recognizable, but completely different!" I'm curious to know how he defines "completely different." The sigils are now part of the variable name, clearing up one of the greatest sources of confusion for new Perl programmers. The for 1 .. 6 -> looks different but it's hardly obfuscated. Ooh, and look! Fewer parentheses are needed.
He also complains about arrows being eliminated in favor of the dot operator. I don't understand his complaint here. It's such a common operator that Huffman encoding suggests that it should be shorter and, conveniently, there's already an operator that's practically an industry standard. How handy. Personally, I always thought the arrow operator was for C programmers who were used to dereferencing structs. The encapsulation violation this implies is a Bad Thing.
Frankly, I am solidly in the "we need a new Perl" camp. Of course, many argue that Perl 6 is too complex. However, when you look at the big picture of Perl 5 you could make the same argument ... until you realize that everyday coding tends to use an easy-to-learn subset of Perl. That's what we're going to see in Perl 6. The easy things will be easy and the hard things will be possible. Now that's not so strange, is it?
In reply to Re: Critique of Where Perl 6 is Heading on Freshmeat.net