Posted
by
Hemos
on Saturday February 09, 2002 @05:38PM
from the looking-at-CLR dept.

Sowbug writes "Here's some interesting Saturday night reading: a critical examination of many of the advertised benefits of .NET's CLR (Common Language Runtime) and the other technologies (MSIL, CLS, CTS) that make it possible. It's written from the perspective of a Java advocate, Osvaldo Pinali Doederlein. "

I have seen several articles on.net in the last week. All of them have been from Java advocates or MS haters. Could we please get some unbiased articles on.net? It is going to be a very important technology in the future, whether you like it or not. It doesn't help anyone to only look at one side of the picture.

I believe this article is actually quite unbiased, considering the source it came from. It admits that CLR is probably better than JVM for implementing other languages than C# or Java, but that it's far from the holy grail MS makes it sound like.

Then it goes on to say that surely the JVM can be extended if this proves to be a selling point for.NET (which is probably true, but it kind of makes you wonder why sun haven't already done it).

Then it goes on to say that surely the JVM can be extended if this proves to be a selling point for.NET (which is probably true, but it kind of makes you wonder why sun haven't already done it).

Probably because language neutrality is not really that big an advantage anyway. Java is a good enough language so that if you really need to use something else chances are you don't want the JVM anyway. The most common case where you might want to target something else at the JVM is scripting languages which appear to already be quite well supported.

Language neutrality is actually quite a substantial advantage. Perhaps not to you, or Java developers...

But to the horde of developers that will be migrating from Visual Studio 6.0 to Visual Studio.NET. I've met quite a few VB developers who are unwilling to give up their syntax yet would love to take advantage of.Net.

It is a very valuable marketing point, and it allows for a very easy transition/upgrade for many developers out there already targetting Windows.

That's the point. The most important is how your PR dept will present your product : Jim McCarthy (responsible for early MS VC++'s releases) in Dynamics of Software Developement explains how it doesn't really matter what are your product's capabilities. The more important is to make people confident about it.

The matter in C# vs Java is who offers the easiest language. Users will pick the one they understand...

Meyer brought into.NET from an early stage, as did several other academics with pet languages noone ever uses. He doesn't tackle the (huge) issues with actually implementing Eiffel on the CLR, probably because he's starting to lose touch with reality due to spending too much time being a pundit.

"Is the superiority of C#/.NET enough to offset the costs of moving to it from J2EE."

A tool that claims to do all things for all people never does anything well. C pound is one of those tools. The article does a good job showing how each of the implimented launguages applies its flaws to C pound rather than it's strengths. The result is a crippled java without multiple inheritences and most of the rest of java's strengths.

The reason people write that they don't like the new M$ toy is not because they don't like M$, it's because they don't like the new toy.

C pound has all the stench of the M$ fortran effort. Before they were the Empire of the Dumb, it was interesting to see a nice little DOS fortran compiler. Next they extended it to include support for their Win3.1 GUI with the user kernel. That was replaced with a 32 bit DOS extended compiler, which was in turn replaced with a module for their Developer, which promised to unite VB, C++ fortran and Java(? I can't remember if java made it in there). After all that jerk around, each transition breaking the previous extentions, the finally dropped it alltogether. They never seriously focused on the isssues that needed to be solved to make it more than a toy, ie be able to compile the tremendous body of legacy code, and in the end trashed it on their platform all together. These days real fortran work is a pain in the ass on M$, with each OS shift breaking the kludge that got around the last limitations. It's much easier to pick up comercial Linux compilers of G77, as everyone else focused on the strengths of fortran and made comilers that do useful work. M$'s effort to extinguish fortran on their platform has simply shifted physisists and others to other platforms.

Go download the.NET STANDARD, and go find the documents that Sun publishs about their technology.

Anybody who is qualified to write about the plusses and minusses of.Net is automatically biased. A microsoft rep or VB programmer will likely right about how wonderful it is. A C programmer will say how poor the performance of VM's are and how limited they are.

Personally I think that those strongly familiar with Java are probably the most qualified to write on the subject of.Net. The CLR is very clearly a similar concept to the Java Virtual Machine, and thus an awareness of the benefits and weaknesses of that model provide useful insights into the capabilities of Microsoft's product.

Really, the only unbiased source in this debate is an uninformed source, and that's really of no help. Take what the author has said, check his facts, and judge his opinions on your own. In the end, you'll probably find that, as it has always been, certain languages and architectures are well suited to certain tasks. You aren't going to write device drivers in C# and you probably aren't going to write a cross platform GUI application in assembler.

Seeing that C# is a 90% copy of java, it would be difficult to think of a more qualified base of people to review C# than java experts...
This charge of 'bias' sure gets thrown around loosely these days. I seem to recall that an article had to contain untrue or highly misleading statements before it would be called 'biased'. Now, if you have a pre-existing point of view you are 'biased'. Very strange, how the language changes.

The article itself is really quite unimportant. The language neutral ability of the CLR is a marketing point as it's a convenient selling point to Visual BASIC developers looking to upgrade. Nobody disputes that, but it is still a very nice feature to have. I challenge anybody to find a company which has code written in only one language.

The conclusion the article makes is what most critically damns it as biased. His points are purely political in nature, he admits it. He goes on to try to distance himself from the bias by claiming he is not condemning.Net framework and it's technical capabilities.

But then he goes on to make an anti-Microsoft statement, condemning this feature as nothing more than marketing, but yet instead implying that Sun is somehow different with their Java hype.

There are a lot of articles out there about.Net which are positive in nature. Those articles don't make it to slashdot because of the biased nature of the web site. That was the point the original poster was making. Hell,/. didn't even post an announcement when the.Net framework SDK became available for download.

The first step is to admit when you have a problem. From there you can solve it.

I'm personally a java fan myself, and I use JSPs for autopr0n.com. But as much as I would like to see that technology succeed, I don't really think there's anything 'wrong' with.net.

Java itself is not any kind of 'true' general standard, sun can do whatever they want to with it. There's no real reason that Microsoft should bind itself to sun's implementation. So.net is pretty much just a ripoff of java, there are some 'evolutionary' enhancements like XML serialization and that sort of thing.

This won't kill java anymore then java would have killed windows. Microsoft's CLR will provide a better way to write windows-only programs. I don't see why everyone needs to be up in arms about it.

Could have fooled me. I develop Java apps on a Linux machine that are deployed not only to other operating systems but to PDAs and other connection limited devices such as java capable cell phones. All with a true cross platform, high quality development environment that is very productive.

"Java is a neat little concept - that has some neat little benefits. But it has caught on for large-scale applications."

Uh, have you ever heard of the "little concept" called J2EE? It's the app server/services technology that powers a big chunk of the large-scale e-commerce backend. I work with this stuff every day, and it has a lot more than "neat little benefits". Have you ever heard of IBM's Websphere? How about BEA's Weblogic? J2EE is currently the ONLY credible enterprise-level app server standard around.

Get your head out of your ass. Little Windows applications at your computer super-store aren't what this stuff is about. It's the server side where the big money, and the truly large-scale systems, are. And on the server, Java rules.

I didnt claim that it didnt rule the server. And as we know Java = J2EE, is it?

I have hard of all that software.

Now I am not going to be belligerent to you, because its not polite. Maybe you could try it sometime. I claimed and I still claim that Java has failed Sun in many ways. Sun's goal was to shift development such that most software developed would run in the Java VM. Today, many years after Sun released Java, they have not hit that target - ie they failed. Java has obviously caught on very strongly on the server side - which MS is trying to undo with.NET.

At the same time, because of that effort, the world might get a development environment which runs on multiple platforms and that is popular with desktop application developers. These "little Windows appllications" ARE what many people buy. If MS sticks to.NET 1.0, Mono finishes on time, and developers adopt VS.NET then MS will suceed where Java failed - to bring the majority of applications to a multi-platform environment.

The big money for single sales are on the server - and java rules that. But on the desktop, of which there are 300 million in the country alone -.NET is poised to suceed where Java failed.

OK, first I'm sorry about the crankiness...I'm just so sick of people thinking it's all about the desktop.

Sure,.NET may succeed on the desktop, who knows. But it's really not the main focus of the overall architecture. The Common Language stuff will work as an application framework, but really, you're basically talking Win32 -- there isn't a compelling reason to switch from the ATL or MFC or whatever. The.NET strategy is server-based. MS knows as well as anyone else that web-based interactions with a remote server (whether it's serving up your word processor or a car-rental/airlane booking service) are where the future is at. I don't deny that the.NET framework will count for something on the desktop, but MS already own that. They want to own the server side as well.

If you still don't believe me, you'll (kindly) notice that MS marketing literature is mainly directed at J2EE. MS even went so far as to re-implement the Java Pet Store server in.NET to compare benchmarks. Remember, MS is about increasing revenue -- it's not happening on the desktop. Once (if) web services explode, MS wants.NET to be the implementation framework of choice.

MFC is a rat's nest of backwards compatibility, broken code, and bugs. There is a big reason to switch from that - its freaking nasty and bad-ass to code for..NET is a major leap forward in API based programming.

Second, people will use.NET by default - the new VS tools are targeted for it. Over the next few years people will adopt it. The exact percentage depends on merit, but say, a good 1/4 will switch just to have the "latest thing".

True,.NET is targeted to kill J2EE et all. If the side effect of that effort is cross-platform desktops apps then great! I'd love to be able to go to download.com and pick from 99% of the posted applications for my linux box instead of 1%. I'd love to be able to use main-stream software that my business partners and clients use without booting Windows. I'd love to write code for my Windows using clients and easily and without modification run it on my box.

I think.NET will succeed in that goal - thats a goal that Sun attempted and failed at. Despite the server side adoption, the desktop, which IS a major component of computing, failed.

And thats' the point -.NET may deliever on the idea of desktop applications that run on many platforms. And if that's true, then great!

I've written a rather large custom application before using Java and Swing - that was back around when the JDK 1.2 had just come out. The base target machine was a P166 with 32MB of ram rinng Win95.

After some work, we had an MDI all-swing application taht worked pretty well and had some a number of nice custom controls. While a little slow on a P166 with 32MB of RAM, it was quite usable and needless to say on anything even a bit more powerful (like the developers screamin' fast P450's) you'd think it was a native app.

So, speed is not really Java's problem on the desktop.

The swing framework I found great and very nice for devloping powerful custom controls with minimal code. I would not say that a good GUI library is what Java lacks either (and there are others to choose from for those that hate Swing as some do).

What I think Java has sufferd from is the large footprint and somehwhat long startup times (though those have been reduced). OS X has helped a lot be really integrating Java into the UI a bit, and doing things like sharing some Java resources for running programs.

So, Java needs some way to help share Java resources to make many desktop Java apps practical.

What Java also needs though is desktop Java programming tools. Some are already there - both Installshield and InstallAnywhere make GREAT Java installers that work well across many platforms. But I would say IDE's have not really helped the Desktop standalone developer. Sure there are a lot of GUI tools, but I think desktop app development needs more than just GUI builders to help you build a good desktop app. While I'm not exactly sure what that might consist of, I think that's an area that needs work.

A core tenant of the.NET Framework is interoperability. Messages are strongly encouraged to be passed with XML RPC, or XML-HTTP style messages. The 1.0 specification has been sent to the ECMA. They are shipping those products now (the framework and the development tools).

Your four hyoptheticals are entirely wrong. And for several reasons.

But the most important thing to remember is that it is not all or nothing. With Mono running on my GNU\Linux box I would be able (assuming it finishes) to run any.NET Framework 1.0 targeted app. I mean, thats just simply the way it is. They are reimplementing the whole Framework.
What does this mean? This means that an all-Linux shop could run most of the apps that will be developed in the coming months and years.

Why will MS let this happen?

Several reasons:

MS makes a staggering amount of money from applications - more than any of its other groups. It does very well with its core products - Visio, Office, etc. These products of course integrate with MS servers, but not necessarily require them (Outlook integrates with Exchange, but not exclusively - you can always use POP/IMAP). These products still have significant value even if not working with MS servers. In fact, few of MS's apps really *require* MS servers. There is no reason you have to use WIndows 2000 server with Windows 2000 Professional. And better yet, many products are in the works to replace MS servers with MS desktops (SAMBA is a better SMB server than Windows).

The point that Miguel was making a ways back was that either the GNU world wins. If MS extends and destroys the 1.0 Framework, then so be it. But the environment will exist, and it alone, by itself, will be better than how most GNU apps are developed. In another case, lets say that MS plays nice with Mono and they co-exist. A few of MS's customers might swith desktops to Linux, while keeping MS products for applications (say if Office was written for.NET).

Whats in it for MS? First, they keep their dominance in the critical office software. They keep Office. Even if Windows is killed, fragmented, dies, or stopped dead in its tracks the critical core applications unit survives. That's good.

Second, it creates a compelling reason to upgrade. Many many many places run Windows 95/98 without thought of moving to modern robust Windows environment based on the NT kernel line. MS would really like to see these people with a more modern OS (in their view). The whole.NET thing encourages them to move to the "next level".

Thirdly, it increases MS's market for future applications and services - they see the trends and they can't stop them traditionally. Linux and OSS are here as platforms, but in MS's view, the application space for OSS platforms is still growing. This is a place.NET can win - one of the last places MS can still expand its market share (other than the server space, which conveinently, is target as well with.NET).

Whats the point?

In the end, all I really care about is the cross-platform application development. If.NET means that I can, without relearning much of anything, take my Windows and move them to multiple platforms, than I am happy. In that regard, I stand my initial statement at the top of the thread that.NET may suceed where Java has failed - by bringing write once run anywhere to mainstream applications.

Exactly. Never. Java is a neat little concept - that has some neat little benefits. But it has caught on for large-scale applications.

Though I suspect that was a typo. Java has caught on for large-scale applications. The reason you can't buy Java apps in Best Buy is because they don't sell large scale applications. They sell boxed programs for PCs and Macs that are almost exclusively written in C++. Java's principle use is for the server side of various business systems.

This is the field MS are aiming for with.NET, too. Indeed, that seems to be its principle purpose: to displace Java from back-end server systems. Microsoft already owns the desktop, and Java is no particular threat there for reasons that don't need to be rehearsed again. For the device market, they have other plans.

For the rest of software - the stuff people buy and pay money for at retail stores, from vertical market software vendors, from various web-sites, and the miscellanous software people use on their desktops, Java has failed.

.NET is aiming for it all - but evidence by the relase of VS.NET - which is the replacement for all MS developers - VB, C#, ASP, VFP, etc. MS owns the desktop, and.NET is an attempt to keep the desktop and displace Java.

But make no mistake - Java failed Sun in the area of the desktop. They wanted most if not all software to be developed for Java. They wanted to see applications for business (desktop apps, mind you), custom software, etc all developed in Java. They failed at it. Most software written for the desktop is not Java based.

And if three things happen - MS sticks to the 1.0 format, Mono finishes within a reasonable period of time, and VS.NET catches on- then most developed apps will run on multiple platforms without modification.

For example: whne was the last time you went to Best Buy and bought any program that was Java based?

When was the last time you went to Best Buy and bought any program that was written in Visual Basic? How about Perl? Python?

Shrink-wrap software for consumers is a VERY small part of the software market. Most software is developed for corporate use, not consumers. Java is very viable for corporate development, especially for server-side code. Swing isn't nearly as successful, but it can do the job if you're a good Swng programmer.

However, MOST of ALL software is not written in Java. Especially for desktop software, of which, bunches is sold (and bunches is downloaded, btw).

Sun attempted to change the targeted development techniques that the majority of programmers are used to. Java did not largely change the desktop softare market. Regardless of why or how that happened its the truth. Java is not largely used for desktop software. Yes, server-side code is very often done in Java. Yes, web development is a strong market for Java.
But in Sun's original plan - to create the next big thing - they failed. Most softare is not written for Java.

IF MS sticks to the 1.0 framework, and developers go with VS.NET, and Mono is completed than all software developed for the 1.0 framework will run on Linux unmodified.

And in that sense, MS will may succeed where Java failed - wide-scale cross-platform desktop application development.

" It is very possible that.NET will suceed where Java failed - true cross platform, high-quality application development environment."

Well there are two things wrong with this sentence.
1) What makes you think Java failed in being a true cross platform high quality application development environment? What is your definition of fail in the first place? Are you saying there are no applications written in java that are cross platform? This is a nonsensical thing to say considering the millions of java devlopers in the world and the tens of thousands of businesses using it every day in massive scaled applications. You must have some really whacked definition of the word "fail".

