Sun Hires Two Key Python Developers

sspringer writes to let us know about Sun's continuing push to support scripting languages other than Java on its Java virtual machine. Sun just hired two key Python developers: Ted Leung, a long-time Python developer at the Open Source Applications Foundation, and Frank Wierzbicki, who is lead implementer of the Jython project. They will both work on Jython, which enables Python to run on the JVM. Last month Sun's CEO said the company wants to "take the J off the JVM and just make it a VM."

Comments

Inevitable, and very welcome

[kripkenstein]

The only innovation that I credit to Microsoft in all its decades of existence is that of the CLR (.NET) being focused on language-independence, and also on Microsoft pushing hard for projects like IronPython to run well. There is really no reason to have to write language bindings all the time; a library written in one language should be accessible to all others. In the long run, this is going to make whatever platform allows that capability far more competitive. Therefore Sun has no option but to go in this direction, especially given the popularity of dynamic languages in recent years.

Actually FOSS might have done language-interoperation in other ways: given that the source code is available, we might have had automated tools to generate bindings automatically (actually this is happening now, with GObject-introspection, which is relevant so far to C, Vala and Python). But this hasn't happened in an extremely useful way thus far.

Note that this is just one reason for having a single VM for all languages. Security, optimization, etc. are others. In summary, kudos to Sun. Better late than never.

A niggle re:Inevitable, and very welcome

[davecb]

Note that this is just one reason for having a single VM for all languages. Security, optimization, etc. are others.

Actually, I'd like to see multiple implementations of a class of (J)VMs, in addition to kripkenstein's point about mutiple languages targeting it/them. This would lead to a rapid shake-out of bugs and disfeatures.

--dave

Mod parent up

[Viol8]

Indeed. The craze for virtualising runtime code has got way out of hand. Its fine if you want binaries to run unmodified cross platform , but it makes no sense whatsoever for anything else. These days people use Java because of the language and the libraries itself, not the JVM. In fact most java developers I know would be quite happy never to see the JVM again and just use a standard compiler , never mind JIT. I certainly don't understand the reason for using a runtime VM to run executables when a standard binary would suffice , which means I simply don't see the point of .NET either.

Re:Mod parent up

[A beautiful mind]

Your post is missing the point.

What you refer to as standard binary is just code that can be made to run on the computer directly, because the CPU understands the commands, etc. A VM is the next evolutionary step in the process, because you determine what's the best assembly/native code on runtime, on the fly, instead of static source code inspection.

This means not only more portable code, but overall faster than compiled execution speeds for programs. So far the VMs have been under performing, but they are improving and at a faster rate than gcc and friends.

So yeah, there is more to it than just platform independence.

Re:Mod parent up

[AKAImBatman]

But if its on a static machine architecture why bother?

Because there's no such thing? The performance paths of a PIV, Core Duo, Xeon, and AMD64 are all different. Should we continue compiling code for the lowest common denominator and just accept that our code isn't performing as well as it could?

And what of runtime optimizations? If the VM detects that this collection only contains objects of type X, it can do away with the casting checks on that collection. Yet if it detects an object of type Y added to the collection, it can undo the optimization on the fly. Statically compiled code can't do that. At best it can provide alternate code paths under certain conditions. Of course, additional code paths massively bloat the executables.

The JVM does these sorts of optimizations today, and thus has unparalleled performance when working with OOP code. That's why all these benchmarks show the JVM kicking ass and taking names later:

http://www.kano.net/javabench/

A C compiler can still outperform a JVM under ideal conditions, but ideal conditions are becoming more scarce for C compilers. In real-world terms, the JVM is going to be able to run your average Java code far faster than your average C/C++ code.

This idea that native code is always faster than virtualized code is a myth, and an old one at that. You need to get with the times or you'll find yourself a dinosaur. (And you don't really want to be brushing up on your "Get off my lawn!" speech yet, do you? ;-))

Re:Nothing New... 12 years later

[Headius]

It's difficult, but it's certainly not impossible. And we're working to make it easier by exposing the JVM's underpinnings. You see, the JVM is already a dynamic language VM; it just has this cumbersome static-typing wrapped around it.

Re:What happened to Tcl?

[MenTaLguY]

I was a heavy TCL programmer back in those days, and built some fairly serious software in it (and still maintain one package to this day). Honestly, looking back, I'm glad TCL didn't win. It's a horrible language.

Absurdly minimal, yes. But it's possible to be too minimal. upvar+uplevel in place of pass-by-reference? Unstructured strings as the fundamental representation for everything? The inability to parse the language without simultaneously interpreting it? I'm sorry, but after a decade of experience I think I can say it's just awful. It's like a Scheme dialect from the planet Htrae.