Slashdot Mirror

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

A basic, ruby, python, fortran, pascal, or c compiler doesn't have to require any more resources than writing in java. The compiler just generates java byte code instead of the native instruction set for the CPU.
This website lists a lot of JVM languages http://www.robert-tolksdorf.de/vmlanguages.html

Sun has new language for client-side scripts.. Just-so-coincidentally, Sun has had a variation of this new "language" available in your browser for a decade! It's called applets and the JRE.

Python, Ruby, JavaScript, Groovy. Whatever. Sun has a Java runtime in the browser, a sandboxed one that can only access the DOM and browser. But you still get all the Java benefits, like multithreading and bytecode compilation. And all the Java benefits, like it's implemented for IE AND Firefox on Mac, Windows, Linux and Solaris. Further, it is available under the GPL, so you can port it to any other platform.

See this web page for details of Sun's leaner faster in-browser JVM.

On an unrelated note, I wasn't aware the .NET SDK was free. Interesting, but I can't see the justification in using F# over Ocaml. Of course, if you're using .NET you might as well get an MSDN kit and visual studio, so I can see where they're going with it.

.NET SDK 2.0. Also, as I mentioned, Visual Studio Express products are available for free for many different uses (app development, web development, database development, game development, etc). If you're developing software professionally, you probably would want to spring for a full Visual Studio product, but for individuals and small projects the Express SKUs work great. XNA's Game Studio Express is built on top of Visual C# Express, for example, and allows you to build games for Windows and/or Xbox 360.

As for why you would use F# instead of OCAML, IronPython instead of Python, Ruby.NET instead of Ruby, etc, is for interoperability. Because the languages are implemented to compile down to IL (.NET's Intermediate Language), they can be used with any other .NET language. For most people it's just a novelty, but it's still cool in a geeky way. BTW, this is no different than building compilers to target languages to the Java VM, like Jython. Why would you use Jython rather than Python? Because it can more easily interact with Java components and other languages compiled to the Java VM. Not a big deal if you're only doing Python work, but invaluable if parts of your product are written in Java and it makes sense to build other portions with Python.

I agree with you on the Lisp part.

Here is a nice link to Lisp and Scheme implementations on top of the JVM.

Until you bust out Haskell# or Lisp#. There are plenty of languages that run on the .NET framework and on the Java virtual machine.

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

I don't know about you, but it seems to me that there is more than one language that runs on top of the Java VM. Even if you debate whether it was "designed" to allow this or not, the other example I quoted was a generic system does meet your criteria.

While not heavily marketed, you can already run quite a lot of languages

If now, with .NET, this is the first time that Sun is thinking about adding other language compilers for their bytecode then they are way to late.

Two seconds of Googling could have told you that the JVM has supported more languages than .net for a long time.

I don't think they will ever be able to top the .NET support already there. If they think this is competing with .NET, it's to little, to late.

You do know that Java is MUCH bigger than .Net out in the real world?

More probable: Sun is going to add Ruby on rails to their JSP system, which is probably the only way they kan add anything to anything.

You really have no idea what you are talking about. Java developers could use Ruby to do fast and easy unit tests for instance. The scripting sessions at the last JavaOne showed lots of other interesting uses. Also it wouldn't surprise me if one possible long time plan wouldn't be to make the JVM the fastest, most stable and therefore the most attractive platform to run all Ruby programs.

I actually find the multi-language of of the CLR to be a negative. I work at a fortune 500 and most of us use C# and/or Java. There are a few groups of "programmers" that have always been VB-only/ASP-Only "programmers". They have really no understanding of programming maintainable code.

I'm not sure I follow your logic... How would forcing your poor programmers to switch languages make them better programmers? I think the best that you could hope for is that they'd still be poor programmers, just in a different language.

Besides, the Java Virtual Machine has just as many, if not more lanugages available for it than the CLR. (Note that I said "available" not "supported.")

sigh... .net is nothing more than a carbon copy of java, optimized for the microsoft OS. The funny thing is that while what you say is true about .net, that it can be targetted by multiple languages, it's kind of funny that you think this is something that .net has a leg up on the competition (java). There are 200 freaking languages that run on the jvm. There are many that are production quality. Microsoft doesn't support Mono on Linux, so every time MS "innovates" (aka copies another feature from java) there will be a delay and a lot of non-working code before Mono catches up. This guarantees that mono on linux will always be crappier than .net on windows.

