What factors led to the development of C# in spite of Java

http://stackoverflow.com/q/3979679/399268

by ashishgandhi • 14 years ago

44 72 14 years ago

tikhonj4• 14 years ago

Fundamentally, Java and C# are extremely similar. What's interesting is how different their philosophies are: Java really values backwards compatibility, does not evolve very fast and tries to hide and features that could cause a programmer to shoot himself in the foot. C#, on the other hand, has had some compatibility breaking changes, has evolved quickly with fancy research features (e.g. Linq is actually much like a monad with SelectMany as bind) and has a bunch of "dangerous" features like operator overloading and unsafe regions.

EDIT: Maybe there weren't actually any language changes breaking backwards compatibility. I'm not sure.

I personally like C#'s philosophy better: PL research exists for a reason and newer features make coding easier; moreover, I can avoid doing really stupid things and so can be trusted with operator overloading! Others maintain the opposite and believe Java's more conservative approach is best.

It would be nice to compare how the two philosophies fare in getting their respective languages adapted, but I fear such a comparison would be flawed: C# is much too tied to Microsoft, so most people not keen on heavy coupling with any particular vendor or OS tend to avoid it for that reason. The opposite is also true: heavy MS shops are much more likely to choose C# just because it's part of .NET, and not because of the language characteristics.

Still, it is very interesting to see what has happened given two virtually identical languages with different backers and philosophies.

statictype3• 14 years ago

I'm curious: What are the breakages in backwards compatibility that C# introduced?

The only one I can think of is the upcoming change in closure semantics for loop variables - something that is being changed to make it work like people would expect for 99% of the case and risks breaking that 1% of cases where someone actually wants the same loop variable to be closed over in all functions defined within the loop.

(e.g. Linq is actually much like a monad with SelectMany as bind)

Correct me if I'm wrong but I believe, with SelectMany, Linq does in fact, provide everything required to support monads.

Agree with everything else you said - especially on flawed comparisons between the two languages.

tikhonj4• 14 years ago

I'm not actually intimately familiar with C#. I remember reading about some of the changes between major .NET version (e.g. 2 to 3) which did not maintain backwards compatibility. However, on review, that may have been backwards compatibility of the bytecode rather than the language proper, in which case I am mistaken.

It would be great if somebody who knows one way or the other for sure chimed in.

kenjackson• 14 years ago

I don't think there was much backwards compatibility breaks, but in generics C# broke forward compatibility of the bytecode, whereas Java didn't (they used type erasure for their generics).

With that said, C# almost always breaks forward compatibility. It seems like a somewhat odd design goal to have for a language nowadays.

noblethrasher4• 14 years ago

Interestingly, named parameters introduced a kind of breaking change:

http://blogs.msdn.com/b/ericlippert/archive/2011/11/07/break...

Strilanc• 14 years ago

The breaking changes are usually minor and side-effects of the other language changes. For example, IEnumerable<T> was made covariant in .Net 4.0. Consider what happened to code passing an IEnumerable<List<int>> to a method with two overloads taking IEnumerable<Object> and Object respectively.

gpvos• 14 years ago

The only major breakage has not been in the language, but in the .NET framework libraries; and then mostly in ASP.NET. Between 1.1 and 2.0, quite a few things broke there. Upgrading was no fun at all.

InclinedPlane2• 14 years ago

The biggest breaking change was from version 1 to 2. Generics were added, as were partial classes, private setters on properties, and delegates. Along the way a lot of little breaking changes were also taken on. Things that change the behavior of the language enough to warrant calling out the incompatibility from previous versions (if you happened to rely on a particular behavior) but which generally result in an improvement in the language.

bad_user6• 14 years ago

     [Java] does not evolve very fast

While this is true for Java the language, it's not true for Java the VM, which evolved a lot faster than the CLR.

And because Java the language does not evolve very fast, the ecosystem has given birth to mature JVM compilers/interpreters for languages such as Clojure, Scala, JRuby and Groovy, amongst others.

The biggest difference between Java and .NET is that the "backers" of Java come from a really big and open-source friendly community.

kamaal2• 14 years ago

For most part of the programming world, Java is synonymous with, Java the programming language, not JVM.

