Please create an account to participate in the Slashdot moderation system


Forgot your password?

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. "
This discussion has been archived. No new comments can be posted.

One Runtime To Bind Them All

Comments Filter:
  • Slashdotted already? (Score:1, Informative)

    by Anonymous Coward on Saturday February 09, 2002 @05:49PM (#2980402)
    Google has a cache [] of the article. Please don't slashdot rhe main server!
  • by Metrollica (552191) <m etrollica AT hotmail D0T com> on Saturday February 09, 2002 @05:56PM (#2980419) Homepage Journal
    There are a few articles at Microsoft on this topic here [] and here. []

  • by typedef (139123) on Saturday February 09, 2002 @06:02PM (#2980438)
    Its from The Lord of the Rings.
    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)

    by SimonK (7722) on Saturday February 09, 2002 @06:36PM (#2980512)
    You were dead on when you said:

    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.

  • by Moderation abuser (184013) on Saturday February 09, 2002 @06:47PM (#2980536)
    Um, why do people think that you can't use different languages with the JVM?


    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... ht ml

  • by frank_adrian314159 (469671) on Saturday February 09, 2002 @08:27PM (#2980803) Homepage
    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 [].

  • by Per Bothner (19354) <> on Saturday February 09, 2002 @08:36PM (#2980833) Homepage

    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 [] 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.

  • by SuperKendall (25149) on Sunday February 10, 2002 @12:00AM (#2981264)
    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.

  • Generic Types (Score:5, Informative)

    by Oink.NET (551861) on Sunday February 10, 2002 @01:59AM (#2981460) Homepage
    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 [] with Chief C# Language Architect Anders 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?

    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)

    by SpryGuy (206254) on Sunday February 10, 2002 @02:45AM (#2981512)
    And let's not forget that a preliminary version of generics is supported in JDK 1.4 (turned on by an option, but not "officially" part of the 1.4 JDK), and will be released as an official feature of the 1.5 JDK.

One small step for man, one giant stumble for mankind.