Sun directly supports java on linux, and existing practice is to deploy new JVM's to linux at the same time as other platforms. The only arguable advantage of mono over java on linux is that it is open source. But even this whithers away when you investigate. Red Hat actually ships with a working open source java implementation called gcj. Just like mono, it lags behind, but it does work. Moveover, just about every new creation in java has an open source reference implementation. The java community has embraced open source. There are very few arenas where I would identify the best-of-breed example as proprietary. If you say "I will use the java JVM, but only open source tools on top of it" you really have not limited yourself much at all. The .net/momo community cannot match this. Sun has announced it intends to release the JVM to open source, and it is just a matter of time until this happens. They really have no choice because of the progress of cleanroom open source JVM's.

There are very few, if any, language feature advantages that .net/mono has over java. Both languages provide nice VM based OO environments. Accordingly, the bottom line is that it all comes down to the size of the body of reusable code. Java wins this with an extra zero at the end. There is so much innovation in the java community that it is exasperating to try to keep up with.

What an incredibly incorrect mess.

Microsoft realized this and tried to fix Java.

They put the delegate functionality in the source code comments. If you think that's a good design, you need your head checked.

Delegates can be easily replicated in Java via Reflection, but Microsoft didn't use that solution, now did they? In any case, it's a heavily discouraged solution. Objects can do everything that delegates can do without the need for special facilities. (Not to mention that they don't fail silently when the signature is wrong. Blech.)

Good GUI frameworks are event-based, meaning that you provide a function to be called when some event (like mouse click) happens. The way around this in Java is a mess of inner classes and listeners.

Listener classes are the natural solution to the problem. There's no "mess in inner-classes" except those done by lazy or bad programmers. But then again, I've seen some pretty crappy C/C++/ObjC implementations too, so don't get too high and mighty here. Especially with delegates, which tend to make just as much of a mess as inner classes do in Java.

Why is Java bad for generating code?

All langauges are bad at generated code, preprocessor or no. Modern Java IDEs use special comments to lock out the areas that are generated. This works just about as well as generated C code. (i.e. Not very well.) The "correct" solution is to use a resource file. In GNOME this is done in GLADE, in Mozilla it's XUL, and in Java you can take your pick. In the past I've built my own, but JAXX looks very nice. It looks like it's based heavily on XUL. (Which I happen to like.)

It is also impossible to debug generated code (like a .jsp) because the generator can't indicate to the compiler what the original line number of the source code was in the corresponding generated code.

You don't know what the hell you're talking about. JSP is actually easier to debug thanks to the fact that the page is inverted into a Java Class file. You can simply take a look at the generated source to find the problem. Most modern servlet containers also insert the line numbers of the JSP file as debugging information. This allows you to look directly in the JSP for the problem. This is made possible by the flexible nature of the Class file format. Something that other languages don't share. (At least, not while maintaining the performance advantages of fully compiled code.)

Why is Java bad for interoperating with other languages? The JVM was designed to run the Java language as specified 10 years ago, and nothing more.

Java is great at interoperating with other languages!

Okay, snarky comment aside, JNI is intended to maintain the integrity of the Java environment. It's not particularly convenient, but it works. Considering how *little* code needs to be written in JNI, this isn't a big deal. Most JNI code these days is autogenerated. (e.g. The JOGL project.) If you find yourself writing more than a VERY small percentage of your app using JNI, then you're doing something wrong. Java has all the libraries you need. You should be using those, and then a few small bindings to handle anything that needs to be native for compatibility.

An example of such a binding would be XPCOM.

Since it's C++, it has to be recompiled for every platform you want to distribute your code on.

Let me get this straight. You're complaining about having to recompile C++ bindings to native code? Is the native code you're interfacing with somehow magically cross-platform or something?

Perhaps they could use a subset of the Java libraries? If J2ME could run on several kilobytes on a mobile phone, what prevents another API subset to work on the specs you mentioned?

Java on the OLPC computer makes a lot of sense. That way the organizers can use any hardware and software configuration, ( even change the HW and SW in future models if they find cheaper alternatives) and not worry about re-developing applications. also, tons of educational Java applets would be instantly available to the new machines. perhaps even bundled with it.

and kids need not fear learning Java. There are tons of languages including scheme, python and others, that run on the java VM.

I assume it means that Sun is better off persuading language developers to run the "P" of the LAMP stack on the JVM (instead of their own byte-code interpreters), growing with LAMP rather than competing head-on with it and losing market share to it.

If Sun is to do that, they should do it before Parrot and the language implementations for it are finished - so that gives them plenty of time.

There are a already lot language implementations that already target the JVM, Sun would not lose by throwing a bit of money at OSS projects that might improve them and add a few more.

The pace of java development is glacial, compared to say what is going on in C# or Ruby.

Most of your post is either correct or arguable, but this is just flat out wrong. Java development has proceeded at a pace faster than any other language in history. Each version that comes out (about one every 1.5 years) contains a boatload of new features and APIs. Besides those that are integrated into the core, there are thousands of mature APIs available from Sun and third parties. Everytime a new technology hits the scene, Java has a stable or leading API before every other langugage.

If Java's pace seems glacial, it's because everyone else is still playing catchup. Java's trying to break new ground while they're working on adding even a tenth of the functionality.

The only other area of contention is the matter of features like Operator Overloading. Most long-time Java coders are actively standing in the way of such features as they screw with the basic tenent of the language. That tenent is that the language itself should be minimal, and that EVERYTHING else should be implemented in libraries. If you have a problem with that, you're free to use one of the few hundred languages that target the JVM, or create your own to meet your needs.

Javascript, python, scheme all run on my JVM And these ones: http://www.robert-tolksdorf.de/vmlanguages.html

As it happens there are many projects (200+) to make a variety of languages run on the various implementations of the Java VM. Even Sun supports Jython and Groovy in addition to the Java language. Turns out this was another idea Microsoft copied.

There are lots of programming languages that generates Java byte code that can be runned as programs or applets. You just need to do a simple search.

Let's see, lots of languages http://www.robert-tolksdorf.de/vmlanguages.html

There you have links to tcl, prolog, lisp, cobol, scheme, basic, VB Basic, C#, logo, Smaltalk, Ada, DynamicJava(Java interpreter), Rhino(Javascript), Forth, Lua, assembler etc...

Tcl, Lisp, Prolog, Eiffel, Sather, Smalltalk, COBOL, Ada, ECMAScript, and Forth aren't enough? Here's the full list of systems which support languages other than Java on the JVM; it's always been much longer than the list for CLR.

For example, VB programmer may with some training be able to move his old VB code's business logic to .NET server.

Wrong. VB.Net is very, very different to VB6 to the point where much of the code will have to be rewritten to either run or run well. Not to mention that there will be extensive training required for VB6 developers to learn the more OO ways of VB.Net.

and that way looking far ahead of Java where you can only 'plug in' with Java only.

Wrong. There are many languages that will run on the JVM e.g. Python, Groovy, COBOL. See here for a full list. Not to mention that having multiple languages is a nightmare in itself for support, maintenance but thats just IMHO.

Besides Microsoft with it's traditional method, is trying to support .NET much as it is possible.

Great. One company supporting .Net. For Java we have: Sun, IBM, Oracle, BEA, Apache, CA, HP, Novell, Apple etc etc. Just look at the list of supporters for the JSR-168 (Portal) and JSR-170 (Content). The JSR process whilst not perfect is a great part of Java and why the platform is doing so well.

More I look .Net, more I've started to wonder why it has been so overlooked.

Easy. (a) Because Microsoft is the ONLY company involved. And that company just happens to have a long history with anti-competitive behaviour (b) Because I want a choice of which servers/OSs to developer and deploy on (c) I want competition so the quality of all the technologies will increase. .Net provides none of these. Java provides all of these.

If you like virtual machines, mono is the only one that performs well and is open source and is designed to be almost programming language independent.

It's awfully funny how C# developers all the sudden get all teary-eyed over the ability to use any other language than C# when the topic of faster JVM's comes up...

But then someone has to go and mention that the JVM runs about 200 languages. How many does .Net run again? And how many are not bastard neutered languages like managed C++?

So I guess you need to re-phrase your statement to say "if you want to have access to many langauges, and have the fastest VM you should really just drop Mono/.Net like a hot potato and stick with Java - until you decide to try a real language on for size and move to Ruby."

If you program, you are inept.

Java has the same multi-language capabilities .NET has:

CLR is basically the same thing as a JVM
IL is basically the same thing as Java Bytecode.

In fact, you're so completely inept, you don't even realize that Java supports more languages than .NET. In fact, when .NET and Java support the same language (which is common), the Java version is more mature and stable.

Languages for the Java VM
http://www.robert-tolksdorf.de/vmlanguages.html

Buy a clue!

Rhino is a JavaScript implementation for the JVM. IIRC, it can run in interpreted mode, but also be compiled into bytecodes (i.e. an actual language compiling to the JVM).

Here's another site full of plenty more languages for the JVM: http://www.robert-tolksdorf.de/vmlanguages.html

1. .NET works with more languages than just C#. Here's a list of languages supported by .NET: http://www.dotnetpowered.com/languages.aspx/. In contrast, Java only supports... well, Java.

Other languages built on the JVM? There aren't many.

Try this page.
From that page : The following is a list of programming languages for the Java virtual machine aside of Java itself. Currently (spring 2005), it comprises close to 200 different systems.

Maybe that's not enough for you, but it is for me.

.NET introduced a new programming language environment that compiles all source code into an intermediate language. .NET languages are compiled into the Microsoft Intermediate Language (MSIL), which is executed by the Common Language Runtime (CLR) software in the Windows computer. The MSIL is similar to Java's bytecode, except that whereas Java is one language, .NET supports multiple programming languages...

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

I thought he was talking of Java the Language, as that's what the article is all about (Java bytecode).

Bytecode is platform, not language. All these languages can be compiled to MSIL (.NET bytecode). Likewise, all these languages can be compiled to bytecode for a JVM.

check out http://www.robert-tolksdorf.de/vmlanguages.html i don't have more info about many of the languages there but at least jython seems to be able to generate java bytecode.

It's been shown already that the Java byte code specification heavily favors a Java-style language, making it cumbersome to support a variety of others. In contrast, Microsoft designed .NET specifically to abstract out as much of the human-interface language as possible.

Nonsense, C# was designed for the CLR and CLS, other languages have been "retrofitted" with various degrees of success. Have you seen the restrictions put on C++ programs to make them able to run in the CLR? Take one step outside those restrictions, and you're in "unsafe" country, aka. native land.

There are a lot of languages which have a Java-oriented implementation.

This is completely untrue. There are a ton of languages that compile to java bytecode. The current list is almost 200 languages!

Parent and modders, please stop propagating this lie.

The difference between Java and Mono is not a technical one in the first place. Both are modern platforms with a JIT compiler and a prefered OO language. Both run on multiple platforms and for bioth are multiple languages available.

The problem is more a political one. On Mono, future language extensions are dictated by Microsoft. The Mono developers could of course extend their VM in any way they want. But they would loose compatibility with Windows.

On Java everyone can join the Java Community Process (JCP). Membership is free and every member is entitled to vote and can even run for election.

Datails can be found at Javalobby.org.

"Power arises when groups of people act in concert." (Hannah Arendt)

You already have the choice.

• No unsigned integer type in Java -- if you need an unsigned long, you're SOL. So it's pretty difficult to code certain numerical algorithms (compression and encryption, anyone?)
• Java the language is inextricably tied to the JVM - C# is just another option for developing for .NET.

b) there are many other languages which run in the java VM (e.g. Jython, Groovy ) Some even run C# in a java vm .

