6 ms·

Funnily enough he was referring to the fact that doubles are proper nullable objects, the inverse of a common reason for people saying that Java sucks.

anonymoushn 13y ago
Do people really say "I wish that all my doubles were actually Maybe<double>s, which could cause my program to explode at any arithmetic operation?" I have never heard this complaint.
- kzrdude 13y ago
  doubles come with that built in -- NaN.
  - TheLoneWolfling 13y ago
    Even better: use the NaN payload to distinguish between null and "standard" NaN.
  - anonymoushn 13y ago
    Most of my operations cannot generate a signaling NaN.
- coldtea 13y ago
  Now, they say "I wish Java had a unified type system, and did not have the Object/primitive type distinction". Which is also a goal for a future Java release, as announced by Oracle (don't know if they'll follow through): Java 9 and 10 will tackle big data, multi-language interoperability, cloud and mobile and ship in 2015 and 2017 respectively, Oracle said Wednesday. For the Java Development Kit (JDK) 10 or after, a fundamental change is being discussed: making the Java language Object Oriented. This might see the introduction of a unified type system that turns everything into objects and means no more primitives.
- TheLoneWolfling 13y ago
  What I want: No object/primitive distinction, but you have to explicitly make objects and methods nullable, and the dereference operator is null-safe. (You use the dereference operator on a null object, you get null. You use the dereference operator to call a nullable method on a null object, you get null. It is a compile-time error to call a non-nullable method on a nullable reference where the compiler cannot prove that it won't be null. Pure functions are implicitly nullable.) It is a compile-time error if you assign a nullable reference to a non-nullable reference and the compiler cannot prove that it won't be null. I've also had an idea for what I call a "pseudo-statically typed" language: instead of checking types at compile time, it checks that you implement all functions called on the parameter at compile time. Public variables are just syntactic sugar for getX/setX, operations are just syntactic sugar for addX/subX/etc. If you define a method with an input type of X, the compiler checks that you only call methods that are defined in X, and then replaces the type with the methods actually called. But nullable "primitives" can actually be useful occasionally, for caching, for example. Having a separate boolean flag works, but can be inefficient (you can store null internally as NaN with a specific payload, for example, whereas a boolean flag generally requires at least a byte, more with alignment. This also allows easier atomic updates.)
  - laureny 13y ago
    Kotlin seems to do exactly what you want.
    - TheLoneWolfling 13y ago
      No checked exceptions, which for me is a dealbreaker.
      - laureny 13y ago
        I sympathize, I think checked exceptions are a good idea overall, just poorly used in Java, but the current trend of languages is clearly showing that we're moving away from the idea. None of the languages that came out on the JVM these past ten years (Scala, Groovy, Clojure, Kotlin, Ceylon, etc...) support checked exceptions.

anonymoushn 13y ago

Do people really say "I wish that all my doubles were actually Maybe<double>s, which could cause my program to explode at any arithmetic operation?" I have never heard this complaint.

kzrdude 13y ago
doubles come with that built in -- NaN.
- TheLoneWolfling 13y ago
  Even better: use the NaN payload to distinguish between null and "standard" NaN.
- anonymoushn 13y ago
  Most of my operations cannot generate a signaling NaN.
coldtea 13y ago
Now, they say "I wish Java had a unified type system, and did not have the Object/primitive type distinction". Which is also a goal for a future Java release, as announced by Oracle (don't know if they'll follow through): Java 9 and 10 will tackle big data, multi-language interoperability, cloud and mobile and ship in 2015 and 2017 respectively, Oracle said Wednesday. For the Java Development Kit (JDK) 10 or after, a fundamental change is being discussed: making the Java language Object Oriented. This might see the introduction of a unified type system that turns everything into objects and means no more primitives.
TheLoneWolfling 13y ago
What I want: No object/primitive distinction, but you have to explicitly make objects and methods nullable, and the dereference operator is null-safe. (You use the dereference operator on a null object, you get null. You use the dereference operator to call a nullable method on a null object, you get null. It is a compile-time error to call a non-nullable method on a nullable reference where the compiler cannot prove that it won't be null. Pure functions are implicitly nullable.) It is a compile-time error if you assign a nullable reference to a non-nullable reference and the compiler cannot prove that it won't be null. I've also had an idea for what I call a "pseudo-statically typed" language: instead of checking types at compile time, it checks that you implement all functions called on the parameter at compile time. Public variables are just syntactic sugar for getX/setX, operations are just syntactic sugar for addX/subX/etc. If you define a method with an input type of X, the compiler checks that you only call methods that are defined in X, and then replaces the type with the methods actually called. But nullable "primitives" can actually be useful occasionally, for caching, for example. Having a separate boolean flag works, but can be inefficient (you can store null internally as NaN with a specific payload, for example, whereas a boolean flag generally requires at least a byte, more with alignment. This also allows easier atomic updates.)
- laureny 13y ago
  Kotlin seems to do exactly what you want.
  - TheLoneWolfling 13y ago
    No checked exceptions, which for me is a dealbreaker.
    - laureny 13y ago
      I sympathize, I think checked exceptions are a good idea overall, just poorly used in Java, but the current trend of languages is clearly showing that we're moving away from the idea. None of the languages that came out on the JVM these past ten years (Scala, Groovy, Clojure, Kotlin, Ceylon, etc...) support checked exceptions.