4 ms·
It's usually one or more of: 1. Using a simple prototype VM seemed easier during initial development 2. When the language was developed, no suitable common VM
by etal 17y ago
It's usually one or more of:
1. Using a simple prototype VM seemed easier during initial development
2. When the language was developed, no suitable common VM existed
3. The language developers thought they could do it better for their specific case, i.e. the point of the implementation is to showcase new VM strategies
Remember that a language and an interpreter are separate things, and usually an author who wants to try an idea for one has to find some suitable stand-in for the other in order to get started.
- johnnybgoode 17y agoThanks. Your #1 and #2 seem to be very common. It looks like we're at a point now where many dynamic languages are attempting to transition to a more advanced VM. This includes Perl, Python, Ruby, and some implementations of JavaScript. I assume they all want to take advantage of the latest VM techniques, and they're all making major changes anyway, so again I just wonder why they don't seriously consider collaborating now.
- etal 17y agoI think it's interesting how the success of projects like this sometimes seems to depend completely on a single person having the right combination of interest and skill. The Jython project was just the coolest darn thing until, from what I can tell, the lead developer got tired of maintaining a mature project with a hairy codebase and left to join (start?) PyPy, an even more ambitious project. So Jython was stuck in a coma with a pre-alpha 2.2 release for like half a decade, while CPython marched on, and no new maintainer was able to bring it back to consciousness -- despite huge demand for it, since Jython at the time was the perfect solution to problems in Java and Python. Finally Frank Wierzbicki came along a couple years ago, squeezed out the stubborn 2.2 release and is on the verge of version 2.5, at which point we can consider Jython back open for business. There's a kind of similar story with Psyco, and I think that one also concludes with PyPy being the "right answer" to the original problem. But back on topic -- in some ways, the dynamic-language communities are collaborating on common VMs. The JVM team is trying to make things easier for other languages with "invokedynamic", the .NET world is keeping up at least (DLR? dunno), and LLVM has good traction as a compilation target. However, I doubt we'll see anyone devote significant effort to porting Python or Ruby to Parrot until Perl 6 lands and provides a compelling demonstration. Meanwhile, PyPy is getting close enough to its goal that we might just want to wait and see if their JIT-compiler-generator solves all of these problems in one shot.
- johnnybgoode 17y agoGood info, thanks. I think you're right about Perl 6 needing to be finished first. It's too bad, because it looks like some opportunities might be missed by then.