For a larger view of the language development being done similar to this, take a look at List of Java virtual machine languages.

I should think that most people will find at least something that appeals to them.

If you need to produce code that runs on a JVM but enjoy the benefits of more advanced languages, have a look at Nice or one of the many other languages for the Java VM.

But also on the platform.

Do not forget that Java (the name) is used for 2 things : The Java platform, and the Java language.

By default, you application for the Java platform using Java language itself (like you defacto develop in C# for MS.net), but there are lots of differents language that can compile to java's bytecode as well.

IMHO, the strength of Java is the platform and not the language. Without the platform concept, it would never have been different from his ancestors C++/SmallTalk/ObjectiveC ! There is the big difference with .net.

MS.net only run on some MS windows OS (No Mono is not&will not be a complete and real .net impl). Whereas Java do run on most OSes !

This is no b*illsh*it but just truth.

If you want to contribute to Java libre world then i invite you to join the FSFGNU Classpath project, as they are building a full GPL implementation of the Java platform!

This can exist because all Java spec (JSR+TCK) are available to the public (including Reference Implementation) so even if the RI is not GPL, you can just create a new implementation that apply whatever license you want. That's how Java managed to balance freedom & compatibility :)

Linux+Java is the baregain for enterprise solution, and with Java 1.5 and Linux 2.6 functionality & TCO are there ! Here we got the reference platform for developement of the next decade.