New Intermediate Language Proposed

WillOutPower writes "Sun is inviting Cray (of supercomputer fame) and IBM (needs no introduction...) to join and create a new intermediate run-time language for high-performance computing. Java's bytecode, Java Grande, and Microsoft's IL language for the Common Language Runtime, it seems a natural progression. I wonder if the format will be in XML? Does this mean ubiquitous grid computing? Maybe now I won't have to write my neural network in C for performance :-)"

Comments

I bet the format turns out to be...

[Anonymous Coward]

...binary.

Re:I bet the format turns out to be...

[biobogonics]

When you consider the radical changes that have taken place between the standards for 66, 77, 90, 95 and proposed for 2000, I bet the format turns out to be Fortran.

Didn't we do this once before?

[Uzik2]

I recall a system based on USCD Pascal. You would
write an interpreter on your target hardware that
would run the pascal p-code. It was supposed to
solve all sorts of problems. Except it was slow.
Nobody would write anything for it, I guess
because they didn't like Pascal, or USCD didn't
fire anybodies imagination with the product.

I don't see why we need to go through this again.
If you need performance write it in assembler or
use nicely optimized C. If you don't then an
interpreted scripting language will usually
suffice. What's the benefit to yet another
layer of abstraction?

Re:Didn't we do this once before?

[metalix]

I believe CLR is supposed to be portable like Java, but functions are compiled to machine level code upon their first call. Of course there are no performance comparisons out there vs Java, because part of the EULA is that you will not publish any. :P

Re:Didn't we do this once before?

[VertigoAce]

One interesting feature of .Net is language interoperability. Someone can write a class in VB.NET and I can inherit from that class in C++ just the same as if the original was written in C++. Sure there were ways of doing this before, but you generally had to treat other components in a different way from stuff written and compiled in your current project's language.

A more typical usage would be to write anything that needs better performance or that needs access to non-.net libraries in C++ (since it can be compiled to machine code before distributing) and then use that component in other languages that are easier for putting a GUI together. Again, it's always been possible to do stuff like this, but .NET makes it seamless (it's just like linking to any other library).

Re:Didn't we do this once before?

[angel'o'sphere]

I recall a system based on USCD Pascal. I also :-) Except it was slow. Well, on my Apple ][ it was good for the fastest code after Assembler. It only got catched when Z80 coprocessors with CPM and Turbo Pascal came en vouge.
I did really a lot of programming in UCSD pascal, and long UCSD p-code was the most wide spread operation sytem/virtual machine.
If you need performance write it in assembler or
use nicely optimized C.
Assembler loses all higher level abstractions, like inheritance, interface implementation, class relationships(relations, aggregations and compositions), thread synchronization. The same is true for C, besides that it is on source level not able to express higher level concepts. You might use assembler instead of C.
How do you optimize assemberl? The operation system, the non existing, but hypotetical VM, the loader, the processor, none of hem can optimzie "assembler". I mean: In Java Byte Code I have all the higher level abstractions of the system inspectable via reflection etc. In assembler I have nothing.
New bytecodes, able to express more higher level informations e.g. like prarallelization, or even this problem: consider you have an CPU server, consider you have code migrating to youor server, consider you want to trust that code, consider, the "owner" of the code does not want to trust you .... So you need a VM on your CPU server, able to execute encrypted bytecode, so hat you as owner of the CPU dont see what the code is calculating. BUT you, a CPU server, you dont want your system compromized, or the code of other clients compromized by any piece of code.
Or, consider this, you want byte code as an mobile agent, similar to the scenario above, but it should be allowed to replicate over a GRID, but only under certain restrictions.
You want to optimize every replica at the VM where it is finally executed, to take an optimum of resources on that point. How do you do that in "assembler"?
Modern byte codes will be likely even closer to the constructs of the high level languages than byte code is. Resource allocation, object creation, class loading, higher level concepts, like delegation, parallelism, synchronization(on multiple mutexes probably), serialization, distributed(pervasive) computing, probably OODB support build in, probably a light weight EJB like execution environment, probably a 4 level hierarchy of VM, meta container, container and executed code ... probably where the VM is itself only "executed" code inside of a meta cotainer. That means modern VMs probably will extract core VM features like garbage collection and thread scheduling outside of the VM into a library, and every piece of code may "class load" its own garbage collection schema. Consider differnt garbage collectors per thread and not per VM.
Well, I could continue for a day with improvements ....
What's the benefit to yet another
layer of abstraction?

The benefit is to optimze on that layer of abstraction and then to project/generate/assemble the optimzation down onto the machine layer(or the next lower layer).

angel'o'sphere

Re:Didn't we do this once before?

[voodoo1man]

Sure, as long as your class looks just like a C# one. Need multimethods, dynamic class redefinition, method combination, a non-crippled model of multiple inheritance, or maybe even prototypes? You're out of luck, because for this interoperability to work, your classes will either have to be C# classes or you have to make them look like ones, and .NET doesn't give you a Meta Object Protocol to do it.

Re:Didn't we do this once before?

[Valar]

Well, the .NET framework gives you lots of appropriate choices. VB.NET and managed C++ can share objects with C#, for example. You can also define classes in VB.NET or managed C++ or whatever and use them in C#. There is a standard for the size of various data types in this framwork (ints, floats, chars, etc), so you don't have to worry about data loss or funny conversions when using data from a class written in a different language.

Re:Didn't we do this once before?

[dmccunney]

I recall the USCD P-system, too. It was a nice idea. It might have been better received if the original implementation hadn't been on an Apple II. The concept requires reasonable horesepower to work effectively. It got ported to the original IBM PC as well, where it battled MS-DOS and CP/M-86 for market supremacy. Once again, it was on a platform that didn't have enough horsepower.

The P-system on a 386 might have been very interesting, but it had already been marginalized to a niche product.

We've seen it elsewhere besides UCSD Pascal: Pascal designer Nicholas Wirth's Oberon language is a programming language and operating environment. For that matter, so is Smalltalk.

What's the benefit to another layer of abstraction? Offhand, network computing in hererogenous environments. Assembler is machine specific. C doesn't always optimize nicely across architectures: you are at the mercy of what the particular compilers support. (Some of the guidelines aimed at Mozilla developers wax eloquent about this, and what rules of thumb you need to follow to write truly portable code.)

Hardware is getting fast enough that another layer of abstraction might just be a win, if it could allow the programmer to concentrate on the task and not worry about what would atually _run_ the code.

We'll see.

Re:Didn't we do this once before?

[cakoose]

I think what he's saying is that the syntax isn't the only thing that defines a language. A language's type system probably plays a more important part in defining how the language works.

With .Net, it may seem like you have a lot of interoperating languages, but they're all basically the same language with different superficial characteristics. VB developers complain about how VB.Net is totally different from previous versions of Visual Basic. It's because they gutted its internals and implanted C#. I wouldn't be able to tell the difference because I see similar syntax, but someone who really knows the language will detect a different core.

That's not to say that different type systems cannot be emulated. Nice is a language with Java-like syntax but with a much better type system (among other things) and it still runs on an ordinary JVM. However, any interoperability will have to be at the level of the lowest common denominator. If you want to call Nice code from Java, your interface ends up losing or having to give up some power.

You really can't even share libraries between truely different languages. The STL just doesn't fit into the Java/C#-style type systems (though generics is a step towards accomodating the STL). Perl libraries are also distinct. Imagine dealing with a Haskell-style lazy list in your C# code. It just wont feel right.

Re:Didn't we do this once before?

[NickFitz]

You might use assembler instead of C

Unless you really need to use every cycle, you're better off writing in a high level language and then recoding the critical portions (as identified through thorough profiling) in assembly language. (I speak as one who needed to use every cycle when I was a games programmer in the 80s. I've often thought of doing an all-assembly, no OS required app today, just to see how ludicrously fast it would run.)

