Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Now comes the hard part: convincing the Perl, Python, Ruby, Lua, and other language developers to use it for their runtimes.
A look at Parrot 1.0
Posted Mar 26, 2009 17:23 UTC (Thu) by elanthis (guest, #6227)
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)
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.
Posted Apr 5, 2009 12:15 UTC (Sun) by dlang (✭ supporter ✭, #313)
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)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds