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

What happened to Tcl?

[Ed Avis]

John Ousterhout used to work for Sun and they had a golden opportunity to push Tcl a bit more and integrate it with Java... but they never did much with Tcl and he eventually left. It's a shame, because I rather liked Tcl with its absurdly minimal syntax.

wow; parrot has had an impact.

[WindBourne]

The only reason why Sun would hire them, now, is if they were concerned about parrot splitting the market.

Re:Inevitable, and very welcome

[Bogtha]

Actually, Python has been appearing on phones for quite a while, notably Nokia Series 60. I'm not sure, but it might also be possible to use Jython with J2ME devices.

A VM is just another PLATFORM!

[StCredZero]

A VM should just be treated as just another Platform! It's a virtual CPU, and instruction set architecture. Taking this further, a language and a set of libraries packaged with a VM should also be considered a Platform just as Windows XP or Ubuntu 7.10 is a Platform. This is precisely why Java version hell exists! You should not update platforms willy-nilly. You should not take a platform and bundle it with an application! If you are smart, you should either make everything supremely backwards compatible (Windows) or supremely upgradeable (Debian based Linux) or make a clean (and well organized) break that provides dramatic benefits (Mac OS X).

Sun didn't get it. Dot-Net got it because they were able to use hindsight to fill in the gaps where Sun didn't. The truth is, VMs and portable languages don't make operating systems irrelevant. They just (partially) virtualize the OS on top of the native one. The sooner VM language people realize this, and all of the pitfalls, the sooner things will get better! (Many already get things right. Python and Ruby seem to get this.)

Re:A VM is just another PLATFORM!

[jilles]

What Java version hell?! It's perfectly backwards compatible (binary and api, minor API bug fixes and deprecations aside). I've been developing on it since 1995 so I have some idea what I'm talking about. I think Java is probably one of the cleanest evolving platforms around (given the massive changes to it since 1995). Compare this to linux where binary compatibility is routinely broken for minor compiler version increments or libc updates. Compare this to C++ which didn't even have a widely endorsed spec until this millennium and continues to have many incompatible compilers (never mind the APIs, I'm just talking about the language semantics here). Arguably, C++ is still a mess.

I think you are also wrong about virtualization. The whole point of virtualization is to abstract away OS specifics to the point where it literally is nothing more than a commodity needed to run the vm. Who cares if it is mac, windows or linux running your php/Java/ruby server? If you are doing LAMP development, virtualization is what allows you to scale your new hot web application using Amazon provided service on demand stuff. Stuff like JRuby shows that virtualization can actually be fast and scalable too (it's basically kicking regular ruby's ass). Jython is basically going the same way.

Microsoft certainly had the right ideas with .Net. Their execution is less than perfect, however. Basically an old Java 1.4 hotspot VM still kicks the CLR's ass easily. In terms of scalability and performance there is really no contest between the two. Nevermind, later versions. However, the CLR design is interesting in some respects and some of the stuff MS has done on top of it is quite innovative. But the truth is that the Java platform is still a fine piece of engineering. Many controversial design decisions taken by Sun in the early nineties around this platform are now slowly being picked up elsewhere too. Basically modern compiler architectures like llvm bring stuff that Sun has been doing for years with Java to mainstream. The whole notion of garbage collection has basically displaced the notion of manually allocating memory (except in the most conservative environments). People do web development in environments that are much slower, crappier and less secure than Java (cough php cough) because development speed is so nice to have. In short pretty much everything Java is doing on the server side has been validated through others imitating with varying degrees of success.

Re:A VM is just another PLATFORM!

[rabtech]

What, you don't deal with classpaths, libs/JARs, and other associated bits? You've never installed an app that changed the classpath, pointing to new (and subtly incompatible) versions of a JAR, thus breaking things in an odd and impossible to diagnose way? Never had someone or something drop new files into Tomcat's shared lib directory that overrode you? Have you never had to dig through 14 layers of config files (vomited all over the filesystem in some sort of byzantine maze) to find out why something won't compile or run?

If you haven't then I suggest you climb down from your ivory tower and check out the real world sometime...

VMs won't be the panacea of performance

[microbox]

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.

I think the VMs are improving towards the speed of static compliation. Sure there are benefits such that we could potentially see faster VM code - but there's also layers and layers of cruft that comes about because of VM abstractions. I think projects like LLVM will eventually produce code faster than any VM, with architecture independence. The project is comparatively young, and I think it will have a bright future.

The JVM, and CLR kinda symbolise the heavy-weight approach of modern software design. A hello-world xaml application uses 40 megs of memory!

With per-core CPU speeds capping, I'd like to see a more cut-down approach to software development. A brand new computer might by 1000 times faster than a similar product 20 years ago, and it seems we write software that's 1000 times slower.

Re:too little too late

[BotnetZombie]

I can hear that you don't like Java very much. Don't really know what you mean by big legacy problems, generally I like working with it (2 last workplaces, 6 years). The biggest reasons are that you have some excellent IDEs, and a huge collection of libraries that take care of the grunt work for just about anything you want to do. The language is also easy to read/write coming from C++ (though of course Python is more pleasing in that regards). My biggest gripe with dry'n'cut Java is the lack of dynamic scripting - which has up to now been manageable with Jython, Groovy and the rest - it should only get better from now on.
I'm interested to know where your dislike for Java comes from?

Java Version Hell -- Hell Yeah!

[StCredZero]

Java Version Hell happens because different VMs and libraries can collide within the OS substrate. Having CLASSPATH as an environment variable encourages this. I am not sure what else contributes to this, but I have had more trouble (as a USER, not a programmer) with the installation of one JRE trashing a different Java application than anything else. Perl utilities I use aren't bothered by this. Nothing in Python I've used is. Why is this?