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."

I'm glad he didn't

[Viol8]

Tcl with its confused mixture of command line style shell script and C syntax made for a horrid language to both read and code in. IMO the only reason it was ever popular was because Tk was a very advanced GUI toolkit for its day but this isn't 1993 anymore, things have moved on and there are many better solutions

Re:What happened to Tcl?

[morgan_greywolf]

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.

Aside from a few niches (mostly, strangely enough, in the realm of scientific computing), Tcl never quite became very mainstream. Sure, it sits quietly on almost every Linux and BSD distro, and sure there are a few things here and there written Tcl or Tcl/Tk, and almost every seasoned Unix developer knows at least a bit of Tcl, the mainstream audience has been eaten by Python and Perl, for the most part. Probably something to do with that 'absurdly minimal syntax', though I guess that still doesn't explain Perl. ;)

Re:Let's take off the 'V' as well!

[Viol8]

Eh? What OS you using , DOS 3.2? Thats easily implemented using file permissions and access control. Well , on unix anyway, can't vouch for Windows. If you don't believe me try and strace a running process you don't have permissions for.

Re:I'm glad he didn't

[Viol8]

Perhaps confused was the wrong word. Hard to read would be a better way of putting it, of which the seperation by spaces was the prime cause. Also I remember it being extremely fussy about where you put the procedure delimiters though perhaps they changed that in later versions.

Um, not just Jython

[tbray]

Well, no, if you check Ted's blog [sauria.com], you'll see that he's going to be working on Python-in-general, not just Jython.

Re:Inevitable, and very welcome

[benjymouse]

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.

Re:Nothing New... 12 years later

[TheRaven64]

As someone who tried to get a Smalltalk compiler to target the JVM, I can say from experience that it is a really horrible design (and .NET copied all of the worst design decisions). The VM imposes so many constraints that it's really hard to implement anything that isn't semantically almost identical to Java on it without seriously compromising the speed. A far better approach is LLVM, which allows you to layer things like garbage collection and object models on top of a common VM.

Re:What happened to Tcl?

[Otter]

There was a time when Tcl/Tk was the least excruciating way of making a simple GUI application on Unix. Once decent toolkits (and, eventually, excellent toolkits) became available, Tcl's main selling point was lost.

Re:Let's take off the 'V' as well!

[CastrTroy]

It allows you to specify per-application permissions, without creating a new user for each application. So you can run something as yourself, from your browser, but give it no access to the file system. You could give an application access to the file system, but no access to the network. Running under a VM lets you have a lot more fine-tuned control over what the application can and can't do. It also does it in a way that's completely platform independant. So even if you are using DOS 3.2 (assuming the VM runs on that platform), then the permissions you set, will work.

Re:Inevitable, and very welcome

[Headius]

Generics are basically no help at all to dynamic languages, so I think that's a red herring. And in fact, it makes implementing interop with dynamic languages much more difficult, since it's an additional class of types you have to be able to deal with and recognize. Ask the IronPython and IronRuby guys about the syntax they've had to come up with to support manipulating generics from within Python or Ruby.

The only problem the JVM has, as far as I can see, is that it's got this whole "Java" thing wrapped around it. The JVM itself is much better suited to all sorts of languages, if only we can punch a hole through the Java exterior. And that's exactly what we're going to do, by adding dynamic invocation support in (hopefully) JDK7 and a host of other features like tail calls, tuples, value objects, continuations, and so on in OpenJDK subprojects like the Multi-Language VM.

If anything, the CLR is a much more difficult platform to develop dynamic languages for due to its strict static-typed nature. You have to do some really unpleasant tricks to get the CLR to run a dynamic language fast, and that costs a lot of development time and hassle. DLR hopes to make some of that happen across all languages, but at the end of the day the CLR is just not as advanced a VM as the JVM.

At any rate, it's going to be an interesting couple of years.

Re:too little too late

[Headius]

