Slashdot Mirror
One Runtime To Bind Them All
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'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.
.net is pretty much just a ripoff of java, there are some 'evolutionary' enhancements like XML serialization and that sort of thing.
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
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.
autopr0n is like, down and stuff.
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.
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.
This point has been made before, but it bears repeating. C# and the CLI (Common Language Infrastructure) are ECMA 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.
- -
Are you an SF Fan? Are you a Tru-Fan?
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.
.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.
.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."
The author is saying pretty much what I figured, which is that
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
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."
We're on the road to Tycho.
Comment removed based on user account deletion
1977 - UCSD Pascal P-Code was going to unify computing under one language.
1990 - Visual Basic revolutionized programming by interpreting to P-code and requiring a run-time.
1991 - Java was going to rock our worlds and promised "write once, run anywhere" using an intermediate byte code that looks a lot like P-code.
2002 - Microsoft promises one runtime to which many languages will compile in the megarevolutionary (and some say Orwellian) dot net architecture.
Like it was said in Ecclesiastes, there is nothing new under the sun.
Another proud carrier of the $rtbl flag
Looks like you picked the right door! Not only do you win a platform supported by a whole industry, but the only truly open standard around! Now THAT bears repeating.
.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.
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
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.
.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"CLR lacks continuations" ... so does JVM
... so does JVM
... etc
.NET, including haskell and scheme.
"CLR requires static single inheritance"
"CLR lacks multiple dispatch"
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
I've finally had it: until slashdot gets article moderation, I am not coming back.
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 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.
Comment removed based on user account deletion