On Thu, Feb 21, 2008 at 01:29:05PM +0100, Juerd Waalboer wrote: : Then backtracking would happen, or more likely: Perl 6 would die. If : this community cannot come up with a virtual machine that can handle : Perl 6, then many people will lose all hope.
Except that the people working on alternatives to parrot are already doing that exploration in parallel, and therefore would have no change in attitude. When it comes to exploration, it doesn't really matter how many people lose hope--it only matters how many people keep hope. :) : But as indicated, this scenario is very unlikely. : : > Let's give some $$$ to say 3 implementations, see what they come up in : > a month. Lets mupltiply their 1/CPU-time with #of tests passed :), and : > the winner gets the rest of the money. : : I do not think a *contest* would be in the best interest of Perl 6. It's already a friendly competition. To the extent that it is perceived as a zero-sum game, we'd lose the friendliness, I fear. : > > And different implementations help to explore different part of the : > > specs. : : Yes, they help. But it's not necessary. I respectfully disagree with your definition of "necessary". :) : > > That also helps rakudo, if the specs are well covered by other : > > implementations and are therfore much stable and really : > > implementable. : : If something turns out to be un-implementable, they will find out : regardless of the existence of other implementations. However, I do have : a lot of faith in Larry Wall's language design skills, and think that : this is a very minor, even hypothetical issue. The trouble is, I have no visibility into the assumptions made in the parrot core that might cause problems later. And certainly the initial design of parrot was aimed more at a "faster Perl 5" than at Perl 6 as we know it now. My knowledge of implementability is primarily at a more abstract level, and cannot easily be brought to bear on any particular implementation. I was already told at the beginning of Perl 6 that nobody wanted my implementation skills. :) : > > If you argue that most people want an implemenation that covers : > > large parts of the specs, the most logical step would be to boost : > > pugs development. It's the most advanced implementation by far. And : > > I do believe that it can be sped up if you really want that. : : If sufficient people were fond of hacking on its Haskell guts, then : probably we wouldn't be having this conversation. But it appears that : most volunteers consider Pugs a very useful exploration project (that : would have been used for bootstrapping if development hadn't stalled), : but see Rakudo as the beginning of a feasible real world Perl 6 : implementation. Yes, as Wim pointed out, pugs really wasn't fast enough to be a real implementation, and the hope that supersmart Haskell optimizers would fix everything didn't really pan out, nor the hope that Perl programmers would flock to learning Haskell in droves. As a case in point, I have two programs that translate STD.pm to versions of Perl that can run on pugs and on Perl 5. The pugs compiler takes about 2 minutes to compile the results, and flakes out half the time for no apparent reason. The Perl 5 compiler takes about half a second, and blows up reproducably. :) : > > So where's that pro parrot bias coming from? : : It shows progress, and several well known, trusted and skilled hackers : work on it. As do other efforts. They're just differently skilled, differently well known, and differently trusted. Larry