I always thought Java went very heavy on the frameworks side. Evolution was faster on the frameworks end.

tikhonj4• 14 years ago

Well, .NET does have stuff like Iron{Ruby, Python, Whatever}. It also has F#, which is awesome, and VB, which isn't.

Also, Java is now backed by Oracle which isn't the most friendly of open source companies either.

However, I was actually only really talking about Java the language and not the JVM.

wvenable• 14 years ago

> it's not true for Java the VM, which evolved a lot faster than the CLR.

I'm curious as to what you mean by this; what part of the Java VM has evolved faster?

vorg• 14 years ago

> And because Java the language does not evolve very fast, the ecosystem has given birth to mature JVM compilers/interpreters for languages such as Clojure, Scala, JRuby and Groovy, amongst others.

Most of those examples you gave (i.e. Clojure, Scala, JRuby) also have CLR versions.

moomin2• 14 years ago

I think the differences between C# 1 and the current Java have been rather downplayed by this discussion. C#1 was different from Java in a number of very important ways:

* You could call directly into the Win32 API (the issue that caused Sun and Microsoft to fall out)

* Value Types. Still being discussed for v8.

* Lambdas. Yes, in version 1.

* C# had enums, Java didn't. (Now Java has better enums than C#)

* A syntactic sugar for property get/set. This was extremely important to Microsoft.

* A decent COM-interop story. Again, very important to Microsoft.

Of course it was similar. It was a design goal to be able to run Java code on the .NET VM. But it was far from identical.

Jon Skeet could no doubt expand this list

dbattaglia• 14 years ago

I'm not so sure about lambdas in v1. I remember v2 added anonymous functions ( ex " delegate(int x){...}" ), and real lambdas not coming until v3.

SiVal2• 14 years ago

There's no big mystery. I was there and saw it all happen. Java, the language, hadn't made any progress for several years. Programmers like me would complain at Java user group meetings here in Silicon Valley that we wanted certain features in Java (enums, lightweight structs, etc.) and the Java guys from Sun would always do an Apple on us: you don't know what you want. You're not experts; we are. We know what you really need better than you do, because we're smarter than you and have better taste, so trust us, you don't really need <whatever features we were asking for>.

There was always a Microsoft rep at those Java user group meetings. After the meeting, he would come up to us and ask us again what we wanted and why. Unlike anyone from Sun, he'd ask good questions, listen carefully, and take notes.

Microsoft genuinely liked the language as a much-better C++, but wanted it to have native extensions on Windows for two reasons: 1) it would encourage the writing of code that would be less portable, thereby reducing the threat to MS's advantage of being the platform with the most apps, and 2) apps written in "pure" Java just weren't as good as native apps, and for Java to become the "better C++" that many programmers inside MS were hoping for (for their own use), it was becoming clear they would need native extensions.

MS tried to produce a Java with native extensions: Visual J++. Sun filed suit, claiming that MS was in violation of contract. I don't recall the outcome of the suit, because MS decided that Java's slowing acceptance as a general-purpose language for client-side apps (and part of that slowness was CAUSED by MS) meant that there was less need to claim support for Java. It wasn't going to take over the world after all. (Steve Jobs later made the same decision). Not supporting it wouldn't mean you would be left behind. They abandoned Visual J++.

