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.

What are those architectural voids? Have any of them been resolved in the time since this thread was posted?

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.

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!

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)?

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:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

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?


All dogma is stupid.

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.)

The reasons that python didn't run on parrot weren't technical. This is a shame, because the technical issues are the easiest to fix.

The issues that caused python to not run on parrot are important, however, as they will potentially get in the way of other languages running on Parrot.

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.

sorry for English

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? :-)

duff

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 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?

Um ... who says perl6 can't be written in haskell? Who says that perl6 can't be bootstrapped into existence using pugs and then use perl6 to write the "real" compiler (maybe it emits C code or even <insert favorite language here> code).

duff

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:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

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.


All dogma is stupid.

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.

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.

They are already starting to appear, Amber

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.