3 ms·

> Both languages don't do much about Tony Hoare's Billion Dollar Mistake, and to me that's an immediate black mark on type safety, though they fail in this rega

> Both languages don't do much about Tony Hoare's Billion Dollar Mistake, and to me that's an immediate black mark on type safety, though they fail in this regard in distinct ways. Java is well on its way to alleviating the problem. [1] [1] https://openjdk.org/jeps/8303099 https://openjdk.org/jeps/8303099

imbnwa 2y ago
They really ruined Optional not solving this then and there
- cogman10 2y ago
  There would always be a hole that's somewhat impossible to fill with the language as is. If you have something like Map<Integer, Optional<Integer>> map; var foo = map.get(1); if `1` isn't present in the map then `foo` has to be set to something. It will be `null` in this case. If the new null restricted stuff makes it in, you can express this as Map<Integer, Optional<Integer>!> map; var foo = map.get(1); and yet, `foo` will still end up being `null` in that case (I assume) because something has to come back if `1` isn't present. At best, that will prevent you from doing `map.put(1, null);`
  - thrw42A8N 2y ago
    The actual point is so that the compiler can tell you that you forgot to check all possible cases. Typescript is really great for this.
  - deleted 2y ago
    [deleted]
  - cobbal 2y ago
    I'm not completely sure what this example is trying to illustrate. Most languages with proper sum types would have `Map<K, V>.get` return an `Optional<V>`. If V happens to be `Optional<Integer>`, then the result will be an `Optional<Optional<Integer>>`, which is a perfectly good type that represents the two ways a value may be missing from the map. Am I missing something?
    - pbh101 2y ago
      The Map interface pre-dates Optional and does not return Optional, so it won't return an empty Optional but rather null. To be more clear: Map<K, V>.get(foo) returns a `V`, not an `Optional<V>`. If your `V` is `Optional<WrappedV>`, cool, but that doesn't change that `Map` either finds or doesn't find a V.
      - stickfigure 2y ago
        The parent certainly knows this. Additional methods could be added to `Map` which return `Optional`. I am annoyed by their absence every day.
        pbh101 2y ago
        Maybe. They didn't seem to communicate any specific knowledge of the Java standard library. Agree an Optional<V> get(K) sounds like an 'obvious' addition, though also I've found that when something 'obvious' isn't added to Java since 1.7, the explanation proffered makes sense to me.
        cogman10 2y ago
        Java doesn't have return type function dispatch. If you had something like: var x = map.get(k); The type of `x` could not be inferred. The best they could hope for is a signature like `Optional<V> getOpt(K);`. Which wouldn't be terribly bad as Java currently has an annoying get definition in the `Map` interface because it predates generics (The current signature is `V get(Object)`). Regardless, if they do want to change the interface, it'd probably be best if they waited for Valhalla to land. One of the problems with `Optional` as it stands is it creates a load of GC pressure. If `Optional` is converted into a value class then there will be effectively no overhead to returning it everywhere.
baranul 2y ago
Actually, a number of modern languages have addressed this. A few of them are: Dart, Rust, and Vlang. However, many of the newer languages seem to address or handle null (nil) safety, a bit differently from each other. In Dart[1] and Vlang[2], for example, "non-nullable" is the default. Vlang doesn't allow null or nil to be used, unless code is marked as unsafe, and primarily only for compatibility with languages that do (like C). In Dart, nullable variables have `?` added to the end of them. [1]: https://en.wikipedia.org/wiki/Dart_(programming_language) https://en.wikipedia.org/wiki/Dart_(programming_language) [2]: https://en.wikipedia.org/wiki/V_(programming_language) https://en.wikipedia.org/wiki/V_(programming_language)

imbnwa 2y ago

They really ruined Optional not solving this then and there

cogman10 2y ago
There would always be a hole that's somewhat impossible to fill with the language as is. If you have something like Map<Integer, Optional<Integer>> map; var foo = map.get(1); if `1` isn't present in the map then `foo` has to be set to something. It will be `null` in this case. If the new null restricted stuff makes it in, you can express this as Map<Integer, Optional<Integer>!> map; var foo = map.get(1); and yet, `foo` will still end up being `null` in that case (I assume) because something has to come back if `1` isn't present. At best, that will prevent you from doing `map.put(1, null);`
- thrw42A8N 2y ago
  The actual point is so that the compiler can tell you that you forgot to check all possible cases. Typescript is really great for this.
- deleted 2y ago
  [deleted]
- cobbal 2y ago
  I'm not completely sure what this example is trying to illustrate. Most languages with proper sum types would have `Map<K, V>.get` return an `Optional<V>`. If V happens to be `Optional<Integer>`, then the result will be an `Optional<Optional<Integer>>`, which is a perfectly good type that represents the two ways a value may be missing from the map. Am I missing something?
  - pbh101 2y ago
    The Map interface pre-dates Optional and does not return Optional, so it won't return an empty Optional but rather null. To be more clear: Map<K, V>.get(foo) returns a `V`, not an `Optional<V>`. If your `V` is `Optional<WrappedV>`, cool, but that doesn't change that `Map` either finds or doesn't find a V.
    - stickfigure 2y ago
      The parent certainly knows this. Additional methods could be added to `Map` which return `Optional`. I am annoyed by their absence every day.
      - pbh101 2y ago
        Maybe. They didn't seem to communicate any specific knowledge of the Java standard library. Agree an Optional<V> get(K) sounds like an 'obvious' addition, though also I've found that when something 'obvious' isn't added to Java since 1.7, the explanation proffered makes sense to me.
        cogman10 2y ago
        Java doesn't have return type function dispatch. If you had something like: var x = map.get(k); The type of `x` could not be inferred. The best they could hope for is a signature like `Optional<V> getOpt(K);`. Which wouldn't be terribly bad as Java currently has an annoying get definition in the `Map` interface because it predates generics (The current signature is `V get(Object)`). Regardless, if they do want to change the interface, it'd probably be best if they waited for Valhalla to land. One of the problems with `Optional` as it stands is it creates a load of GC pressure. If `Optional` is converted into a value class then there will be effectively no overhead to returning it everywhere.

baranul 2y ago

Actually, a number of modern languages have addressed this. A few of them are: Dart, Rust, and Vlang. However, many of the newer languages seem to address or handle null (nil) safety, a bit differently from each other. In Dart[1] and Vlang[2], for example, "non-nullable" is the default. Vlang doesn't allow null or nil to be used, unless code is marked as unsafe, and primarily only for compatibility with languages that do (like C). In Dart, nullable variables have `?` added to the end of them. [1]: https://en.wikipedia.org/wiki/Dart_(programming_language) https://en.wikipedia.org/wiki/Dart_(programming_language) [2]: https://en.wikipedia.org/wiki/V_(programming_language) https://en.wikipedia.org/wiki/V_(programming_language)