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."
Python Developers? (Score:5, Funny)
Re:Python Developers? (Score:5, Funny)
It sank into the swamp. (Score:3, Funny)
Re:Python Developers? (Score:5, Funny)
Have you followed Gilliam's career? Almost everything the guy works on is cursed, usually with multiply-redundant curses in case one of them fails...unless you want Sun to die you don't want him working there. The poor fella.
On the other hand it would be nice to see the giant foot falling from the sky to crush any run-time errors.
Re: (Score:2)
Re: (Score:2)
I don't think the GP was in any way trying to defame our respected friend Mr. Gilliam.
Re: (Score:2)
woman: I don't want *any* java!
chorus: jav jav jav jav jav jav jav jav, crufty java, bloated java!
Re:Python Developers? (Score:4, Funny)
What happened to Tcl? (Score:5, Interesting)
I'm glad he didn't (Score:3, Informative)
Re: (Score:2, Insightful)
Re: (Score:3, Informative)
Re: (Score:2)
At least Tcl isn't as freaky about indentation. Fortran 90 did away with indent-specific formatting.
Re: (Score:2)
That's the problem for me. I prefer a richer (less minimal) language, so that my programs can be minimal.
I have only hacked a single major Tcl program, and it was not enjoyable. It felt like badly designed C code, only with a more verbose syntax ... and no type checking.
Re: (Score:2)
I used it the other day for the first time on my EEE PC and it was really easy to write. If I had tried it earlier I would probably have written more GUI code for my scripts in the past 10 years. Hindsight is a wonderful thing...
Tcl is a bit on an anti LISP. In Lisp everything is
Re: (Score:3, Informative)
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 expla
Re:What happened to Tcl? (Score:4, Informative)
Re:What happened to Tcl? (Score:5, Informative)
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.
wxWindows is small too (Score:2)
And has the added benefits to integrate nicely with the OS, unlike Tk which looks like an arse whatever OS you run it on, for lacking a proper theme engine until very recently.
Re: (Score:2)
I try not to make stuff up. I will try to replicate the issue and post the err msg tomorrow.
Re:What happened to Tcl? (Score:5, Funny)
What happened to Tcl? Well judging from the look of it, I'd say it was run over by a car, then hit by a train, then had a nasty encounter with stampeding bison, then got a nasty infection from a facehugger, then beaten up by Ripley and was then promptly nuked from orbit. It's for the best, it was in a great deal of pain and nobody wants to live like that.
Seriously though, that's one ugly language. I always got the impression it's what the inventor of Brainfuck would create if he were actually being serious.
Re: (Score:2, Funny)
Re: (Score:2)
As I heard the story (n-hand so take with a grain of salt), Sun hired Ousterhout because they wanted a language platform they could control and use against Microsoft. However, Ousterhout insisted that TCL remain with its open license.
When Gosling and crew showed off Oak (later Java), Sun realized they had what they needed, a completely home grown system they could own and control.
Java became the favorite child, TCL was ignored (so was SELF, another language Sun was interested in). So Ousterhout left Sun
Re: (Score:2)
Ousterhout never worked for Sun, they simply provided him with office space and equipment to work on Tcl/Tk away from his regular job as a university professor. I'm pretty sure the original Tcl book makes this clear in the preface, but my copy is in storage at the moment so I can't check.
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: (Score:2, Insightful)
Why you should not use Tcl [vanderburg.org]
Indeed, you feel you need a bath after using upvar. But plenty of other languages lack proper references; Python for example (though it can kind of emulate them with the Ref container). (Python programmers at this point will retort that it does have references, indeed every variable is a reference. In which case you move the discussion one level up and the ques
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
A VM is just another PLATFORM! (Score:5, Interesting)
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.)
A VM is a tradeoff (Score:2)
As StCredZero said, a VM is a platform and a target of development environments.
However, it doesn't need to have a single implementation, any more than the i86 platform does, so I encourage people to create multiple implementations of a given VM ABI and target different languages toward it.
This, like building on different hardware, exposes bugs with great enthusiasm, which fairly rapidly yield code quality and stability, visible as a falling bug rate.
In effect, it's a way to trade more bugs now for f
Re:A VM is just another PLATFORM! (Score:5, Interesting)
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
Re: (Score:3, Interesting)
Re: (Score:2)
Basically all it takes is having a clue and setting up your build and deploy environment properly. Clueless idiots manually copying libraries to what they think is the right
Java Version Hell -- Hell Yeah! (Score:3, Interesting)
Re: (Score:2)
As far as I understand, python 2.2 and 2.5 are quite far apart and 3.0 will break language and platform compatibility. It kind of matters which python you have. Good luck with the version from 1995. I happen to run into this a lot because pys60 is based on 2.2 which means that most third party stuff doesn't work there. Thanks to dynamic
Re: (Score:2)
Re: (Score:2)
Arguably the main contribution of Java has been bringing all the smalltalk goodies to mainstream (finally). Some compromises were made along the way but the overall result is still pretty nice.
Re: (Score:2)
Also, I think many people would love to be able to develop small apps for mobile phones using Python. This opens a whole new market for this language! Very welcome change, indeed!
Re: (Score:3, Interesting)
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.
Re:Inevitable, and very welcome (Score:5, Informative)
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:Inevitable, and very welcome (Score:5, Informative)
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: (Score:2)
Re: (Score:2, Informative)
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 ther
Re: (Score:2)
Re: (Score:2)
2008 - the year of the VM shootout (Score:3, Funny)
Re: (Score:2)
DLR (Score:2)
Re: (Score:2)
Nothing New... 12 years later (Score:2)
Anyway, Sun has been harping about how the "JVM" could support multiple languages. They talked about Basic and fortran, I guess with M$ pushing C# and C++ on the JVM. Java can finally justify the multi-language
Re:Nothing New... 12 years later (Score:5, Informative)
Re:Nothing New... 12 years later (Score:5, Insightful)
Re: (Score:3, Informative)
wow; parrot has had an impact. (Score:3, Interesting)
Re:wow; parrot has had an impact. (Score:5, Funny)
Re: (Score:2, Informative)
Sun is going after the ruby and python developers because
Re:wow; parrot has had an impact. (Score:5, Informative)
Re: (Score:3, Funny)
Actually it's because, with the current economic decline, Sun can no longer afford to hire Perl programmers... :-)
Um, not just Jython (Score:5, Informative)
Scripting? (Score:2)
Parrot? (Score:2)
Mod parent up (Score:4, Insightful)
Re: (Score:2)
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: (Score:2)
If you're moving between different platforms then sure , I already said VMs are useful. But if its on a static machine architecture why bother?
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: (Score:2)
I'm sorry, but what you are saying simply cannot be true.
A VM of any flavor, must run on top of and use the services of the underlying OS, I don't care if its a *nix, Windows, Netware, Be, Symbian, whatever. Unless the VM directly exposes the application that is running within the VM to an OS call ( fopen() ) then the VM must puts its own wrapper around it, do whatever error checking the VM is going to do, then pass it to the OS, let the OS complete the operation, take the handoff back from the OS, then h
Re: (Score:2)
Do you any concept at all what a Just In Time Compiler is? The JVM has absolutely no problem linking to an fopen() call because it compiles the code
Re: (Score:2)
Re: (Score:2)
Actually, it doesn't *have* to be written in C/C++. It can be written in any self-hosting language. The fact that you are unaware of that already displays your ignorance.
You're really not wrapping your head around this idea of runtime optimizations, are you? The idea that the Virtual Machine can understand the underlying data
Re: (Score:2)
OK , its *probably* written in C/C++. Lets face it , its hardly likely to be written in Perl or Lisp.
"You're really not wrapping your head around this idea of runtime optimizations, are you? The idea that the Virtual Machine can understand the underlying data structures well enough to NOT compile in any exception checking or cast checking
Re: (Score:2)
Do you any concept at all what a Just In Time Compiler is? The JVM has absolutely no problem linking to an fopen() call because it compiles the code into native instructions. The reason why it's faster is because it can optimize that native code at runtime. i.e. It can take the results of runtime profiling and recompile the source into a different code path. That code path can execute for as long as the JVM detects that it is valid. The moment the JVM detects that it is invalid, it can recompile with a more general code path.
Then what is the point of having a Virtual Machine? If JIT compiles JAVA to native code and allows it to execute outside the boundaries of the VM, then what is the point of even having a VM? Perhaps this is a wording problem? To me a Virtual Machine allows the underlying architecture to isolate anything running in the VM.
And if the JIT is that hot, then why bother with the rest of the cruft? Why not Simply JIT the code and launch it native and abandon the notion of a VM?
In other words what does the
Re: (Score:2)
The point of the virtual machine is to provide an imaginary execution platform. The original purpose of such a platform was portability, though these days it has become a center for all kinds of research.
That is an incorrect statement. The JVM is logically perfect. i.e. There is no way to feed a program into the JVM that penetrates to the hardware below. How the JVM
Re: (Score:2)
Someone took the time to explain to you how things actually work regardless of the fact that you didn't do even a modicum of research up front. That someone also gave you a very large pile of ready-made research material to help you understand so that you could discuss more intelligently. (Which you obviously didn't read.) Even then, that same person was willing to explain the inner workings of the Hotspot VM in terms that were easy to digest and under
Re: (Score:2)
Optimizations added to Java 5.0:
http://java.sun.com/performance/reference/whitepapers/5.0_performance.html [sun.com]
Hotspot internals Q&A session:
http://blogs.sun.com/nike/entry/hotspot_internals_q_a [sun.com]
Another highly interesting set of benchmarks:
http://java.sys-con.com/read/45250.htm?CFID=388847&CFTOKEN=9460D898-B6BB-AC8B-3C74121E272A4D92 [sys-con.com]
VMs won't be the panacea of performance (Score:3, Interesting)
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 faste
Re: (Score:2)
I see this as an argument for the JVM approach rather than against it. As we start seeing 4/8/16-core processors, one (or both) of two things will have to happen for us to get any benefit from the added cores. Either programmers are going to have to learn to parallelize their code and languages are going to have to make multi-threaded programming a lot easier or we're going to need an abstraction layer between the programmer and the hardware that's capable of parallelizing
Re: (Score:2)
In Python, it is trivially easy to add new methods to a class or module at runtime. The only way to compile such code statically would be to link against a Python compiler that can create the new opcodes from newly-generated source on the fly. At that point, what's the advantage over just using a VM in the first place?
Re: (Score:3, Funny)
And that's what lisp was doing about 25 years ago.
Re: (Score:3, Insightful)
Yep. But are there arguments for or against other than "Lisp did it"?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
There are four good reasons to run a VM, that I know of:
Re: (Score:2)
The last thing I want in a production enviroment is some runtime optimiser fiddling away under the bonnet. I want the binary to be consistant in its operation with no extranious BS going on other than the OS VM system itself. Besides which the optimiser is not going to be able to 2nd guess what the OS is going to do - it might try and optimise some pipeline calc on the fly just for the VM to be swapped out halfway through.
"A better question now might be, what's the point of a tradi
Re: (Score:2)
The thing is, it's very likely that this optimizer is better than you are.
It took me a very long time to understand and embrace this concept. It finally clicked when I read this paper [paulgraham.com] about spamfiltering. Specifically:
Re: (Score:2)
Re: (Score:2)
True enough. Now, what if it's not deterministic that this other class will be loaded, and in some cases, it's never loaded?
I am not necessarily arguing that the JVM, as written, is the best possible example of runtime optimization, but I do think it's possible to do it right.
Re: (Score:2)
Then that is even worse, you end up with an application that sometimes performs well and sometimes performs badly based on whether during that session the user has done some action with a totally unrelated part of the app that caused the "other class" to be loaded.
Re: (Score:2)
And occasionally performing much worse, while unacceptable for some applications, is also one approach t
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Re:too little too late (Score:5, Informative)
Re: (Score:2)
jVM+Jython+C just doesn't look compelling to me compared to Python+C, in particular since Jython lacks a lot of important Python libraries. And I don't see Sun catching upwithn two devs.
Re: (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 ma
Re: (Score:2)
Re: (Score:2, Interesting)
Re: (Score:2)
Java IDEs attempt to solve at the IDE level what are really language problems.
and a huge collection of libraries that take care of the grunt work for just about anything you want to do.
Did you read what I said? I do not find Java's libraries useful: a lot of functionality doesn't exist at all, and the libraries that do exist are poor in many ways.
I find existing C/C++ libraries a lot more useful than existing Java libraries, and that makes Python, no
Re: (Score:2)
You know, the really laughable thing is that morons like you were arguing against Java with exactly the same bullshit arguments a decade ago. They had to be dragged kicking and screaming into the Java world.
Not some little HelloWorld app with 3 script file that a kid puts together in Notepad and thinks he's a programmer now.
You just show your ign
Re: (Score:2)
The top two languages, according to a casual Google search, are PHP and ASP, in that order. So Java is at best third, unless we can find some actual statistics to pin it on. The only sites I ever notice a JSP page on are various corporate websites which are basically HTML brochures. The only site I actually use that I know is running Java is Gmail.
That's a deeply flawed methodology, unless what you're after is "The top languages that are used by websites that expose their implementation technology to the end user". ASP and PHP seem to be more discoverable because their programming models encourage the use of .php and .asp/.aspx extensions. It doesn't necessarily mean that the conclusion is wrong, just that you can't use this as a leg
Re: (Score:2)
I do agree that it's a deeply flawed methodology, but I couldn't find a better one -- and I figured it was better than "anonymous coward says so".
As for the rest of the post, looks like it's been modded flamebait, which is probably appropriate.