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

Python Developers?

[techpawn]

Got my hopes up! I thought you meant John Cleese and Terry Gilliam had new work at Sun...

Re:Python Developers?

[stoofa]

Sun statement: We have hired a key Python developer, Ted Leung Frank Wierzbicki... We have hired TWO key Python developers - I'll start again. Amongst our Python developers are such key people as..."

Re:Python Developers?

[ricebowl]

Got my hopes up! I thought you meant John Cleese and Terry Gilliam had new work at Sun...

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:Python Developers?

[techpawn]

What would you prefer Michael Palin and Eric Idle? I'm not sure they're any good with Java.

Re:Python Developers?

[rubycodez]

salesman: 'ow about o'r java desktop running a java virtual machine wi' jython accessin' from a java portal server, that's not got much java in it.

woman: I don't want *any* java!

chorus: jav jav jav jav jav jav jav jav, crufty java, bloated java!

Re:Python Developers?

[Anonymous Coward]

John Cleese did work for Sun, back in 2005. He was a "keynote speaker" (read entertainment) for one of their last live NC (Network Computing) events. I think it was NC05Q3.

Re:Python Developers?

[Hythlodaeus]

No, they're clearly working on the Parrot VM (which is just resting.)

Re:Python Developers?

[Anonymous Coward]

It depends how you mean cursed. If you meant brilliantly original and to hell with what the mainstream thinks then yes.

Terry Gilliam is one of my favourite directors.

Re:Python Developers?

[ushering05401]

He was more likely referring to events such as those depicted in Lost in La Mancha http://en.wikipedia.org/wiki/Lost_In_La_Mancha, and the recent death of Heath Ledger.

I don't think the GP was in any way trying to defame our respected friend Mr. Gilliam.

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.

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: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:What happened to Tcl?

[Bogtha]

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:What happened to Tcl?

[foobarbaz]

What happened was it starting sucking and never stopped.

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:What happened to Tcl?

[ChristTrekker]

Tcl, good grief... We have people at my company that don't know anything but Tcl, thus we get web apps on our intranet written in it. Angels and ministers of grace, defend us!

Re:What happened to Tcl?

[dwarfking]

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 and formed Scriptics.

So basically it was because Sun wasn't allowed dominating control over TCL that they didn't keep backing it.

Disclaimer: I'm a fan of both Java and TCL. I particularly like TCL's Starkit system of a self contained executable that is drag-and-drop deployable without requiring a runtime install.

Re:What happened to Tcl?

[Ed Avis]

Web apps in Tcl... yes why not?

Someone who knows nothing but Tcl, mind you, is likely to be a bad Tcl programmer. This remains true for any value of Tcl.

Re:What happened to Tcl?

[blueberry_tx]

The problem with TCL is that it is a single pass parser, not a normal expression (recursive descent) parser like other languages. This makes it the programmers job to worry about interpolation. A real pain, getting all the evals right. Just like shell programming, but then I work with people who love KSH, bash, etc. I've never understood that masochistic behavior.

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:What happened to Tcl?

[morgan_greywolf]

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. That sounds like it's right on the money, actually. Now that we have Gnome/GTK, wxWidgets and KDE/QT bindings for Python, Perl, Ruby and a slew of other scripting languages, the easiest way to make a simple GUI application is with PyGTK ;) (Heh! Just a little humor for you Perl/Ruby/Qt/KDE/wxWidgets/etc. people)

Re:What happened to Tcl?

[MenTaLguY]

I was a heavy TCL programmer back in those days, and built some fairly serious software in it (and still maintain one package to this day). Honestly, looking back, I'm glad TCL didn't win. It's a horrible language.

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:What happened to Tcl?

[Ed Avis]

Honestly, looking back, I'm glad TCL didn't win. It's a horrible language.

Why you should not use Tcl

upvar+uplevel in place of pass-by-reference?

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 question becomes: why no references to (mutable) references?)

Unstructured strings as the fundamental representation for everything?

Everything runs on your computer using memory, which is a big long string of bytes. Ultimately, an unstructured string is the fundamental representation for all data in all languages. What matters is the tools the language provides to let you manipulate the data in that string.

The inability to parse the language without simultaneously interpreting it?

Perl also suffers from this problem.

I'm sorry, but after a decade of experience I think I can say it's just awful.

I can't argue with that. But at least it sucks in interesting and playful ways.

Re:What happened to Tcl?

[LizardKing]

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?

[korbin_dallas]

No, I believe its a jar.exe 1.6 error msg stating it cannot open the JAR file. Zip notwithstanding, its an error. The customers really hate it when it doesn't work.

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?

[ColinMacleod]

The inability to parse the language without simultaneously interpreting it? Perl also suffers from this problem.

Wrong, Perl parses and byte-compiles the whole program on startup, while Tcl only parses and byte-compiles each block the first time it's executed, so a rarely-executed piece of code might have lurking errors. (Apart from that, Tcl is far cleaner, more readable and consistent than Perl though)

Re:What happened to Tcl?

[Ed Avis]

Wrong, Perl parses and byte-compiles the whole program on startup,

However it remains true that you cannot parse the language without evaluating it. The BEGIN block in Perl gives code to be executed at compile time. If you skip these BEGIN blocks then it is likely that the program will fail to compile. There is no way to parse a Perl program, in general, without running the code in the BEGIN blocks.

An excessively rigorous proof of this is Perl Cannot Be Parsed.

Re:What happened to Tcl?

[Anonymous Coward]

Your link is grossly outdated, about a decade or more and most of the points raised there have change, are no longer valid or just silly.

For a nice review of what Tcl has to offer:
http://antirez.com/articoli/tclmisunderstood.html

Re:What happened to Tcl?

[dkf]

Now that we have Gnome/GTK, wxWidgets and KDE/QT bindings for Python, Perl, Ruby and a slew of other scripting languages, the easiest way to make a simple GUI application is with PyGTK ;) (Heh! Just a little humor for you Perl/Ruby/Qt/KDE/wxWidgets/etc. people) Then it will look poor on Windows and terrible on OSX. For most professional GUI developers, those are far more important platforms than Linux. FWIW, making things look good on OSX takes quite a lot of work if you're not used to using the native tools for that platform, and OSX apps tend to look bizarre on any other platform too; porting's just a pain in all cases. (If you wish to dispute this point, do so with screenshots...)

Re:What happened to Tcl?

[dkf]

What happened to Perl? 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 hallucinate about if he were actually on crystal meth. There, fixed that for you.

Re:What happened to Tcl?

[dkf]

Why you should not use Tcl Gosh, now that's an ancient reference (about 14 years old) that's full of BS (and has been for well over a decade). About the only point I'd concede is that Tcl still isn't keen on linked lists, which is on the grounds that for most code a vector (i.e. collection indexable by numeric position) is a better choice.

Re:What happened to Tcl?

[dkf]

The problem with TCL is that it is a single pass parser, not a normal expression (recursive descent) parser like other languages. You are aware that the language compiler uses recursive descent?

This makes it the programmers job to worry about interpolation. A real pain, getting all the evals right. Hardly anyone uses evals these days.

Just like shell programming, but then I work with people who love KSH, bash, etc. I've never understood that masochistic behavior. Tcl's different to the shells in that it does exactly one round of substitution (unless you go out of your way to run something through again, but that's possible in many languages). Shells can do many rounds of substitution on a single string as well as splitting it up into many words, and though convenient, it makes writing secure code in them very challenging. (The only time I do proper shell hacking these days is when I'm working with autoconf and friends. But I prefer to not think about auto*...)

