A lot of posts have been cropping up recently about Perl 6 and the common thread seems to be "It's taking soooooooo long!" I'd like to explain, as a sometime contributor, why I think the process is taking so bloody long. In no particular order ...
- There's two projects - the Perl 6 language and the Parrot VM. The more ambitious project, in terms of implementation, has always been Parrot. It's been almost 6 years since Dan started it and it will probably be another 2-3 years before I would build something on top of it.
It's taking so long because you only get two of "Fast, Good, Cheap". Since anything associated with Perl has to be Good, it's a Fast-Cheap scale. There's about 10 developers, nearly all of which are volunteer, with another 20-30 testers. To me, that's high on the Cheap factor, which means that things are going to be very slow. You're more than welcome to help fix that. I'm sure that Parrot would be avaible in 6 months if all the developers were able to work on Parrot as their fulltime job. All you need to do is pay them. IMHO, all the developers are worth at least US$100/hr.
- But, that doesn't explain what's taking an average of 250 development hours/week for 9 years. (For the math-impaired, that's 7500 development hours/year, or 67_500 development hours total.) Well, here's a partial high-level list of the requirements on Parrot (in no particular order):
- Fast
- Reliable
- Runs on every OS known to man
- As parsimonious with RAM as possible
- Unicode aware
- Handles continutations and coroutines and treats functions as first-class data
- Is threaded
- Is garbage-collected
I don't know about you, but that's a very tall order. In comparison, the Java VM (which started 15 years ago and had 13 fulltime development staff for several years) only achieved half of those requirements after 10 years of development and use.
- Perl 6 isn't about fixing Perl 5's problems. Well, it is, but not within the Perl 5 framework.
The issue is that Perl 5 is too successful. P5 is over 10 years old, but Perl itself is not even 20. That should say something about how good Perl5 is. For something to replace that, it has to be seriously better. Like, radically better. Some of the features in Perl 6 I'm excited about (in no particular order):
- Lexical grammar changes
- Everything is an object, but only if I want to think of them that way
- This means code is an object that I can manipulate
- tie and overload both go away
- I can change both the syntax and semantics of the language within a lexical scope
- I have access to a real OO metamodel
That's some serious power! Don't worry if you don't understand the words ... just bask in the knowledge that CP6AN is going to seriously rock.
- Yet, with all that power, P6 will still provide all the scripty-doo and one-liner power that you've come to expect from P5. In fact, you will still be able to write pure P5 code within P6. Name another language that's completely and 100% backwards compatible after a major version upgrade.
- Perl6 is exploring some uncharted territory in terms of programming theory. The P6l mailing list happens to be very near the forefront of OO metamodels, roles/traits/mixins, parsing theory ... the list goes on. It's not like all the theory has been laid out and P6l just has to cherrypick the features it wants to add. P6l is creating some of the theory as it goes along! If that doesn't give you the warm fuzzies, I don't know what will.
In short, Perl 6 is taking so long because it has to. If it didn't, then it wouldn't be a worthy successor to Perl 5. You do want a worthy successor, don't you?
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
|
Re: Why Perl 6 is taking so !@#$ long
by tilly (Archbishop) on Feb 28, 2006 at 07:46 UTC
|
Please allow me to state a contrary view.
It is my personal belief that neither Perl 6 nor any other mainstream language will ever be based on Parrot. Parrot is likely to continue to be an interesting project in its own right, but it won't ever do what people are hoping for from it. This view finally crystallized for me last summer when I was at Sam Ruby's follow-up Piethon talk. Since then I've only heard confirmation.
Despite much work, Parrot still can't run the Piethon. Not even close. We like to talk about how Parrot will be optimized for dynamic languages, unlike the JVM and .NET. Yet there is a version of Python that runs on the JVM and passes the Piethon. There is a version that runs on .NET and passes all tests but one of the Piethon. (The failing test is the number of comparisons that a sort does.) But Parrot doesn't have one.
Worse yet, according to Sam there is no good way to do it! The problem is that the Piethon heavily exercises Python's meta-model, so it really smokes out hidden assumptions about how Python is internally structured. Assumptions that are in direct conflict with how Parrot thinks Python should be structured. So you either have to alter how Parrot is designed, or else you need to write an interpreter in Parrot and run Python on that - losing all of the speed advantages that Parrot was supposed to give you. (In fact you're inevitably going to be a lot slower.)
Sam indicated that with some changes Parrot could work well. But whenever he pointed out the necessary changes Leo would say "that's stupid", Dan would avoid the argument with Leo, and nobody else would say anything. Which indicates that the technical problems reflect people problems. Which is bad because technical problems are easier to fix than people problems.
OK, now Dan is gone. But as Dan pointed out, he left in large part because of Leo. Well Sam left before him for the same reason. And Sam is a big loss. If you're writing a project like Parrot then you want people who have lots of experience in implementing interpreted languages on top of virtual machines. You also want someone who has been heavily involved in the core of multiple languages. It would be nice to have someone who has served on multiple standards organizations, and therefore has experience in sorting out competing technical needs. Sam has done all of those things. AFAIK, Leo has done none.
Therefore my belief is that Parrot will not be used for running any widely used high-level languages.
Now I'm sure that I will be criticized for saying this. "Bitch, bitch, bitch. Can't you do something better than complain?" "If you think it needs help, why don't you contribute?" etc. So let me respond to that in advance.
First of all what I am saying is not just a complaint. I am stating a measured negative opinion on the likelyhood of a project succeeding. I am showing the reasons for that opinion. Saying that people are not allowed to have and express such opinions is tatamount to saying that people are only allowed to listen to one side of the story.
Secondly the problems that I'm talking about are not ones which I feel that my personal contribution can affect one way or the other. They are intrinsic to the core people and design of the project. Unless I am willing to become one of those people and change that design, I can't affect that. And I'm not willing to do that because I lack background, time, and energy for the task. Contributing to a project that I feel is going to fail regardless of my contribution is a waste of energy.
Thirdly I believe that my opinion is reasonably well-informed. OK, I have not exactly been an active participant in Parrot or Perl 6. But I have followed the project over the years. For instance I've read most of Dan's Squawks, seen Larry and Damian's pronouncements, gone to multiple talks by multiple people, read many weekly (or often fortnightly) summaries, donated money to the cause, and so on and so forth. I'm not a random moaner on slashdot.
Fourth, note that I've criticized Parrot, not Perl 6. That's because I believe that Perl 6 will happen. It won't hit all of its original goals, but thanks to Audrey there is an implementation coming along.
Fifth I have a strong impression that there is an unfortunate amount of groupthink about Perl 6. People have invested enough into the dream that they don't want to hear that it might not work. And they don't want other people to hear that because they fear that it will drive away potential contributers and become a self-fulfilling prophecy. That's understandable, but I don't have that investment. I see no reason not to call it as I see it. And the way that I see it is that people are being told to shut up unless they agree with certain opinions. And that offends me, not the least because I happen to hold some of the opinions that are not supposed to be expressed. | [reply] |
|
|
| [reply] |
|
|
What are those architectural voids? Have any of them been resolved in the time since this thread was posted?
| [reply] |
|
|
|
|
| |
|
|
|
A question, you say that you do not think Parrot will ever run a real-world language but then mainly go on to explain why this is the case for Python, and unless I've misunderstood the reason you give is that Parrot does not fit well with the internal Python workings. From what I've seen on the perl6 and parrot mailing lists (mind you, I only understand about 1/10th of what goes on there, so I may be wrong) development of Parrot is mainly directed towards serving as a VM for Perl 6. I know cross-language compatibility is one of the project goals and often expounded as one of the main selling points, but at the moment the project seems to be headed towards getting Perl 6 running first and worry about the others later.
Also (again, unless I'm misunderstanding something) Pugs is beginning to target Parrot as a backend, as is PGE, so some real work seems to be going on to establish Parrot as the working VM.
Do you think the plan of action of getting Perl 6 running first and then "fix" the VM towards suitability for other languages gradually is infeasible? Will it be stuck in too many ruts to ever serve as a general-purpose VM for dynamic languages? Personally I couldn't care less about Python running on Parrot, my main interest would be in Perl 6.
Or was your main point that you do not see Parrot ever evolving to a state of usefulness because of the people who are currently working on it and the personal politics involved (you've certainly not been the first to express that POV)?
| [reply]
[d/l] |
|
|
Personally I couldn't care less about Python running on Parrot, my main interest would be in Perl 6.
Actually, you do care. You just don't know you care. The biggest selling point about Parrot and the reason TPF has been funding Parrot development on and off for over 5 years has been that you can have all the majors compile down to PIR. Once you do that, then you have interlanguage operability that is only really available in .Net.
Imagine this - you are about to write a new web application. You really like Ruby-on-Rails and ActiveRecord, but you really need to use a huge legacy library written in Perl5 for accessing some random crap. Normally, you'd look longingly over at Ruby, then whip out CGI::Application, Class::DBI, and get to work.
Now, imagine that you can use ROR, AR, and your legacy library. Plus, write some linkage code in Perl6. THAT is what Parrot's all about.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
|
|
|
|
There is much, much more that went into my opinion than I said here. A lot of it I can't say, because it is based on private and/or privileged conversations that it would be wrong to repeat.
Basically for me the Python episode was the final piece of many that convinced me that a project that I'd long wondered about, was going to fail.
Parrot is supposed to provide a common base for everything that you'd want in a high-level scripting language so that you could implement a bunch of them and make them transparently interoperable. Which meant that it was supposed to be designed to meet all of their needs. And Parrot is critical to the Perl 6 plans, because that interoperability between Perl 5 and Perl 6 is the upgrade path that people are supposed to use.
Python makes a pretty good litmus test for this goal. Python is exactly the kind of high-level language that is supposed to run well on Parrot. Python was half of the original inspiration for Parrot. Python actually has multiple implementations, so the people trying to implement that on Parrot have plenty of prior art to look at. You aren't going to get an easier realistic test case in its target domain of languages.
Well Parrot failed to do that. And it looks like it will never do that. Which doesn't bode well when you go to try to implement more difficult languages, like Perl 5 and Perl 6 on the same base.
And if you come back and point me at Ponie, I'll be willing to bet you $100 that there won't be a stable version of Ponie on Parrot before 2010. (I say 2010 because I have to collect my money sometime...) Perl 6 I won't bet on - Pugs can target virtually anything. Heck they even target JavaScript. In fact looking at http://pugs.blogs.com/pugs/ I just noticed the pX subproject, that targets Perl 5's VM. Get that working well, and you've just solved 90% of the reason for having something like Parrot. (Inline::* addresses the other 10% to my satisfaction.)
| [reply] |
|
|
| [reply] |
|
|
You summarized very well, so well that I better understand my own feelings about the subject: I browsed summaries on said lists, and your summary of summaries now makes things better structured.
One point I want to share my opinion though:
... note that I've criticized Parrot, not Perl 6. That's because I believe that Perl 6 will happen. It won't hit all of its original goals, but thanks to Audrey there is an implementation coming along.
Actually Autrijus stepped in very unexpected and interesting manner:
- He made an unbeleivable implementation of perl 6, and this made great boost of development. Many people became beleivers of perl6 and stepped into development. Every person can receive committer bit.
- Many people looked seriously on Haskell.
Now there are much less stupid claimings about Python being useless only because it is whitespace-dependant (Haskell is whitespace-dependant but very serious language)
- Pugs, while quite brilliant implementation, supports and depends on parrot. I think this is more of political decision other than technical. This way more parrot people became involved in Pugs and no disappointed in parrot people.
Before Pugs and after pugs are very different volume of efforts spent on Perl6, so actually Pugs awakened perl6 and parrot, because now people see direction.
sorry for English
Best regards,
Courage, the Cowardly Dog
| [reply] |
|
|
Pugs, while quite brilliant implementation, supports and depends on parrot I don't think that pugs depends on parrot in any way. Sure, if you want to use PGE (which is written in PIR), then you need a working parrot somewhere. But that's just a small part of what you get from pugs.
Besides, now that there's a prototype implementation of PGE, who's to say that someone won't recreate it using Parsec? (In fact, I believe Audrey has already started doing this) Just because some small part of pugs uses parrot doesn't mean that that part can't be swapped out with a non-parrot version at any time.
The real question is: Will we get a workable perl6 compiler out of all this? :-)
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
|
|
|
|
| |
|
Perl6 can be written in Haskell as there are already compilers for almost every OS out there.
Check out the current implementations.
Though I have to point out that Pugs currently depends on the cutting edge Glasgow Haskell Compiler (GHC) for some features but most of these will be incorporated into the new Haskell-Prime standard and therefore propagated to all implementations.
Anyways, one of the goals of Perl6 is to be self-hosting. Check out this Pugs overview.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
Do you have any idea how often people set out to create new languages?
Most never complete them. (Though Roger Browne is putting enough energy in that I wouldn't bet against his completing this one.)
The vast majority of those do not become widely used That's a much harder barrier.
Let's examine his value proposition for a second. He is aiming for people who want to use a high-level scripting language centered around design by contract and would like to interoperate with the Parrot versions of Ruby, Perl and Python. That means that his success depends on there being workable Parrot versions of Ruby, Perl and Python. I've already talked about why I don't see Parrot developing a version of Python any time soon. From what I've heard, the Ruby community is singularly uninterested in Parrot. And I have good reason to believe that Ponie isn't going to be delivered in any reasonable time frame. Without Ponie, there is no impetus for anyone other than enthusiasts to be particularly interested in Perl 6 on Parrot. (Particularly not now that pugs is starting to target Perl 5 bytecode.)
So unless I'm wrong about one or more of the above, his project can't become popular unless someone comes up with an unexpected killer application for Parrot.
| [reply] |
Re: Why Perl 6 is taking so !@#$ long
by stvn (Monsignor) on Feb 28, 2006 at 04:00 UTC
|
I couldn't agree more with all your points, especially your first one:
There's two projects - the Perl 6 language and the Parrot VM. The more ambitious project, in terms of implementation, has always been Parrot.
This is exactly why i think the Pugs project is so important, because it decouples these two projects from one another. It makes no sense for Perl 6 (the language) to have to wait until Parrot (the VM) is done before it can be implemented. These two tasks are natural canidates for parallelization in my mind, and IMHO the Pugs project is doing exactly that.
| [reply] |
Re: Why Perl 6 is taking so !@#$ long
by brian_d_foy (Abbot) on Feb 28, 2006 at 02:53 UTC
|
I also tell people that a lot of the core developers are still making sure Perl 5 works. It's not like everyone has gone off to work on Perl 6. If they did, Perl 5 bugs wouldn't get fixed, and we don't want that situation. :)
| [reply] |
Re: Why Perl 6 is taking so !@#$ long
by japhy (Canon) on Feb 28, 2006 at 04:48 UTC
|
But will Duke Nukem Forever be written in Perl 6? This, I believe, is the big question.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
Re: Why Perl 6 is taking so !@#$ long
by Scott7477 (Chaplain) on Feb 28, 2006 at 05:48 UTC
|
Given the number of developers it shouldn't be a surprise to anyone that it's taking a while. Personally, I favor good and cheap over fast.
It's not like other languages are going to wipe out Perl in a hurry, anyway. The C language has been around for about 30(?) years and BASIC in all its forms at least 25 years.
I'm willing to wait for Perl6 and Parrot to meet the design requirements because once it is done it is likely to be around for thirty years or more.
Your manhour calculation comes out to 25 hours a week for each of those 10 developers,
which means they are each putting in a significant chunk of their non-work time into this.
So they deserve kudos instead of brickbats.
| [reply] |
|
|
The C language has been around for about 30(?) years and BASIC in all its forms at least 25 years
Basic is nearly twice as old as that. It was written by
Kemeny and Kurtz at Dartmouth University in the early 1960s. On the subject of Basic, in case people haven't seen it yet, Audrey Tang's Visual Basic Rocks talk is a required read.
• another intruder with the mooring in the heart of the Perl
| [reply] |
Re: Why Perl 6 is taking so !@#$ long
by ambrus (Abbot) on Feb 28, 2006 at 11:45 UTC
|
Name another language that's completely and 100% backwards compatible after a major version upgrade.
Look. C++ is quite compatible with C89 in the sense that most C89 programs you could think of would compile in C++ and produce identical behaiviour. It's not "completely and 100% backwards compatible", but I think it's at least as compatible as perl6 would be with perl5 (I'd bet this even on this stage of p6).
Also C99 is quite compatible with C89. (On the other hand, C89 is not that compatible with original K&R C, nor is C++ compatible with C99.)
| [reply]
[d/l] |
Re: Why Perl 6 is taking so !@#$ long
by spiritway (Vicar) on Feb 28, 2006 at 04:54 UTC
|
Well said, dragonchild. You're being very reasonable and patient. I think that we really have no right to complain about the time, unless we're also willing to *do* something about it - to help out in some way. I'm content to wait. If I want to hurry it along, I can do my bit to contribute something - even if it's only cash, not patches.
OTOH, this better be worth the wait ;-P
| [reply] |
Re: Why Perl 6 is taking so !@#$ long
by shotgunefx (Parson) on Feb 28, 2006 at 06:53 UTC
|
| [reply] |
|
|
| [reply] |
|
|
No. I dont believe that to be the case. In fact Ive seen it stated quite clearly on p5p that this was a misinterpretation of something Larry said once and that it has never been true. Perl 5.10 is going to be Perl5, theres no intention of making Perl 5.10 anything more than a better Perl5. Perl 5.10 may have some Perl6ish features, and it probably wont introduce any new features that directly contradict Perl6, but its Perl5.
What people are doing on Perl 5.9.x is to make a better, smaller, faster, more efficient, more convenient Perl5, which is actually in my mind a direct threat to the Perl6 project. The better Perl5 gets the higher the bar will be for Perl6. In fact I suspect that unless Perl6 represents serious advantages over Perl5 for the Perl5 feature set that Perl5 will never be replaced by Perl6. Instead I expect that what we will see is a bifurcation, with both continuing on to have long lives but for two mostly different user communities. (And IMO we are already seeing this bifurcation occur with Pugs).
---
$world=~s/war/peace/g
| [reply] |
|
|
|
|
| [reply] |
|
|
|
|
|
Re: Why Perl 6 is taking so !@#$ long
by syphilis (Archbishop) on Feb 28, 2006 at 09:44 UTC
|
In short, Perl 6 is taking so long because it has to. If it didn't, then it wouldn't be a worthy successor to Perl 5. You do want a worthy successor, don't you?
Never sure how to answer a question that's phrased in the negative ... especially when it's a rhetorical question ... and when it's preceded by a positive assertion.
If I said "yes", would that mean that I do want a worthy successor, or that I don't want a worthy successor ?
In short, I'm personally comfortable with Perl 5 ... and it does everything I want it to ... the longer Perl 6 takes, the better.
Cheers,
Rob | [reply] |
Re: Why Perl 6 is taking so !@#$ long
by blackstarr (Friar) on Feb 28, 2006 at 14:01 UTC
|
dragonchild++
Thank you for a clear look at the issues. Reading what you say about what is going into P6 makes me lick my lips in anticipation! Anything that good is well worth waiting for.
Hats off to all the good guys/gals doing the hard brain-bending for us lesser mortals.
| [reply] |
|
|
