5 ms·

I've never done any Windows development, so I'm curious as to why C# might be considered superior to Java (especially Java 8). Is it simply better language fea

I've never done any Windows development, so I'm curious as to why C# might be considered superior to Java (especially Java 8). Is it simply better language features ( typing, generics, etc.?), or does the argument also include .NET and the CLR? Will Microsoft open up development on unix systems (not mono)? I've interpreted signals from the CEO as an indication this could happen. What about visual studio?

MichaelGG 12y ago
The CLR is more flexible than the JVM, but if you're only using C# you'll usually only notice when doing C interop. With the major exception of structs and generics, which may provide large speed improvements. C# the language is superior in essentially every way to Java. Far less code = less bugs. F# takes it up another notch, while allowing you to keep interop. Microsoft has had plenty of opportunity to officially support Mono, but they have not. Their patent promise only extends to Mono as long as you don't run into other issues with Microsoft. If MS wanted, they could, at any time, start really supporting Mono and work to unify runtimes. But anything's possible.
- V-2 12y ago
  To be fair, F# has its counterparts in the JVM world (like Scala or Clojure). I used the rather niche Kotlin lang on Android, for hobby projects so far, and it's pretty nice, too, even if not fully mature. More similar to Scala, I believe.
  - pmoriarty 12y ago
    I don't think F# is particularly similar to Clojure. No more similar than OCaml or SML are to Lisp (which is not very).
    - V-2 12y ago
      True, it's a different FP flavor. They (F#, Scala, Clojure) are in similar position though in that they're FP-centred alternatives to the main language of the platform (C#, Java)
- pmoriarty 12y ago
  "Far less code = less bugs" ? By that measure, APL programs must be the least buggy in existence.
  - MichaelGG 12y ago
    The recent discussion on K suggests that may be the case.
    - azth 12y ago
      Link?
      - MichaelGG 12y ago
        https://news.ycombinator.com/item?id=8475809 https://news.ycombinator.com/item?id=8475809 I'm not sure if K generalizes well. It may be that plenty of software has edge cases that must be handled that don't have any elegant representations. I have a hard time believing such little code can actually work that well. But it seems impressive enough that I plan on learning it some and making sure I'm not massively missing out on something because it seems foreign. From my own experience, less code certainly means less bugs. Even with denser code. Simply having to jump around to find stuff (due to more lines) seems to cause more problems
        chipsy 12y ago
        I've been gravitating towards the stance lately(independently of reading about K and the APL family style) of aiming towards "total-factor symbol reduction" - i.e. a program coded with fewer symbols, and fewer unique symbols, is preferable to one that introduces many new symbols, or uses existing ones inefficiently. From this perspective, just factoring out imperative code into a named subroutine becomes a pain point because it adds new symbolic content - a new name, things being passed in, things being returned, things that were in scope suddenly falling outside of it. It is no longer an "organization tool" - you can add a level of block scope and a comment for that instead, and navigate the resulting large functions with code folding. And classes - well, classes become something to avoid! APL style simply moves this concept down to the per-character level of thought and advocates additional care towards certain measures of readability. "It is more likely," says the APL programmer, "that you will see a typo in a 2 character name than in a 10 character name." The language aids in this process by providing tools that drastically condense common operations and encouraging their use as the default.
V-2 12y ago
Well, Java caught up somewhat with version 8: with lambdas and Streams to provide LINQ-like functionality - which, however, isn't equally good imho, and not extendable because it's not based on extension methods. And unfortunately I have no access to these goodies anyway, as an Android dev :/ Ah, and then there's still the inferior, type erasure based generics. There is nothing on par with C#'s awesome async-await. There's no yield return semantics (when used properly, you can create very clean and robust code thanks to it). You've got to deal with the infamous checked exceptions (I think it's the consensus these days that this wasn't such a good design choice after all). No single-root type system (so you've got Integers and ints, and the latter aren't objects) etc. And there's more, even little things like var keyword or partial classes that don't exist in Java (like many language features, partial classes can be used for evil, but it's very helpful for dealing with autogenerated code). Operator overloading. Nasty and weird syntax for annotations (in compare to C#'s attributes). Some of these can be a matter of taste for sure and I'm not interested in language flamewars :) I write both Java and C# for living, just personally I prefer the latter. It would be real big if Microsoft purchased Xamarin and made it free (or much cheaper). They've really gained momentum in recent time and it feels like they are getting recognition from MS now.
- brusch64 12y ago
  coming back to Java, after some years of programming C# I have the same feeling. C# feels like Java done right. Many of Java's shortcomings can be masked with a great IDE (making setters and getters) nobrainers - but I prefer C#.
  - dserodio 12y ago
    Except for pass-by-value and pass-by-reference. Java's model of always passing a reference value makes the mental model around references so much simpler.
    - brusch64 12y ago
      It makes the model simpler, but I found this pretty cumbersome. I wanted to write a method returning two values (Boolean), so I had to return an array of Booleans. Out parameter seem easier for me (and more concise)
asveikau 12y ago
Generics in C# don't do type erasure. That's one of the "language nerd" features that's a big win. Most other stuff I can think of is kind of surface level. (Though nice to have: Property syntax, native interop that sucks less, IDisposable, closures, extension methods, linq)
NicoJuicy 12y ago
Actually, because Windows development (using Visual Studio) is not only c# It's also vb.net, f# and so much else. Even node.js is integrated now! In short, it's a very adaptable IDE (with a lot of features also). But it isn't Windows anymore since Owin. What's also nice is that they are innovating the platform for integrations with popular (opensource) like features. Eg. The scaffolding of Rails got integrated into Asp.Net MVC in it's own way. NodeJS selfhostable option is adapted into .Net as "Owin". SignalR is their realtime component, you got live IDE features when developing webapps (it uses SignalR in the background) It's kinda a mix of "all worlds" :)
dserodio 12y ago
I'm surprised Microsoft hasn't bought Xamarin yet. Mono being a first-class citizen (with an appropriate license) would do wonders to attract Java and non-MS developers to .Net - myself included.

MichaelGG 12y ago

The CLR is more flexible than the JVM, but if you're only using C# you'll usually only notice when doing C interop. With the major exception of structs and generics, which may provide large speed improvements. C# the language is superior in essentially every way to Java. Far less code = less bugs. F# takes it up another notch, while allowing you to keep interop. Microsoft has had plenty of opportunity to officially support Mono, but they have not. Their patent promise only extends to Mono as long as you don't run into other issues with Microsoft. If MS wanted, they could, at any time, start really supporting Mono and work to unify runtimes. But anything's possible.

V-2 12y ago
To be fair, F# has its counterparts in the JVM world (like Scala or Clojure). I used the rather niche Kotlin lang on Android, for hobby projects so far, and it's pretty nice, too, even if not fully mature. More similar to Scala, I believe.
- pmoriarty 12y ago
  I don't think F# is particularly similar to Clojure. No more similar than OCaml or SML are to Lisp (which is not very).
  - V-2 12y ago
    True, it's a different FP flavor. They (F#, Scala, Clojure) are in similar position though in that they're FP-centred alternatives to the main language of the platform (C#, Java)
pmoriarty 12y ago
"Far less code = less bugs" ? By that measure, APL programs must be the least buggy in existence.
- MichaelGG 12y ago
  The recent discussion on K suggests that may be the case.
  - azth 12y ago
    Link?
    - MichaelGG 12y ago
      https://news.ycombinator.com/item?id=8475809 https://news.ycombinator.com/item?id=8475809 I'm not sure if K generalizes well. It may be that plenty of software has edge cases that must be handled that don't have any elegant representations. I have a hard time believing such little code can actually work that well. But it seems impressive enough that I plan on learning it some and making sure I'm not massively missing out on something because it seems foreign. From my own experience, less code certainly means less bugs. Even with denser code. Simply having to jump around to find stuff (due to more lines) seems to cause more problems
      - chipsy 12y ago
        I've been gravitating towards the stance lately(independently of reading about K and the APL family style) of aiming towards "total-factor symbol reduction" - i.e. a program coded with fewer symbols, and fewer unique symbols, is preferable to one that introduces many new symbols, or uses existing ones inefficiently. From this perspective, just factoring out imperative code into a named subroutine becomes a pain point because it adds new symbolic content - a new name, things being passed in, things being returned, things that were in scope suddenly falling outside of it. It is no longer an "organization tool" - you can add a level of block scope and a comment for that instead, and navigate the resulting large functions with code folding. And classes - well, classes become something to avoid! APL style simply moves this concept down to the per-character level of thought and advocates additional care towards certain measures of readability. "It is more likely," says the APL programmer, "that you will see a typo in a 2 character name than in a 10 character name." The language aids in this process by providing tools that drastically condense common operations and encouraging their use as the default.

V-2 12y ago

Well, Java caught up somewhat with version 8: with lambdas and Streams to provide LINQ-like functionality - which, however, isn't equally good imho, and not extendable because it's not based on extension methods. And unfortunately I have no access to these goodies anyway, as an Android dev :/ Ah, and then there's still the inferior, type erasure based generics. There is nothing on par with C#'s awesome async-await. There's no yield return semantics (when used properly, you can create very clean and robust code thanks to it). You've got to deal with the infamous checked exceptions (I think it's the consensus these days that this wasn't such a good design choice after all). No single-root type system (so you've got Integers and ints, and the latter aren't objects) etc. And there's more, even little things like var keyword or partial classes that don't exist in Java (like many language features, partial classes can be used for evil, but it's very helpful for dealing with autogenerated code). Operator overloading. Nasty and weird syntax for annotations (in compare to C#'s attributes). Some of these can be a matter of taste for sure and I'm not interested in language flamewars :) I write both Java and C# for living, just personally I prefer the latter. It would be real big if Microsoft purchased Xamarin and made it free (or much cheaper). They've really gained momentum in recent time and it feels like they are getting recognition from MS now.

brusch64 12y ago
coming back to Java, after some years of programming C# I have the same feeling. C# feels like Java done right. Many of Java's shortcomings can be masked with a great IDE (making setters and getters) nobrainers - but I prefer C#.
- dserodio 12y ago
  Except for pass-by-value and pass-by-reference. Java's model of always passing a reference value makes the mental model around references so much simpler.
  - brusch64 12y ago
    It makes the model simpler, but I found this pretty cumbersome. I wanted to write a method returning two values (Boolean), so I had to return an array of Booleans. Out parameter seem easier for me (and more concise)

asveikau 12y ago

Generics in C# don't do type erasure. That's one of the "language nerd" features that's a big win. Most other stuff I can think of is kind of surface level. (Though nice to have: Property syntax, native interop that sucks less, IDisposable, closures, extension methods, linq)

NicoJuicy 12y ago

Actually, because Windows development (using Visual Studio) is not only c# It's also vb.net, f# and so much else. Even node.js is integrated now! In short, it's a very adaptable IDE (with a lot of features also). But it isn't Windows anymore since Owin. What's also nice is that they are innovating the platform for integrations with popular (opensource) like features. Eg. The scaffolding of Rails got integrated into Asp.Net MVC in it's own way. NodeJS selfhostable option is adapted into .Net as "Owin". SignalR is their realtime component, you got live IDE features when developing webapps (it uses SignalR in the background) It's kinda a mix of "all worlds" :)

dserodio 12y ago

I'm surprised Microsoft hasn't bought Xamarin yet. Mono being a first-class citizen (with an appropriate license) would do wonders to attract Java and non-MS developers to .Net - myself included.