Inevitable, and very welcome

[kripkenstein]

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.

Re:Inevitable, and very welcome

[SolitaryMan]

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

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:Inevitable, and very welcome

[neuromancer23]

>> The only innovation that I credit to Microsoft in all its decades of existence is that of the CLR (.NET)

Uhh... Actually they stole that one too. Multiple languages were available for the JVM way before the CLR even existed:

http://www.robert-tolksdorf.de/vmlanguages.html

Support for multiple languages on the JVM has been around since 5/23/95 (the initial release date of the java platform to the public).

Re:Inevitable, and very welcome

[jhines]

VAX/VMS had this in their libraries, with a clear API, and calling conventions from all languages. One could mix and match languages as needed.

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

Re:Inevitable, and very welcome

[kripkenstein]

I'm familiar with SWIG; it's a nice tool. But it isn't as immediate as things can be in a language-independent VM. So while SWIG makes things far easier, it doesn't make things trivial.

Re:Inevitable, and very welcome

[rdean400]

Actually the JVM was multi-language before Microsoft ever released the CLR. The fact that the CLR had multi-language flexibility as a selling point doesn't change this fact.

Re:Inevitable, and very welcome

[Anonymous Coward]

"different languages can share actual objects without having to wrap them" So, all you're really talking about is (void *)?

There's a reason for wrapping costs, usually to enforce the interface design from being abused.

Cool!

[davecb]

Can they develop some more of Monty?
I haven't seen anything new from him
for a long time.

--dave

everything, including the sun, came from???

[Anonymous Coward]

given freely as a gift to man'kind'. let yOUR conscience be yOUR guide. you can be more helpful than you might have imagined. there are still some choices. if they do not suit you, consider the likely results of continuing to follow the corepirate nazi hypenosys story LIEn, whereas anything of relevance is replaced almost instantly with pr ?firm? scriptdead mindphuking propaganda or 'celebrity' trivia 'foam'. meanwhile; don't forget to get a little more oxygen on yOUR brain, & look up in the sky from time to time, starting early in the day. there's lots going on up there.

http://news.yahoo.com/s/ap/20071229/ap_on_sc/ye_climate_records;_ylt=A0WTcVgednZHP2gB9wms0NUE
http://news.yahoo.com/s/afp/20080108/ts_alt_afp/ushealthfrancemortality;_ylt=A9G_RngbRIVHsYAAfCas0NUE
http://www.nytimes.com/2007/12/31/opinion/31mon1.html?em&ex=1199336400&en=c4b5414371631707&ei=5087%0A

is it time to get real yet? A LOT of energy is being squandered in attempts to keep US in the dark. in the end (give or take a few 1000 years), the creators will prevail (world without end, etc...), as it has always been. the process of gaining yOUR release from the current hostage situation may not be what you might think it is. butt of course, most of US don't know, or care what a precarious/fatal situation we're in. for example; the insidious attempts by the felonious corepirate nazi execrable to block the suns' light, interfering with a requirement (sunlight) for us to stay healthy/alive. it's likely not good for yOUR health/memories 'else they'd be bragging about it? we're intending for the whoreabully deceptive (they'll do ANYTHING for a bit more monIE/power) felons to give up/fail even further, in attempting to control the 'weather', as well as a # of other things/events.

http://video.google.com/videosearch?hl=en&q=video+cloud+spraying

dictator style micro management has never worked (for very long). it's an illness. tie that with life0cidal aggression & softwar gangster style bullying, & what do we have? a greed/fear/ego based recipe for disaster. meanwhile, you can help to stop the bleeding (loss of life & limb);

http://www.cnn.com/2007/POLITICS/12/28/vermont.banning.bush.ap/index.html

the bleeding must be stopped before any healing can begin. jailing a couple of corepirate nazi hired goons would send a clear message to the rest of the world from US. any truthful look at the 'scorecard' would reveal that we are a society in decline/deep doo-doo, despite all of the scriptdead pr ?firm? generated drum beating & flag waving propaganda that we are constantly bombarded with. is it time to get real yet? please consider carefully ALL of yOUR other 'options'. the creators will prevail. as it has always been.

corepirate nazi execrable costs outweigh benefits
(Score:-)mynuts won, the king is a fink)
by ourselves on everyday 24/7

as there are no benefits, just more&more death/debt & disruption. fortunately there's an 'army' of light bringers, coming yOUR way. the little ones/innocents must/will be protected. after the big flash, ALL of yOUR imaginary 'borders' may blur a bit? for each of the creators' innocents harmed in any way, there is a debt that must/will be repaid by you/us, as the perpetrators/minions of unprecedented evile, will not be available. 'vote' with (what's left in) yOUR wallet, & by your behaviors. help bring an end to unprecedented evile's manifestation through yOUR owned felonious corepirate nazi glowbull warmongerin

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

[obstalesgone]

JVM? VM? I already have machines that run Java and Python. What do I need a virtual one for?

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

[zdzichu]

Simple, take one of Azul's Java CPUs.

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

[Yetihehe]

You need virtual machines for security. If you for example don't want for one program to be able to spy on another's workings.

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:Let's take off the 'V' as well!

[Anonymous Coward]

Wow, you really know your stuff!

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:Let's take off the 'V' as well!

[Anonymous Coward]

You still don't need a virtual machine. Under linux, just type:
man 2 ptrace

Ptrace gives you a way to intercept all system-calls, so you can make any process as secure as you want.

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

[Anonymous Coward]

You think Python doesn't run on a virtual machine too?

2008 - the year of the VM shootout

[A beautiful mind]

I guess we'll see which is better, Python's native, (J)VM or Parrot.

Re:2008 - the year of the VM shootout

[Constantine XVI]

You forgot the .NET CLR (IronPython)

Re:2008 - the year of the VM shootout

[TheLink]

But parrot is dead! ;)

Re:2008 - the year of the VM shootout

[Anonymous Coward]

I've got my money on Python running as JavaScript winning the performance crown. :-)

Re:2008 - the year of the VM shootout

[Anonymous Coward]

I wonder why's the parent market funny. If it is because Parrot, it certainly doesn't talk about *that* Parrot.

Re:2008 - the year of the VM shootout

[Samurai Crow]

Also forgotten is http://llvm.org/ , the fastest target of the platforms supported by PyPy. It also supports native code on x86, x86_64, PPC, and PPC64. Static compiling is available on all of those and several others besides.

A niggle re:Inevitable, and very welcome

[davecb]

Note that this is just one reason for having a single VM for all languages. Security, optimization, etc. are others.

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

Nothing New... 12 years later

[mlwmohawk]

In 1995~1996 I was working at a medical imaging company and we were exploring the idea of using Java and its about to be announced graphics interface to be the basis of our new computerized viewers. This was in the time frame of the DEC Shark, a strong ARM based thin client, and Sun's HotJava browser.

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 aspect of their VM.

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:Nothing New... 12 years later

[Headius]

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.

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:Nothing New... 12 years later

[JAlexoi]

The fact that it's not easy to create a Smalltalk compiler to JVM bytecode, does not mean that it's design is horrible...

Re:Nothing New... 12 years later

[H0p313ss]