Instead, MS wanted their own Java-like language with no strings attached. Java was a trademarked name, so they created a language with a different name but all the Java features (LANGUAGE features) that programmers liked so much, plus most of the features that Java programmers were begging for that Sun was sniffing at, plus the native extensions needed to write Windows apps that would only run on Windows AND would run so well they would, in general, be indistinguishable from native apps written in Visual C(++), and they built a great app builder (VC#) to go with it.

They did a beautiful job with Visual C# and rattled Sun so much that suddenly a lot of those "impossible" features we "didn't need anyway" became available in Java, but C# has always maintained a healthy lead over Java in nice features for client-side programming, IMO.

(And Java has maintained a superior overall adoption rate, especially on servers.)

davesims• 14 years ago

> MS tried to produce a Java with native extensions:

Not exactly. MS replaced Java's existing native extension functionality (JNI) with Windows-only native hooks called JDirect. Interestingly, it did so with these @com (EDIT: sorry, I meant @dll -- @com was related to COM hooks, which stuck around well into the .NET era as attribute hooks) method macros that, in a way, prefigured attributes in both Java and C#.

EDIT: If by 'native extentions', you meant the WFC classes, then yes these were additions, not a replacement of JNI. But these were not part of the lawsuit per se. The suit focused on the removal of JNI and the corruption of the JVM spec with the JDirect functionality.

> plus most of the features that Java programmers were begging for that Sun was sniffing at

'most of the features' is pushing it a bit. The only feature that J++ had over Java 1.1 at the time was method pointers (delegate). The lawsuit focused on those corruptions of Java: removing JNI as well adding JDirect and the 'delegate' keyword. This, according to the court, violated the terms of the license agreement signed by MS.

Microsoft lost the lawsuit, and that was the reason they ditched J++ and began work on C#/.NET, which built upon many of the lessons learned in J++. I think otherwise MS's plan was to continue building an ecosystem around the MSVM not unlike what they eventually built around the CLR.

It would be interesting to compare the MS/Sun ruling with the recent Google/Oracle ruling, as the terms of the two suits were rather similar.

It would seem to me that the biggest difference there is that MS did in fact sign a license agreement with Sun that constrained the nature of their use of Java. Google did not sign any agreement, and I wonder if this was a calculated move on Google's part, in light of the MS/Sun J++ ruling.

Considering the recent ruling by Judge Alsup regarding Android's similar adoption/modification of the Java spec, does this mean Microsoft would have stood a better chance by simply implementing J++ with no agreement from Sun at all? On my naive, IANAL reading of it, that would seem to be the case.

itsboring4• 14 years ago

Not relevant to the question, but:

Some of the comments in that thread illustrate a widespread misconception that C# isn't cross-platform. We're finishing up a game that runs on windows, osx, ios, and android, with a server on linux; and it's written in C#.

Microsoft's CLR and BCL implementation aren't cross-platform, but I haven't used those in quite some time.

statictype3• 14 years ago

I assume you're using MonoTouch/Unity for your game?

How about your server code? Is that ASP.NET running on Linux? Or something else?

itsboring4• 14 years ago

We've used both Unity and MonoTouch for different projects. They have their problems, but much less so, I think, than different native implementations on every platform.

On the server side, we just build the latest stable mono release and we made a socket server wrapped around libev (similar to what Manos de Mono does).

(I guess I lied, we have a small amount of web stuff in Ruby, but mostly just to serve content.)

tikhonj4• 14 years ago

While C# is cross-platform, almost everybody using it seems to be on Windows. Also, a bunch of the libraries people normally use with C# are Windows-specific (like WPF, I guess. Does anybody still use WPF?). Also, Microsoft has some patents which put projects like Mono in a potentially poor situation, which is why it isn't entirely embraced by the free software world.

Java, on the other hand, is, for better or worse, used heavily on all the different platforms. Moreover, most Java libraries (like Swing. Does anybody still use Swing?) are cross-platform.

I find F# a much more interesting language than C#. Do you know how F# behaves on Linux? While I've heard of people using C# on Linux and Android, I haven't heard anything about F#. Then again, the Linux people might just prefer OCaml.

microtonal• 14 years ago

For standardized (and some other parts) of .NET/C#, Microsoft provided a patent license:

http://www.mono-project.com/Licensing#Patents

itsboring4• 14 years ago

I would, of course, agree that the majority of C# developers are on Windows (this seems natural). However, I think mono is in wider use than people think because of the fact that it's embedded in products like Unity. It's often not very obvious.

WPF was a definite non-starter for mono. Just too huge of an undertaking; much more focus on GTK#. Sometimes it's easier to bring something else to Windows than to bring Windows to everything else. In the case of WPF, it seems like not bothering was probably the correct move...

My understanding is that F# works just fine on linux and mac, but I haven't had the opportunity yet. Quite interested in this as well.

rrreese• 14 years ago

WPF is used extensively in enterprise. Alternatives are Windows Forms which is pretty old,and significantly less flexible, or web apps. WPF can host Windows Forms, so for legacy its a way better option then web.

cturner• 14 years ago

How do you package games to run?

Something that seems to be a disadvantage with Java over native builds is the way it complicates the task flow for users trying to install your software. Either they have to download a large distribution that includes the JVM inside it (are distributors even allowed to redistribute Java like this?) or else they have to download and install the JVM, and then configure their new application to point to it.

How does this work when you're using c#?

itsboring4• 14 years ago

In the case of iOS, the code gets AOT-compiled and any unused bytecode is stripped out. Mono is statically linked in and adds about 6mb at the minimum.

On desktop, the necessary parts of the mono runtime would just be included with the distribution package; much like any other DLL. I don't think any developer in their right mind would ask people to download the mono installer. On the plus side, this doesn't pollute their system with registry entries or system files.

It's clearly not optimal to have that overhead, but it was preferential to porting to each platform in this case.

mrcsparker• 14 years ago

From what I remember, it was one main thing: delegates

From Sun: http://java.sun.com/docs/white/delegates.html

soc882• 14 years ago

Seeing how Java tries to play catch up currently, this reads down-right bizarre. :-)

