One Runtime To Bind Them All 479
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. "
Slashdotted already? (Score:1, Informative)
Articles at Microsoft.com (Score:3, Informative)
Re:"One Runtime To Bind Them All" (Score:2, Informative)
Actually, the correct quote would be "One Runtime to rule them all, and in the darkness bind them."
In the land of Redmond, where shadows lie...
Correct (Score:4, Informative)
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.
You can use many languages with the JVM (Score:4, Informative)
Hmm?
Are you all silly billies?
There's dozens of the bastards... Christ, the've even got Cobol and Ada. I wasn't even trying hard and, sorry tolk...
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages
--
Re:Cross-Platform Java CLR (Score:3, Informative)
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].
Re:job fun != nerf toys (Score:2, Informative)
I think Python/Jython is the only language that allows you to do things like this. I doubt it's true for all the other languages which are compilable to the JVM.
Kawa [gnu.org] allows you to define classes in Scheme that extend Java classes. It even supports multiple inheritance, by compiling a Scheme class to a pair of a Java interface and a Java class.
Java has not yet failed on the desktop... (Score:3, Informative)
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.
Generic Types (Score:5, Informative)
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.
Re:Generic Types (Score:2, Informative)