2) GNU will create mono. Mono will run C#. It will not be 100% compatible with the MS implementation. This is because MS holds patents on most of the.NET infrastructure. Also the some of the most important parts of the.NET are not submitted to any standards body and are not published. Mono will have to do without them.

What makes you think Java failed in being a true cross platform high quality application development environment? What is your definition of fail in the first place? Are you saying there are no applications written in java that are cross platform? This is a nonsensical thing to say considering the millions of java devlopers in the world and the tens of thousands of businesses using it every day in massive scaled applications. You must have some really whacked definition of the word "fail".

Java has failed in Sun's primary quest - to bring massive cross-platform applications to the desktop. That was the goal. Since the inception, Java has now shifted to server computing far more than desktop computing. On the desktop end Java is basically a web-browser trinket language. Those are the facts. Commerical applictions are not generally developed in Java. Server applications can be.

Java failed to catch on the desktop. Therefore, it is a failure.

2. Good points all around. However, Mono will implement the entire.NET 1.0 Framework. Any app targeted for the 1.0 version will run (assuming Mono doesn't fall off into the ocean). A number of the APIs are being submittted to ECMA. And at this time, it looks like MS is not going to break Mono on purpose (though you never know with them).

There is a strong chance that the.NET 1.0 Framework will catch on. If that is the case, and Mono is completed in a reasonable amount of time - Mono/Linux users will be able to run mainstream desktop applications without additional effort.

I don't think massive cross-platform applications on the desktop was ever Sun's primary goal for Java. As others have noted, before it was called Java it was aimed at embedded systems, and its initial hype was based on bringing "interactivity" to web pages, which it turned out people didn't care for (and Netscape's implementation was about as bad as it possibly could've been). Several third parties (notably Lotus and Corel) failed with Java desktop development, but AFAIK the only real major desktop Java project Sun attempted was the JavaStation(?) diskless terminal, and that would've failed regardless of the software since it was an overpriced, underpowered and incompatible hardware platform.

But after all that, I agree that free.NET implementation(s) may succeed on the libre software desktop (I don't care what it does on the unfree desktop), where Java has failed to gain any significant foothold.

I think C# and.NET are kinda neat despite their source (I could say the same about Java's source, they're both amoral corporations), and I hope that mono does meet all of Miguel de Icaza's expectations in terms of making free software developers more productive. I also think Java still has a chance on the libre desktop if and only if Sun wakes up and makes the JDK open source!

"what about Servlet programming and JSP for dynamic web pages and database connectivity? These are desktop applications! They just run in a browser; on the desktop"

Very true..jsp pages seem to be by far the most common dynamic pages seen on bank and investment websites. I'd say that seeing such heavy use in such demanding environments speaks quite well to how successful java's been.

Sun is a hardware company. Java was developed as an embedded application language. It lucked out with the growth of the web and the development of applets. Sun realized that if all applications were written in applets, then all a worker needed was dumb PC running a browser, with the heavy lifting done by (ta da!) a Sun server. You know, "the network is the computer(tm)." Remember?

This is what lit a fire under Mr. Gates' ass. Navigator + Java = badNews. However, applets turned out to be craplets (even while MS wrote the best JVM); stand-alone Java was too slow for the desktop; Java failed to score any significant headway.

But, Java could still be marketed for *server* development, so Sun decided to retrofit the embedded-language-that-could into a full-blown enterprise development lanaguge. (Hence the evil that is J2EE.)

Of course, using Java on the server means buying big iron, which, by coincidence, Sun happens to sell. It was always about the server.

It is very possible that.NET will suceed where Java failed - true cross platform, high-quality application development environment.

Who told you that? Steve Baller?

Let's summarize the article as, "A tool that claims to do all things for all people in all places, generally does nothing well." Hey, its good for my writing skills =:> As the authors point out:

Programming languages exist in wide variety, not only because different tasks (from systems programming to artificial intelligence) require different tools, but also because there is no One True Way to serve even one domain.

Yup, it's true and he goes on to show us how C Pound is gimped by the limits of each of the languages it wishes to extend and extinguish.

The CLS only supports single, static inheritance.

Languages such as C++ and Eiffel need multiple inheritance of implementation. Cross-language support for MI may not be possible, as MI creates some hard problems (like repeated inheritance and name clashes) that different languages solve in different, incompatible ways.

Yup!

There is currently zero support for generic programming in the CLS.

Compile-time mechanisms like C++ templates are supported, but they are not cross-language: no way to instantiate your stack.

He goes on with a few more damming examples including how incompatible different (VB buzzord!) Methods are. His conclusion is both damning and accurate:

For the CLR, we can certainly rely that everything is optimized to favor C#. The result will be inferior performance for any language which behavior is significantly different from C#.

Someone asked what people are "up in arms about." I suppose the Java people, who have made a fine and stable standard, are upset because the MicroTurds are going to spend lots of money saying this new C# is better than their work when it is not. They will back it up with the usual spred specturm attack of poor performance for all other languages under their platofrm. I feel their pain. Me? I'm not up in arms because I could care less, M$ is irrelavant. Even if they built the best freaking comiler in the world, their underlying OS is still so buggy and screwed up applications will never work right. People have noticed. The other folks up in arms are M$ dependents who are consistently let down. Their demise is the demise of my coworkers and it brings me no joy.

First off, the Mono project has the gaol of implementing the entire.NET Framework 1.0 - which includers compilers, the CLR, and the new set of APIs. If that is the case, any app targeted for the 1.0 framework would run on Mono - and hence Linux.

However, if MS decides to break Mono, which it probably could, then Mono would probably be useless. It is interesting to note that they have released Visual Studio.NET and adheres to the 1.0 specification. Unless they start breaking it in the service packs, then I'd expect the 1.0 spec to stick.

If that is the case, and I suspect it will be (just my opinion, though), and if Mono finishes its implementation of the 1.0 spec, then good things will happen. Main stream apps that are developed with VS.NET will be able to run without modification on Mono.

And if that happens,.NET will suceed where Java failed - and bring high-quality, high-level, multi-platform development to the mainstream.

So I'm confused here... are you *against*.NET then, or are you applauding the fact that we'll get a "true cross platform, high-quality application development environment"?

I am not against.NET - its just a bunch of code. It'd be nice if I could write applications in an environment I am familiar with (Windows programming) and then distribute them for multiple platforms. That'd be cool in my opinion. If it works out great, because then when I am on my Linux box I can run mainstream apps without any additional effort.

Java itself is not any kind of 'true' general standard, sun can do whatever they want to with it.

While Sun can do anything it wants with Java, it is just as much a standard as.NET, complete with specifications and third party implementations.

Now, what makes you think that Microsoft won't do exactly what it wants with.NET? I mean we already have interoperability problems between SOAP implementations. What is going to stop Microsoft from issuing.NET+ or.NET 2002 or whatever? Complete with extensions to the.NET standard (perhaps some even documented) that mean the code that is written for.NET on Windows doesn't run well or at all on.NET for other platforms?

And of course all those fancy development tools (Visual.NET) will require and make full use of these extensions.

Wait, say that again, "third party implementations", meaning what exactly? Modifications to the original "standard" or building off of the already existing base? I don't think that I've seen a GPL'd java or a red-hat java. While I've seen plenty of vm's and additional components I don't think I've seen any truly third party implementations. If what you said was true then Microsoft would have had right to continue to fudge their version of java into anything they wanted to.

On to standards: Standards come in two forms A) Standard by popularity B) Standard by decree. While Java is a standard by popularity (similar to how IE is the standard browser), Sun refuses to give up any control whatsoever of the product in order for it to make a very important step into an actual documented and decreed standard. This would mean giving some measurable control up to a standards board such as ECMA, IETF, etc. What makes you think that Sun won't do exactly what it wants with Java?

