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

[Just Some Guy]

And that's what lisp was doing about 25 years ago.

Yep. But are there arguments for or against other than "Lisp did it"?

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:I'm glad he didn't

[Ed Avis]

The syntax is not confused: quite the opposite. It is consistent and very minimal. One command per line, lists separated by spaces, "" quotes with variable interpolation, {} quotes without interpolation, [] to call a function, $ gets the value of a variable, and that's pretty much it.

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.

Re:What happened to Tcl?

[Ed Avis]

Honestly, looking back, I'm glad TCL didn't win. It's a horrible language.

Why you should not use Tcl

upvar+uplevel in place of pass-by-reference?

Indeed, you feel you need a bath after using upvar. But plenty of other languages lack proper references; Python for example (though it can kind of emulate them with the Ref container). (Python programmers at this point will retort that it does have references, indeed every variable is a reference. In which case you move the discussion one level up and the question becomes: why no references to (mutable) references?)

Unstructured strings as the fundamental representation for everything?

Everything runs on your computer using memory, which is a big long string of bytes. Ultimately, an unstructured string is the fundamental representation for all data in all languages. What matters is the tools the language provides to let you manipulate the data in that string.

The inability to parse the language without simultaneously interpreting it?

Perl also suffers from this problem.

I'm sorry, but after a decade of experience I think I can say it's just awful.

I can't argue with that. But at least it sucks in interesting and playful ways.

Re:I'm glad he didn't

[Anonymous Coward]

IMO the only reason it was ever popular was because Tk was a very advanced GUI toolkit for its day...

There's also expect (which was based on tcl)...basically the best friend any sysadmin capable of hacking together a quick script could ever have. That was the only reason I ever learned tcl.

Re:too little too late

[Headius]

With two devs, perhaps not. But there's far more than two devs working on Jython, and they've made great progress this past year. Plus I'm going to do what I can to help them reuse work we've done on JRuby, so they can focus more on compatibility and Python features they're missing.

The reason Sun hiring Frank is important is because it provides a full-time developer to help anchor the OSS work that's already happening on Jython. And that's the right way to do things, since it's the community members that make projects like Jython work.

It's unfortunate that you won't be one of those community members, but it sounds like you've got what you need already. I hope you'll consider helping out if the JVM or Jython again become attractive options for you.