You're probably half right. I think it stems from a realization that Java doesn't have to be the only tool on the JVM. And to that end, we're working hard to improve the ecosystem for language development in a number of ways. Heck, some of the most interesting parts of JRuby aren't even written in Java anymore...they're generated programmatically. Java is just one way to create JVM bytecode. We need both better tools for creating bytecode for many languages, and a better way to make the JVM's dynamic underpinnings serve many languages. We're working on both.

Re:wow; parrot has had an impact.

[handmedowns]

Actually the reason Sun hired them is they've made a commitment to get Glassfish http://glassfish.dev.java.net/ [java.net] running other higher level languages besides Ruby. So now they've got some jruby developers and jython developers. They're really trying to push their appserver platform, and with the acquisition of MySQL, they have a complete stack under their roof (SunOneWeb, Glassfish, MySQL) not to mention, OpenDS, OpenSSO, Metro, among other things.

Sun is going after the ruby and python developers because they're diversifying. Sun's biggest software competitor is IBM which directly or indirectly controls all of its products and their dependencies.

Re:wow; parrot has had an impact.

[Otter]

Basically, Leung lost his job, posted [sauria.com] on his blog that he was looking, someone at Sun read it and they made him an offer. I don't think this whole thing is nearly as elaborately crafted a strategy as people are making out.

Re:What happened to Tcl?

[korbin_dallas]

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.

Re:Nothing New... 12 years later

[TheRaven64]

Exactly my point. Unless your type system and dispatch semantics closely match Java, you need trampoline objects which make everything horribly slow. The dynamic call primitives in the latest proposal go a long way towards this, but there is still not enough runtime type introspection for a lot of neat language features.

Re:Inevitable, and very welcome

[Anonymous Coward]

For the record, Scala interops with Java generics seamlessly in 2.7.0. Just because generics are implemented via erasure doesn't mean the compiler doesn't still insert marker symbols into the bytecode. In fact, without these it would be impossible even for Java to work with its own generic libraries.

Re:What happened to Tcl?

[Anonymous Coward]

Oh and Java 1.5 and Java 1.6 jar classes are incompatible

What kind of shit are you on? Jar is, and always has been a .zip file.

So you must mean .class files?

Now please tell me a platform that you take an app written for a new release, and use on an older release without special compiler commands telling it to use the old release, and avoiding all the new stuff. Ohh, wait that is just USING THE FUCKING OLD RELEASE.

No Java 5 shit does not work on Java 1.4. No Windows XP applications don't run on Windows 2000.
But Java 1.4 apps run fine on Java 5, and Java 6. Just like Windows 98 & 2000 apps run on XP. Unless the developer does something fucking retarded like use a private API.

JRE install, whether its in your distro or not, you still need it, and the right version

Did some stupid fuckwit use a private API, I bet they did. Only one thing has been deprecated and REMOVED from the API, that is System.getEnv. It was re-added in the Java 5 as Sun released they fucked up.

I'm not claiming that TCL does not have advantages over Java, such as its smaller runtime and the fact it has been ported all over the place, but please don't just make shit up when you want to bash Java. I know it is hard to bring out the "Java is slow" line anymore as no one believes it, but making up new shit, well it is just low.

Re:What happened to Tcl?

[Anonymous Coward]

"...you're gonna make a gui in Tk if you use Perl, Python, Ruby anyway."

No, I moved on to wxWidgets in my Python. I prefer the platform native look and feel and richer widget set it gives though Tk is (has?) starting to improve in that direction.

Re:Inevitable, and very welcome

[wuzzeb]

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, you should check out SWIG [swig.org]. It has been around since 1995... open source has had automated tools to generate bindings for a long time now. The main problem with this approach is that C does not give enough information. The biggest problem is memory management. most scripting languages are garbage collected, but there is not enough information in C headers for SWIG to know where memory is allocated, and so on.

Essentially, using SWIG comes down to letting SWIG wrap everything just from the headers, except you need to tell SWIG about memory management.... which functions allocate memory that should be garbage collected, which functions take ownership of memory so the object should be removed from garbage collection, and so on....