4 ms·

"Modernized Java", it's basically a slightly uglier C#. Not that I'd argue C# isn't modern, it's in fact one of the most 'modern' languages I can imagine at th

by tinco 13y ago

"Modernized Java", it's basically a slightly uglier C#. Not that I'd argue C# isn't modern, it's in fact one of the most 'modern' languages I can imagine at the moment, but it's kind of wry that C# did such a good job of keeping current where Java lagged so terribly behind.

bad_user 13y ago
Same can be said for the JVM vs CLR, only in reverse.
- commentzorro 13y ago
  I had always thought that the CLR was considerably ahead of the JVM, though admittedly only anecdotally. What is in the JVM that is not in the CLR that makes the JVM further ahead, so to speak.
  - windust 13y ago
    Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.
  - bananas 13y ago
    Technical aspects are almost irrelevant. For me, it's about the ecosystem. I do a fair bit of work on the CLR and JVM. The JVM has the following advantages: open source, cross platform, free tooling[1], incredibly more mature 3rd party libraries, zero OS cost to deploy, architectures ready to roll out of the box. A lot of the Java stuff I do is literally integrating some off the shelf bits that work 100% reliably first time and it's done. Compare to C# where I end up having to do a lot of leg work and navigating immature, abandoned or just broken open source projects. [1] By the time I've bought VS Pro 2013 with MSDN, ANTS profiler, NCover, VisualSVN, I'm down a pile of cash.
  - bad_user 13y ago
    Well, as it turns out, that was just Microsoft's marketing. They did have a head start, but they dropped the ball on that one ever since .NET 2.0.
- moonchrome 13y ago
  JVM doesn't even have value types or generics making it practically unusable in some scenarios. While JVM implementations might be better quality for specific problem domains I'd say CIL is probably better than JVM. Not to mention CIL was designed to be a Common Intermediate Language from start so language interop is nicer (generics are a nice example)
  - lmm 13y ago
    Actually I've heard that CIL generics make language interop harder, because you're essentially forced to have a generics model that corresponds exactly to C#'s. This was a major factor in abandoning the .net version of Scala. (Whereas on the JVM, type erasure means that Scala is free to apply its own generics model rather than having to match Java's)
    - moonchrome 13y ago
      It's not like Scala has generics interop with Java, you can't use advanced Scala generics from Java so I don't see your point. I'm sure they could have erased the extra stuff on CIL and support a basic subset that's visible to .NET languages. Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.
      - sixbrx 13y ago
        Yet the CLR model is apparently not flexible enough to implement type classes, which Scala can handle in a very flexible way. Here's Microsoft's rejection claiming that the current CLR can't practically support type classes: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes https://visualstudio.uservoice.com/forums/121579-visual-stud... Apparently baking the generics into the generated bytecode has downsides in flexibility.
      - bad_user 13y ago
        > It's not like Scala has generics interop with Java Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode. > you can't use advanced Scala generics from Java I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it? > I'm sure they could have erased the extra stuff on CIL Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics. As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all). > Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types. That's not true. Reified generics isn't the only solution to this problem you know. Scala can specialize the generic types for primitives ... http://www.scala-lang.org/api/2.10.4/index.html#scala.specialized http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...
aerique 13y ago
Would you mind expanding on what you think is modern about C#?
- sidmkp96 13y ago
  Properties, lambdas (thought they have it in Java 8, but it is still too late) to start with.
- egeozcan 13y ago
  Async, lambdas, extension methods, linq and "the dynamic type" (late binding). Yes, many similar but older implementations for these exist, I know, but in C# they work in harmony - and that's a bit hard to explain for me =)
  - UK-AL 13y ago
    Type inference.
  - tinco 13y ago
    And more syntactic sugar than is good for your teeth :) (I'd also want to add generics to the list, but it's over 10 years old, still not many languages that implement it so well)

by tinco 13y ago

bad_user 13y ago

Same can be said for the JVM vs CLR, only in reverse.

commentzorro 13y ago
I had always thought that the CLR was considerably ahead of the JVM, though admittedly only anecdotally. What is in the JVM that is not in the CLR that makes the JVM further ahead, so to speak.
- windust 13y ago
  Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.
- bananas 13y ago
  Technical aspects are almost irrelevant. For me, it's about the ecosystem. I do a fair bit of work on the CLR and JVM. The JVM has the following advantages: open source, cross platform, free tooling[1], incredibly more mature 3rd party libraries, zero OS cost to deploy, architectures ready to roll out of the box. A lot of the Java stuff I do is literally integrating some off the shelf bits that work 100% reliably first time and it's done. Compare to C# where I end up having to do a lot of leg work and navigating immature, abandoned or just broken open source projects. [1] By the time I've bought VS Pro 2013 with MSDN, ANTS profiler, NCover, VisualSVN, I'm down a pile of cash.
- bad_user 13y ago
  Well, as it turns out, that was just Microsoft's marketing. They did have a head start, but they dropped the ball on that one ever since .NET 2.0.
moonchrome 13y ago
JVM doesn't even have value types or generics making it practically unusable in some scenarios. While JVM implementations might be better quality for specific problem domains I'd say CIL is probably better than JVM. Not to mention CIL was designed to be a Common Intermediate Language from start so language interop is nicer (generics are a nice example)
- lmm 13y ago
  Actually I've heard that CIL generics make language interop harder, because you're essentially forced to have a generics model that corresponds exactly to C#'s. This was a major factor in abandoning the .net version of Scala. (Whereas on the JVM, type erasure means that Scala is free to apply its own generics model rather than having to match Java's)
  - moonchrome 13y ago
    It's not like Scala has generics interop with Java, you can't use advanced Scala generics from Java so I don't see your point. I'm sure they could have erased the extra stuff on CIL and support a basic subset that's visible to .NET languages. Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.
    - sixbrx 13y ago
      Yet the CLR model is apparently not flexible enough to implement type classes, which Scala can handle in a very flexible way. Here's Microsoft's rejection claiming that the current CLR can't practically support type classes: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes https://visualstudio.uservoice.com/forums/121579-visual-stud... Apparently baking the generics into the generated bytecode has downsides in flexibility.
    - bad_user 13y ago
      > It's not like Scala has generics interop with Java Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode. > you can't use advanced Scala generics from Java I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it? > I'm sure they could have erased the extra stuff on CIL Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics. As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all). > Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types. That's not true. Reified generics isn't the only solution to this problem you know. Scala can specialize the generic types for primitives ... http://www.scala-lang.org/api/2.10.4/index.html#scala.specialized http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...

aerique 13y ago

Would you mind expanding on what you think is modern about C#?

sidmkp96 13y ago
Properties, lambdas (thought they have it in Java 8, but it is still too late) to start with.
egeozcan 13y ago
Async, lambdas, extension methods, linq and "the dynamic type" (late binding). Yes, many similar but older implementations for these exist, I know, but in C# they work in harmony - and that's a bit hard to explain for me =)
- UK-AL 13y ago
  Type inference.
- tinco 13y ago
  And more syntactic sugar than is good for your teeth :) (I'd also want to add generics to the list, but it's over 10 years old, still not many languages that implement it so well)