densh• 14 years ago

Wow, they really thought that inner classes were an elegant and supreme solution. That strikes me as a really weird aesthetics attitude. Inner classes always felt like an accidental misfeature which everyone regretted about but couldn't remove it due to backwards compatibility.

shmerl• 14 years ago

Mostly political reasons it seems. Java was always encumbered with patents and licensing restrictions especially for mobile usage, which came out the ugly way as we know with the latest Oracle's lawsuit. Even though Oracle didn't succeed, but nevertheless there was always a risk. I guess Microsoft didn't want to depend on that, but on the other hand wanted to leverage familiarity with Java to lure Java developers into using C#. Rather boring and uninspiring move (creating a close clone), but Sun can be partially blamed for not making Java truly free (like C++ for example).

mariusmg• 14 years ago

Politics between SUN and MS was the main reason. But the low quality (and by that i mean things like doing value type allocations in the heap, shitty libraries for UI (Swing), the language not having common sense features such as delegates/properties etc) implementation of the JVM was another.

thebluesky5• 14 years ago

There are many reason's it made sense for MS to create their own Java-like system, but the "low quality" of the JVM implementations is not one of them. The JVM implementations (HotSpot, IBM J9) are more efficient than the CLR in virtually any sensible benchmark you care to run and it's been that way since about December 1998. e.g. http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

noblethrasher4• 14 years ago

That shootout is between the JVM and Mono. The CLR outperforms Mono.

That being said, my understanding is that JVM programs slightly outperform CLR programs in terms of speed while CLR programs do better than those on the JVM(s) in terms of memory.

dvhh• 14 years ago

the benchmark is pretty much irrelevant, because if it was we would all be coding in C or Fortran, or why not machine code or assembly ? On the other hand I find that the mono project (young, open source implementation ), is doing quite great against java 7 (commercial implementation, unless I misread). It would be interesting to see how the openJDK is performing ? (the real question would be : is openJDK crippled compared to the Oracle - JDK ?)

strictfp• 14 years ago

Another very interesting question closed as off-topic.

angry-hacker• 14 years ago

Why interesting questions are getting closed all the time on Stackoverflow? It's not THAT off-topic and everyone are interested in it, what harm does it do that it needs to be closed...

Edit: Ok, now they deleted whole thing instead... because someone pointed out that it shouldn't been closed...

arikrak• 14 years ago

They deleted it, but it can still be seen in Google's cache. Someone needs to tell Wikipedia and StackOverflow that they're going a bit overboard with all this deleting. Why don't they just demote stuff to show lower down in searches or something? http://webcache.googleusercontent.com/search?q=cache:mdxfQ2k...

tzs• 14 years ago

One factor is that Microsoft wanted a programming language with Java's language features that could be used to write Windows programs.

Sun was adamantly against the notion of people writing Windows programs in Java (or Unix programs in Java, or Mac programs in Java). Java programs were supposed to be for the Java platform.

What factors led to the development of C# in spite of Java

Related Stories