|
in reply to Why Perl 6 is taking so !@#$ long
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. |
Re^2: Why Perl 6 is taking so !@#$ long
by BrowserUk (Patriarch) on Feb 28, 2006 at 12:50 UTC
|
Therefore my belief is that Parrot will not be used for running any widely used high-level languages.
Ditto.
Technically, there are distinct voids in the architecture of Parrot. Dan attempted to address these on several occasions with both discussion and mandate but was either dogged into submission by constant and ongoing counter-debate or just ignored.
| [reply] |
|
|
What are those architectural voids? Have any of them been resolved in the time since this thread was posted?
| [reply] |
|
|
I'm afraid I stopped following the progress of Parrot around the time of my post above, so I have no idea what has happened in the interim and cannot comment on what if anything has changed or improved.
As for what voids existed at that point in time, I would be hard pushed now to remember exactly what my concerns were. I do have a few references and emails from off-forum discussions I had at the time, but trying to rekindle my understanding of the issues now would be dificult. More to the point, most of the issues involved are a matter of history in the parrot forum archives and available to anyone with an interest.
There are also much better qualified people than I to analyse and summerise the debates that took place back then that convinced me that things were not headed in the right direction. And people who have continued to follow the project that will be better placed to discuse what if any course corrections have taken place.
Basically, "No comment".
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
What are those architectural voids? Have any of them been resolved in the time since this thread was posted?
Well, I've never followed parrot development, but in the meanwhile Dan left; well actually that was well before the post you're responding to was written: you can read his rant^Wconsiderations here, it's a nice and very interesting reading anyway. However I don't even know what those architectural voids are, nor does he who hinted at them, but to answer your question, a wild guess based upon reasonable assumptions may yield 'no' as an answer. But what is important is the beast is still actively worked on and regular snapshots of it are released. So it's a lively project. Have faith!
| [reply] |
|
|
|
|
| |
|
|
Re^2: Why Perl 6 is taking so !@#$ long
by tirwhan (Abbot) on Feb 28, 2006 at 15:35 UTC
|
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] |
|
|
Oh, I get the general usefulness of a cross-language VM, and the desirability of having "one VM to rule them all". But to me personally it doesn't matter so much that we get a practically working Python implementation on top of Parrot any time soon. I've looked at Python three times over the last years and hated it every time, so I can safely say I won't use it for programming ever ("ever" being the most dangerous and error-prone time-period to invoke in any statement of course ;-). Similarly, if I come across a Python app/library and a slightly inferior Perl counterpart I'll use the Perl version because if something goes wrong or I need to change it I can burrow in myself.
So while I understand that cross-language compatibility would be a very desirable thing for many people, I personally care more about Perl 6 being done. If we get a working Parrot which runs Perl 6 but only limps at Python I'd be happy and leave the people who are interested in Python to fix Parrot later (if that's possible).
And about .Net, isn't it true that it only offer interlanguage operability by turning every language into a heavily obfuscated version of C#? Does anyone actually use multiple languages in a single project on .Net? I know Jython has been around for ages, does anyone actually use it for serious work?
| [reply]
[d/l] |
|
|
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] |
Re^2: Why Perl 6 is taking so !@#$ long
by Courage (Parson) on Mar 02, 2006 at 15:33 UTC
|
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] |
Re^2: Why Perl 6 is taking so !@#$ long
by dragonchild (Archbishop) on Feb 28, 2006 at 15:00 UTC
|
I haven't been following P6C other than to scan the summaries. I certainly don't have the chops to understand even half of what's going on down in the trenches. So, if you're concerned about the future of Parrot, then I'll be concerned.
My question is this - Perl6 can't be written in Haskell. So, if it's not Parrot, who's going to write the P6 VM and in what?
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] |
|
|
| [reply] |
|
|
The requirement that says "Must run on every OS known to Man, and then some." Writing C that's that portable is hard, but I don't think I need to tell you that. One of the features I haven't mentioned is PGE, which is, essentially, the parser. Patrick Michaud is currently writing it in PIR. Who's going to write it in C? I don't know enough portable C to do so ... finding someone who knows enough, has the time, and is interested is going to be a ... challenge.
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] |
|
|
|
|
I think the main problem is that any VM written in a higher-level language will be too slow for practical use. That's why the Java VM and Mono are written in C (and .Net is written in C++?). The compiler doesn't matter so much, it's only involved once in the execution process and can be written in a higher-level language, but for the actual runtime you need to get as close to the metal as you can which means writing it in C.
| [reply]
[d/l] |
|
|
|
|
| |
|
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] |
Re^2: Why Perl 6 is taking so !@#$ long
by shotgunefx (Parson) on Feb 28, 2006 at 09:06 UTC
|
| [reply] |
Re^2: Why Perl 6 is taking so !@#$ long
by chromatic (Archbishop) on Feb 28, 2006 at 09:16 UTC
|
And the way that I see it is that people are being told to shut up unless they agree with certain opinions.
If you're talking about what I've written, then you've completely misunderstood my point and you're arguing against a strawman.
| [reply] |
Re^2: Why Perl 6 is taking so !@#$ long
by zentara (Cardinal) on Mar 01, 2006 at 12:05 UTC
|
Therefore my belief is that Parrot will not be used for running any widely used high-level languages.They are already starting to appear, Amber
I'm not really a human, but I play one on earth.
flash japh
| [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] |
|
|
