Re^2: Why Perl 6 is taking so !@#$ long

[tirwhan]

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

[dragonchild]

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.

[tirwhan]

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?

[tilly]

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

[Elian]

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.