The fact that it's not easy to create a Smalltalk compiler to JVM bytecode, does not mean that it's design is horrible...

What he said was:

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

So he learned from the exercise "that it is a really horrible design". Not "that it is a really horrible design" because his goal was hard to achieve. I am no VM expert, but those people I know who are have worked on both Smalltalk and Java VMs are and the only positive thing I've ever heard about the JVM design is how exceptions are propagated on the stack.

There's lots of things I like about Java but it's a huge shame that it took almost a decade to catch up with the state of the art in Object Oriented languages.

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:I'm glad he didn't

[Ed Avis]

The syntax is not confused: quite the opposite. It is consistent and very minimal. One command per line, lists separated by spaces, "" quotes with variable interpolation, {} quotes without interpolation, [] to call a function, $ gets the value of a variable, and that's pretty much it.

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.

Re:I'm glad he didn't

[rockhome]

How is it harder to read than Python?

At least Tcl isn't as freaky about indentation. Fortran 90 did away with indent-specific formatting.

Re:I'm glad he didn't

[glop]

Actually, Tk is still cool. Python has Tkinter which is just plain natural, easy and pretty. I remember that Tk in Tcl was just what you describe but the Tkinter binding just gives a pythonic feel (i.e. clean syntax, readable etc.).

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 a function whereas in Tcl everything is a command. This creates an opportunity to increase aspirin sales ;-)

Re:I'm glad he didn't

[Anonymous Coward]

"C syntax"? You obviously have Tcl confused with something else.

As for things moving on, Tk has moved on, too. It is quite the modern toolkit what with the ability to do themes and native widgets and whatnot.

The biggest problem Tcl has, IMO, is that its concepts are a bit too advanced for people who are only familiar with traditional languages to grasp. If all you've done is C and visual-whatever languages you've got some unlearning to do before you can really take advantage of Tcl.

Re:I'm glad he didn't

[jgrahn]

The syntax is not confused: quite the opposite. It is consistent and very minimal.

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:I'm glad he didn't

[Anonymous Coward]

IMO the only reason it was ever popular was because Tk was a very advanced GUI toolkit for its day...

There's also expect (which was based on tcl)...basically the best friend any sysadmin capable of hacking together a quick script could ever have. That was the only reason I ever learned tcl.

Re:I'm glad he didn't

[Tablizer]

The syntax is not confused: quite the opposite...

Guys, guys, everybody has their favorite language and people like them for different reasons. Let's not have a my-lang-can-beat-up-your-lang fight.

Re:I'm glad he didn't

[BJH]

You're complaining about the wrong poster.

Perhaps you meant to reply to the grandparent?

Re:I'm glad he didn't

[BJH]

Everything's hard to read until you get used to it.