How do you optimize assember?

You gain extensive experience with the procesor and platform to which you are writing, and you work bloody hard. It also depends on whether you are optimising for space or speed. For example: writing a game for the Amiga, I was told by the customer that it had to run on machines with half a meg of RAM (the entry-level machine). I once spent a whole day seeking a way to save 12 bytes; the first part of the solution involved recoding a routine using a different algorithm. The rewrite saved me 8 of my 12 bytes, and executed in the same number of clock cycles (that was a crucial constraint). I then got the other four bytes by using the interrupt vector for an interrupt I'd disabled. As I was writing to the silicon (not even using any ROM routines), I could get away with this. I wonder what kind of warnings a modern C++ compiler would throw up for this kind of behaviour ;-)

Assembly language is fun, but life can be too short. I had to spend so much time fitting the above-mentioned game into half a meg that, by the time it came to market, 1Mb was the standard required by all games anyway.

Assembler loses all higher level abstractions... In assembler I have nothing

If you design your code well you have plenty. Even when you inline code to save the overhead of call/return, you will be aware of the functional purpose of those 50 instructions considered as a single entity. The same discipline required to write well-constructed code is needed for assembler. It's similar to using an old version of BASIC, with only GOTO and GOSUB for transferring control; although it allows the sloppy thinker to produce spaghetti code, a good coder will adhere to the same abstractions as they would use in a higher level language.

I'll stop rambling about the past and go and write myself a Forth system now :-)

(P.S. p-code was extremely cool. When I first got acquainted with Java, it was the first thing I thought of. Plus ca change, plus ca ne change pas...)

Article text

[kiwipeso]

Mountain View, Calif. - Sun Microsystems is inviting competitors IBM Corp. and Cray Inc. to collaborate on defining a new computer language it claims could bolster performance and productivity for scientific and technical computing. The effort is part of a government-sponsored program under which the three companies are competing to design a petascale-class computer by 2010.

Sun's goal is to apply its expertise in Java to defining an architecture-independent, low-level software standard - like Java bytecodes - that a language could present to any computer's run-time environment. Sun wants the so-called Portable Intermediate Language and Run-Time Environment to become an open industry standard.

The low-level software would have some support for existing computer languages. But users would gain maximum benefit when they generated the low-level code based on the new technical computing language Sun has asked IBM and Cray to help define.

Whether IBM and Cray will agree to collaborate on the effort is unclear. Both companies have their own software plans that include developing new languages and operating systems as part of their competing work on the High Productivity Computing Systems (HPCS) project under the Defense Advanced Research Projects Agency (Darpa).

"We think languages are one area where the three of us should cooperate, not compete," said Jim Mitchell, who took on leadership of Sun's HPCS effort in August.

Last week Sun proposed to IBM's HPCS researchers they pool separate efforts on such a software language, an idea Sun said Darpa officials back. Sun also plans to invite Cray into the effort. Representatives from IBM and Cray were not available at press time.

The language could be used not just for the petascale systems in the project, but for a broader class of scientific and technical computers.

"Java has made it easy to program using a small number of threads. But in this [technical computing] world you have to handle thousands or hundreds of thousands of threads. We need the right language constructs to do that," Mitchell said.

What's the point?

[Sheetrock]

We've already established that moderate proficiency in a high-level language with a good optimizing compiler is worth far more than mastery of assembly in today's environment, what with the size and scope of most programming tasks nowadays. Creating an intermediate language seems to couple the worst inefficiencies of high-level programming and assembly micromanagement: something akin to writing 'machine code' directly for a Java VM to optimize your application instead of just writing the darn thing in C, compiling it to the three platforms it's going to run on, and getting a 300% speed boost.

What's wrong with making a good compiler that writes directly to machine code? I would think Cray and IBM would be even more inclined to do so, given their control over the hardware their software will run on.

Re:What's the point?

[miu]

I think they are hoping that creating intermediate targets will make optimization and scaling easier. This is similar to the approach taken by gcc. The core compiler team can focus on creating a correct and effecient intermediate representation and the team porting to a new architecture focuses on taking the intermediate representation and creating correct and effecient assembly for that target.

Re:What's the point?

[basking2]

This is a good question to ask.

So, one of the ideas behind C# was to make an intermediate laguage (MS-Java-byte-code, if you will) which could be quickly compiled for the CPU in question. Stick a system call envrionment and garbage collector around it and you have [roughly] what C# is. One of the nice things about Java was that it was for no specific machine... it was very very simple at the instruction level, but making native code from that can be a pain.

Now, from the looks of the posted article some folks now want an intermediate laguage that can represent concepts like instruction vectorization and maybe SMP (hypter threading) and perhaps some other more complicated constructs that Java's machine code just doesn't talk about.

The end result is that you would have very fast machine code for the number-crunching loops in the code and portability. The compile time would be fairly quick and the optimization for the local CPU would be "smart" and fast if you marked up what where vectorizable instructions.

Why C# falls short, I can't say. I've only looked at the Java machine, never at how C# represets a program.

Hope this is helpful!

Re:What's the point?

[Tim C]

omething akin to writing 'machine code' directly for a Java VM to optimize your application instead of just writing the darn thing in C, compiling it to the three platforms it's going to run on, and getting a 300% speed boost.

