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
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.
-- Ed Avis ed@membled.com
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.
I guess we'll see which is better, Python's native, (J)VM or Parrot.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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
davecb@spamcop.net
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
The only reason why Sun would hire them, now, is if they were concerned about parrot splitting the market.
I prefer the "u" in honour as it seems to be missing these days.
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.
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.
Well, no, if you check Ted's blog, you'll see that he's going to be working on Python-in-general, not just Jython.
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.
I am TheRaven on Soylent News
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
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.
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.)
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.
I am TheRaven on Soylent News
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.
Like all pain, suffering is a signal that something isn't right
When I first came here, this was all statically typed. Everyone said I was daft to build a dynamic language on the JVM, but I built in all the same, just to show them.
...It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Lad, the strongest castle in all of England.
tomorrow who's gonna fuss
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?
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.
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?