7 ms·

If Java could be redesigned from scratch, with no concern for backwards compatibility, it would probably look a lot like C#.

Locke1689 15y ago
Indeed. Java, from the programming language design standpoint, has made some very poor decisions. The following come to mind immediately: * Lack of first class functions * 'null' type C# has fixed both of those.
- quanticle 15y ago
  More to the point, C# has integrated an excellent map-reduce framework in the guise of (P)LINQ. Java still doesn't have anything analogous to that, nor does it plan to, if the latest roadmaps are any guide.
  - squidsoup 15y ago
    I'm not certain that Java really needs this. Developers that wan't a more functional style should consider making a transition to Scala or Clojure. Scala can evolve at a much faster pace than Java as well, given that the core language is tiny and most of the language constructs are implemented as libraries.
    - StrawberryFrog 15y ago
      I'm not certain that Java really needs this We weren't certain that C# needed it. Until we tried it.
      - runevault 15y ago
        He didn't say they weren't useful, just that Java the Language doesn't need it, due to the fact other languages that have interoperability with Java on the JVM have these features already. .NET isn't as language rich as the JVM currently unless I missed some major changes.
        StrawberryFrog 15y ago
        I get that you can call across to another language that has more functional features. But that's not the same as having little bits of it right there. e.g. when you want to find the latest item in a list, instead of a loop, you do: return purchaseList.OrderBy(pur => pur.Date).FirstOrDefault(); and carry on. It's great. You don't tend to have that fine granularity when working across languages. I don't know if you missed F# or not, but if you want a fully functional language in the ML / Ocaml lineage on .Net, you can write some code in that and interoperate.
        runevault 15y ago
        I have worked with F# in a limited degree, but one choice is not as good as all the options given by the JVM right now.
- benjiweber 15y ago
  How has c# fixed null?
  - kevingadd 15y ago
    I'm not certain what he meant, but C# has three things that java doesn't in this area: Value types (so you can have complex data types that are never null) Nullable value types (T? or Nullable<T>) Null coalescing operator Using those three features appropriately makes it a lot easier to avoid unexpected nulls causing bugs in your software.
    - DougBTX 15y ago
      A good quote from the Anders Hejlsberg (lead architect of C#) about nulls: http://stackoverflow.com/questions/178026/why-is-null-present-in-c-and-java/178090#178090 http://stackoverflow.com/questions/178026/why-is-null-presen... For example, in the type system we do not have separation between value and reference types and nullability of types. This may sound a little wonky or a little technical, but in C# reference types can be null, such as strings, but value types cannot be null. It sure would be nice to have had non-nullable reference types, so you could declare that ‘this string can never be null, and I want you compiler to check that I can never hit a null pointer here’. 50% of the bugs that people run into today, coding with C# in our platform, and the same is true of Java for that matter, are probably null reference exceptions. If we had had a stronger type system that would allow you to say that ‘this parameter may never be null, and you compiler please check that at every call, by doing static analysis of the code’. Then we could have stamped out classes of bugs.
      - hello_moto 15y ago
        Guess what people do in real-life web-services? Instead of being able to send null DateTime, the WS dictates that the client must send something. Therefore, the client sends Epoch date thus the code must handle this properly. What about dealing with Database when NULL actually means something (in certain situation, we do want to put NULL instead of some random value/junk). There's always trade-off.
jan_g 15y ago
I do not see the need to constantly evolve a language and/or push for rewrites from scratch. Java as a language succeeded precisely because it was relatively simple, yet powerful enough. For example, I believe that adding generics was a mistake, especially in a crippled form (due to compatibility with previous language versions). I favor switching the language/environment once you feel that you need more expressing power. E.g. use Scala, Jython or Clojure if you need JVM, or perhaps Erlang for server-side.

Locke1689 15y ago

Indeed. Java, from the programming language design standpoint, has made some very poor decisions. The following come to mind immediately: * Lack of first class functions * 'null' type C# has fixed both of those.

quanticle 15y ago
More to the point, C# has integrated an excellent map-reduce framework in the guise of (P)LINQ. Java still doesn't have anything analogous to that, nor does it plan to, if the latest roadmaps are any guide.
- squidsoup 15y ago
  I'm not certain that Java really needs this. Developers that wan't a more functional style should consider making a transition to Scala or Clojure. Scala can evolve at a much faster pace than Java as well, given that the core language is tiny and most of the language constructs are implemented as libraries.
  - StrawberryFrog 15y ago
    I'm not certain that Java really needs this We weren't certain that C# needed it. Until we tried it.
    - runevault 15y ago
      He didn't say they weren't useful, just that Java the Language doesn't need it, due to the fact other languages that have interoperability with Java on the JVM have these features already. .NET isn't as language rich as the JVM currently unless I missed some major changes.
      - StrawberryFrog 15y ago
        I get that you can call across to another language that has more functional features. But that's not the same as having little bits of it right there. e.g. when you want to find the latest item in a list, instead of a loop, you do: return purchaseList.OrderBy(pur => pur.Date).FirstOrDefault(); and carry on. It's great. You don't tend to have that fine granularity when working across languages. I don't know if you missed F# or not, but if you want a fully functional language in the ML / Ocaml lineage on .Net, you can write some code in that and interoperate.
        runevault 15y ago
        I have worked with F# in a limited degree, but one choice is not as good as all the options given by the JVM right now.
benjiweber 15y ago
How has c# fixed null?
- kevingadd 15y ago
  I'm not certain what he meant, but C# has three things that java doesn't in this area: Value types (so you can have complex data types that are never null) Nullable value types (T? or Nullable<T>) Null coalescing operator Using those three features appropriately makes it a lot easier to avoid unexpected nulls causing bugs in your software.
  - DougBTX 15y ago
    A good quote from the Anders Hejlsberg (lead architect of C#) about nulls: http://stackoverflow.com/questions/178026/why-is-null-present-in-c-and-java/178090#178090 http://stackoverflow.com/questions/178026/why-is-null-presen... For example, in the type system we do not have separation between value and reference types and nullability of types. This may sound a little wonky or a little technical, but in C# reference types can be null, such as strings, but value types cannot be null. It sure would be nice to have had non-nullable reference types, so you could declare that ‘this string can never be null, and I want you compiler to check that I can never hit a null pointer here’. 50% of the bugs that people run into today, coding with C# in our platform, and the same is true of Java for that matter, are probably null reference exceptions. If we had had a stronger type system that would allow you to say that ‘this parameter may never be null, and you compiler please check that at every call, by doing static analysis of the code’. Then we could have stamped out classes of bugs.
    - hello_moto 15y ago
      Guess what people do in real-life web-services? Instead of being able to send null DateTime, the WS dictates that the client must send something. Therefore, the client sends Epoch date thus the code must handle this properly. What about dealing with Database when NULL actually means something (in certain situation, we do want to put NULL instead of some random value/junk). There's always trade-off.

jan_g 15y ago

I do not see the need to constantly evolve a language and/or push for rewrites from scratch. Java as a language succeeded precisely because it was relatively simple, yet powerful enough. For example, I believe that adding generics was a mistake, especially in a crippled form (due to compatibility with previous language versions). I favor switching the language/environment once you feel that you need more expressing power. E.g. use Scala, Jython or Clojure if you need JVM, or perhaps Erlang for server-side.