5 ms·

Did they really have to split the library into generic/non generic? I think Java handled that much better. It's been more than a decade since I last used C#, s

Did they really have to split the library into generic/non generic? I think Java handled that much better. It's been more than a decade since I last used C#, so excuse me if I recall incorrectly.

nathanaldensr 9y ago
I'm not sure what you mean by "split the library," but what Microsoft did do is introduce generic versions of many popular and essential classes. For example, the untyped ArrayList became Collection<T>, List<T>, etc. Microsoft did this to retain backward compatibility with existing code.
enitihas 9y ago
Java didn't handle it much better, they simply chose a different tradeoff. They chose to implement generics via type erasure, which basically means List<String> and List are the exact same classes at runtime. .NET chose to implement specialised generics. Many people think that is a better tradeoff.
- KMag 9y ago
  Note that Java's originally only generic type, the array, has C#-style reified generics. The early JVM implementors should have felt a bit dirty in providing reified generics support for arrays at the VM-level without at least having a forward-compatible VM-level provision for general reified generics.
  - Someone 9y ago
    I think they made the right choice at the time. Targeting devices smaller than desktop computers about 5 years before C# (in a time when Moore’s law was in full swing), they had to cram the jvm in much smaller systems than C# targeted.
  - int_19h 9y ago
    C# did the same exact trade-off in 1.0.
  - deleted 9y ago
    [deleted]
  - mwkaufma 9y ago
    See also: syntax-baked reified arrays, slices, maps, and channels in go (but "no generics" right?)
Maultasche 9y ago
I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is. I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation. The fact that C# generics are understood by all parts of the .NET ecosystem makes it so much better and boosts the language to a much higher level than Java. C# and Java always seemed to be roughly the same to me until C# got generics, and that boosted C# to a much better plane of existence, which was followed by a great deal of innovation such as LINQ, async-await, lambdas, etc, all of which benefit from C# generics.
- xenadu02 9y ago
  To answer the parent's question: Yes, it was necessary. Doing it the way they did allowed source compatibility with pre-generic or non-generic-aware code. Passing a List<string> to something that expects an IEnumerable works just fine and effectively gives you the Java solution (at a source level) when talking to older APIs! This is why interface IEnumerable<T>: IEnumerable. >I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is. It is worse than that. Java generics don't work with value types at all thanks to this. A C# List<int> is much closer to a zero-overhead abstraction. It does not box the primitive int values. If Java ever adopts primitive generic types it will break compatibility or introduce massive performance overhead, as touching any non-generic API forces a boxing conversion. Either it negates the reason for type-erasing originally or it eliminates the main benefit of non-boxing value type support (performance). (I should clarify that Java doesn't have first-class value type support either so this really only applies to primitives) >I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation. It was a deliberate design decision to retain compatibility between pre-generic and post-generic Java code. Personally I think that was the wrong tradeoff; there is never a better time to make a breaking change than right now. The cost only ever increases with time. It was also clear back then that Java would exist for far longer with generics than without and that far more code would be written in Java post-generics than pre-generics. The result is everyone who uses Java is stuck with limitations and negative performance impacts forever, rather than accepting some short-term pain. It is also my personal opinion that source compatibility is what developers actually cared about and Sun should have told the stodgy risk-averse big Java houses to suck it up and get ready for JVM v2. It would have been a good opportunity to fix a few other things in the JVM. C# had the benefit of hindsight in some ways. I'm not sure if Java demonstrates how open delivers inferior results, how bad leadership can impact a project, or just what happens if you pay attention to what "enterprise" customers claim they want.

Did they really have to split the library into generic/non generic? I think Java handled that much better. It's been more than a decade since I last used C#, so excuse me if I recall incorrectly.

nathanaldensr 9y ago

I'm not sure what you mean by "split the library," but what Microsoft did do is introduce generic versions of many popular and essential classes. For example, the untyped ArrayList became Collection<T>, List<T>, etc. Microsoft did this to retain backward compatibility with existing code.

enitihas 9y ago

Java didn't handle it much better, they simply chose a different tradeoff. They chose to implement generics via type erasure, which basically means List<String> and List are the exact same classes at runtime. .NET chose to implement specialised generics. Many people think that is a better tradeoff.

KMag 9y ago
Note that Java's originally only generic type, the array, has C#-style reified generics. The early JVM implementors should have felt a bit dirty in providing reified generics support for arrays at the VM-level without at least having a forward-compatible VM-level provision for general reified generics.
- Someone 9y ago
  I think they made the right choice at the time. Targeting devices smaller than desktop computers about 5 years before C# (in a time when Moore’s law was in full swing), they had to cram the jvm in much smaller systems than C# targeted.
- int_19h 9y ago
  C# did the same exact trade-off in 1.0.
- deleted 9y ago
  [deleted]
- mwkaufma 9y ago
  See also: syntax-baked reified arrays, slices, maps, and channels in go (but "no generics" right?)

Maultasche 9y ago

I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is. I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation. The fact that C# generics are understood by all parts of the .NET ecosystem makes it so much better and boosts the language to a much higher level than Java. C# and Java always seemed to be roughly the same to me until C# got generics, and that boosted C# to a much better plane of existence, which was followed by a great deal of innovation such as LINQ, async-await, lambdas, etc, all of which benefit from C# generics.

xenadu02 9y ago
To answer the parent's question: Yes, it was necessary. Doing it the way they did allowed source compatibility with pre-generic or non-generic-aware code. Passing a List<string> to something that expects an IEnumerable works just fine and effectively gives you the Java solution (at a source level) when talking to older APIs! This is why interface IEnumerable<T>: IEnumerable. >I disagree. I think that C# generics are way better. The C# generics are supported at the virtual machine level, whereas Java just pretends to do generics. Java generic types are unknown to the virtual machine since the compiler just compiles a List<Foo> to a list of objects, leaving the VM ignorant of what it really is. It is worse than that. Java generics don't work with value types at all thanks to this. A C# List<int> is much closer to a zero-overhead abstraction. It does not box the primitive int values. If Java ever adopts primitive generic types it will break compatibility or introduce massive performance overhead, as touching any non-generic API forces a boxing conversion. Either it negates the reason for type-erasing originally or it eliminates the main benefit of non-boxing value type support (performance). (I should clarify that Java doesn't have first-class value type support either so this really only applies to primitives) >I thought the Java implementation was almost a workaround to avoid the hard work of a true generics implementation. It was a deliberate design decision to retain compatibility between pre-generic and post-generic Java code. Personally I think that was the wrong tradeoff; there is never a better time to make a breaking change than right now. The cost only ever increases with time. It was also clear back then that Java would exist for far longer with generics than without and that far more code would be written in Java post-generics than pre-generics. The result is everyone who uses Java is stuck with limitations and negative performance impacts forever, rather than accepting some short-term pain. It is also my personal opinion that source compatibility is what developers actually cared about and Sun should have told the stodgy risk-averse big Java houses to suck it up and get ready for JVM v2. It would have been a good opportunity to fix a few other things in the JVM. C# had the benefit of hindsight in some ways. I'm not sure if Java demonstrates how open delivers inferior results, how bad leadership can impact a project, or just what happens if you pay attention to what "enterprise" customers claim they want.