I program in Tcl heavily, and just like other scripting languages, it has its warts and fiddly bits (points finger at Python's indentation requirements), but overall it's as easy to use and flexible as Perl/Python/whatever.

Re:I'm glad he didn't

[belmolis]

I'd say that Tcl is actually a funky dialect of Lisp, one with a reasonable amount of syntactic sugar. Tcl "commands" are not statements, they are expressions. They return values. In fact, you can use a rather functional style in Tcl. Tcl also has the "code is data" property. You can generate code and eval it on the fly.

Re:I'm glad he didn't

[Anonymous Coward]

TCL/TK is the only easy way to programming for PC. There's nothing like it around. You can create usable software in days, not weeks. Of corse if you are a professional programmer with years of Java/C++ programming you tend to see tcl/tk with bad eyes. Whem your only tool is a hammer...

Re:I'm glad he didn't

[Anonymous Coward]

Could be worse.. Could be Perl which has no consistency at all.
Could be Python where indentation is syntactically important.
Could be Ruby which is not half bad actually, but every now and then tries to act like Perl.

What I like about Tcl is that it's a consistent language. It has a very small easy to understand syntax rule-set. It's well supported on a bunch of platforms. It's easy to teach non-programmers to use. It's by far the easiest of the scripting languages I know to embed in applications and to extend.

Oh...and the user community is actually friendly, helpful, and almost never flames newbies.

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:wow; parrot has had an impact.

[techpawn]

is if they were concerned about parrot splitting the market.

They're pythons! The parrot's dead... 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!! 'E f-in' stuffed it!

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/ 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 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:wow; parrot has had an impact.

[Anonymous Coward]

not to mention, OpenDS, In case you hadn't heard, Sun gave the OpenDS team the boot.

Open Letter

Re:wow; parrot has had an impact.

[fahrbot-bot]

The only reason why Sun would hire them, now, ...

Actually it's because, with the current economic decline, Sun can no longer afford to hire Perl programmers... :-)

Re:wow; parrot has had an impact.

[Sprout]

Sun had been thinking about doing this for some time. My becoming available was a reason to go from thinking to acting. There will likely be other dynamic language work happening at Sun, not just Ruby and Python.

- Ted Leung

Re:wow; parrot has had an impact.

[Anonymous Coward]

Posting anon for obvious reasons...

Nah your just new there that's why you think that. Give it 6-12 months and after a couple of management re-orgs they'll lose interest. Sorry to burst your bubble.

It's....

[wildzeke]

Cue music.

too little too late

[nguy]

I think Sun missed the boat on dynamic languages. For years, they had a Java-only policy for the JVM.

At this point, there are more useful libraries and tools for C Python than there are for Java. Sun's new found love for Ruby, Groovy, Bsh, and Jython mainly seems to stem from the realization that "pure" Java just didn't work out.

Re:too little too late

[Anonymous Coward]

Ha, ha....when I see comments like these I am laughing so hard it hurts.

Java didn't work out??? Which universe do you live in?

We have a whole team of Java devs here, earning good salaries, working on interesting projects, being able to afford homes, cars, plasma TVs, etc. We're a multi-billion $$$ company

Number of Python / Ruby / Tcl developers employed here: 0. ZERO. Not one. NADA.

So, Java not working out, eh? Young boy, get some some education before you start spewing rubbish like this.

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:too little too late

[BotnetZombie]

Missed the boat is perhaps too harsh - but they're definately late to it. All the same, people have been successfully using jython and jruby for some time now, even though many experience some integration problems. Speaking for myself, 3-4 years of using jython has been mostly a joy, but not completely painless.

Re:too little too late

[Anonymous Coward]

I think you missed the point. Sun ran for the longest time under the mindset that Java was the only programming language you will ever need. That it will be able to do everything and anything. Incorporating other languages and dropping the "J" from "JVM" is showing that they are finally acknowledging what everyone else has been harping on and have known for years.

Yes we are all fully aware that Java is the most popular language in use and that many developers make a living off the language. Although, if you are a multi-billion dollar company and do not have at least one fellow using Python in your org...that's a bit odd. I would make a good guess that you might not know your organization as well as you think.

Re:too little too late

[nguy]

well, yes, Sun realized that. But I realized a few years ago that I don't really need a JVM anymore. If I want safe code, I write it in Python. if I want speed, I write in Pyrex or C.

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:too little too late

[Anonymous Coward]

Sure, maybe there is some junior doing some scripts in some little cubicle somewhere.

But every day 99% of our senior guys are focused on things such as ActiveMQ, OSGi, RCP, J2EE, Java EE 5.

You know, real stuff...the one corporations really use when they need to pull in a project involving 50 developers that will serve hundreds or thousands of users.

Not some little HelloWorld app with 3 script file that a kid puts together in Notepad and thinks he's a programmer now.

Re:too little too late

[Anonymous Coward]

Can I live in your world too?

Well come for a holiday.

Sun has for some time said that other languages could play on its VM.

Alas its VM was not designed well for other languages.

Re:too little too late

[nguy]

Sure, Jython is the nicest way of using the Java platform. That still doesn't answer the question of why I would want to use the Java platform at all. Maybe Jython is good for people with a big Java legacy code problem, but for anybody else, C Python seems better to me.

Re:too little too late

[nguy]

You know, real stuff...the one corporations really use when they need to pull in a project involving 50 developers that will serve hundreds or thousands of users.

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 ignorance with comments like that; there have been many more successful startups using scripting languages than Java.

Yeah, corporations buy lots of Java: that's because they have plenty of money to waste, don't need to innovate, and rely on mediocre developers.

Re:too little too late

[Anonymous Coward]

We have a whole team of Java devs here, earning good salaries, working on interesting projects, being able to afford homes, cars, plasma TVs, etc.

Dusty COBOL decks, oil spills and nuclear power plant accidents also create lots of jobs; that doesn't make them good technologies.

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?

Re:too little too late

[nguy]

The biggest reasons are that you have some excellent IDEs

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, not Jython, the language of choice.

I'm interested to know where your dislike for Java comes from?

From actually implementing the same kind of system once in Java and once in other languages. From trying to write desktop applications in Java. From using it for more than a decade.

Re:too little too late

[Headius]

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.

Re:too little too late

[Anonymous Coward]

50 developers for an application that will serve hundreds or thousands of users? Good grief, if we were looking for an example of what's wrong with Java, you just gave an excellent one. Do you even realize how idiotic your statement is?

Re:too little too late

[Anonymous Coward]

Being able to use JDBC. That's what I love about Jython.

Mod parent up

[Viol8]

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.

Re:Mod parent up

[CastrTroy]

Running under a VM is really nice for debugging purposes. Changing the code in mid-run, and continuing on executing the code saves a lot of time. Also, you can actually rewind from an exception in .Net, fix the problem, and continue on debugging. Running thing's in .Net lets you get a whole lot more information about where your memory is being used, or where the performance bottlenecks are. Some of this stuff is probably possible without a VM, but having a VM adds a lot of features that you simply can perform with regular machine code.

Re:Mod parent up

[Anonymous Coward]

Damn, you must be some kind of programming guru!

Re:Mod parent up

[Anonymous Coward]

> certainly don't understand the reason for using a runtime VM
> to run executables when a standard binary would suffice

Which is why Vala is so cool.

Re:Mod parent up

[A beautiful mind]

Your post is missing the point.

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:Mod parent up

[Just Some Guy]

I certainly don't understand the reason for using a runtime VM to run executables when a standard binary would suffice

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:Mod parent up

[Glock27]

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.

There are some nice things about running on a VM. For one thing, once you've debugged the JIT code generation, you can pretty well prove that large classes of nasty things can't happen. The other argument usually given is that doing JIT compilation presents optimization opportunities not present during static compilation.

The VMs are doing very well, considering that gcj has been under development for a long time as a traditional compiler, and often loses to the Sun JVM in testing. I do think a traditional compiler is the way to go for hard real time stuff, but you also need deterministic GC (or guaranteed no GC during RT operation). The gcj folks should probably implement the RT Java extensions as their next major effort.

I believe Project Harmony was to use a traditional compilation approach. I wonder how things are going there, I'll have to check it out..

Re:Mod parent up

[SanityInAnarchy]

There are four good reasons to run a VM, that I know of:

1. Reflection. It may be possible with a compiled program, but I've never seen it done, and most VMs make it much easier.
2. Runtime optimization. Optimizing at runtime means your program can take advantage of knowledge of the actual, running system to optimize itself. Psyco took advantage of this -- it compiled multiple versions of various things (to x86 binary, I might add) and then chose one to run based on the kind of load the program was actually getting.
3. Faster than interpreting. Take any so-called "scripting" language -- Perl, Python, Ruby, PHP, Visual Basic, JavaScript -- would you really expect a language which supports "eval" to compile to a traditional binary? But they can be compiled to bytecode, which is faster than interpreting them line by line.
4. Higher-level library calls. Example: If Perl6 and its Parrot VM are ever finished, Python and Ruby programs will be able to use CPAN modules directly, as though they had been written in Python or Ruby. Currently, this kind of thing happens in .NET all the time. And because it's a property of the runtime, it works the same way on any platform.

That's in addition to compile-once, run-anywhere, which is a good thing anyway. In college, for instance, there was one assignment in which we were to write against a library provided by the professor. We were given a jar file, not source code. I was able to develop and test on amd64 Linux and/or ppc OS X, depending which I wanted to use at the time. It was almost certainly graded on a 32-bit x86 Windows XP.

A better question now might be, what's the point of a traditional compiler? Or, why would you prefer one over a VM with JIT?

Re:Mod parent up

[mechsoph]

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.

And that's what lisp was doing about 25 years ago.

Re:Mod parent up

[Just Some Guy]

And that's what lisp was doing about 25 years ago.

Yep. But are there arguments for or against other than "Lisp did it"?

Re:Mod parent up

[Viol8]

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

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

[Viol8]

"2. Runtime optimization."

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 traditional compiler? Or, why would you prefer one over a VM with JIT?"

Because I don't see any good reason for having an extra layer between my program and the OS if its not required.

Re:Mod parent up

[mechsoph]

It makes execution a lot faster than bytecode interpreting, and it makes development a lot faster than static (c-style) compilation. So yes, having a native compiler as part of the runtime is a very nice feature. In fact, lisp even lets you do things like implement a natively compiled python without having to do any work on code generation.

Re:Mod parent up

[SanityInAnarchy]

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.

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 about spamfiltering. Specifically:

The statistical approach is not usually the first one people try when they write spam filters. Most hackers' first instinct is to try to write software that recognizes individual properties of spam. You look at spams and you think, the gall of these guys to try sending me mail that begins "Dear Friend" or has a subject line that's all uppercase and ends in eight exclamation points. I can filter out that stuff with about one line of code....

When I did try statistical analysis, I found immediately that it was much cleverer than I had been. It discovered, of course, that terms like "virtumundo" and "teens" were good indicators of spam. But it also discovered that "per" and "FL" and "ff0000" are good indicators of spam. In fact, "ff0000" (html for bright red) turns out to be as good an indicator of spam as any pornographic term.

I've tried a statistical spamfilter myself, and it works. It's that old principle of, at a certain point, the computer is better at it than you are -- or, at the very least, more reliably better and with so much less effort that you'd have to be insane to do it manually.

A simple example: C code. It compiles to some fairly ugly assembly, yet there are compiler optimization flags that will make it, on average, pretty decent. It's theoretically possible you could write better assembly, but it would take so obscenely much time, and the compiler is already doing it for you, so why bother? You wait until the performance is actually hurting you, and then you find a tight loop, take the smallest part of your program which the compiler didn't do quite as good a job with as you could -- and there, you write assembly.

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.

It might be swapped out anyway. And by the time you're being swapped out, it doesn't really matter how fast you were running. Those few extra cycles spent in runtime optimizations aren't going to be the final straw.

The existence of swap also creates problems for having your program be entirely deterministic in its performance. If you want that, you write in C, probably mostly ASM, and you put it on a Real-Time OS.

Most people don't need things to be that consistent -- it's good enough if it is fast on average. Even things like a game -- computers are fast enough that a garbage collection cycle or a bit of runtime optimization will take place in much less than a single frame or tick.

And you're also assuming that such a VM won't communicate with the OS, or be a part of the OS. Take a look at Microsoft's Singularity for an idea of where that might go.

Because I don't see any good reason for having an extra layer between my program and the OS if its not required.

But you give no reason for that preference, other than not liking runtime optimizations.

I see no reason to have an OS at all if it's not required -- let's all write x86 assembly while we're at it! -- but it's certainly a nice thing to have.

Re:Mod parent up

[AKAImBatman]

But if its on a static machine architecture why bother?

Because there's no such thing? The performance paths of a PIV, Core Duo, Xeon, and AMD64 are all different. Should we continue compiling code for the lowest common denominator and just accept that our code isn't performing as well as it could?

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/

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:Mod parent up

[FlyingGuy]

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 handoff back to the application that is running within the VM.

I wouldn't even know where to start in an attempt to write a VM, but I do know that if you are going to use the DISK, at some point you have to talk to the underlying OS, and if you have something between you and the OS, then it cannot be faster then talking directly to the OS.

Can a well written JAVA application outperform a poorly written C or C++ app, yes I am quite sure it can. Can a well written JAVA app outperform a well written C or C++ application, I very much doubt it.

I really doubt if java is going to do this any faster:

#include <stdio.h>
void main()
{
printf('Hello World');
}

I mean really now...

class myfirstjavaprog
{
public static void main(String args[])
{
System.out.println("Hello World!");
}
}

Re:Mod parent up

[petermgreen]

The issue with many of the runtime optimisations is predictability. For example if there is only one descendent of an abstract base class in use java can and does inline all the method calls when it jits. If another descendent of that abstract class is loaded then java has to stop doing that. If the method is doing something simple and was calld in the middle of a tight loop that could be a huge performance. An example of this issue was "direct" and "non direct" bytebuffers, use only one and things are fast but use both and performance dropped through the floor.

IIRC they "fixed" that issue in 1.6 by adding optimisations for a method with two possibilities but that isn't really what I would call a fix.

It is IMO very bad if a change in one part of an application can drastically affect the performance of another part.

Re:Mod parent up

[AKAImBatman]

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 handoff back to the application that is running within the VM.

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.

You assume there is something magical about system calls. Why? System calls link against code just fine, and an fopen() will run just as fast in Java as it will in C. (Though there's no performance gain because the OS calls are out of the VM's reach.)

I really doubt if java is going to do this any faster:

Your Hello World example is a straw-man. There is no significant computation going on there, and therefore, nothing that can truly be tested. Try something more realistic like inserting 10,000 items into a hashtable, running an RC4 encryption routine, performing a Fast-Fourier Transformation, or one of the millions of other processes that will have a real-world result that can be measured and compared.

In these areas the JVM can (and does!) shine because of its ability to optimize execution on the fly. An expert coder can use low-level features of C/C++ to cheat the test (as McCombs managed to do here), but usually only at the expense of violating the test purpose of the test. (e.g. McCombs ignored the fact that the hashtable would normally contain a wide variety of object types, and thus in optimizing for small strings, screwed up the purpose of the test. Even worse, his solution was highly wasteful with memory and has a bug that would result in a buffer overflow if a large enough number of iterations was passed in.)

In apples to apples comparison, the JVM almost always wins. And there's no reason why it shouldn't. The JVM JIT compiler can do all the same optimizations that a traditional compiler can do, plus a wide variety of optimizations that never used to be possible. The JVM is at the cutting edge of Computer Science. It has well over a decade of new technologies on the now-aging C/C++ platform. There are hundreds of academic papers on the engine, and dozens of computer scientists who have helped make it as fast as it is today.

But don't take my word for it. Go read up on the Hotspot VM before you decide to call me a liar again. Here, I'll even get you started.

A decade old, but easy to read introduction to the engine: http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html?page=1

A more recent architectural overview on the modern Hotspot compiler:
http://java.sun.com/products/hotspot/whitepaper.html

A variety of papers and presentations on the VM:
http://java.sun.com/javase/technologies/hotspot/publications/

The Hotspot FAQ (answers a lot of questions about why Hotspot sometimes shows up impossibly fast/slow in microbenchmarks):
http://java.sun.com/docs/hotspot/HotSpotFAQ.html

When you're done, think about the number of optimizations the VM is doing in everything from heap management to mallo

Re:Mod parent up

[AKAImBatman]

A few more links...

Optimizations added to Java 5.0:
http://java.sun.com/performance/reference/whitepapers/5.0_performance.html

Hotspot internals Q&A session:
http://blogs.sun.com/nike/entry/hotspot_internals_q_a

Another highly interesting set of benchmarks:
http://java.sys-con.com/read/45250.htm?CFID=388847&CFTOKEN=9460D898-B6BB-AC8B-3C74121E272A4D92

Re:Mod parent up

[Viol8]

The VM isn't written in some magical code above and beyond normal code - it has to be written in C/C++ itself. So why not just write any optmisations the VM can do into your own code. If you say thats impossible then explain how rhe JVM manages it , or is there an infinite regression of VMs running on top of VMs? I could easily write some embedded assembler to test the CPU type (x86 cpuid op ill do nicely) and base the flow of my C/C++ code around that. Sorry , but you're clutching at straws.

Re:Mod parent up

[AKAImBatman]

The VM isn't written in some magical code above and beyond normal code - it has to be written in C/C++ itself.

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.

So why not just write any optimizations the VM can do into your own code.

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 until the JVM traps changes to the data structures that then back out those optimizations is not percolating, is it?

Can you do it in C/C++ code? Sure. The result would look a lot like what the JVM is doing, except with a lot of duplicate hand-written assembly code to provide multiple execution paths.

I could easily write some embedded assembler to test the CPU type (x86 cpuid op ill do nicely) and base the flow of my C/C++ code around that.

Modern C/C++ compilers already do that, genius. As I mentioned before, it bloats the code beyond belief. (But it does work!) That covers only a small section of the optimizations that the JVM is capable of performing. Though it is theoretically possible, no one has yet produced a C/C++ compiler that creates programs that can insert and yank alternate versions of a code path depending on the runtime profiling. And even if they did, it would produce a rather MASSIVE (possibly reaching an impractical size) increase in the the size of the executable. The JVM gets around this because it can generate the code at runtime. Thus the JVM can use a set of optimizations that cannot be computed at compile time.

Now hand in your geek card. You're fired for failing Comp-Sci.

Re:Mod parent up

[JAlexoi]

Are you an EXPERT ON ALL the architectures of all processors?
Will you be able to write a big app with all code paths for each and every processor? And then will it be even equivalent in size to JVM itself?
You know , I can write an app on Atmel processor that will outperform the best of breed processors one to one comparison? Why? No OS. Direct instructions for processor and highest level of optimizations.

The morale is: A specialized anything is better than a generalized something. (better - here means performance)

Re:Mod parent up

[FlyingGuy]

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 VM get me?

With all the optimizations that JIT can do, how come it is not a stand-alone native compiler?

Are you saying that in the middle of execution post _JIT, that the VM will simply halt application, roll everything back or save the state of the application, recompile the code ( I am assuming a new executable image is created ) reset all the data and then relaunch at the last know Instruction Pointer? How can that be if the code has recompiled since all kinds of code is now very different?

Re:Mod parent up

[AKAImBatman]

Then what is the point of having a Virtual Machine?

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.

If JIT compiles JAVA to native code and allows it to execute outside the boundaries of the VM

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 executes the code is irrelevant as long as it does it per the contract it is designed under. If you want to know more about the contract, feel free to read the Java Virtual Machine Specification: http://java.sun.com/docs/books/jvms/

If you want to learn more about the Computer Science concept of a Virtual Machine, then feel free to start here: http://en.wikipedia.org/wiki/Virtual_Machine

And if the JIT is that hot, then why bother with the rest of the cruft?

What cruft? There is no cruft.

Why not Simply JIT the code and launch it native and abandon the notion of a VM?

Early JITs pretty much did a compile at startup and then disappeared into the background. But you still need services like object creation, object management, heap management, garbage collection, thread management, etc. Those are all services integral to the JVM. There's no reason to compile new code to do it when the services have already been compiled into the VM layer.

With all the optimizations that JIT can do, how come it is not a stand-alone native compiler?

I just got done yelling at the original moron for this complaint. Don't you think you should pay closer attention to that reply rather than repeating the same mistake?

Are you saying that in the middle of execution post _JIT, that the VM will simply halt application, roll everything back or save the state of the application, recompile the code ( I am assuming a new executable image is created ) reset all the data and then relaunch at the last know Instruction Pointer? How can that be if the code has recompiled since all kinds of code is now very different?

You're thinking at least, but you don't understand the coupling of classes inside the JVM. Each class in Java is an independent code file that does NOT link at runtime. Inside each of those code files is a collection of methods. Each of these methods is an independent chunk of code. When a call is made from one method to another, control is handed off to the JVM so that it can be redirected to the correct target.

Think about that for a moment. What you effectively have is a bunch of loosely coupled code modules floating around in memory. The default way of executing a method in the Hotspot JVM is to run it through an interpreter. Very clean and simple, though not exactly fast. But if the HotSpot JVM sees that a method is being executed a lot (remember, it gets control every time a method is called!), it will change the code path. It will first compile the bytecode into native code, then perform a native jump to the new method. All method and return calls (unless they get inlined!) will be compiled into native instructions that jump back to the JVM's control.

Now if the JVM continues to see a method called a lot, it will decide to waste a LOT of CPU power on optimizing it. It will do all kinds of analyses on the path the code can execute, if it is possible for an edge case to occur, if there are instructions that will never get executed, so on and so forth. It will then create a super-optimized piece of native code that is logically wrong. And when I say it is logically wrong, I mean that there are checks or huge swathes of code that simply don't exist. It's just b

Re:Mod parent up

[FlyingGuy]

You know what, I have been trying to have a reasonable conversation with you. But it is quite clear that you are incapable of that. You are the type of person who simply wants to show off. You know what you little fucking karma-whore, go fuck yourself. You are quite clearly what is very very wrong with /. I am not normally prone to violence, but for you I would make an exception. Buh-Bye asshole.

Re:Mod parent up

[Dillon2112]

Wow. I've been coding distributed systems in Java and Jini for 4 years and I didn't know a lot of this stuff. Good set of posts - thanks.

Re:Mod parent up

[Viol8]

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

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 until the JVM traps changes to the data structures that then back out those optimizations is not percolating, is it?"

What is perculating is the amount of overhead this runtime checking takes. But the time the VM has run through its optimisation algorithm the normally compiled code could probably have already run its standard code and moved on to the next section.

"Though it is theoretically possible, no one has yet produced a C/C++ compiler that creates programs that can insert and yank alternate versions of a code path depending on the runtime profiling"

You're assuming optimisation can only be done in assembler. Its perfectly possible to optimise at the C level otherwise most OS kernels would be 10 million lines of assembly code with C just being use for the API wrappers. You need to move out of your closeted VM world and look at how things are done elsewhere.

Re:Mod parent up

[SanityInAnarchy]

If another descendent of that abstract class is loaded then java has to stop doing that.

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:Mod parent up

[petermgreen]

True enough. Now, what if it's not deterministic that this other class will be loaded, and in some cases, it's never loaded?
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:Mod parent up

[AKAImBatman]

You are the type of person who simply wants to show off.

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

And the only response you can come up with is, "Wah! Show-off!"?

Grow up, will you? Your behavior is unbefitting of a man your age.

Re:Mod parent up

[SanityInAnarchy]

Seems to me, based on an uneducated guess, that it would sometimes perform better, and sometimes just as well as, it would have without the runtime optimizations -- and only very occasionally would it perform much worse. After all, how many times will that "other class" be loaded and unloaded? If the answer is "a lot", wouldn't the pattern of loading/unloading be noticed by the runtime, and optimized for?

And occasionally performing much worse, while unacceptable for some applications, is also one approach to garbage collection that works quite well in practice. And garbage collection is another place where it seems to be worth it not to worry about yourself.

Re:Mod parent up

[dkf]

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. The truth is that most average code, whether in C, C++, or Java, is a pile of rubbish that's difficult for the compiler to make go really fast. The problem is usually that average programmers tend to not be aware of what operations are expensive, and hence do truly stupid things (and most string handling out there in all three languages is a classic example of this shocking tale, alas).

Um, not just Jython

[tbray]

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.

VM Craze

[Anonymous Coward]

There is a simple reason behind the JVM push or 'craze'. Good programmers are hard to find , difficult to retain, and worth their weight in gold.

So instead of finding those good programmers, why not develop a programming language that shields the programmer from themselves, and allows us to hire lots of cheap, low skilled mediocre programmers. Enter Java.

Don't worry about complex things, like overloading, algorithms, memory management, let java do it for you.

The entry level programmers can crank out huge mounds of steaming code in record time.

they don't have to worry about destroying the OS, overwriting pointers, null pointers, etc, because the virtual machine will shield them from all that.

There is still a core group of very good programmers, all being used to write more and more virtual machines, so the mediocre programmers have something to use.

Re:VM Craze

[edittard]

Are you saying that Java is the new cobol?

Scripting?

[Intron]

This must be some new java of which I am unaware.

Virtualization

[Anonymous Coward]

I don't understand the whole software virtualization craze. Modern CPU's already have silicon dedicated to keeping programs and memory seperate.

Silicon can generally do anything software does, but 1000x faster.

Why devote all this energy to helping make programming simpler, at the cost of speed?

Java is great for say 'presentation' apps, that need a quick and dirty interface.

Try to do anything large with it, and the performance drags down.

Sometimes, you just HAVE to use more than a few hundred megs of RAM, and the overhead of the VM just kills performance.

Better stick with C/C++.

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

Re:A VM is just another PLATFORM!

[jilles]

I actually know what I am doing when messing with Java and it also helps that I actually understand (and even appreciate) how the classloader works (another quite brilliant design decision from SUN), so no this has never been an issue for me. I'm quite handy with tomcat and yes, I've worked on real and I might say pretty obscure systems.

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 place is indeed a nuisance. Any idiot can break any system. As for debugging, I actually kind of like attaching to a JVM and inspecting what is going on in full detail (remotely). I don't know of many other systems that allow me to do that.

Re:A VM is just another PLATFORM!

[Paul Fernhout]

Almost all of the good stuff in Java and the JVM (from garbage collection through hotspot compiling) was developed first for Smalltalk, sometimes decades earlier.

Re:A VM is just another PLATFORM!

[jilles]

Yep, smalltalk definitely deserves credit here. It still has some nice characteristics over Java.

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:A VM is just another PLATFORM!

[Rick BigNail]

And not to forget Self, the simple yet powerful language from Sun.

To the fools thinking Java didn't make it...

[Anonymous Coward]

Java is really two things: Java the language and Java the VM.

And even tough I find that Java-the-language has many warts (bring me Scala [another interesting language targetting the JVM] with DbC and I switch asap), I does many real-world jobs.

And what about Java-the-VM? Best thing that happened to computing these last 20 years... Not a single buffer overflow in the VM since it exist (there have been buffer overflows in 3rd party C-written lib that the JVM depended upon). The VM is bullet-proof by design. A buffer overflow would be due to an implementation error in one of the VM, not in the VM technology design. The VM is simply immune to buffer overflows.

Re-read this. A thousand times: no buffer-overflows. 99% of the security issues plaguing programs written in other languages simply can't happen when you're running your program under the JVM. Last serious issue I remember affecting me was in a 3rd party, C-written, lib (zlib). Funny uh?

Speaking of security... You realize you can install the whole friggin' JVM in a user account on Un*x? No need to be root. (Last time I checked for whatever reason this was impossible under Windows, but I bet it's more Microsoft's fault than Sun's). You can install a whole f*cking JVM without needing to be root... Wild.

