|P is for Practical|
Re^3: A wholly inadequate reply to an Anonymous Monkby pmichaud (Scribe)
|on Apr 23, 2010 at 16:54 UTC||Need Help??|
Here we go again, a post that is almost entirely filled with speculation divorced from reality... (see how many "might haves" and "maybes" there are in the post).
If you read some of [Perl 6 RFCs] you'll see that people mostly didn't want to turn Perl 6 into the total rewrite it has become. Most of the suggestions were along the lines of fixing the return value of chomp, giving us a better object system, or fixing path handling.
First, I claim that "giving us a better object system" (i.e., Moose) would not have happened without having first having had the opportunity to see what would be done by a total rewrite. (In particular: multimethod dispatch, function signatures, strong typing, invariant sigils on variables, and twigils.)
Second, I think that what Larry and the cabal eventually discovered (I wasn't there at the time) was that you couldn't incorporate most of the new suggestions into Perl without first going through a total rewrite. Yes, some of the ideas from Perl 6 are now making it into Perl 5, but I claim that this is possible only because the ideas were discoverable as part of the exercise of creating a total rewrite. Even if you claim the new concepts would've been achieved via a simple re-iteration, I'll still contend that the evidence shows that the timeframe wouldn't have been significantly shorter than what we have now (see below).
In short, Perl 6 might have been basically a re-iteration of Perl 5 in the same way that Perl 5 was for Perl 4. Only this time we could break backwards compatibility to fix some of the hairier bits.
I wasn't involved at the time of the RFCs, but my understanding is that the issues involved in bringing these new features to Perl were (and still are) far greater than simply dealing with backward compatibility. A number of Perl 5 experts have told me that the other reason for "total rewrite" with Perl 5 is that fixing Perl 5's core codebase would also take a huge amount of work and have uncertain chances of success. And guess what, those experts were correct -- it took 7.5 years to get from Perl 5.6 to Perl 5.10. Thanks to the heroic efforts of a number of pumpkings and core hackers, the Perl 5 codebase of today is orders of magnitude improved over what existed in 2000. But I also believe (from what others have told me) that many of the fundamental problems are also still present.
(Anticipating those who will say "Perl 5.10 would've arrived much quicker if we hadn't gotten distracted by Perl 6", please (1) cite your evidence for such a claim, and (2) note that many well-known Perl 5 experts and insiders, including pumpkings, strongly disagree with the notion that work on Perl 6 has impeded Perl 5 development in any significant way.)
Had this been done we might have gotten something in 2-4 years that was production ready (ran all of CPAN) and cleaned up the worst warts. Had we cleaned up the worst parser edge cases you might be running jPerl on your JVM now instead of jRuby.
I think this is even more speculation contradicted by available evidence. I don't know of any Perl 5 core hacker who seriously contemplates making significant changes to the Perl 5 parser, or that such changes could reasonably happen in just a few years. And I certainly have plenty of evidence available to indicate that even minor changes to the Perl 5 parser have taken years for evaluation, testing, and being incorporated into an actual release.
Several Perl 5 experts (again, including former and current pumpkings) have told me that Rakudo and Perl 6 remain Perl's best (and some say only) chance for Perl (both 5 and 6) ever making it to the JVM or .Net virtual machines. And anyone who wants to port Perl 5 to other virtual machines would certainly want a better parsing engine than what is currently available, which brings us back to needing a new grammar engine, which brings us back to needing Perl 6.
It was claimed that there was no existing VM that could run a lot of dynamic languages, now it turns out that the JVM/.Net can do that just fine...
Okay, you're essentially accusing the Perl leaders of 2000 of having imperfect foresight. And you're omitting the fact that JVM and .Net weren't at all "open platforms" then (and in many ways they still aren't), so if "the new Perl" needed something not available through those VMs at the time, there was little chance of having that something added in a timely manner.
Regardless, the debate about whether Perl should have pursued a new VM is ultimately a red herring in my book. My other points still stand-- even using Perl 5 as the underlying VM it has taken Larry a couple of years to write up a parser for our new language. And from an early date that parser has required Perl 5.10 and Moose, neither of which were available in any sort of usable form until 2007 at the earliest.
(I grant that it's entirely plausible that Larry could've created his standard grammar implementation using 5.8 and without Moose. But my speculation is that Larry would've instead taken the time to design something like Moose and the additional features he would need in 5.8 to support the grammar. Which, if you think about it, is in fact exactly what has happened. :-)
10 years later we still don't have our apple pie.
Answer 1: I have an apple pie, and a new and better tasting apple pie shows up at my doorstep each month. Perhaps the apple pies I'm receiving aren't sufficiently cooked to your culinary standards (yet), or aren't the type of pie you're looking for, but it's wrong to claim there aren't any apple pies being produced.
Answer 2: Maybe you don't have your apple pie yet, but I guarantee that your Perl 5 pie is now much tastier and better for you because of the work that has gone into making the Perl 6 apple pie.
But it's interesting to speculate on what could have happened differently. Maybe we'd have a Perl 6 for 6 years already by now...
No, you'd likely have a Perl 5.10 that would be called "Perl 6". And you would have only had it for two years (Perl 5.10.0 was released in December 2007). It would probably be seen as having the same level of "incremental improvements" over Perl 5.6 that Python 3 does over Python 2, and with a similar (slow) adoption rate.
It probably wouldn't have had the ~~ smart match operator, cited as "the most exciting change" in Perl 5.10 over Perl 5.8.
It would still be considered ugly (many people find Perl 6 much less ugly by comparison). And Ruby and Python would still be where they are today.
If the speculations being offered were being used to improve on what is happening today, then I might agree that it's "interesting to speculate". But much of what I see is speculation used to justify FUD like "10 years later we still don't have our apple pie" and "We'd have Perl running on the JVM by now", i.e., statements that I find to be totally unsupported or contradicted by the available evidence.