Slashdot Mirror
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."
Within the Python community, interest in Parrot seems completely dead.
Generic VMs are so 2005, the future of Python runtime is PyPy. From a single implementation of Python (written in Python), they can compile Python code to C, JVM, automatically create a customizable JITed VM, etc...
Check them out: they are doing some seriously cool stuff and they can use a bit of help.
There's a hidden treasure in Python 3.x: __prepare__()
Ian Piumarta and the VPRI [http://vpri.org] are doing some amazing work related to this story.
COLAs: Combined Object Lambda Architectures - A Complete System in 20,000 Lines of Code.
http://piumarta.com/software/cola
The system is slowly evolving towards version 1.0 which
* is completely self-describing (from the metal, or even FPGA gates, up) exposing all aspects of its implementation for inspection and incremental modification;
* treats state and behaviour as orthogonal but mutually-completing descriptions of computation;
* treats static and dynamic compilation as two extremes of a continuum;
* treats static and dynamic typing as two extremes of a continuum; and
* late-binds absolutely everything: programming (parsing through codegen to runtime and ABI), applications (libraries, communications facilities), interaction (graphics frameworks, rendering algorithms), and so on.
http://piumarta.com/papers/colas-whitepaper.pdf
http://piumarta.com/papers/EE380-2007-slides.pdf
http://piumarta.com/pepsi/objmodel.pdf
http://www.vpri.org/html/work/NSFproposal.pdf
Allen Wirfs-Brock and Dan Ingalls are currently working on bringing notions like Colas to the browser so that we can use any programming language WE choose to for our browser based applications. Check out their interview here.
http://channel9.msdn.com/posts/Charles/Dan-Ingalls-and-Allen-Wirfs-Brock-On-Smalltalk-Lively-Kernel-Javascript-and-Programming-the-Inter/
My first thought on reading this was an old software engineering maxim, usually (and probably correctly) attributed to Don Knuth:
Universal VMs are old as the hills (anyone [else] here old enough to have programmed on the UCSD p-System?). We shift towards VMs to gain independence and portability, and then we shift back to direct, spot or JIT compilation to improve performance. It's an old, old dance, and one that will likely go on for years to come. ..bruce..
Bruce F. Webster (brucefwebster.com)
Wasn't platform independence the selling point of UCSD's p-system? Yes, it worked, but it never really caught on. One camp of software development says that hardware is always getting faster, cheaper and more efficient, so adding a layer of abstraction between the source code and the hardware is not a problem. The other camp says we can use those same performance improvements to build software that does more things, on larger data sets, with better graphics, and in general make what once were impractically large and complex software tasks run on the average users' systems. Over the last three decades, the market has favored the latter.
you have to bear in mind that scripting languages, in order to be _reasonably_ efficient, have to do intermediate byte code _anyway_.
python uses a FORTH-like intermediate byte code, for example. the similarity to CLR will be pretty high.
when you come to things like V8, that does on-the-fly _compilation_ which is basically the same thing as intermediate byte code, only a bit more extreme and aggressive.
so the technology is beginning to move in the direction of "grey area" - thinning the distinctions.
i like the idea of using javascript as the VM intermediate language.
what's really neat about using javascript is that people have been optimising the hell out of it for a loooong time.
so, pyv8 demonstrated an empirical result of running python TEN times faster than the standard compiler does, by translating the python into javascript and then V8 compiling it to i386 assembler on-the-fly.
that's _very_ cool.
Except if your organisation works in Java they probably want their Java developers to be able to modify and extend your code... so having it written in a language they've never seen before, even if it's binary-compatible with Java, probably isn't what they want. I'm a huge fan of developing code in solving problems in the language that's most appropriate but this just breaks down when not all programmers have the same level of experience / fexibility
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
I think they'd like to bring that convenience to a 'higher' level. I make my living writing ActionScript and JavaScript and I felt like a jerk when I read a book recently that described C as a 'high-level' language.
Most of what I write everyday has problems between browsers on the same operating system. The flexibility you describe would be a joy for me.
Thanks mate, you're doing a great job. I downloaded Parrot and gave it a go. Perl6 is looking good. But, Parrot tells me that Larry got one of his perl6 programs wrong. If you look at Apocalypse 12, Larry has this:
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. Later in the example program, Larry wrote this:
The first line is illegal, because you can't change the read-only value of x. But the second line calls clear(), which tries to change the value of x. At this point, Parrot barfs with: "Cannot assign to readonly variable current instr.: 'parrot;Point;clear' pc 609 (EVAL_13:181)" and then lots more barf. So is this correct? If you make an object attribute which is rw, you can change it either in a method or by calling $object.attrname(42) for example, but if it's not rw, you can't change it ever, even in a method.
Is Apocalypse 12 wrong when it has a method that changes a non-rw attribute? Or is the compiler wrong in not letting the method change the attribute? I think Apocalypse 12 is wrong, because since rw means read-write, the lack of rw should be read-only. And read-only is not the same as private, so a method should not be able to change a read-only attribute.
Anyway, that's the answer to "Will we ever see Parrot?". You can see it right now. Or wait until Tuesday like chromatic says.
The move towards VMs is going to make programming easier. Everybody saw what happened with Java and write once, run anywhere. It didn't quite work out, but it was pretty close. If we can have perl code being compiled into bytecode, that'll give us speed improvements comparable to switching from CGI to mod_perl or FastCGI. Since so many people talk about the speed of running code, that's important.
If the same VM can run code from different languages, that's going to produce some very interesting effects. Why have a language flamewar when the VM can run any language? Instead of endless flaming, we can encourage people to use whichever language they like to write their code, then get the VM to do the dirty work.
In the article, it says that in the future, operating systems might ship with a generic VM that can run code from any language. This is a great idea, when you link it with the idea of high-level-language VMs. The more code you write, the more bugs you get. High level languages let you do the same thing with less code. Less code means less bugs.
Imagine what we can achieve when we have VMs available to run pure functional code, and you link that with the advances in storage technology. Since a pure function returns the same result given the same parameters, we can create something like rainbow tables to cache the function results. This is going to be so much better than calling malloc and free and using pointers.