Well, that's just one thing, of course you get lots of pretty tools that can connect to these shiny VMs: remote profiling anyone? I mean, really, what does your language offer you? Can I easily turn on and off remote profiling of running apps written in your favorite language? Really? How easy is it?

And now think for a second: how easy would it become if suddenly your language, instead of being clumsy and hard to debug remotely, hard to profile remotely, prone to buffer-overflows, etc. was targetting an industrial grade JVM?

You start to get it? You start to understand why you are still in the stone age and others have seen the light? (Scala, for example, is an impressive 'functional OO language' that targets the JVM).

The next-big-language-that-will-be (TM) will target a bullet proof of VM or it will not be.

So back to the point: there are still fools today that think that 'Java is dead', or that 'Java didn't cut it' or, pathetically, that 'Java is slow' (these trolls needs to be hit with a cluestick)...

Well, I've got some news for you: every non-cash money transaction involves Java in the process at one point or another, Java powers most of the world's biggest sites (eBay, GMail, FedEx, ... Do I really need to list 99% of the most visited sites?), you cannot buy a Blu-Ray player without having a JVM (it's part of the Blu-Ray specs), there are entire countries where people carry Java SmartCards in their pockets (as an ID or for health care).

Talking of GMail, what does Google think of Java? That it's so convenient they want you to use that instead of messing with ugly EcmaScript for AJAXy-like development (GWT anyone? Allo? You code this using Java). Android? Want to develop apps for Android-powered phones? Better learn Java dude. The JVM concept is so sound that Google even wrote their own JVM (Dalvik... It's not called Java to bypass trademark issues, nice job Google ;)