... why would anybody want to use multiple languages for the same project anyway?
If you start a project you are pretty happy if you(r people) can deal with one language (or as few as possible) there is simply no need for this.
The way I see it, it's a nice-to-have feature, but no killer-feature.
Platform-independence, on the other hand, *IS* a killer feature because you can be sure that your customers can use it and can also switch platforms.
Java is not only implemented, but also tested and proven on many, many platforms. It's established in many ways -.NET just doesn't offer enough for people to switch over to it. It may be the successor of Visual Basic (= the users that use anything from MS anyway), but IMO not much more.
I think.NET is a solution without a problem.

... for a single project of any size. Its very important that everyone can read and modify everyone else's code (not that they DO, just that they CAN). Using libraries written in another language: maybe. Using many languages on one project: insane.

There are also two errors in the rest of your post: Java's platform independence works just fine, and C# and the CLR have been released, they're not "planned".

> why would anybody want to use multiple languages for the same project anyway?

Possibly because different languages have different strengths. At my work, most of the system for the project we are working on is written in Java, but I am writing one module in Mercury because that particular module does a lot of symbol manipuation and has a large 'logical' component, so a logical language is far more suitable than Java, but only for that component.

However, in these cases, it is good to have to go through some middleware (I'm using CORBA) or API to keep the modules apart. rather than sharing of structures pushing everything down to a lowest common denominator. So in that way, I agree with you....NET is a solution looking for a problem.

But the thing that I hate about java is that there are so many different JVMs (or runtimes if you want to call it that).

Having many different JVMs would be great if they weren't all incompatible in some way.

Java is meant to be a "write once, run anywhere" but the sad fact is if I switch JVM then I can't even get some java programs to run on my own computer let alone on someone elses.

The easiest and best way to fix this would be for Sun to release their code under a free lisence and everyone switch to that. The next best way to fix this would be to make every JVM compatible, which might happen on some imaginary world but not is never going to happen in the real world. The third solution is to stop pretending that the JVMs are compatible and start distributing programs with the JVM they use. That's probably the only solution that works.

I hope that we don't end up having the same kind of crap with c# on Linux. In this sense I would really prefer one Runtime to bind them.

Under Windows, there are two VMs: one from Sun and one from IBM (the MS one is so woefully out of date, it doesn't count). I don't know of anyone who deploys under the IBM JVM (except for people who deploy IBM Websphere under Win32).

Sure, there are different RELEASE VERSIONS of the Sun JVM and different RELEASE VERSIONS of the IBM JVM, but by and large the "incompatibilities" are bug fixes. Complaining about fixing bugs is silly.

On most other platforms, there is a single VM, supplied by the vendor. On the Mac, there is a VM for OS 9 and one for OS X.

So I'm not exactly sure what the benefit of Sun open sourcing the JVM is. Do you not want to see bug fixes?

There are, actually, many successful "common language runtimes", with names like Pentium, SPARC and others. Mainstream CPUs are equally fitted to very different languages as they only do the most fundamental, low-level operations, so they cannot be biased towards particular languages.

Q: So why do we have the need for a next bytecode layer on top of Pentium & SPARC?A: To be cross platform! This is correct in the case of Java and the JVM. The intention is compile once, run everywhere.

The problem we now have however is that Microsoft sees cross platform differently in my opinion. Cross-platform is merely compatibility between their CE, Win9x and NT product lines. How big will the push be within one year by Microsoft to keep the developed truly cross platform?

Mainstream CPUs are equally fitted to very different languages as they only do the most fundamental, low-level operations, so they cannot be biased towards particular languages.

Actually, this is not true.

Current machines are heavily biased toward running manifestly-typed, single-stack-oriented languages much more quickly than others (that would be Fortran, C, etc., for all of you less than language astute types out there). Languages that use more complex models (like C++ with its indirect VTBL pointer calls) run slower. Languages that use even more complex features like dynamic typing, continuations, re-entrant exceptions (like Lisp, Scheme, Smalltalk, etc.) run even slower. And languages that have non-standard control structures (SNOBOL, ICON, PROLOG, expert system shells, etc.) run slowest of all. All of these issues can be ameliorated by enough compiler technology, but in the end, the cost of emulating these features in the VM adds up.

My point is that there is no such thing as a completely language neutral VM. One can try to make the VM more general, but you do pay for it in RT size and performance. VM's take less of a hit than silicon in these cases, though, and all of the VM manufacturers could do a better job of extending their VM's. Putting in hooks for dynamic typing, overflow checking, non-contiguous stack segments, and non-fixed method lookup machinery would help a lot.

For more interesting info on how this applies to silicon processor design (especially WRT C), see Hennessy and Patterson [fatbrain.com].

Yes you can compile Python to the JVM, but can you use Java objects inside Python code? Thats a driving feature of.Net...which I presume not so much to make multi-language programming easier, but to make the programming language itself obsolete as a point of leverage (compared to the framework).

Yes, you _can_ use different languages with the JVM, but the efficiency cost is frequently not worth the effort.

Every runtime environment, whether it be CLR, a JVM, or even machine code for a particular processor, provides capabilites that make some languages more efficient than others (although the machine code tends to be most language neutral - the more low level something is, the less assumptions it is going to impose).

To give some specific examples of things that the JVM does poorly (if you want these features), and this is not an exhaustive list:

* The JVM doesn't deal with unsigned quantities - you could design a class that emulates them, but it is going to be a big speed hit.
* No tail recursion - this is really important for functional languges, some of which absolutely require it. There are workarounds such as a technique called a 'trampoline' where you essentially take over stack management for yourself, but the cost of this in speed and complexity can be high.
* You cannot play directly with pointers. This is usually seen as a good point, but there are occasions that the ability to work with the very low level stuff allows very fast code. Again, you can always get the job done without them (except for OS level stuff and device drivers), but at a cost.
* If you want to use a different object model than the JVM assumes, you have to work around the JVM rather than with it.

Yes, there are lots of languages that have been implemented on top of a JVM but they will tend to be much slower, more resource hungry, and will often have all sorts of extra restrictions in the fine print that doesn't make these implementations a good choice for most applications. They are interesting excercises, and good on the people who have done the ports, but I consider the JVM suitable for only two sorts of language:
* Java, for which it has been tuned,
* Scripting languages, where speed is not of critical importance.

You could also build any language on top of a Turning Machine, but that doesn't mean it is a good idea.

There are, actually, many successful "common language runtimes", with names like Pentium, SPARC and others. Mainstream CPUs are equally fitted to very different languages as they only do the most fundamental, low-level operations, so they cannot be biased towards particular languages. There aren¦t many different ways to perform a conditional branch. However, there are radically different ways to support methods and functions, or most constructs found in high-level languages. The consequence is that every language needs different compilers and runtimes to implement their features, and different libraries to support their vision of software development.

Is he kidding here? As long as you are using any mainstream CPU, imperative languages are favored. All those CPU's are based on von Neumann model. Any program written in functional or logical languages will be penalized when run on such CPU's. So, at this moment there isn't a CPU architecture that will treat all programming paradigms equally, and neither a CLR/VM.

MS is at least trying to build a platform that will intergrate different languages. This is intention of CLR.

SUN is not trying to do this and JVM wasn't invented for this purpose. Sure JVM can be extended to support other languages, so can my plastic cup holder.

Any program written in functional or logical languages will be penalized when run on such CPU's.

This strikes me as a false statment in general. The best example is the Symbolics Lisp machines. They were nuked from the market when RISC-based workstations performed faster than the Symbolics machines that were supposedly "tuned" for Lisp.

Are there ANY example out there of a specialty chip for a language outperforming a general purpose chip? I don't mean clock speed for clock speed, but at the same cost. More efficient but more expensive means niche at best.

I think that the "most efficient architecture for a give task" argument often gets quite circular.

At the moment, the vast amount of development is done with imperative languages, and there are only a few common CPU's which all support those quite well - that's where the money is.

Compare the resources put into optimising a RISC chip, or even more, the incredible level of resources put into speeding up the x86 and compatibles, and at the other end, the huge volume of those things sold (don't forget the embedded market too).

This is why the Symbolics machines could not compete:
* I very much doubt that they could come even close to matching the resources that Intel, AMD, IBM, Motorola etc. could put into CPU design.
* Even with what they could produce, there was no way they were going to sell the volume of other manufacturers - therefore they had to charge a lot more.

This is why they lose out, even after the advantage of only having to tune for one language.

It my be possible (I'm no expert on this), that RISC is simply an inherently better way of producing a fast Lisp machine than trying to tweak for Lisp specifically, however looking at what gets sold and for how much has so much distortion that it is really no evidence either way.

One thing I will say for the general purpose chip for functional languages - it is much easier and more efficient to compile a functional language to assember than it is to compile it to JVM bytecode or even C. It is low level, so there are far less assumptions about how your language is going to behave to work around.

This point has been made before, but it bears repeating. C# [www.ecma.ch] and the CLI (Common Language Infrastructure) [www.ecma.ch] are ECMA [www.ecma.ch] standards! As such Microsoft no longer truly controls them. There is nothing to keep Microsoft from 'embracing and extending' these standards if they do not like the direction they are going. Just as they can with any open standard. Just as you can with any open standard.

MS tried the embrace and extend strategy with Java, remember? And they ran into a huge roadblock. Namely Java is not an open standard. Despite what Sun says in the press releases the standard is not open in the same sense. Sun controls it and Sun can shut down any attempt to create a non-conforming version.

From some points of view this is a good thing. But, although I appreciate any argument that starts with 'We need to avoid incompatible versions.' I also know that Sun has not proven any better than Microsoft as a steward when it comes to keeping the commons clean and competitive. To put it simply; I just don't trust them. And I think there is an equally persuasive argument that competing products evolve faster while products without competition tend towards stagnation. This eco-system analogy appeals to me.

From this point of view let us return to 'embrace and extend'. In a closed standard a single organization controls all progress for that standard, with limited participation from the outside. In an open standard the process is, at least titually, open to outside input and you are more likely to see third-party enhancements absorbed into the standard itself. Furthermore no corporation is going to sue you if you create your own implementation of the standard. Even if it is tweaked to work best on a competing platform. (Can we all say 'Mono'?)

So, the way I look at it, C# and the CLI will drive Sun to improve Java. Third-party implementors will drive the C# and CLI specifications faster than MS would alone. In the end we get better technology. I like better technology. So I win either way.

Besides, I like the design of the CLI a lot. And C# looks like an arguably better language than Java.

Finally, many arguments in the 'One Runtime' article seem a bit weak to me. For example, "... Design-by-Contract, a fundamental strength of Eiffel that.NET does not support." Since when does 'Design By Contract' have to be baked into the underlying runtime to make it work? What is keeping you from implementing any kind of runtime you want on top of the CLS?

Jack William Bell, who likes the idea of coding with mix-n-match programming languages.

There is nothing to keep Microsoft from 'embracing and extending' these standards if they do not like the direction they are going. Just as they can with any open standard. Just as you can with any open standard.

Yes, but from a practical standpoint, if Microsoft decides to take the products in a direction away from the Open Standard version, then the Open Standard version will immediately become irrelevant.

Which, come to think of it, was exactly what they intended to do with Java. Make the Sun version irrelevant.

Yes, but from a practical standpoint, if Microsoft decides to take the products in a direction away from the Open Standard version, then the Open Standard version will immediately become irrelevant.

Which, come to think of it, was exactly what they intended to do with Java. Make the Sun version irrelevant.

Why? Apply that same question to Unix. Is Unix irrelevant because AT&T created a closed version of it? Or, for that matter, any number of other closed versions from any number of vendors? Or, even, an Open Source version? There is a common thread through all of those versions of Unix: Posix -- which is an open standard. Non-Posix implementations did not succeed in the long run no matter who created them.

Look, I don't trust MS either. And yes, they did try to hijack the Java standard. They did it by providing enhancements to the Java standard that were compelling enough that people used them. Sun had two choices; absorb the enhancements into the standard or take their ball and go home. They chose the latter.

So who was the winner in that little spat? MS? Sun? We programmers? I would call it losers all around.

With an open standard at least you know there is a chance some third-party enhancement that survives in the marketplace because people want to use it will get into the standard. And MS can only extend the standard with their own proprietary enhancements. They have limited control the standard as it exists now and (with the exception of patented stuff) cannot keep us from adding the enhancements to the standard if we like them.

Look, I don't trust MS either. And yes, they did try to hijack the Java standard. They did it by providing enhancements to the Java standard that were compelling enough that people used them. Sun had two choices; absorb the enhancements into the standard or take their ball and go home. They chose the latter.

They also did it by providing a buggy implementation of the Java 1.0/1.1 classes that made it impossible to run, say, an applet in their JVM just like it would run in the standard implementations.

"With an open standard at least you know there is a chance some third-party enhancement that survives in the marketplace because people want to use it will get into the standard. And MS can only extend the standard with their own proprietary enhancements. They have limited control the standard as it exists now and (with the exception of patented stuff) cannot keep us from adding the enhancements to the standard if we like them."

Perhaps this is MS learning from Sun's mistakes. Even though Java is successful in certain applications, it would most likely be used for a wider range of applications if Sun hadn't been so harsh in keeping absolute control of their standard.

Microsoft must know by now that good things come from the programming community, therefore having the community suggest (and even implement) useful enhancements to their standard only helps them gain popularity.

Microsoft must know by now that good things come from the programming community, therefore having the community suggest (and even implement) useful enhancements to their standard only helps them gain popularity.

Hurray! Someone that understands my point and can make it more clear and concise than I can!

Jack William Bell, who thinks that we need to keep a gimlet eye on Microsoft anyway.

This point has been made before, but it bears repeating. only tiny parts of C# and the CLI (Common Language Infrastructure) are ECMA standards. Those standards are of no relevence in the real world due to their high level of incompletness and the very high degree of power that MS has amongst developers on the dominant platform.

This point has been made before, but it bears repeating. only tiny parts of C# and the CLI (Common Language Infrastructure) are ECMA standards. Those standards are of no relevence in the real world due to their high level of incompletness and the very high degree of power that MS has amongst developers on the dominant platform.

Can you back that up with details? So far as I know all of the C# standard is open, all of the CLI standard is open and the all (or at least the most significant) non-platfrom specific libraries of the CLS are open.

MS tried the embrace and extend strategy with Java, remember? And they ran into a huge roadblock. Namely Java is not an open standard . Despite what Sun says in the press releases the standard is not open in the same sense. Sun controls it and Sun can shut down any attempt to create a non-conforming version.

Java is controlled through the trademark, not the language standard. Microsoft is free to embrace and extend Java all they want (and the have in fact with C# and J#). What Microsoft cannot do is call their variant Java.

Jack William Bell, who likes the idea of coding with mix-n-match programming languages.

As somewone who has to maintain code from time to time, the idea horrifies me.

Java is controlled through the trademark, not the language standard. Microsoft is free to embrace and extend Java all they want (and the have in fact with C# and J#). What Microsoft cannot do is call their variant Java.

Valid point, but doesn't it cut both ways?

Jack William Bell, who likes the idea of coding with mix-n-match programming languages.

As somewone who has to maintain code from time to time, the idea horrifies me.

As do I. And I already have to deal with multiple languges, backends, frontends, extension libraries, coding styles, naming standards and everything else under the sun. At least with the CLI I know that I have a better chance of things interoperating. Besides some languages do map to a particular problem space better than another. And I can split work up between expert coders (with C#) and less skilled coders (with VB or Python).

Jack William Bell, who notes that the only responses posted so far supporting his stance come from Anonymous Cowards...

Just because they are ECMA standards doesn't mean MS can't "embrace and extend" them should they choose to. It just means that their extended version won't be the "ECMA" version. Microsoft doesn't control the IETF Kerberos specification but that didn't keep them from embracing and extending it.

Just because they are ECMA standards doesn't mean MS can't "embrace and extend" them should they choose to. It just means that their extended version won't be the "ECMA" version. Microsoft doesn't control the IETF Kerberos specification but that didn't keep them from embracing and extending it.

Actually that was exactly my point! MS can do exactly that. But if they do there is nothing (except patents) to keep ECMA from adding those enhancements to the standard if the enhancements really do provide something worthwhile.

Patents are a problem here, no way around that. But they are a problem everywhere! ECMA can always argue that an enhancement that cannot be reproduced is enough to keep the implementation from being called 'C#' or whatever. I don't think this is likely though. I am sure MS is a major financial contributor to ECMA for one thing.

In any case I consider this ability of MS (or anyone else) to embrace and extend a good thing. At least so long as we can pick and choose, in the marketplace of ideas, those enhancements we think add value then we will continually improve the standard. As has been pointed out you can do this with Java too -- but you cannot call it Java. In the case of an open standard like C# you can still call it C# and make some claim of being part of the C# idea-space. That is vital to the evoloution of an open standard. If the MS extensions to Kerebos are something people like you and me want to use then they should be added to Kerebos. Simple as that (patents aside).

Jack William Bell, who thinks that (generally) software patents are evil.

At least so long as we can pick and choose, in the marketplace of ideas....

Nice to know that with a convicted monopolist inventing the technology you will always be able to pick and choose between competitors isn't it...... Oh wait, there are no reasonable competitors to MS as ruled by a court of law.

Finally, you're arguments for embrace and extend apply just as much to Java as they do to C# - you can embrace and extend but if the owner of the trademark doesn't approve you have to rename it. Java is an open standard, go to http://java.sun.com and grab a copy of the *full* specification if you desire as well as specifications for new additions that are under review. If you think that standards only work when they come from non-profit standards organisations then perhaps you should look at the mess that is HTML these days and rethink how well international standards work.

If your only argument for C# is that it's open I think you a) have no clue about how to decide upon an appropriate programming language and b) are sorely mistaken about what is open and how useful it works.

Finally, you're arguments for embrace and extend apply just as much to Java as they do to C# - you can embrace and extend but if the owner of the trademark doesn't approve you have to rename it. Java is an open standard, go to http://java.sun.com and grab a copy of the *full* specification if you desire as well as specifications for new additions that are under review. If you think that standards only work when they come from non-profit standards organisations then perhaps you should look at the mess that is HTML these days and rethink how well international standards work.

Given time I can come up with several examples, but lets go with one here: Basic is an open standard with lots of (varied) implementations. PICK is a language (among other things) that ended up looking rather like Basic after several evolutionary changes. Why did PICK evolve towards Basic? PICK was arguably better on several levels. But it was a closed, proprietary standard.

If you created your own version of PICK you couldn't call it PICK and you could not participate in the mind-share generated by PICK. But anyone (including Bill Gates) could create a version of Basic and call it 'Basic'. As a result everyone knew what it was. It was part of the idea space for Basic, even if it wasn't exactly a kosher 'Basic'. So Basic, despite being technically less powerful, ended up owning the most mind-share. In the marketplace of ideas it became something that was traded at a higher level. PICK could only keep up by following, because its mind-share was smaller.

Make no mistake; mind-share is important. Sun knows this. Microsoft knows this. There is no way Microsoft would be playing the game the way they are if they were not playing catch-up. In this case the real winners are the programmers of five years from now when idea convergence and the natural workings of the marketplace of ideas create a better technology.

If your only argument for C# is that it's open I think you a) have no clue about how to decide upon an appropriate programming language and b) are sorely mistaken about what is open and how useful it works.

First rule of civil debate: Attack the message, not the messenger. Personally I believe that I am fully capable of making such distinctions by using a rich and approprite set of heuristic comparisons which I need not detail here. Can you accept that and choose to disagree with me solely on the basis of my ideas and opinions? If so then you are trading in that 'marketplace of ideas' I keep blathering about. Otherwise you are only trading in insult and antipathy. I have nothing to offer in exchange there.

Looks like you picked the right door! Not only do you win a platform supported by a whole industry, but the only truly open [jcp.org] standard around! Now THAT bears repeating.

Of course, I'm talking about the Java language. Where else do you get something where the language and VM are controlled by a standards body composed of many companies across many industries, that have to approve all changes made (Sun only controls licencing of the Java trademark)? How about a standard where real everyday people like you and I can propose changes and make comments on proposed standards?

Wait, you were thinking you might get.NET? Odd, I thought they didn't have the full standard submitted to the standards body. And I'm not clear on how I can comment on progressing ECMA standards.

Lastly, what's stopping you from writing everything on top of a raw turning machine? After all, everything you want to do is technically supported...

Check out calling conventions from Eiffel# to C# and then perhaps you'll rethink the usability of cross-language prgramming.

What a pleasure to see such a balanced, well-written and thorough analysis of the situation. I didn't see any great evidence of Java "advocacy" - this person appears extremely well-versed in langauge design and familiar with a good variety of languages, as well as more than willing to point out Java's flaws.

The author is saying pretty much what I figured, which is that.NET is much better than what MS has been doing in the past, however it's still just a sugared-up clone of J2EE, whose "cross-langauge" benefits are ultimately dubious and primarily a marketing invention.

I would also make the case that "unsafe" mode/pointer arithmetic is a flaw, but that's not the matter at hand. The high point of the article were these two paragraphs in the conclusion:

"Playing with the.NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a language's most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the system's look and feel, add a few features, but never compete with a fully new toolkit."

For those quick to make an ignorant response, he's not saying more radical structural departures are impossible, though many are - but more often that diverging "client languages" suffer in performance and, in many cases, have been "embraced and extended" in order to become compatible. He goes on:

"There are, actually, many successful "common language runtimes", with names like Pentium, SPARC and others. Mainstream CPUs are equally fitted to very different languages as they only do the most fundamental, low-level operations, so they cannot be biased towards particular languages. There aren't many different ways to perform a conditional branch. However, there are radically different ways to support methods and functions, or most constructs found in high-level languages. The consequence is that every language needs different compilers and runtimes to implement their features, and different libraries to support their vision of software development."

The second paragraph from the article you posted states that "mainstream CPUs are equally fitted to very different languages as they only do the most fundamental, low-level operations, so they cannot be biased towards particular languages." If you agree with that statement, and think it's a crux in the arguement, I'm not sure how you can say you don't agree with the inclusion of "unsafe" modes in the.NET framework. They're part of what makes the framework flexible enough to even come close to supporting "non skinned" languages, and in a speedy method at that.

It's a question of role. "Unsafe" code, lagnauges, and systems are necessary at a variety of levels in general purpose computing. That doesn't mean they're a good idea for.NET, which I take to be "high-level," "distributed" and "enterprise" computing platform, and one with pretensions to a modern, practical and durable security model...

It's important to note that VB.NET does not support pointers and the "unsafe" modes of operation that were discussed in the Slashdot article yesterday. The model that protects business programmers from themselves and ensures the security of *that particular aspect* of the seciruty model is not in the framework itself but this so-called "skinning." The icing on the cake is that the framework itself (which has nothing to do with that aspect of security, but rather code-locale and permission-based security) allows these things for more advanced languages than VB (like C#.)

I'm no Microsoft fan but.NET is not as bad as the author makes it out to be.
He lists numerous limitations of the CLR/CTS/CLS. Lets remember that.NET is in its infancy. How great was Java when it first came out?

If Microsoft fails to deliver, we'll all have a great laugh. However, if Microsoft does deliver and MONO succeeds, we'll have an explostion of desperately needed applications that will run on Linux.

The worst thing that I can say about.NET is that it is controlled by the Evil Empire and the worst thing I can say about MONO is the name makes me think of a horrible illness that takes a long time to get over.

"...but unfortunately still bound to Microsoft's usual way of doing (and marketing) things: proprietary technology presented as the apex of openness, and a strongly biased system presented as language-neutral"

I've been doing a lot of Java programming for my current job and I tend to find that the VM limits my options when I might want to use the power that UNIX provides me. Checking my program's process ID, for example, to see if it's already running. I've also been finding that the concept of having a VM to run your programs in breaks down pretty quickly, largely because various applications will require a different VM. So you end up with several VMs on your hard drive and several VMs in memory (at 40MB a whack) and none of the applications ever seems to check to see if there's a compatable VM already on your hard drive.

The whole thing ends up being awkward, and it is my impression that running code in a VM limits me as a programmer to the power of an inferior operating system. I DO like JSPs though.

Been reading and talking to some friends who worked on IBM's SOM product/project in the early 1990s. Seems that CLR is pretty much the same concept. SOM allowed for you to access objects (and their associated methods) from any programming language. Of course it never made it much past OS/2 - though PM Shell used it (I believe). Anyone used SOM think CLR is the same thing - yet again??
[ibm.com]SOM 3.0 Readme

With all the talk of.NET and C# killing Java, I decided to take a look at Visual Studio.NET for myself.

One question that I have not seen raised is this: It is easier to write programs for Linux and *BSD than it is to write programs for Windows. Many open-source programmers use this as an excuse for charging for the Windows versions of their products.

That said, why would anyone but a Windows programmer want to program for.NET when it is as messy to program for as Windows is?

Mono may support.NET programs, but do Linux, etc. developers really want to go to all the trouble of writing to.NET when Sun's JVM provides the same functionality and a much cleaner API?

I think if Sun's JVM supported other languages like Perl, Python, C, C++, etc..NET would have absolutely nothing to offer to the developer community.

I think the languages support in CLR are impressive, but still, if you have to write to a Windows-like API, what good does it do you?

Although there are a lot of things I like about.NET and the dev tools that go along with it, I still think Java and the JVM are better for cross-platform development.

The CLR runs MSIL, MSIL being an instruction set, much like the instruction set of any microprocessor. It's designed to be JITted and designed for all the rest of the.NET goals, but it's still just an instruction set.

You can implement anything using the MSIL instruction set. It may be less efficient for some things, but the same is true of all processor instruction sets.

Do we need MI support in the instruction set? The x86 instruction set doesn't have any particular instructions that are designed to support multiple inheritance, the C++ language standard defined how vtables and whatnot work to make it happen.

I certainly think that the CLR could stand the criticism and have its hype deflated, but I'm not finding a lot to recommend the JVM. Sun doesn't even acknowledge, much less support languages other than Java on the JVM, with the exception of GJ, which it would rather absorb than support.

I might also note that there are languages very much not like C# available for.NET, including haskell and scheme.

Generic Types. There is currently zero support for generic programming in the CLS.

Nobody has mentioned this yet, so I will. A research version of the CLR implements true generics, but because they only have limited resources, they decided not to include it in the first release. The following is quoted from this interview [oreilly.com] with Chief C# Language Architect Anders Hejlsberg:

Hejlsberg:
But with respect to the generics that you asked about, I definitely think generics are a very useful concept and you can certainly tell that from all the generics research that's taking place in academia and industry. Templates are one solution to the problem. In our internal discussions, we concluded that we wanted to do it right for this new platform. But what we would really like is to have generics understood by the underlying runtime. This is different from how some of the generic prototypes have been built. Take Java's notions of "erasure" where there's really no knowledge of generics in the system. By having the common language runtime understand the concept of generics, multiple languages can share the functionality. You can write a generic class in C# over in one place and someone else using a different language can use it.
But making generics part of the runtime also enables you to do certain things much more efficiently. Instantiation of generics should ideally happen at runtime. With C++, instantiation of templates happens at compile time, and then you have two options: you can either let your code bloat or you can try, in the linker, to get rid of some of the bloat. But, if you have multiple applications, you can forget about it. You're just going to get bloated code.

If you push the knowledge of generics into the common language runtime, then the runtime can understand that when an application or a component asks for a list of "Foo's," it should first ask: "Do I already have an instantiation of a list of "Foo?" If so, use that one. Indeed, if Foo is a reference type, and if we do the design right, we can share the instantiation for all reference types. For value types, such as ints and floats, and we can create one instantiation per value type. But only when an application asks for it. We've done a lot of the design work and groundwork necessary to add generics to the runtime.

It's interesting you asked earlier about the IL because deciding to add generics impacts the design of the IL. If the instructions in the IL embed type information -- if, for example, an Add instruction is not an Add, but is an Add int or an Add float or an Add double -- then you've baked the type into the instruction stream and the IL is not generic at that point. Our IL format is actually truly type neutral. And, by keeping it type neutral, we can add generics later and not get ourselves into trouble, at least not as much trouble. That's one of the reasons our IL looks different from Java byte code. We have type neutral IL. The Add instruction adds whatever the two things are on top of the stack. In a generic world, that could translate into different code when the generic is instantiated.

Osborn:
Is that available to all.NET languages?

Hejlsberg:
Yes. Microsoft Research in Cambridge has created a generics version of the common language runtime and the C# compiler. We're looking at how to move that forward right now. It's not going to happen in the first release, that much we know, but we are working on making sure that we do things right for the first release so that generics fit into the picture.

Remember the whole story about the _other_ rings: Power given to the leaders, to control their people. Of course, the leaders took the rings out of their personal greed. Sauron completely takes them, as he is able to control all the other rings, and holders of those rings, with the ONE RING.

Sounds just like it: Here, use these beautiful new "rings" (.NET), and all will be good. At least until I use my super-powers to control you when you least expect it.

All languages are totally inappropriate for many projects. Your point should not be that C# is an inappropriate language of choice, but that any language is. A broad view would teach many languages, and since business applications ARE what most developers end up doing, there is no reason that C# shouldn't be one (if not the) language to be taught as that part of the broad view.

I disagree with the quote as well, but for a different reason. A whole generation of programmers are already educated in address/pointer compatible languages. Complaining about a particular platform or model stifling innovation seems like a post-mortem to me... it's been stifled since the modern processor was introduced.