Without disagreeing with you, I wonder how you can judge the marketing success or failure of a project intended to last at least 20 years at this point in its adoption cycle.
Are there any valid criticisms to be made of Perl 6 or its process?
Certainly. The failure to have a Perl 6 running on Parrot within a few months of Parrot's inception hurt development immensely. The RFC process demonstrated that the initial idea of a Python 3000 style rearranging of a few external features and some internal structures was not nearly ambitious enough. Rethinking regular expressions into grammars was a huge example of hubris.
My point stands, though: the intent of Perl 6 was never to create a language or runtime or compiler which would gradually succumb to a Perl 7 which would gradually succumb to a Perl 8 and so on. Since the RFC process the intent of Perl 6 has to been to create a Perl which solves the limitations and flaws of Perl 5 and can thrive for the next twenty or more years.
Put another way, the most important feature of Perl 6 is that is provides what Larry always intended of Perl 5: a language which allows you to create your own lexically-scoped dialects as necessary.
My point stands, though: the intent of Perl 6 was never to create a language or runtime or compiler which would gradually succumb to a Perl 7 which would gradually succumb to a Perl 8 and so on. Since the RFC process the intent of Perl 6 has to been to create a Perl which solves the limitations and flaws of Perl 5 and can thrive for the next twenty or more years.
The intent was to completely set aside iterative development in favor of a big design up front which is supposed to last decades without change, like some Egyptian pyramid or the Great Wall of China? And this intent came about because of a desire to fix all of Perl 5's flaws and limitations all at once?
That is one of the classical blunders! The most famous of which is "never get involved in a land war in Asia", but only slightly less well-known is the Second System Effect!
The intent was to completely set aside iterative development...
Goodness, no--quite the opposite. The intent was and still is to allow iterative development and in-place upgrades, rather than requiring repeated flag-day breaks of backwards compatibility (the "it's obviously time to increment the major version number").
Of course not. What gives you the impression that this is the case? There will be a Perl 6.1 with features not present in Perl 6.0 in the same way that Perl 5.12 has features not present in Perl 5.10.
If you meant to ask "Why not release a cut-down version of Perl 6.0 several years ago and iterate on that so you could be up to Perl 6.5 or something by now?" the answer is more complex. First, the most necessary feature of Perl 6 to allow for in place upgrades without falling into the morass of backwards compatibility that slows down the development of Perl 5 was not yet ready. That's a difficult problem and one you don't get many chances to do over.
Second, none of the implementations were mature enough to recommend for general purpose use. (That's as much due to internal strife in Parrot as anything else.)
If so, I guess we're not going to get Perl 6 after all. After all, all the existing implementations have adopted strategies of getting some features working then getting more. It certainly looked to be working pretty well. I mean, in the last month, I've used grammars, feeds, hyper-ops, lazy lists, and many of the other cool features Rakudo has already implemented. I mean, feeds seriously got added last night. Any project still adding wonderful features like feeds after 30 public releases can't have much hope, if developing Perl 6 requires implementing every feature addition at once.
And the other implementations have it even worse... How am I going to tell sorear that, despite probably averaging over a dozen commits to Niecza[0] each day since the beginning of the month, and the incredible progress he's been making with it, he's doomed because he isn't trying to implementing everything all at one?
Joking aside, no one's trying to implement every feature of Perl 6 at once. The developers of the various Perl 6 implementations are trying to implement feature after feature. Sure, some of them are so productive that the Perl 6 implementation on which their brains run must have implemented auto-threading,
but even they aren't trying to implement everything before they make a release. Rakudo's 31st compiler release is this Thursday; and Rakudo [1] is coming out the 29th. Pugs[2] has had quite a few releases. Pawel Murias just released Mildew[3] and STD.pm[4] on CPAN.
Rakudo , for example, isn't going to have all of Perl 6 implemented; but it has quite a bit, and that quite a bit includes some great things, some of which no one else is even trying to do.
Without disagreeing with you, I wonder how you can judge the marketing success or failure of a project intended to last at least 20 years at this point in its adoption cycle.