95% of all cellphones out there have a JVM too, btw...

At the (major) bank I'm working for, we just ported a complex application to Java: tens of PCs doing Monte Carlo simulations at night. Speed? Exactly the same has what we had before (we did tests before porting the app... I knew we'd get exactly the same perfs, but some dumbass reading lame comments everywhere about 'Java-being-slow' wanted to be sure). Now we get faster development time.

Most criticism I read about the JVM is the same old song from the 90's. Yup, Java was a pain in the a*se on Linux in the 90's. Times have changed.

All the people saying that 'Java didn't make it' are fooling themselves. Wake up. Java is the biggest language succes

Re:To the fools thinking Java didn't make it...

[Anonymous Coward]

Why do you keep modding down every java advocate? Can you at least argue with them? Or is there only one proper way of doing things? Meh. I'm posting as AC to avoid an angry mob of dynamic lagnuages zealots.

Re:To the fools thinking Java didn't make it...

[SanityInAnarchy]

And what about Java-the-VM? Best thing that happened to computing these last 20 years...

Without checking, I'll bet you $10 that Sun didn't invent the concept of a VM.

Not a single buffer overflow in the VM since it exist

You don't need a VM to do that.

I mean, really, what does your language offer you? Can I easily turn on and off remote profiling of running apps written in your favorite language? Really? How easy is it?

