Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Java Microsoft Programming IT Technology

Hejlsberg Talk About Generics in C# and Java 128

Posted by timothy from the from-the-source dept.
An anonymous reader writes "artima.com has a very interesting interview with Anders Hejlsberg - the Borland guy now at Microsoft who can best be defined as MR C# - doing all the stuff that Borland wouldn't let him do. He discusses generics in C#, Java (1.5) and C++. Naturally there is the chance of bias but he does raise some interesting points againt Java's generics. Specifically that Java's genericised collections will have to box all primitive types as full objects, whereas C# does not. This is a big performance plus for C#. Java created the primitive types in the first place to address performance concerns but appears to be stepping sideways here. I can't help wondering if Sun has taken this approach to get the syntatic sugar in the language without requiring a bytecode change, but perhaps in a future VM version will allow primitive generics (obvioulsy forcing a bytecode regeneration)?"
This discussion has been archived. No new comments can be posted.

Hejlsberg Talk About Generics in C# and Java More

Hejlsberg Talk About Generics in C# and Java

Comments Filter:
  • " Specifically that Java's genericised collections will have to box all primitive types as full objects, whereas C# does not. This is a big performance plus for C#."

    Do you have any references to back that up, or is this just "conventional wisdom"?

    I'm not saying it's incorrect, but I'd wait until there are two implementations to compare.

    • Re:Performance of generics (Score:5, Insightful)

      by hibiki_r ( 649814 ) on Wednesday January 28, 2004 @12:26PM (#8114078)

      Just read a little further into the article. It seems that to avoid having to make changes in the VM, the Java generics have to become just like the current containers at the bytecode level. The main difference would be taht instead of having to type all the ugly type casts yourself, the compiler would do it for you. Obviously, this doesn't lead to any performance increases over Java 1.4 containters.

      Compare this to, let's say, C++ templates, where the compiler makes a new copy of the template class specifically for each and every type you use on it. That makes the executable size increase a bunch, but it allows the compiler to pay the performance price, making the code perform almost like a program where a human programmer would have written a copy of the template class for each and every type you ever used it with.

      Since the design of the java 1.5 generics is public knowledge, it's pretty easy for anyone with a reasonable programming knowledge to analyze it. It just seems that run-time efficiency wasn't the first thing in the designers minds.

    • For as long as I have been a Java programmer (4 years) at least, there have been collection libraries [sourceforge.net] for Java that are specialized for primitive types. One of their main reasons for existence is to avoid the performance overhead of boxing.

      You can get a very rough idea of the performance gain here [onjava.com] (scroll down to "Trove Primitive Collections"). It's a significant difference.

      Of course, for most apps that people are writing for Java (i.e. webapps for business), an optimization of this magnitude won't be

      • On the other hand, IIUC, MS intends to write large sections of Longhorn in C#.

        Maybe that's why it's not due until 2006: they have to wait for commodity hardware to get fast enough to run it responsively.

  • Boxing in Java (Score:3, Interesting)

    by Ianoo ( 711633 ) on Wednesday January 28, 2004 @12:05PM (#8113833) Journal
    Primitive types are boxed in C#, just automatically wrapped and unwrapped as required. But what he seems to fail to realise is that Java 1.5 is introducing this too, so that I will be able to define method(Object obj) and type method(12) and will receive a boxed Integer type. This should work fairly for generics too (I hope).

    • Re:Boxing in Java (Score:2, Interesting)

      by drkich ( 305460 ) *
      Yes, C# does auto-boxing for the user. However, his point was that the Generics will not auto-box the primitive inside of an object.

      So for instance if you have a List, you can not place an Integer with out unboxing it. Vice-versa, if you have a List you can not place an int into with out boxing it.

      However if you have a List you can place an int into it directly without boxing it.
      • For some reason my > and < were removed, and I did not realize it.

        So for instance if you have a List<int>, you can not place an Integer with out unboxing it. Vice-versa, if you have a List<Integer> you can not place an int into with out boxing it.

        However if you have a List<int> you can place an int into it directly without boxing it.

    • Re:Boxing in Java (Score:4, Interesting)

      by jovlinger ( 55075 ) on Wednesday January 28, 2004 @12:20PM (#8114000) Homepage
      Automatic boxing and unboxing will be identical to manual boxing from a performance standpoint.

      I got the impression that C# could actually use generics to instantiate the array at type int, rather than type Integer with autoboxing.
      • That's what will happen in C# generics (supposedly).

        It will be neat, but it adds more complexity to the system.
        • It will be neat, but it adds more complexity to the system

          Yes, but complexity at the right place: in the compiler. Exposing the boxing/unboxing distinction to the programmer makes it easier to generate good code, but you now have all this manual wrapperized stuff to deal with all over your code.

          On the other hand, research has shown that even naive analysis will allow you to generate quite good code from LISP, which is nominally completely statically type-opaque (you have no idea WHAT you have until you
          • Um. It also adds complexity to the runtime, and to the programmer.

            Generics is not like a recompile and go situation. You have to rewrite all your code that uses lists and collections if you want to use the new generic features, otherwise you get new compile errors when useing the collections. This is not as bad for C# as compared to Java since C# is a much younger language and thus the API is also smaller (so far).

            Since in .NET CLR a List is actually compiled into a list that only holds ints (and not o
            • I think you're mistaken regarding the need for recompiling your C# source code before moving to Whidbey. First of all, generics are optional and there will still be a List class that is perfectly happy to take your Object-derived instances and hold them for you.

              Since in .NET CLR a List is actually compiled into a list that only holds ints (and not objects), it actually has a completly different codepath then a List or List.

              WTF are you talking about? The only way you're going to get an instance of a cl

              • Of course this:
                ArrayList intList = new ArrayList();

                Should have been this:
                ArrayList<int> intList = new ArrayList<int>();

              • Re:Boxing in Java (Score:2, Informative)

                by Steveftoth ( 78419 )
                My bad, I should to have said that a Generic List is compiled at runtime into a seperate class by the JIT.

                Since in .NET CLR a List is actually compiled into a list that only holds ints (and not objects), it actually has a completly different codepath then a List or List.

                WTF are you talking about? The only way you're going to get an instance of a class that implements IList and only holds ints is to do this ArrayList intList = new ArrayList(); If you just choose ArrayList myList = new ArrayList(); yo
                • I think what is going on is that you will get a list class for each separate value type and then one list class that will hold all the reference types (the value type is sort of like pointer).

                  I mean, how many value types are there already? So you get a couple instantiatians of the class instead of one. And if you are really worried about footprint, you can use only reference types in your list.

              • No one said they're the silver bullet, but as someone else indicated, spend some time deriving classes from CollectionBase and you'll quickly appreciate having strongly typed collections with no heavy lifting on your part.
                I never pass around collections outside of my own programming interfaces. Otherwise you have other problems.

                Most of them relate to bounds checking and not type checking. Bounds checking which may change at runtime, rather then simple type checking which is rather static. I personally
    • yeah, but the whole point is that C# doesn't need to box primitive generic types, it'll just JIT-compile a version of that method specifically for that primitive type, so a <T>[] becomes an int[] (as opposed to a casted Object[]), for example. Likewise for object types, C# doesn't need to do the casting that Java requires.
  • Specifically that Java's genericised collections will have to box all primitive types as full objects, whereas C# does not. This is a big performance plus for C#.

    The Java collections operate this way right now (in JDK 1.4) and AFAIK have operated this way since the beginning. You can't add a primitive type to a collection, genericised or not, it has to be a first class Object. In terms of performance, whether or not the conversion is done explicitly or automatically shouldn't matter. If anything, the aut
    • This is just my interpretation. I'm not a C# developer:

      Its faster because C# ints don't have to be converted. They are already objects (more like second class structure-like objects). When you define a collection of ints in C#, there is no boxing needed to populate the collection.

      You are right about Java, however. The byte code looks the same if you use generics, or not. There won't be any performance loss from old code, just better looking code.

      What the article is saying, is that adding primitives
      • What the article is saying, is that adding primitives to a collection is slower than adding objects (due to boxing - automatic or otherwise).

        Yes, but the title of this article is "Generics in C#, Java, and C++". My question is, what the hell does autoboxing in Java have to do with generics? With generics, only objects can be put into collections. Without generics, only objects can be put into collections. Nothing's changed!

        Of course, I think the real point of this article is to use the topic of Generics

        • Re:Nothing's changed here... (Score:5, Informative)

          by sab39 ( 10510 ) on Wednesday January 28, 2004 @02:06PM (#8115118) Homepage
          It doesn't have anything to do with autoboxing in Java, but it has everything to do with boxing in Java versus C#.

          Both C# and Java require boxing if you want to put an int into an object variable. They differ in whether that boxing is automatic or not (at least until Java makes it automatic in 1.5), but that's irrelevant: it still happens, so the performance impact is the same in both languages.

          However, if you're trying to put that same int into an ArrayList<int>, the two languages are very different.

          In Java, ArrayList<int> is really just ArrayList<Object> under the covers, and stores its contents into an array of type Object[], so the boxing operation still needs to happen. Hence, there's a performance hit.

          In C#, ArrayList<int> is interpreted as such at the runtime level and the JIT compiler creates native code for it that stores the contents in an array of type int[]. When you store values into that array, no boxing is needed, automatic or otherwise. No performance hit.

          Both C# 1.1 and Java 1.4 collections can hold primitive types if you box them. In Java 1.5, you get some extra syntactic sugar (which C# had from day one) but the boxing still happens. In C# 2.0, generic collections can hold primitive types without boxing. That's the difference that he's trying to get across in this article, and why it's specific to generics.

          All of this is explained very clearly in the article and it amazes me that so many people can't grasp it...
          • I don't think that it makes List into int[]... since it sounds like you can put whatever into List, which means that you could have a subclass of int.

            The impression I got was that autoboxing was not necessary because everything is always boxed ( i.e they have no primitves in C# ).

            Please correct me if I'm wrong.

            • Re:Nothing's changed here... (Score:4, Informative)

              by sab39 ( 10510 ) on Wednesday January 28, 2004 @03:53PM (#8116482) Homepage
              I'm afraid you are wrong.

              While "int" is treated "as if" it were an Object in the CLR, and behaves as if it was a subclass of Object, it really is a value type: It's allocated on the stack, cannot be subclassed, and is passed by value when it's used as a method parameter or return value.

              The same goes for all the other built in primitive types (float, decimal, double, long, short, bool, char etc), along with user-defined Structs and Enums. These are all considered "Value Types" in the CLR.

              When instances of value types need to be treated as Objects, they are boxed, just like in Java, except that it's transparent and automatic and there's no separate class that represents the boxed type - the distinction Java makes between int and Integer simply doesn't exist in C#. (System.Int32 is just an alias for int and isn't equivalent to Integer at all in any way).

              The article clearly states that in Generic C#, the JIT actually creates specialized binary code whenever a generic class is instantiated with a value type argument. It even uses the example of List<int> turning into int[] (remember value types like int can't be subclassed, so the subclass problem doesn't arise).

              C# provides the "illusion" of no primitives, but it's certainly not true that everything's always boxed. It just provides a more elegant and flexible model of boxing than Java does.
    • In C#, no conversion/wrapping/boxing, whether manual or automatic, will be necessary. The parameterized type will actually store the values in their unvarnished, primitive form.

      C# generics are smart enough to treat value types differently than reference types (or what you're calling a "first class Object"), while Java generics are not.

  • Why Generics? (Score:3, Interesting)

    by HaiLHaiL ( 250648 ) on Wednesday January 28, 2004 @12:15PM (#8113941) Homepage
    I'm a Java developer of 4 years and I'm unimpressed by generics. Why have all those 's dirtying up my code, only to enforce strong typing on my collections? If strong typing is really important, I can create my own strongly-typed collection. Otherwise, there's something called GOOD CODING, along with runtime exceptions, which enforce it. I don't see the need for all that extra ugly syntax just to enforce it at compile time.
    • "all those <>'s"

      (who would have thought I need to use html entities in posting "Plain Old Text"?)


    • I think it's a marketing thing. Every now and again, the PHBs have a need to scream, "Look - we added new stuff"!!!
      It doesn't really matter if the new stuff is useful or necessary, just so long as they can slap a "Now With 14% More Creamy Goodness" sticker on the side of the box.
    • Why have all those 's dirtying up my code, only to enforce strong typing on my collections?

      Because compile time errors suck much less than run time errors.

    • Re:Why Generics? (Score:5, Insightful)

      by Aniquel ( 151133 ) on Wednesday January 28, 2004 @12:33PM (#8114150)
      A couple different reasons, actually. First, as mentioned in the article, performance. If you're using generics (come on, call them templates!) and compile-time checking, then you don't need to do the dynamic casting at run-time (c# doesn't, according to the article).

      Second, don't scoff at compile-time type checking - I've run into problems on large java projects where there's been some confusion as to what, actually, has been stored in certain collections. Generics prevent this.

      It comes down to this: How much help do you, as a programmer, want?

      • Second, don't scoff at compile-time type checking - I've run into problems on large java projects where there's been some confusion as to what, actually, has been stored in certain collections. Generics prevent this.
        I've run into this too, and you know what the solution is? To go to the programmer's cube who is responsible for the code and beat him/her with your clue stick until they wise up.
        • Clue sticks can't solve all humanity's problems; we're too far gone as a species for that. But if you can have an automated tool enforce the rules, why not use it? Admit it: Generics make it easier to understand the code, because you are always sure of what you get. Nobody is FORCING you to use generics. But if you do use them, your code will be more readable, even if you are a lousy programmer.
          • "Clue sticks can't solve all humanity's problems"

            Who says they can? It just will make you feel better and release some stress beating the hell out of someone. Much better if he's responsible of something.
          • But generics don't solve the problem of bad programmers, it just forces them to be more creative.

            And no, I don't think that generics make it any easier to read the code

            If someone hands you this interface.
            public interface CrappyInterface {
            public Map<String,String> getStringMap();
            }

            and tells you that their class implements it, what good has generics done you. Nothing. It buys you compile time saftey, sure, but what does the interface actually do? That requires documentation, and in the documentatio
            • That's not the problem he's talking about. The main point with generics is that if you have something like

              List names;

              then you don't know anything about what type to get out of that list. And if the coder had done something strange like put numerical references to a database with names in the list then you'll get a run-time error. If the list instead is

              List names;

              then you at least know something about what to expect from the List. (And you know that you have to hunt down documentation for it since it's n
              • "You shall use preview, you shall use preview, you..."

                The first example should read (as it does) List names;

                The second example should read List<Integer> names;
        • And what happens when you're on a team of 100, and you don't know everyone's contributions?

          Your attitude just doesn't scale.
          • Neither do software teams of a hundred people!

            Neither Java or C# can solve the problem of having too many people on the same project with bad management.

    • Re:Why Generics? (Score:5, Insightful)

      by Naerbnic ( 123002 ) on Wednesday January 28, 2004 @12:48PM (#8114305)
      "To ask the question is to know the answer"

      The easiest response to that, is the point you just brought up. To get some semblance of compile time type checking, you'd have to make your own type. There are various disadvantages to this, among which are:

      • It uses up your precious time to do what should be almost automateable
      • You can't easily fit back your custom class into the standard classes Java would provide. Your derived class, for instance, would be returning class Foo instead of object. Java doesn't allow you to override methods that vary only by return type
      • Depending on naming, the new class may not be apparent to someone using your API to what it is, especially if your custom class is simply a wrapper around a standard class


      As for the benefits of generics, a basic one is that it makes the intent of the code clearer (since you don't want to make a custom type, for the reasons above). The other major one I can come up with right now, is making your interfaces clearer to people who would use your classes. By fully specifying the type (including what is supposed to be in collections), you can make sure the class user is clear on what the interface to a method is, and if he makes a mistake, the compiler will tell him. This means you don't have to deal with all the messy exception handling and such that would go along with just using Object base types.

      I am agreed that the < > syntax can be too verbose at times, especially with something like LongClassName<AnotherName> foo = LongClassName<AnotherName>(). Of course, this leaves us with a quandary, since on the one had we want to be able to easily see and specify types of everything, which would suggest using full typenames everywhere. On the other hand, we could introduce typedef like functionality, but that would have some problems of clarity. It seems that Java has historically, and still is taking the first approach.

    • From your post, it seems that you're probably not working on a large (200K+ lines) application, where more than 3 or 4 programmers are involved in development.

      If I could be the sole maintainer of all of the code in my project, I'd not see all that big of an advantage in generics. the main thing would probably be avoiding all of those ugly typecasts all java programmers have to live with, but all in all It'd not be a big deal. However, on a big project, I REALLY, REALLY want to be able to easily know which

    • I'm a Java developer of 4 years and I'm unimpressed by generics ... I don't see the need for all that extra ugly syntax just to enforce it at compile time.

      It's a good thing then that you don't have to use generics if you don't want to. The choice is great, isn't it?

      Personally I do a lot of development with the Java collection framework. Generics will save me a lot of time and code spent checking Object types.

    • If strong typing is really important, I can create my own strongly-typed collection.

      Over and over and over again...

      something called GOOD CODING, along with runtime exceptions, which enforce it. I don't see the need for all that extra ugly syntax just to enforce it at compile time.

      Bwahaha. Nice troll. Ask any serious programmer, and he/she will tell you that good coding practice calls for as many checks as possible during compilation, while it's still in the lab. "Whew, it got caught during ru

      • Ask any programmer who has worked on large system using strongly-typed and untyped languages which they prefer. They're probably all still working in Scheme/Lisp or Smalltalk and never went back to their tinkertoys, aka C++.
    • Why have all those [< >]'s dirtying up my code, only to enforce strong typing on my collections?

      I was assuming that the < >s would remove the need for the much dirtier

      fooCollection.add(new Double(fooPrimitive));

      and

      fooPrimitive = ((Double)(fooCollection.get(xxx))).doubleValue();

      etc.

      Or is this still required?

    • Re:Why Generics? (Score:3, Insightful)

      by Dr. Bent ( 533421 )
      If strong typing is really important, I can create my own strongly-typed collection.

      Sure you can. You can also write the Java bytecode by hand, in hexadecimal, using only your pinky fingers to type.

      The point of generics is to reduce (significantly) the amount of time it takes to create strongly typed collections. In addition, it makes those collections more reusable. For example, if I make a strongly typed Iterator, either I have to make an Iterator that doesn't inherit from the java.util.Iterator inter
    • Let me get this straight. On the one hand I can declare the contained type once at declaration time. On the other hand, I can declare the contained type every time it is used.

      Speaking from personal experience, objects are used at least several times after being declared.
    • I'm a COBOL developer of 10 years and I'm unimpressed by Java. Local variables? Dynamic memory allocation? Bah! I don't need all those dirtying up my code. You should declare all of your variables globally and allocate memory statically for the lifetime of your program. If dynamic allocation is really important, I can create my own functions in assembly language.
  • I've been waiting for a long time before generics get released for C#. At least now e know they're doing them properly. Sounds like they will outperform java significantly... at least with value types.
  • Not having to "box primitives" is certainly an advantage in that it makes the language cleaner. So I think C# is better because of this. But I find it hard to believe that this "improves performance". I would think the whole reason for treating primitives differently is to improve performance, as they can go through optimized code rather than the path taken by normal user-defined objects. So a collection of boxed primitives in Java may be slower than non-boxed primitives in C#, but this was done so that a c
    • The types of performance problems you're talking about are orders of magnitude away from the performance problems that users percieve when using Java applications though. The same problem exists in C#, and users will percieve it as slow too as soon as average and below average programmers start using C# for applications that people actually use.

      When somebody says that a java application is painfully slow, the problem usually stems from the use of stock objects and the programmer's lack of understanding of
      • The types of performance problems you're talking about are orders of magnitude away from the performance problems that users percieve when using Java applications though.

        I disagree here.

        Think of Moore's law, processor speeds, etc... Java is a fast enough language for doing just about anything a user needs to do. Even if java were only 25% as fast as native code, that would be 2 cycles of Moore's law, 36 months, 3 years ago. (And, java is much faster than 25% of C, check here [bagley.org])

        3 years ago, users were a

        • Re:It does seem any "performance" argument is bogu (Score:1, Interesting)

          by Anonymous Coward
          One other area where java gets a bad rap for being slow is in startup time. I write a lot of small java apps and continually loading the jvm adds about a second to the startup time on my machine. I've gotten around this by creating a RAM disk at startup and copying the jvm executable and jars over. This gets rid of the noticeable startup time. JVMs should come with the option of loading into memory at startup...it would help dispell the myth that java, by nature is too slow.

          But you're right about the G
        • I would agree with you if it were impossible to make a responsive GUI in Java. It isn't. Most unresponsive Java GUI's are slow due to poor choice of object operations when responding to events, not because it's using 'non-native' GUI calls, which at worst add a layer of library indirection.

          The slowness we're talking about isn't typically miliseconds, it's whole seconds. You're talking about graphical slugishness, which is a whole differen't issue, and one that most users don't even notice.
    • So a collection of boxed primitives in Java may be slower than non-boxed primitives in C#, but this was done so that a collection of normal objects is faster.
      Faster than what? Faster than the Java implementation would have been had they done it properly (i.e. modify the byte code, not rely on type erasure, etc). Or are you saying that this ommision makes the Java generics implementation faster than the C# generics implementation?
      • What I'm saying is it *doesn't* make the C# implementation faster. If C# is written intelligently, the best it can do is make it the *same* speed.

        Now C# could in general be written better and do the *same* job faster. And I agree that this ability makes the language *better*. But saying this better feature of the languages is the *reason* it does something faster is bogus. I am pretty certain the artificial differentiation between primitives and objects in both languages is in order to make them more effic
        • There are two types of objects: 1) value types (primitives, enums, structs, etc...), and 2) reference types (objects and boxed value types).

          There are two types of collections: 1) collections of value types, and 2) collections of reference types.

          Collections of value types are usually faster because they don't require: 1) individual heap storage for each element, and 2) dereferencing references to elements.

          Java doesn't have generic collections of value types.

          C# will potentially on-demand JIT compile many

    • It's not simply that primitives go through optimized code in collections. Primitives in Java are fundamentally different than objects in that they are stored inline with their context (either the stack, an array, or the object they're a member of), whereas objects are always referred to by reference and stored somewhere on the heap.

      <oversimplification>So for example, an int[10] takes 40 contiguous bytes (4 bytes per int) on the heap. That block contains the actual values of the ints. An Integer[1

    • RTFA

      For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int<, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler ac

  • Can't Believe (Score:2, Informative)

    by Apreche ( 239272 )
    People complain about the dumbest things. I always laugh when someone complains about the performance of java. Guess what, if your app needs to be high performance, you shouldn't be doing it in java. If it doesn't need to be high performance but it needs to run on every os and computing device under the sun, then you should use java.

    Programming languages are tools. Hammers for nails, screwdrivers for screws, C for hardcore big stuff and python/perl for everyday fun. Java was never intended to be high per
    • Guess what, if your app needs to be high performance, you shouldn't be doing it in java.

      I laugh when people make sweeping generalities that aren't based in reality.

  • The other downside to java generics is worse (Score:5, Informative)

    by Matt2000 ( 29624 ) on Wednesday January 28, 2004 @12:42PM (#8114248) Homepage
    I read the article to see what the numbers were on performance differences. Turns out there were none, what a surprise! So as usual, in theory, perhaps maybe there might be a performance difference and maybe it might be significant or not, or both. Until real comparisons are made, safe to ignore.

    What's more important is his other problem with Java generics which is that in runtime it's not possible to tell what type a collection is compiled as, this is to retain bytecode compatibility. So reflection will have no clue on any of this generics stuff, which isn't a deal breaker, it's just a downside I hadn't heard about before.
    • I use both C# and Java everyday and I think that the reflection issue won't hurt many people.

      I prefer the Java approach because it means my 1.5 Java code is compatible with pretty much every modern JVM out there.

      I'm sick of trying to identify whether I have a user machine with .NET 1.1 or 1.0 on it. I know that my C# code should work on 1.1 and 1.0 but I have far less confidence than (say) running my 1.4 code on a 1.3 JVM. Java gives me a lot more confidence!
    • It depends on your perspective. Java 1.5 code will run on a Java 1.4 VM (unless it uses some of the new APIs). I can only assume C# won't be able to manage this.
  • Because Java is the best and C# is wrong and if this really is a performance difference then performance doesn't matter today but it probably isn't really a performance difference and what matters is clean syntax and open portability VM I bytecode everybody knows bean he needs to read blah, grouty, blah.

    It seems many Slashdot readers not only fail to read the articles or others' comments, but can't even be bothered to read the whole little summary blurb before commenting.

    Half the comments on this story ar

  • Oh, the irony! (Score:3, Interesting)

    by joelparker ( 586428 ) <joel@school.net> on Wednesday January 28, 2004 @12:51PM (#8114332) Homepage
    ...we do fairly aggressive code sharing
    where it makes sense, but we are also very
    conscious about not sharing where you want
    the performance.

    Welcome to the Microsoft business model. :)

  • C# vs Java (Score:4, Insightful)

    by astrashe ( 7452 ) on Wednesday January 28, 2004 @01:05PM (#8114479) Journal
    I've been reading through the various segments of the interview, and I tend to buy most of what Hejlsberg says on various Java vs. C# issues.

    But I keep coming back to the idea that the changes (or improvements) aren't enough. If you accept that all of the changes are improvements, that they make things better, they're still not enough to justify getting locked into a single vendor, or in learning new libraries.

    C# cleans up some of Java's annoyances, which is great, but the annoyances just aren't big enough to make the shift worthwhile. That's the problem.

    I think the libraries problem is huge for Microsoft. The java libraries are just getting to be so big, complex, and rich that it will be very hard to get people to move away from them.

    I don't think that anyone says there aren't annoying things in Java, parts of it that wouldn't be done differently if the language could be redesigned from scratch. But those annoyances are liveable -- for the most part, you can deal with them.

    Java's has those libraries, though, and one of the reasons the libraries are so rich is that Sun opened up the process to other companies. MS is huge, they have a lot of smart guys, but I just don't think they can compete with Java's comparative openness.

    That's the thing -- you can read about checked exceptions, and agree that it would be nice if java handled things more like C#, but it's not even close to being enough to overcome the value of java's openness vs. Microsoft's closed approach.

    In the end, it really comes down to the business model.
    • Then take your Java library code, compile it with IKVM [ikvm.net] running on Mono [go-mono.com], and write code in C# using it without being locked into any vendor :)

      • Re:C# vs Java (Score:3, Insightful)

        by astrashe ( 7452 )
        Thanks for the IKVM link. It looks like a pretty cool project, although the blog is a little over my head.

        But if I had a job writing software for large banks, or some other very serious group of people (I don't), I'd be afraid of using something like IKVM and Mono -- again, Java's annoyances don't seem annoying enough to push people that far out of the mainstream.

        Isn't the primary value of these sorts of projects in the learning?

        I mean, in order to follow the IKVM development blog, I'd have to be a much
        • I'm using IKVM in production right now in a real (albeit small) company. And mono plan on releasing 1.0 within the next 6 months, which they will recommend for production use - we're evaluating that for use within our company also.

          I have some development tools [nongnu.org] written in Java which have language-independent output (supporting both Java and C#) but our company primarily uses C# these days. Still, every developer had to install the JDK and a JDBC driver in order to run our compile process, since it invokes t
          • SUN's philosophy is a little bit like "One language to run them all, one language to bind them, one language to link them all . . ." It is kind of like you go whole hog with Java or not at all, and part of the reasoning is that if you link it to other stuff you create platform dependencies.

            But Matlab has a cool way of using Java objects, and Java objects have a less-fuss connection to Matlab than MEX-C++. And for tight loops in pure numerical code, Java oddly enough is actually pretty efficient.

            JNI al


  • I've never used genrics. From what I understand, it's a way to keep a group of different objects in a collection without having to warry about what type of object they are when you retrieve them.
    I can't think of any useful application where I need a collection of different types of objects. In some case where I might (a shopping cart) the items can just implement an interface to guarantee me the operations I need to perform on different objects.
    Why would I need to collect a String, an int and some user-defi
    • You apparently do not understand generics. Generics are not keeping "a group of different objects in a collection". Generics allow just the opposite. Rather than having a container that accepts values of type Object, you specialize a generic container to only accept and return values of your type.

      Actually, I was going to give an example, but rather I will instruct people to RTFA.


      • Is that all? Seems like much ado about nothing.
        • Write C for five years. Then write C++ for another five with a compiler that does not support generics/templates. No STL, no BOOST, no ATL/WTL, no nothing. Then switch to a compiler that supports them and drool in amazement at how much easier writing code suddenly becomes.

          That's not "much ado about nothing", it's just that you don't know what you're talking about.

          C# and Java are getting generics because you don't want to spend three days inheriting from DictionaryBase or whatever to crate yet another st

          • I don't like the templates/STL combo. I'm not saying it's not usefull, but is too much like a macro mechanism and can be messy. When you make a simple syntax error the compiler messages maybe 5 lines long and not at all clear on what the problem is. And very few people know the internal workings of a STL implementation, and it seems to me that you need to know quite too much to really have control over it. A guy over here that programmed C/C++ for years and use STL didn't know when you need a copy construct
    • No one has explained this well yet. Generics are not about containers. They are about writing algorithms that are can be reused for different data types. However, collections are a usefull example of how they can be used, so I will start with that.

      There are a couple ways to design containers. First you have have them hardcoded into the language like, but eventually someone will want a different way of storing data than the language provides, and will have to implement their own container. The next simplest

  • ...but perhaps in a future VM version [Java] will allow primitive generics (obviously forcing a bytecode regeneration)

    Allowing primitive type arguments in generics would not necessarily require any changes to the VM or bytecode.

    The Java 1.5 implementation of generics is substantially based on the Pizza compiler, which allowed primitive type arguments without requiring boxing (links: the pizza compiler [sourceforge.net], the GJ compiler it evolved into [unisa.edu.au], some academic papers about the compilers [lamp.epfl.ch]).

    If I remember correctly

    • RTFA. AH is not talking about being able to pass primitive types to generics, he's talking about the JIT compiler being able to use primitive types in an instantiation of a generic. In Java all generics' type parameters are derived from Object (whether or not they were specified as such). In C#, type parameters can be unboxed primitive types and the JIT-generated code will treat them as such.
  • Contrary to what the interview claims, there are. Please refer to Bjarne Stroustrup's page: http://www.research.att.com/~bs/bs_faq2.html#const raints In addition, "The compiler checks it, but you could also be doing it at runtime with reflection, and then the system checks it". It is a waste to double-check at runtime what has been guaranteed at compile time.
  • ... is that C++ templates suck compared to C# generics.

    BUT he is lying, it is actually the other way around. ;)

    "C# does strong type checking when you compile the generic type. ... <snip> ... So in C# generics, we guarantee that any operation you do on a type parameter will succeed."

    I don't understand what Mr. Hejlsberg is saying here. Does he imply that C# code is checked before you compile it, and the programmer is prevented from typing the wrong thing, using their super-secret-mind-reader-thin

Slashdot Top Deals

Did you know that for the price of a 280-Z you can buy two Z-80's? -- P.J. Plauger

Close