Can you provide any evidence for the quoted 300% speed boost? I code Java for a living, and ignoring the JVM startup hit (how often do you start and stop the sort of app you'd write in Java anyway?), it's anything but slow.

Re:What's the point?

[plastik55]

Because a well-designed intermediate language will help optimization. Being somewhat higher-level than raw machine code, not yet having to worry about the specific details of registers and pipelining, makes it easier to perform higher-level optimizations because the IL can be more easily analyzed. And when you compile from IL to the target you will have just the same opportunities for platform-specific optimizations as if you had compiled straight from the source language.

The other benefits of using an IL are manifold. New languages can be implemented without having to write a compiler for each platform. New architectures can be supported without having to write compilers for each language.

Re:What's the point?

[iabervon]

All good compilers use at least one intermediate language. It's practically impossible to do good optimizations otherwise, even on a single platform. For example, you want to inline functions if that would improve performance, but in order to determine whether it improves performance means that you need to look at things like register allocation, which depends on things like the machine code implementation of complex expressions; however, inlining a function needs to be done with the higher level information about flow control and the structure of the function call. So you basically can't do any of the interesting optimizations without a good intermediate language.

Furthermore, getting from the high-level langauge to the intermediate language is cross-platform, which means that any optimizations done at this level are then available to all of the code generators for different platforms; this code is reused across back-ends. It also means that you can support multiple front-ends with the same back-end, and make your C++ and Java automatically compatible by virtue of sharing an intermediate language, and they also both benefit from the same architecture-specific back-end.

There's no reason that having an intermediate language means that you'll stop compiling at that level and use an interpreter for the intermediate language to run the program. In fact, gcc always compiles its intermediate language into machine code, and it can compile Java bytecode into machine code as well. Modern JVMs compile the bytecode into native machine code when the tradeoff seems to be favorable, and they can do optimizations at this point that a C compiler can't do (such as inlining the function that a function pointer usually points to).

An intermediate language essentially pushes more of the skill into the optimizing compiler, because the same optimizing compiler can be used for more tasks. Also, if the compiler is used at runtime, it can optimze based on profiling the actual workload on the actual hardware. This is especially important if, for example, IBM decides to distribute a single set of binaries which should run optimally on all of their hardware; you run the optimizer with the best possible information.

Re:What's the point?

[tomstdenis]

" it's anything but slow"

It's also a memory hog! ;-)

Kiddin. Whatever I code in C. I let the compiler sort out what platform it runs on. [hint: I write portable C code so it doesn't matter]

Tom

Re:What's the point?

[Tim C]

Please, enlighten us. I'm not trolling, incidently - I'm a Java programmer professionally, although I admit that I've not really looked too deeply into Java's bytecode, but I'm training myself in C# and .NET - I have a genuine interest.

Anyways, why are there a bunch of Java programmers, ignorant of .NET architecture and capabilities, who are so intent on slandering .NET? If people criticize something, shouldn't they at least understand that thing first?

Same reason you get C/C++/Perl programmers slandering Java, and Linux zealots slandering Windows, Windows zealots slandering Linux, vi users slandering emacs, etc, ad nauseum - people around here have a tendency to either hate what they don't know, or try it once, hate it, and never touch it again, remaining ignorant of how it has improved since.

Re:What's the point?

[HiThere]

I will consider "fair treatment" for NET once I'm convinced that it isn't tied by patents or copyrights or other legal restrictions to the implementations that MS chooses to allow.

OTOH, I'm dubious of Java for similar reasons. But Sun is in less of a position to be abusive.

Re:What's the point?

[grotgrot]

What's wrong with making a good compiler that writes directly to machine code?

Because that doesn't give you best performance. Machine code represents an exact processor implementation. Tradeoffs have to be made with backwards compatibility (eg Redhat is compiled for Pentium), expected cache sizes (optimising size vs performance), processor specifcs (Itanium has 4 instructions per bundle, Sparc has one instruction after branch) etc.

While it is true that you could compile for an exact machine, it is a horrible way of trying to ship stuff to other people, and it does require recompilation if anything changes. (The former is why Redhat pretty much picks base Pentium - if they didn't they would need 5 or so variants of each package just in the Intel/AMD space. Granted they do supply a few variants of some packages, but not everything, and Gentoo people can confirm that doing everything does help).

Using IL lets the system optimise for the exact system you are running at the point of invocation. It can even make choices not available at compile time. For example if memory is under pressure it can optimise for space rather than performance.

It also allows for way more aggressive optimisation based on what the program actually does. While whole program optimisation is becoming available now (generally implemented by considering all source as one unit at link time), that still doesn't address libraries. At runtime bits of the standard libraries (eg UI, networking) can be more optimally integrated the running program.

Machine code also holds back improvements. For example they could have made an x86 processor with double the number of registers years ago. If programs were using IL, a small change in the OS kernel and suddenly everything is running faster.

Needless to say, using IL aggresively is not new. To see it taken to the logical conclusion, look into the AS/400 (or whatever letter of the alphabet IBM calls it this week). I highly recommend Inside the AS/400 by Frank Soltis.

Re:What's the point?

[angel'o'sphere]

Ah, come on, that is anything but not insightfull ...
What's wrong with making a good compiler that writes directly to machine code?
a) it wont run on my phone, because no one will port teh compiler
b) it wont run on my new internet enabled microwave, because no one want to port the compiler
c) it wont run on my cars electronic, as no one want to port teh compiler
d) it wont run on the next ESA space probe, the Venus Express, because no one want to port the compiler
and so on.
Whats wrong with having an ultimative VM designed and freeing all software developers from all porting issues for one and for ever?
Whats wrong with having an ultimative VM designed and freeing all hardware developers to be braked out by compatibility issues?
Come one, code geeks. Make a step into the future!! A 4 GHz Pentium is about 16 million times faster than my Apple ][ which I used 15 years ago. Why should I be burdened with coding habits over 20 years old? I dont want to write 10 to 100 lines of assembelr a day, because it expresses far less in terms of instructions than 10 to 100 lines of C. And I dont want to write 10 to 100 line sof C a day becaue it expresses far less in terms of instructions than 10 to 100 lines o C++ ... and so on for Smalltalk, Python, LISP ...
We need more different higher level languages and more VMs, as it is easyer to make a new VM than a new processor. We do not need more compilers for the same old languages just because one built a new processor somewhere ... which is wasting 80% of its die (and 80% of its resources, energy put inot its production, waste produced and released into the environment) to be "compatible" with some old 8086 invention.
angel'o'sphere

Re:What's the point?

[Lazy Jones]

Because a well-designed intermediate language will help optimization

All good compilers already use well-designed intermediate languages. A general intermediate language that aims to be equally suitable for many high level languages will most likely be inferior to the best intermediate language for a particular high level language.

The other benefits of using an IL are manifold. New languages can be implemented without having to write a compiler for each platform.

Great. Just what we need - another of those braindead technological "advances" like human-readable data interchange formats that makes life easier for a few developers (simpler, cheaper compiler development) and harder for millions of users (worse performance). Frankly, the only advantage for the rest of us I can think of would be the higher probability of the resulting tools being mostly bug-free.

Re:What's the point?

[Mike McTernan]

In terms of compiler optimisation, the higher the language the better. Strict typing and a language that allows the compiler to infer more about the call tree should enable better global optimisation. Lower level languages suffer from the problem that the programmer is explictly describing how to do something, and not what it is trying to do; thus the compiler can just unroll loops and perform peephole optimisations.

If a language was sufficently high enough that you could describe to the compiler that you were implementing a recursive function (e.g. shell sort), the compiler should then be able to perform fold-unfold optimisation and convert the code into a more efficient tail iterative function. Fans of Haskell and similar languages might recognise this. Some C compilers will convert recursion to iteration where possible, but this is only in simple cases.

The fact is that today, even as C has reached maturity and as high level as it is, there are still some optimisations that are impossible because of subtleties of the language. For example, multiple pointers may point to the same memory, but depending on how the pointers are assigned, the compiler has no idea that this is the case, and has to follow the code in a literal fashion.

My personal view is that languages like Java still have a lot to offer. I would like to see a lot more investment in the compiler to perform better optimisations, and would also like to see a compile on install system for Java like C#; if I run an applcation it would atleast be nice if the compiled parts were cached somewhere. This I believe could make good performance gains, and it's interesting that Sun's Server Hotspot VM actually performs more optimisation when compiling a class than the Client VM, however, because of the increase in time taken to load and compile a class, the Client VM omits some optimisation techniques to favour speedier loading. I guess this descision is to make GUI's more responsive and reduce app load times; compile at install would remove this constraint. We should be going to higher level languages, not lower, and concentrate on getting to compiler correct.

Re:What's the point?

[AKAImBatman]

Well considering Java's startup time removes it from all manner of applications, it's a bit of a strawman to argue that startup time doesn't matter.

*cough* *cough*
Bullshit
Bullshit
Bullshit
Bullshit
Bullshit
Bullshit
Bullshit

Please take your bullshit trolling elsewhere. There are those of us with work to do.

Re:What's the point?

[whereiswaldo]

Why didn't they play the "patent card" with Win32? They could have raked in the dough by charging every application developer a licensing fee.
Because it has anti-trust all over it and would hurt Microsoft more than help it.. The same thing applies to .NET.

That may be so that antitrust would come into play, but I really doubt that is the reason Microsoft hasn't charged app developers licensing fees for Win32.
The real value of an operating system is the applications that run on it. Microsoft wants everybody to be writing applications for MS Windows, and not for other operating systems. It is in their best interest not to charge licensing fees to allow people to write on their OS.

On the other hand, it is not in their best interest to have a lot of people writing applications for Linux and other operating systems (since that adds value to those operating systems). For this reason, I would not be surprised if Microsoft tried to hinder development on other platforms, however that may be accomplished. The bottom line really is, it's up to them what they want to happen with .NET, not you.

Re:What's the point?

[gregfortune]

Granted, it doesn't (yet) have some database specific features such as server settings, but those settings are often managed by the DB sysadmin with command line tools anyway.

Yep, that's me :) As an independant consultant doing everything from project management to programming to tech support, I end up doing pretty much everything and most of it remotely through ssh.

As to a custom solution in VB, I'll bet it didn't have pie charts, graphs, "top 100" listings, and other great features that help find those lost ISOs, installers, temp files, etc. Oh, and did I mention that it's free? :-)

Yes, all of those things... Is it as fast as du and find? Couple that with the fact that I really don't care about the graphs/etc and it's not something I'll probably ever bother with. Admining remote servers does something weird with the minds of people and prevents them from enjoying any nice GUI tool 'cause they're not real useful through ssh with X forwarding disabled ;o)

You use Linux and you don't use BitTorrent to download it?! String him up by his pinky toe!

Yep, no BitTorrent for me. Gentoo freak here. You use Linux and you need BitTorrent? Hand over your geek license now! :)