Depends on the app, but I think Ruby Waves will do that and more.

Can you run "eval" in Java? Can you open existing classes and monkeypatch them, tweak them to your bidding?

So back to the point: there are still fools today that think that 'Java is dead', or that 'Java didn't cut it' or, pathetically, that 'Java is slow' (these trolls needs to be hit with a cluestick)...

Actually, I think that .NET is a better Java than Java. And I hate Microsoft, too, but those are the facts.

Well, I've got some news for you: <inane rambling list of things Java is run in>

By that logic, C must be the fucking grail!

you cannot buy a Blu-Ray player without having a JVM (it's part of the Blu-Ray specs)

Part of a certain version of the specs. I'm fairly sure there were early players which did not have a JVM. The one that Blu-Ray does have is not anywhere near a full-fledged desktop JVM.

Talking of GMail, what does Google think of Java? That it's so convenient they want you to use that instead of messing with ugly EcmaScript for AJAXy-like development

Wow. Between EcmaScript and Java, I'll take EcmaScript every time. The fact that you choose Java tells me that either you are a fan of static typing, or you have no idea just how powerful EcmaScript is. (I'll give you a hint -- the guy who invented it wanted to do a LISP interpreter, but his boss told him to write some C-like script. So he wrote a LISP interpreter with C-like syntax -- and that is EcmaScript.)

I should also mention: I worked on HD-DVD. Anyone I talked to about it who had worked with both said they preferred working with HD-DVD. I wonder why that is?

I will say that aside from the storage/bandwidth issue, HD-DVD was ahead technologically for most of the race. (That said, as a user, I mostly just want to watch the movie, so more storage and bandwidth makes a lot of sense.)

GWT anyone?

Yeah, I hate it.

GWT depends on browser identification. It actually serves you an entirely different script based on which browser you're running. If it doesn't recognize your browser, it serves you a non-AJAX version.

In my mind, that is broken by design, yet many people consider it to be a feature. And because of this broken design, I have to keep a Firefox window open for no reason other than to run my Google Apps.

most sites you visit

Excuse me? Are you kidding me?

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.

Now, if you're wondering why you got modded down, let me take you on a brief tour:

Re-read this. A thousand times: no buffer-overflows.

Quoted in a context where it's actually inaccurate, yet you're arrogant enough to insult our intelligence.

You can install a whole f*cking JVM without needing to be root... Wild.

Well, f*cking amazing! I can do that with really any language

Re:To the fools thinking Java didn't make it...

[rdean400]

I'm not going to make a value judgment on the rest of the post, but there is one thing that needs to be cleared up:

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 legitimate basis for reaching that conclusion.

Re:To the fools thinking Java didn't make it...

[SanityInAnarchy]

Does Java not encourage .jsp extensions?

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.

Parrot?

[kbahey]

This seems to overlap/compete with Parrot. Of course Sun are expected to promote their own JVM. I don't see Perl going JVM though.

