Generic VMs Key To Future of Coding

snydeq writes "Fatal Exception's Neil McAllister calls for generic VMs divorced from the syntactic details of specific languages in order to provide developers with some much-needed flexibility in the years ahead: 'Imagine being able to program in the language of your choice and then choose from any of several different underlying engines to execute your code, depending upon the needs of your application.' This 'next major stage in the evolution of programming' is already under way, he writes, citing Jim Hugunin's work with Python on the CLR, Microsoft's forthcoming Dynamic Language Runtime, Jython, Sun's Da Vinci Machine, and the long-delayed Perl/Python Parrot. And with modern JITs capable of outputting machine code almost as efficient as hand-coded C, the idea of running code through a truly generic VM may be yet another key factor that will shape the future of scripting."

Comments

Will we ever see Parrot?

[CRCulver]

I remember some years ago the elation people felt when Parrot was announced. At last, we could leverage the strengths of either Python or Perl--or whatever other interpreted languages--but work with a common interpreter. But then the hype started to die down, and the last edition of O'Reilly's book on the subject appeared over four years ago. Within the Python community, interest in Parrot seems completely dead. Are the Perl folks going it alone, and when might we see the project reach a successful deployment?

Re:Will we ever see Parrot?

[chromatic]

Patrick Michaud wrote a bare-bones Python implementation in eight hours. It doesn't support all of Python, but it supports a large amount -- and, to my knowledge, he'd never implemented a Python compiler or interpreter before. That project, Pynie, has languished for a while, as he's spending more time working on Rakudo (the Perl 6 implementation on Parrot), but it's a viable port just waiting for someone to work on it. Lua is functionally complete as of 5.1 (I believe), and Tcl, PHP, and Ruby are in progress.

You can play with the latest versions of all of these languages on Tuesday, 21 October, when we make our next monthly stable release (though partcl just moved to a separate repository, so you can check out the current version there on a different schedule).

Re:Will we ever see Parrot?

[chromatic]

Note that x is read-only, and y is read-write. I assume that if you don't put rw after an attribute, it's read-only. Otherwise, there's not much point having rw.

That's true, but note that the rw attribute only applies to the accessor method. A12 says:

The traits of the generated method correspond directly to the traits on the variable.

Further, it says:

In any event, even without "is rw" the attribute variable is always writable within the class itself (unless you apply the trait is constant to it).

The idea's a little tricky at first, but those types of declarations (and the public/private attribute distinction you get with the use of twigils or has versus my govern the visibility and type of access only outside the class.)

LLVM plug

[Anonymous Coward]

article didn't include it, but this open source project seems to have similar goals

http://llvm.org/

Re:LLVM plug

[naasking]

I'm still very surprised how few people are aware of LLVM. It's a truly low-level hardware abstraction layer, on which you can implement any language. OCaml, Haskell and Python have bindings for it IIRC.

Wait, this sounds familliar!

[neokushan]

Sure this sounds quite a bit like something Microsoft, of all people, tried to create? That's right, I'm talking about .Net! Microsoft loved touting how you could develop .Net applications in C#, C++ or even good ol' VB and it should all work the same and even interoperate.
But it's .Net and I'm sure anyone with any experience knows that despite the supposed advantages, it has quite a few disadvantages as well. But at least it made VB somewhat useful again.

None the less, I wouldn't hold my breath on this one, sounds like a pipe dream to me and I'm sure some would argue - what's the point in running your code through a VM if you can just run it natively?

On a side note: As efficient as hand-coded C? In my experience, 90% of the time someone tries to write "efficient" C, they end up causing more problems than it's worth (early-optimisation and all that). Perhaps it should be reworded to say something like Hand-crafted C from a C Master".

Re:Wait, this sounds familliar!

[_jameshales]

There are some programming language implementations that "compile to C".

Re:Wait, this sounds familliar!

[Anonymous Coward]

I suggest you look up Scala and Jython.

Javascript - as a VM intermediate language(!)

[lkcl]

no don't laugh, it works very well! there are a number of very good reasons for this.

1) javascript is actually an incredibly powerful language, in particular due to the concept of "prototype"ing.

2) javascript, thanks to web browsers, has an unbelievably large amount of attention spent on it, to optimise the stuffing out of it. as a result, the latest incarnation to hit the streets - the V8 engine - actually compiles to i386 or ARM assembler.

3) the number of "-to-javascript" compilers is really quite staggering. see the comments from pyv8 article for an incomplete list.

GWT has a java-to-javascript compiler; Pyjamas has a python-to-javascript compiler. There's a ruby-to-javascript compiler - the list just goes on.

then there's the pypy compiler collection, which has javascript as a back-end. (and, for completeness, it's worth mentioning that it also has a CLR backend, LLVM.org backend, and a java backend).