Wasn't able to get Wurm Online working... Looks like most of the people on Windows centric anyway, but I might post a message up on Monday and try to get it figured out.

As far as CVS goes, I'm command line. If I have to do a diff, I end up in kompare (very very sweet little program) and I've fired up Cervisia a couple times, but haven't really found it necessary. I don't do much tree maintence because I'm a pretty solitary developer, but for the times I have needed to look through changelogs, etc, the command line tools suffice. If times change and I actually get to hire employees (woot!), I'll have to hunt down a good tool like SmartCVS. If it's the only thing available, I'll run it even if it starts slow :) FYI, the screenshots make it look like a very nice program.

Back to the topic at hand, I agree that apps can be written poorly in general and a slow startup time in an app doesn't mean that all apps written in that language will be slow to startup, but my personal experience thus far is not very promising.

When I said I avoid Java apps when I have a choice, it's because when I look for a new editor/tool/etc and I compare a couple of apps, I tend to gravitate towards those apps that *feel* fast. I have yet to find a Java app that I *enjoy* running.

XML ?

[noselasd]

Did I see XML and performance in the same sentence ?! ... brain overload.. does not make sense...

Re:XML ?

[Anonymous Coward]

Good god. XML is VERY VERY good for what it was designed for: semantic markup of texts. It is not very good as a straightjacket on a programming language.

Re:XML ?

[benjamindees]

I saw that too.
Then I saw Posted by michael and everything was better.

Re:XML ?

[noselasd]

Indeed it is, still, people want to use it for just about anything it _wasn't_ desgined for. ;-(

Re:XML ?

[mabinogi]

That may be true, but XML would be a great way to bring them back!

Re:XML ?

[mrogers]

The days that loading binaries from disk into memory was a significant performance hit are long gone...

Haven't used Mozilla recently, have you?

Re:XML ?

[squiggleslash]

XML is not for the semantic markup of texts. That's HTML and its XML equivalents. XML is a way of encapsulating structured data in a text format that's "easy" to parse.

Now, in all honesty, I still think it's a lemon, but it's not quite as limited (or intended to be limited) as you suppose it is.

I just wish IFF had survived the death of the Amiga as a mainstream platform.

Re:Next try?

[be-fan]

Eh? I think that's a large coffee at Starbucks. I think it goes "Java short," "Java tall," and "Java grande."

but the biggest question is...

[b17bmbr]

The effort is part of a government-sponsored program under which the three companies are competing to design a petascale-class computer by 2010.

will sun survive until then?

GCC

[norwoodites]

Sun should have invited us GCC developers also to help out with this because most of us want a way to do Inter modular optimizations but we have the FSF looking over our shoulder on how we implement it, right now (the mainline) you have to compile all the source files at the same time to get IMA to work correctly and you have to say to produce an .o file first.

Buzzword compliance

[ajs]