A VM is a tradeoff

[davecb]

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 fewer later (;-)).

--dave

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:VMs won't be the panacea of performance

[curunir]

With per-core CPU speeds capping...

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 code written without the pervasively-multi-threaded mindset.

The first option isn't particularly likely since it seems, for whatever reason, many developers can't visualize multi-threaded execution reliably enough to write multi-threaded code that isn't buggy as all hell.

That leaves the second option, which can either be done at compile-time or at runtime. The JVM takes the runtime approach, which avoids issues of having to compile the code prior to knowing the exact hardware available. To a limited extent, the JVM is already capable of dynamically multi-threading code to take advantage of multiple processors/cores. The engineers at Sun will continue to improve the JVM's capabilities in this regard, and I think we'll eventually see the JVM start to become significantly faster than native code that isn't specifically written for parallel execution. Basically, if you take a Java program written with a single-threaded mindset and a C program written the same way and, provided the complexity is great enough to mitigate the startup of the JVM (i.e. not Hello, World!), the Java version will most likely benefit far more as the number of available cores increases.

DLR

[drewness]

IronPython runs on the .NET DLR (Dynamic Language Runtime), which is on top of the CLR. The DLR does dynamic types and dynamic dispatch, unlike the CLR. Apparently the DLR code lives in the IronPython tree for the moment, but when IronPython 2.0 is ready they're going to integrate and release the DLR into .NET along with a couple other dynamic languages.

It sank into the swamp.

[mounthood]

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.

wxWindows is small too

[DrYak]

wxWindows (the one used by VLC) which actually use native UI as backend (GTK on linux, native on Windows, etc.) is small and easily packaged along the software (unlike Win32 GTK which requires an additional install).
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:wxWindows is small too

[morgan_greywolf]

Hmmmm...remind me to use wxWidgets on my next cross-platform application, k?

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?

Re:Java Version Hell -- Hell Yeah!

[jilles]

That's why you shouldn't have set your classpath as an environment variable but using the commandline; via declared dependencies in the jar file or using something like OSGI.

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 typing you find that out when things break or don't parse.

And perl, please ... Apples and oranges, nuff said.

Re:Java Version Hell -- Hell Yeah!

[StCredZero]

I have come up with the idea of using CLASSPATH set by the command line independently. (We do that so that we can use Weblogic's JVM client incorporated with our Smalltalk client with the JVM running as a thread under our process, and talk to it using the Java Native interface through C.) However, lots of installs still set PATH and CLASSPATH for you! (Oracle 9!)

And as far as incompatible versions of Python and Perl go -- those should be treated as complete breaks. (And are by smart developers.) By promulgating the idea of backwards compatibility Java is also making it harder for their platform to evolve. (Like WIndows.)

Ousterhout did work for Sun

[ColinMacleod]

See http://wiki.tcl.tk/1413 and http://phaseit.net/claird/comp.lang.tcl/SunScript_story

Re:What happened to Tcl? - It's Evolved!

[Anonymous Coward]

I have to respond here because most of the responses here are sorely outdated and just plain wrong.
Tcl the language isn't perfect, no language is, but it IS evolving and you have to look a the total SUM of the parts that are offered.
The big picture here is Tcl/Tk does a LOT of things VERY well!

Tk: Tk is still a relevant and up-to-date toolkit. As of the latest release (8.5) it has a comprehensive collection of theme-able widgets that look native on Windows, OSX, Linux, etc. Plus, you can still program your GUIs the same way it's been done for years and not have to learn the latest "framework of the week"... Plus it is SMALL, the entire Tcl language AND Tk toolkit on Windows can be encapsulated in a 1.6MB DLL!
It is still incredibly easy to use:
button .b -text "Hello, world"
pack .b

SQLite: The author of SQLite is a big fan and user of Tcl and provides one binding with SQLite ... to Tcl! Needless to say it is a top-notch and easy to use binding, probably the best one available for SQLite. Tcl and SQLite are a perfect match for each other.

Distribution: As was mentioned here in another post, Tcl/Tk applications are very easy to create AND distribute! No need to worry about having huge runtime systems installed on the user's machine as is required by Java, .NET, Adobe AIR, with versioning issues, etc. Just include the small Tcl/Tk platform-specific library(s) with your application and they're good to go! There are various methods available for distributing your apps: Starkits, Freewrap, etc.

Tcl: Consistent, easy-to-understand and incredibly flexible syntax. Procedural, functional, object-oriented. Bytecode compiled.

Plus there's all the other things that Tcl/Tk has done well for a LONG time such as proper Unicode support, cross-platform applications, open source, multiple OOP options (soon we'll have OOP in the core), Virtual File System, powerful Tk canvas and text widgets, on-the-fly bytecode compilation, proper multi-threading, the new Teapot/Teacup package distribution system (awesome!), etc... it goes on and on.

Give it a new, fresh, honest look and I think you'll be pleasantly surprised!

http://www.tcl.tk/ (official Tcl/Tk website)
http://www.activestate.com/ (download FREE ActiveTcl)
http://groups.google.com/group/comp.lang.tcl/topics (VERY helpful newsgroup)

Good Job Frank

[Ashcrow]

I worked with Frank Wierzbicki in a previous position. Good guy, smart, and a true pythonista. I'm happy to see him in this new position and hopefully he will be able to provide some guidance to Python in the jvm ... it makes me excited about jython again.

It's the implementation, not the language.

[Gazzonyx]

While I agree with absolutely everything you've said, I have one bone to pick with you on the C++ issue. It's not the standards committees' fault that GCC-3.2 will let me increment a pointer inline (against ISO definition of an lvalue) and that same code doesn't compile on GCC-3.4 which does honor the ISO standard. The problem isn't the language, it's the implementation. The same could be said for GNU's JVM, which I had the displeasure of forcefully ripping out of a Linux distro a few weeks ago when it ramped up the CPU to full utilization while I had Eclipse sitting idle.

Re:It's the implementation, not the language.

[jilles]

Gnu's Java compiler (not a full vm as far as I know) doesn't pass Sun's test suits as far as I know. There are quite a few VM implementations around and the ones that Sun actually allows to use their trademark all pass extensive sets of testsuits. Things like gnu classpath and apache harmony are very compatible as well (although not yet 100% complete implementations) of the API as well. That still leaves some room for incompatibilities but these tend to be very minor. There's no such thing for C++. There's just the specification which despite all the hard work has many ambiguities and lacks a widely used reference implementation. This leaves the door wide open to implementation differences. Things have been improving of course but it isn't even close to how different Java vms are compatible.

In any case, idealism aside, there's no good technical reason I'm aware of to use the Gnu JVM. It's slower, less scalable, has more bugs and implements less of the standard. Even the license ceased to be an issue some time ago. You are better of running e.g. the Sun compiler or one of the commercially available VMs such as JRockit or the IBM JVM. Red Hat maintains a nice branch of the official Java code that is 100% free of the few remaining closed source dependencies (beer & speech).

Re:What happened to Tcl? - It's Evolved!

[dkf]

Tk: Tk is still a relevant and up-to-date toolkit. As of the latest release (8.5) it has a comprehensive collection of theme-able widgets that look native on Windows, OSX, Linux, etc. It looks like shit on Linux, not native. On Win and OSX, it's great. But for sure not under Ubuntu, and I bet that's also true under other Linux flavours. Additional work on themes needed I think.