5 ms·

Excellent writeup, and he nails the fact that C# vs. Java is not the same as CLR vs. JVM.

solutionyogi 17y ago
Interesting. I don't think it's right to discount the CLR and focus on the language whereas the fact is that C# can not do certain things without support from CLR. [In fact, for each C# feature, I like to know whether it's a compiler trick or CLR feature.] The biggest example I can think of is 'generics'. Java 'generics' are implemented using the compiler and JVM has no clue about them whereas CLR actually understands them and you get full reflection support for generic classes. Read this detailed article on Generics in Java vs C#: http://www.jprl.com/Blog/archive/development/2007/Aug-31.html http://www.jprl.com/Blog/archive/development/2007/Aug-31.htm... I also like the utility of AppDomains supported by CLR. Overall, I love .NET platform precisely because how all the modules (CLR, languages) are integrated with each other to give you a powerful tool set. Other than JVM being portable, I don't know of a single case where JVM is superior to CLR. [Performance wise there is not a measurable difference between the two.]
- snprbob86 17y ago
  There is no reason why you can't implement a C# compiler which uses the same compiler "tricks" as Java. In fact, someone has: http://www2.mainsoft.com/content/port-net-apps-java-ee http://www2.mainsoft.com/content/port-net-apps-java-ee (I've never used that software and can't say if it really works as promised, but I don't see why not) Which side of the fence the compiler/runtime fence any given feature fails on is probably more a function of (human) resource pooling on the Microsoft managed languages teams than any technical constraints.
  - solutionyogi 17y ago
    That's COMPLETELY incorrect. I have been following blogs of CLR team and C# compiler team members and they think very hard about whether a feature needs to be a compiler feature or in the runtime itself. If they are short on manpower, they don't implement a feature rather than implementing it at the wrong level.
    - snprbob86 17y ago
      Since you probably haven't been following my comments here on HN: I work at Microsoft on a very C#-centric team. I have good friends on, and direct working relationships with, the managed languages teams here at Microsoft. The "wrong level" corresponds to the goals and direction of the greater managed languages team. If the C# team wanted to implement every feature without any regard for the Visual Basic or F# team, they could. Clearly, they aren't going to do this because it creates wasted effort, inconsistency between languages, and maintainence complexity. Moreover, implementing on the wrong level has impact on performance and the developer experience. I didn't mean to imply that they do the wrong thing because they are short on man power. On the contrary, they do the right thing because they are short on manpower. Everything could be a compiler trick, but that doesn't mean everything should be. The managed languages teams here at Microsoft absolutely kick ass; they know what they are doing.
- itgoon 17y ago
  JVM apps (at least if they are running in a container) aren't just portable across OS' (which is what I assume you meant), they are just plain portable. In other words, I can tar up a Java appserver, copy it to another machine, untar it, and run it. No GAC, no registry, no caspol, no mysterious .dlls. It's all right there. Usually ;)
jwilliams 17y ago
Indeed - but there is the language, the VM and the class library. He separates the VM - but lumps the class library and language together (or at least, doesn't explicitly distinguish this).

Interesting. I don't think it's right to discount the CLR and focus on the language whereas the fact is that C# can not do certain things without support from CLR. [In fact, for each C# feature, I like to know whether it's a compiler trick or CLR feature.] The biggest example I can think of is 'generics'. Java 'generics' are implemented using the compiler and JVM has no clue about them whereas CLR actually understands them and you get full reflection support for generic classes. Read this detailed article on Generics in Java vs C#: http://www.jprl.com/Blog/archive/development/2007/Aug-31.html http://www.jprl.com/Blog/archive/development/2007/Aug-31.htm... I also like the utility of AppDomains supported by CLR. Overall, I love .NET platform precisely because how all the modules (CLR, languages) are integrated with each other to give you a powerful tool set. Other than JVM being portable, I don't know of a single case where JVM is superior to CLR. [Performance wise there is not a measurable difference between the two.]

snprbob86 17y ago
There is no reason why you can't implement a C# compiler which uses the same compiler "tricks" as Java. In fact, someone has: http://www2.mainsoft.com/content/port-net-apps-java-ee http://www2.mainsoft.com/content/port-net-apps-java-ee (I've never used that software and can't say if it really works as promised, but I don't see why not) Which side of the fence the compiler/runtime fence any given feature fails on is probably more a function of (human) resource pooling on the Microsoft managed languages teams than any technical constraints.
- solutionyogi 17y ago
  That's COMPLETELY incorrect. I have been following blogs of CLR team and C# compiler team members and they think very hard about whether a feature needs to be a compiler feature or in the runtime itself. If they are short on manpower, they don't implement a feature rather than implementing it at the wrong level.
  - snprbob86 17y ago
    Since you probably haven't been following my comments here on HN: I work at Microsoft on a very C#-centric team. I have good friends on, and direct working relationships with, the managed languages teams here at Microsoft. The "wrong level" corresponds to the goals and direction of the greater managed languages team. If the C# team wanted to implement every feature without any regard for the Visual Basic or F# team, they could. Clearly, they aren't going to do this because it creates wasted effort, inconsistency between languages, and maintainence complexity. Moreover, implementing on the wrong level has impact on performance and the developer experience. I didn't mean to imply that they do the wrong thing because they are short on man power. On the contrary, they do the right thing because they are short on manpower. Everything could be a compiler trick, but that doesn't mean everything should be. The managed languages teams here at Microsoft absolutely kick ass; they know what they are doing.
itgoon 17y ago
JVM apps (at least if they are running in a container) aren't just portable across OS' (which is what I assume you meant), they are just plain portable. In other words, I can tar up a Java appserver, copy it to another machine, untar it, and run it. No GAC, no registry, no caspol, no mysterious .dlls. It's all right there. Usually ;)

jwilliams 17y ago

Indeed - but there is the language, the VM and the class library. He separates the VM - but lumps the class library and language together (or at least, doesn't explicitly distinguish this).