I really hope the author's smiley was to indicate that he understood that his string of buzzwords was meaningless.

What I hope is that Sun takes a good, long look at the only intermediate assembly that has been designed with language neutrality in mind, Parrot. While this article is over 2 years old, it's a decent starting point. Parrot has already been used to implement rudimentary versions of Perl 5, Perl 6, Python, Java, Scheme and a number of other languages. The proof of concept is done, and Sun could start with a wonderfully advanced next generation byte code language if they can avoid dismissing Parrot as, "a Perl thing" with their usual distain for things "not of Sun".... IBM on the other hand is usally more open to good ideas.

Re:Buzzword compliance

[Tim C]

Language neutral? Perhaps I'm just skimming your linked-to article too quickly, but this is what leapt out of the page at me:

"Parrot is strongly related to Perl 6... Perl 6 plans to separate the design of the compiler and the interpreter. This is why we've come up with a subproject, which we've called Parrot that has a certain, limited amount of independence from Perl 6." [emphasis added]

That certainly doesn't sound like it's been designed with language neutrality in mind. For what it's worth, MS's IL was designed with at least four languages in mind - VB.NET, C#, managed C++ and J#, and a couple of dozen others have been or are being ported to it, including Fortran, Cobol, Haskel, and (iirc) even perl.

As you say, the article is over two years old, so maybe they've changed their goals since then - but that article at least gives a very strong impression that Parrot is tied intimately in with Perl.

Re:Buzzword compliance

[penguin7of9]

Parrot looks like it will be a nice intermediate language for languages like Python, Perl, and Java. But Parrot lack the right primitives for an intermediate language for high-performance numerical computing.

Right now the only widely used intermediate language that comes close to being suitable for high-performance numerical computing is Microsoft's CLR (JVM actually still has better implementations, but it lacks important primitives like value classes).

Re:Buzzword compliance

[Elian]

Nah. we put that in to not scare people. Parrot is, for all intents and purposes, completely independent from Perl 6 and has been for ages. (well before that article was written). While we're going to put in anything we need to make perl 6 run on parrot, the same can be said of anything we need to run Python and Ruby. (Which has already happened, FWIW) The only difference is that Matz and Guido haven't asked for anything yet...

*SIGH*

[mike3k]

No wonder we have to keep making faster CPUs just to maintain the same performance. Is Java on a PIII or G4 any faster than hand-optimized assembly code on a 486 or 68030?

Soon we'll need a 10 GHz CPU just to be able to boot tomorrow's OS in less than 5 minutes.

ANDF?

[myg]

What about the Architecture Neutral Distribution Format from the TenDRA project?

That format could be extended into a vendor-neutral format for both interpretation, just-in-time compilation, and batch compilation.

Need more info...

[devphil]

The article is very light on details.

The low-level software would have some support for existing computer languages. But users would gain maximum benefit when they generated the low-level code based on the new technical computing language Sun has asked IBM and Cray to help define.

Huh?

So, how many languages are being proposed here? A new "low-level" one, plus a higher-level "technical computing language" designed to make the most of the lower-level one? Just what's so special about this new low-level language that requires a specific new language to get the "maximum benefit" out of it? I don't have to write in Java to be able to compile to the JVM bytecode. For that matter, I could write in Java and compile to some other assembly language.

New back-ends ("low-level languages," if I understand the article) are added to GCC all the time. We never needed to add a whole 'nother front-end just for them.

I suspect that the real situation is less weird, and the journalist got confused... or heck, who knows, maybe they're proposing half a dozen new languages. It's Sun, after all.

Maybe now I won't have to write my neural network in C for performance :-)

Odd. I wouldn't have thought you'd need to do that these days anyway.

Reminds me of the old quote...

[Waffle Iron]

"There is no problem in computer science that cannot be solved by adding another layer of indirection."

high-performance computing

[Via_Patrino]

I don't think they're trying to create a language for "high-performance computing" but a language for a "high-performance multi-processor computer", since they're focusing on threads and sun isn't a very good example (jvm) of high-performance.

In my opinion I would like a C language variation that let me specify how many bits i would like to use for a variable, because it would save a lot time because of memory bandwidth (cache space included) and is very boring to make a good implementation of that in assembly.

What struck me was this

[Anonymous Coward]

"I wonder if the format will be in XML? [...] Maybe now I won't have to write my neural network in C for performance"

Is he on crack? :-)

Parrot assembly?

[Ars-Fartsica]

I thought an open, peer-reviewed, high performance IL/runtime was exactlywhat Parrot was trying to accomplish.

what is new about this??

[esj at harvee]

Architectural Neutral Distribution Format has been around for years and solves many of the same problems (and more).

I guess it is one more time around the (reinvention) wheel for sun.

Re:Next try?

[The Lynxpro]

"One thing puzzles me, however. What is Java grande? Was it so shortlived that I missed it?"

Better yet, where is Java Venti?

If you stop and think about it, what could a Sun/Starbucks partnership entail? The Starbucks card working on the SunRay platform, taking your virtual login identity to every Starbucks location you frequent? Even better to realize that just about all Starbucks locations have WiFi hotspots. Oh the conspiracy!

Please clarify

[Anonymous Coward]

Is it the 'XML' and 'performance' or fact that you found a complete sentence on Slashdot sending your brain into overload?

Cheer up.

[SharpFang]

Quite insighful... but it isn't as bad as it looks.
1) Nobody forces you to write in Java for PIII. Write hand-optimised asm sniplets for PIII and include them in bigger Java or C app for time-critical pieces. You get real PIII performance.
2) The software quality drops, but slower than CPU speed rises. That means your Java app for PIII will still work -slightly- faster than hand-coded ASM for 486.
3) Development cost. You can spend a week to write a really fast small piece of code in ASM. Or you can spend that week on writing quite a big, though slow app.
Most visible in games. Things like Morrowind, where crossing the map without stop takes a hour or more, and exploring all the corners is months of play, were plainly impossible when it all required hand-coding. Now for a developer it takes shorter to create a mountain in game than for a player to climb it. Of course the player needs better CPU to be able to display the mountain which wasn't hand-optimised, just created in an artificial high-level language defining the game world, but if you're going to enjoy the experience - why not?

UCSD Pascal

[Detritus]

For its time, UCSD Pascal was an excellent language and operating system. Its main problems were price and politics, not performance or technical issues. Many people, including myself, wrote software for it. The speed penalty of the p-code interpreter was offset by the compactness of p-code, which was important on the memory-constrained PCs of the time. UCSD Pascal, like other alternative operating systems of the period, could not compete with MS-DOS and PC-DOS, which sold for well under $100, on price.

C-Bonics

[Epistax]

