| |||||||||||||
A look at Parrot 1.0A look at Parrot 1.0Posted Mar 26, 2009 5:45 UTC (Thu) by flewellyn (subscriber, #5047)Parent article: A look at Parrot 1.0
Great!
Now comes the hard part: convincing the Perl, Python, Ruby, Lua, and other language developers to use it for their runtimes.
(Log in to post comments)
A look at Parrot 1.0 Posted Mar 26, 2009 17:23 UTC (Thu) by elanthis (guest, #6227) [Link]
Lua will never use it. The entire Parrot design goes against the design goals of the Lua authors -- the entire point of using Lua is less about the actual grammar/syntax and all about its very tiny, very fast, very easy to wrap, ANSI-C runtime.
If you're going to use a massive, powerful runtime, you might as well use a more capable syntax with it.
To be honest, I don't really see the point of mixing 20 different languages in a project anyway. It's enough of a nightmare when you have to mix 2, because finding "multi-lingual" developers these days is not easy (sadly). Most of the languages out there are really so close as to be redundant anyway. One of the things people love about Ruby, for example, is that it can pretty much entirely replace Perl.
On top of that, there's the issue of the totally different "API design" issues. A class/object in Perl might be called foo::bar, in Python it might be Foo.Bar, and in Ruby it might be Gluger. The methods might be named print, Print, put, write, display, etc. You end up having 50 implementations of the same damn thing to do things "the Python way" or "the Ruby way" or "the Perl way." This in turn destroys the possibility of actually mixing components written in the different languages because the HTTP component in Perl might produce and consume totally different objects than what the Python HTTP components are using.
Fixing that issue essentially requires that all these languages end up using a single shared standard library. Which in turn means _completely_ breaking compatibility with application written for the original runtimes.
Parrot as a low-level VM and runtime may be useful. It gives language implementors a set of pre-written and ready-to-use code to get a high performance runtime.
All this talk of mixing languages and sharing components and getting everyone to switch so rainbows can start shooting out of our butts is complete nonsense.
Mixing Languages in a Project Posted Mar 26, 2009 18:11 UTC (Thu) by pkolloch (subscriber, #21709) [Link]
I agree that I would not by my own choice mix many languages in one project. I also agree that homogenizing naming conventions (so that the language transitions will be next to invisible) is probably not going to happen. Many language communities did not even achieve this kind of homogeneity in their own language ecosystem (e.g. C++).
Yet I strongly disagree that this is not a proper and important use case. Some special purpose libraries are just not written in your favorite language. Being able to integrate them easily is fantastic.
A look at Parrot 1.0 Posted Apr 5, 2009 12:15 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
all that it will take to accomplish that is to show that language X running on parrot is better (faster, less resources used, fewer bugs, etc)
if that is true you will see conversions (after they get over the NIH syndrome ;-)
for perl it will be a good check against the mainline (there isn't currently any second implementation of a language spec, so with only one implementation, the implementation is the spec)
|
|||||||||||||