Sun Hires Two Key Python Developers 173
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."
Inevitable, and very welcome (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:4, Insightful)
Re:I'm glad he didn't (Score:2, Insightful)
Re:Nothing New... 12 years later (Score:5, Insightful)
Re:Mod parent up (Score:5, Insightful)
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 (Score:3, Insightful)
Yep. But are there arguments for or against other than "Lisp did it"?
Re:Mod parent up (Score:5, Insightful)
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/ [kano.net]
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:What happened to Tcl? (Score:4, Insightful)
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? (Score:2, Insightful)
Re:I'm glad he didn't (Score:1, Insightful)
Re:too little too late (Score:3, Insightful)
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.