Slashdot Mirror
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."
Got my hopes up! I thought you meant John Cleese and Terry Gilliam had new work at Sun...
Ask not what you can do for your country. Ask what your country did to you
Ask not what you can do for your country. Ask what your country did to you
Yes, and Microsofts strong focus on multiple languages from the onset also gives the CLR/DLR some clear advantages over the JVM.
The CLR was built around a the notion of a Common Type System (CTS) which means that different languages can share actual objects without having to wrap them. Wrapping cost performance (wrapping and unwrapping when passing between languages). But wrapping is also inherently language-pair oriented, i.e. between 2 pairs of languages such as Java and Jython. Other dynamic language cannot inherently use Jython objects but must also wrap the "canonical" java objects. It is not that it is impossible to achieve on the JVM platform, it's just that Microsoft has a much more mature VM and type system for this kind of job.
Take Java generics. The JVM type system have no notion of "template" or "generics", hence the generics in Java are implemented through the dreaded type erasure. But that means that no other language (e.g. Scala) can share generic types with Java. Contrast that with the CLR where generics are 1st class type citizens, both in their generic form and when all type parameters has been fully bound.
Interestingly, the CLR/CTS seems to have been developed seperately from (but coordinated with) C#. The CLR type system can actually represent types which you cannot describe using C# or VB.NET. The CTS is "bigger" and more generalized if you will. The Java VM was always just aimed at serving the Java bytecode. This is something that is going to haunt the JVM now when they are going all multi-language and dynamic.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Wrong.
Tcl biggest selling point now is the packaging and deployement.
I've written apps in a lot of languages, and deployed them all. Absolutely nothing beats Tcl for cross platform deployments. I got a starkit for ppc405, wrote my app on x86. A simple script packaged it all up in less than 2Mb.
Another few lines, and I had a win32, linux and ppc405 single file executable(for each) ready to go.
We also use java, which requires a separate 20Mb JRE install, whether its in your distro or not, you still need it, and the right version. Oh and Java 1.5 and Java 1.6 jar classes are incompatible, HAHA. And how many of you out there have a JRE for ppc405 (not a Mac, but a older series used in embedded systems)? Tcl is deployed on far more architectures.
The 8.4 and later versions are very fast and lightweight.
Making a gui in Tk is fine and simple, and well, you're gonna make a gui in Tk if you use Perl, Python, Ruby anyway.
All those other tools could learn from the Tcl packaging design.
They Live, We Sleep
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.
.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.
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
Jilles