I propose that this intermediate language be called C-Bonics, and it should be taught in all classrooms in place of C. Many people don't learn proper C in their homes so it isn't fair to force them to do it in school.

If you've not implemented parallel code X-Arch

[fw3]

Then you (like the pos(t)er of this article and most of the comments) probably don't follow what the value is here.

Maintaining high performance code across cpu achitectures is bad enough (and I know of some supercomputing centers which are continuing with technically inferior AMD64/Xeon clusters rather than switch to PPC970 precisely because they know they can't afford to re-optimize for that arch).

Factor in that today most numerically intensive code is still written in FORTRAN because competing languages simply can't be as easily optimized.

Now let's think about SMP, while POSIX threads are portable, the best performace probably requires different threading code depending on arch/unix varriant. (And of course NPTL for linux is still in CVS.)

Now let's think about massively parallel, where inter-cpu communication will be handled a bit differently on every platform.

So the payoffs to developing an efficient cross-platform language layer are pretty substantial. (Which does not imply that I expect IBM to jump on to Sun's bandwagon on this :-))

Grid

[AaronGTurner]

There are several issues with regard to current programming techniques and grid computing for HPC. Some include:

• Legacy code - both user code and 3rd party libraries such as NAG.
• Matching OSes. Java alleviates this to some extent at the expense of performance . Also not all JVMs are equal. If you can use more resources then slower, less efficient execution isn't such a problem. I.e. a balance between ease of use and code efficiency. Good java code helps!
• Matching executables and dynamic libraries. Static compilation helps.
• Matching system capabilities for additional tools, such as MPI, PVM etc
• Licensing
• Data replication, transfer, etc

Java isn't a bad way to offer the capability to run your code on many platforms, but it is easy to write slow code that really doesn't match the HPC speed requirement, although some do use it for HPC. Faster bytecode or JVMs that do ecen better at optimising bytecode would be a help, but I am not sure if there is enough algorithmic information left in the bytecode to allow the best optimisations on all architectures. Perhaps this is where the new initiative is aimed?

An alternative route is to publish capabilities for processing via web or grid service type mechanisms and then use brokers and discovery services. This would work well for widely used production codes, e.g. charm, fluent, etc

too little, too late

[penguin7of9]

The effort is part of a government-sponsored program under which the three companies are competing to design a petascale-class computer by 2010.

We already have such a runtime: it's called "CLR". The CLR is roughly like the JVM but with features required for high performance computing added (foremost, value classes).

Sun wants the so-called Portable Intermediate Language and Run-Time Environment to become an open industry standard.

I hope people won't fall for that again. Sun promised that Java would be an "open industry standard", but they withdrew from two open standards institutions and then turned Java over to a privately run consortium, with specifications only available under restrictive licenses.

Sun's goal is to apply its expertise in Java to defining an architecture-independent, low-level software standard - like Java bytecodes - that a language could present to any computer's run-time environment.

Sun's "expertise" in this area is not a recommendation: the JVM has a number of serious design problems (e.g., conformant array types, arithmetic requirements, lack of multidimensional arrays) that attest to Sun's lack of expertise and competence in this area.

What this amounts to is Sun conceding that Java simply isn't suitable as a high-performance numerical platform and that it will never get fixed (another broken promise from Sun). But because the CLR actually has many of the features needed for a high-performance numerical platform, Sun is worried about their marketshare.

The question for potential users is: why wait until 2010 when the CLR is already here? And why trust Sun after they have disappointed the community so thoroughly, both in terms of broken promises on an open Java standard and in terms of technology?

Maybe we will be using a portable high-performance runtime other than the CLR by 2010, but I sure hope Sun will have nothing to do with it. (In fact, I think there is a good chance Sun won't even be around then anymore.)

Re:too little, too late

[penguin7of9]

You are quite right that current JVM implementations will outperform CLR implementations on comparable code. That's not surprising since JVMs are far more mature.

But that is only true for comparable code. If you write C# code using value classes and do an idiomatic translation into Java, the Java code will run very slowly because you cannot express something like a value class efficiently in Java. It doesn't matter how good the Java JIT is, it just can't optimize things that the JVM doesn't let programmers write down.

And the advantage that JVM JITs have on the more limited functionality they offer is likely short-lived: give CLR implementations another year and they will equal the JVM on their common subset of instructions, and they will still have the advantage of their additional primitives.

Note that Sun is not talking about extending the JVM anyway; this sounds like it's going to be a new and incompatible virtual machine from Sun.

who cares about who Sun invites?

[penguin7of9]

I don't see how Sun is even relevant or why it matters who they "invite". They had their chance with Java and they blew it. I doubt the numerical community is going to give them another chance after what they have been through with Sun over the last decade.

I suspect the next intermediate language for high-performance numerical computing is either going to be the CLR, some extension of the CLR, or something entirely different, developed in academia.

This could have cool implications

[Omega1045]

Even if other big players like MS do not participate, this could really be cool for cross-platform applications. Imagine a caching JIT for such a language. Now imagine a converter that could take Java or .NET assemblies and convert them to this new "byte-code". I am sure a 3rd party would step-up to write the MS version!

Now we are talking! I want my C# to compile to native code on Linux, Sun, and IBM mainframes. I want to take Java programmers in my firm and have their code call my C# and visa-versa. This could be a big step towards that.

Re:Next try?

[kingkade]

Ok, so now that Java is on the retreat they try to enter a new area?

It's probably because there's no Java user community or usefull implementations out there. And it has virtually no practical application on the desktop for that matter. Maybe because it doesn't do 3D or sound. Or is not so usefull as far as scalable RDBMS abstraction or a real application server for the enterprise. Maybe they need to move into the mobile market. What's really needed is a good Java IDE to get developers on board. Changes should be driven by the software community and making the source open would help as well. Sun should also be making improvments in Java's next(?) version.

You're right, I guess "we" should just cut our losses.

SUN does not understand High Performance Computing

[Anonymous Coward]

Having tried to write HPC apps in Java, there are some very serious problems with the current JVM.

1. Lack of scientific data types, such as complex numbers.
2. Lack of multidimensional arrays.
3. Inept implementation of floating point arithmetic.
4. Poor choices for defaults, such as array bounds checking and pretty printing ascii I/O.
5. Onerous penalties for JNI calls and serialization.
6. Intermindable process for correcting deficiencies with the language.

SUN has not displayed an understanding of HPC. Adding OpenMP or other "HPC" friendly capabilities to the VM is not going to correct design decisions with remove performance from "High Performance computing.

Re:Next try?

[bckrispi]

Java is on the retreat??? Wow, I've been gainfully employed as a Java architect for the past five years; it musta' been a fluke. IBM, Oracle, Novell, et al must not know what their doing by investing millions in building their products around the Java platform. Come to think of it, there are sooo many alternatives to Java for enterprise, server-side computing. Thank you for your insight. I'll turn in my resignation and pick up a .Net book tomorrow.

XML?

[CatOne]

Why, so intermediate files can be 100 times larger than they already are? :-P

Mod parent up

[Anonymous Coward]

That is right on the money. Sun is trying to make an alternative to the CLR - a blantant attempt to take back developers who've switched from Sun J2EE to MS .Net.

Now, I'm all for having alternatives, but what's going to happen to Java? Will Java compile to IL? The Mono project and DotGNU project both have plans for compiling Java to IL, allowing .Net and Java apps to talk to each other natively - why then is Sun developing yet another IL standard? The Common Intermediate Language, the ECMA standard which is used by both .Net and Mono, is the only IL we need. On the other hand, building multiple implementations of the standard IL for running on different operating systems is where Sun should be focusing their efforts.

Only if Sun's IL interoperates with the Common Intermediate Language will I be rooting for Sun.

My God, they've reinvented CADOL

[rs79]

Why is it I find PARROT more readable than Perl?

LLVM?

[shnarez]

Why not just use something like LLVM and/or extend it instead of re-inventing the wheel?

LLVM is already made to be low-level (like assembly language) but with high-level types (struct, int, array) like high-level languages. Sounds like just what they would want.

FREE YOUR MIND!

[SharpFang]

Don't limit your imagination to bounds of i386-compatibile architecture!

Ever thought about writing interpreter or VM in VHDL and implementing it on a FPGA board? That would be pretty similar.

>if it supports things like procedures
Stacks substituted for local variables, CALL, RET, what a problem?

>nested complex arithmetic expressions,
Can be un-nested at compile time, not really going far from assembly. Just remember that each +, ( or % is a separate call. Can be RPN, why not? That's very close to assembly.

>and named varables
Is it a big problem in assembly? Just pick a register or memory cell and give it a name.

>and no sane high-level language can be without those things.
Implementing some of those in compiler (ASM needs compiler too!) and the rest in hardware is far from impossible :)

Simply start the design not like with modern languages "We need commands that do this, that and that" and then try to fit them into existing hardware through compilers, but build a hardware that can perform your basic commands directly. So if I call fork(), I don't get a ton of system commands launched, just a single CPU cycle gives me a nice copy of the process and it runs _really_ simultaneously, not by time-sharing. If I want to send signal to some other process, it doesn't go through several levels of OS indirection, it's handled by the hardware, like a hardware interrupt. To perform write() and consider it done in one cycle, or at most as many cycles as many characters i'm writing(). by having my Of course I'm limited by the hardware on how much I can do, but isn't that the case always? Just that next to limits on RAM and CPU speed I get limits on number of variables, number of processes etc? (especially if I can make those dynamic limits, buy better chip, get more processes)
The problem with C is that it's -a bit- too far from the hardware. A bit too much goes on without programmer's knowledge. How do I know ++ operator is 1-cycle CPU INC command or a 300-cycle call to math library to perform addition? I want to be able to select a chunk of code and see CPU cycle count. To have granted command execution time.

so let me get this straight...

[Kunta Kinte]

The question for potential users is: why wait until 2010 when the CLR is already here? And why trust Sun after they have disappointed the community so thoroughly, both in terms of broken promises on an open Java standard and in terms of technology?

You don't trust Sun, so you're recommending...

Microsoft????

Ohh-kayyy..., next post please.

Compilers 101

[p3d0]

I don't understand your question, but if you're asking why we need intermediate languages, then I can answer that.

Imagine N high-level languages and M target platforms. A naive approach would wind up creating NxM separate compilers.

Intermediate languages (ILs) allow you to write N "front-ends" that compile the N high-level languages to the IL, and M "back-ends" that compile from the IL to the M target platforms. So rather than needing NxM compilers, you only need N+M.

Even more significant is the optimizer. Front-ends and back-ends are relatively straightforward, but optimizers are very hard to write well. In the naive approach, you need NxM optimizers. With an IL, you only need one. The front-end translates to IL; the optimizer transforms IL to better IL, and the back-end translates to native code.

In summary, to answer one of your questions:

What's wrong with making a good compiler that writes directly to machine code?

Every optimizing compiler uses an IL anyway. These companies, I presume, are simply agreeing to use the same IL across their products (though I'm only guessing because the article is slashdotted).

About time.

[AnotherBlackHat]

I was begining to wonder if the pcode code concept was ever going to catch on - it's what, 35 years old now?

-- this is not a .sig

Oh god

[mcc]

So now it's considered a defeat or a "retreat" to create a new and improved version of one of your products?

Hey, I heard that Microsoft just released a new version of their OS and called it "Longhorn". cn I say "Ok, so now that WinXP is on the retreat they try to enter a new area?"

Personally, I would consider "Hm, Microsoft seems to be catching up to us. Let's make something better than current Java OR .net." to be the most extreme sign of life possible. Honestly I wish they'd done it sooner.

Re:Not unreadable XML ()

[kurt_cagle]

In all honesty, the XML would be generated at a level where hands would likely never touch it, more likely through a series of transformations. Having written XML generators for C++, C# and Java, I've found that the XML is, by itself, very verbose, because it is fundamentally a meta-level description. You wouldn't write:

<func optargn="burp">arg1 arg2 arg3 lst</func>

you'd write

<function name="foo">
<param name="arg1" type="xs:string"/>
<param name="arg2" type="xs:integer"/>
<param name="arg3" type="cplxOpj"/>
<param name="arg4" type="xs:string" optional="yes"/>
<!-- implementation code -->
</function>

In all likelihood, the fragment will have been generated via a UML interface or something similar, and this would then be produced through a simple transformation.

Before objecting to the cost involved, consider that both an XML parser and an XSLT transformation are fairly straightforward finite state machines, and could very easily be dropped into firmware (something that is already beginning to happen). Because of the ubiquity of XML, firmware processing of XML is making more and more sense, and once you have that, it becomes a natural for building ILs and related compiler technology.

Massive parallelism that doesn't suck is hard

[Animats]

This is yet another attempt to breathe life into the boondoggle of massively parallel architectures.

Over the last few decades, there have been many exotic parallel architectures. Dataflow machines, connection machines, vector machines, hypercubes, associative memory machines (remember LINDA?), perfect shuffle machines, random-interconnect machines, networked memory machines, and partially-shared-memory machines have all come and gone. Some have come and gone more than once. None has been successful enough to sell commercially in quantity. Very few of these machines have ever been purchased by any non-government entity.

There are two ends of the parallelism spectrum - the shared-memory symmetrical multiprocessor, where all memory is shared, and the networked cluster, where no memory is shared. Both are successful and widely used. Everything in between has been a flop.

Despite decades of failure, people keep coming up with new bad ways to hook CPUs together, and getting government agencies to fund them. It's more a pork program than a way to get real work done.

By the time one of these big wierdo machines is built, debugged, and programmed, it's outdated. A few years later, people are getting the same job done on desktops. Look at chess. In 1997, it took Deep Blue to beat Kasparov. Kasparov is now losing games to a desktop four-processor IA-32 machine.

Figuring out more effective ways to use clusters is far more cost effective than putting a National Supercomputer Center in some Congressman's district in Outer Nowhere. There's a whole chain of these tax-funded "National Supercomputer Centers". The "Alabama Supercomputer Center" has ended up as an ISP for the public school system, hosting E-mail accounts and such. It's all pork.

Not enough

[12357bd]

Think big please. Hundreds of thousands of threads, is not enough, we need millions, thousads of millions of threads.

The only way to get to this level is changing hardware. Current computers, are big memory pools with a single (logical) execution unit, that's the fault.

We need to build thousands of simpler executions units, and parallelization will be a real issue. Switching threads/process is not the answer.

On the software front, two musts for a new languaje: a) it should be 'aspect oriented' (flexible interception). b) automatic paralelization extracted at compile time from objects sets analisys.

Next sig please..

JAVA vs. .NET

[digitaltraveller]

Putting corporate politics aside, what would be nice from a technical perspective is an intermediate language that is register-based. Microsoft decided to copy java so thoroughly they also copied java's mistakes by making the .NET runtime a stack machine. Market reality tells us Intel/AMD is not going away anytime soon, it would have been wise to make MSIL fit more nicely into the x86 architecture for performance purposes.

The mono/.DOTGNU projects are similarly unfathomable. It will be nice to have these tools available to run more bloated GUI's, but if one of these projects really wanted to differentiate itself, that project should instead focus on a C# to native-compiler using gcc's backend and let the other project focus on a compiler-to-MSIL. I guarantee you that project would become the 'winner'.

Re:English as an intermediate language?

[NickFitz]

I don't have the patience to write more of this crap

You need Forth - possibly the only language where you make up the language as you go along.

Example of the Forth definition for the "make everything explode because the time or energy has run out" routine in a game I wrote years ago:

: kill_everything ( - )

player explodes
mine explodes
thing_at_top explodes
thing_at_side explodes
bubble bursts ;

FWIW, "bursts" was a convenience word used to make it read better. Its definition was:

: bursts (thing_to_burst - )

explodes ;

(The bits in brackets are stack diagram comments. The argument "thing_to_burst" is actually the address of the data structure representing the animated entity,)

By judicious use of the English language in choosing your names, you could write what people thought was pseudocode, and it compiled and ran :-)

Just one more reason to Free Java

[roman_mir]

I posted this before, but it looks to me that this is still on topic here. How about making Java Free, openning it to new possibilities, optimizations etc.
----------
I would like to see GNU/Linux to become a more powerful platform and by a more powerful platform I mean a platform that provides the user with a pleasant experience. Now, to provide a pleasant experience a platform must give the user a choice - a choice of applications that exist for the platform is a step in the right direction. However, GNU/Linux is not such a platform yet. If it were, it would have been embraced by the masses already and it is not. There are a few things that GNU/Linux system is lacking and one of the more important lacking components is a convenient tool that allows a novice create his/her own software for the platform, software that easily manipulates data imported from multiple sources and allows to create graphical interfaces to that data. In the Microsoft this functionality is provided by such a ubiquitous tool as Visual Basic. In the Free Software world there are many tools that are extremely powerful but none of them have the same kind of momentum that Visual Basic delivers on Microsoft platform.

To answer the question- "What can be the VB for Free Software?" we need to look at the kind of problems that will have to be solved by this tool. The problems solved by VB are of many kinds, but for the general public VB provides the bridge that closes the gap between a user and a multitude of small problems that the user wants to solve. Of-course it is possible to just create a VB IDE for FS platforms but I believe there is a more interesting solution to this problem and it is Java. Just like VB, Java runs in a virtual machine, so the user will never really have direct access to any hardware resources, but an abstract layer of JVM can provide a nice buffer between the user and the hardware and at the same time Java will always behave in the same way on multiple other platforms, including Windows. Java has thousands of convenience libraries, there is enough Free Software written for Java that can be integrated into an IDE. However there is a big problem with the language itself - it is not Free.

Sun allows anyone to use Java for free but nobody can modify the language itself except for Sun. In order for Java to become for Free Software and Gnu/Linux what VB became for Microsoft, Java has to be Freed and put out under the GPL. There is also probably a good business sense in it for the Sun Microsystems as well - their language suddenly becomes the language of choice for millions and thousands will work on improving the language, the virtual machine, the compiler etc. In this case Sun will stay in a position that Linus finds himself in - they become the gate-keepers for the vanilla Java tree, but Java will branch and will become much more spread than it is right now. Sun can capitalize on that by providing more Java based solutions and services.

Now it is likely that Sun management will not agree to the change of their Java's status, however, if there was an immediately profitable reason for them to do this, they just may turn around and start thinking about it. A reason that is profitable could be a large sum of cash available to them upon releasing Java under the GPL. Where could this money come from? These money could be collected by the FS and OS supporters, the developers and the users who would like to see more momentum in the GNU/Linux movement towards a successful (wide spread) desktop solution. I suppose no one will seriously object to have one more powerful tool in their Free Software tool-bag. Java can be this tool and it can be just the thing needed to tip the scales over towards quick appearance of a useful and a popular GNU/Linux desktop.

Re:Just one more reason to Free Java

[elflord]

Sun allows anyone to use Java for free but nobody can modify the language itself except for Sun. In order for Java to become for Free Software and Gnu/Linux what VB became for Microsoft, Java has to be Freed and put out under the GPL.

First, you've made the mistake of confusing the language with an implementation of the language. These are different things entirely. I'm not even sure what it would mean for the language itself to be "free". Maybe if it were submitted to a truly open standards group (like ANSI/ISO C and C++) that would make it more "free" but I don't see how that would help. Of course having a good free implementation of the language is important, but that doesn't mean that Sun needs to provide that implementation. gcc is not provided by the original implementors.

Of course there are free software implementations of java.

As for releasing java under the GPL -- I don't see it happening. Releasing it under an appropriate open source license would help Suns implementation become more popular, but they wouldn't be able to make money licensing their source code.

Re:*Sigh* how will decimal ruin this.

[jared_hanson]

Do you even know what you are talking about anymore?

Intermediate languages are essentialy a processor independant instruction set. You compile down to this instruction set and then let the virtual machine translate to the native instruction set, hence cross platform. These intermediate languages are binary and have no concept of decimal or hexidecimal.