5 ms·

After starting using Option<T>, no implementation of null is 'brilliant' any more. Not that any one of them ever was.

deleted 4y ago
[deleted]
deltaonefour 4y ago
I want to specify Option<T> with exhaustive pattern matching as the only way to extract the value out of the container is the safest way. Optionals without this feature/restriction are actually the same as a null. if(optional_value.has_value()) if(value != NULL) Both of the above checks are STILL required or it's an error. Optionals only propagate the null to another method call. There has to be exhaustive pattern matching for this feature to truly shine.
- blacksmithgu 4y ago
  Even optionals with bad 'is null / get' assessors are better than nulls, because they come with nullsafe operators like map / flatMap and the 'get' call usually always errors or panics on failure.
  - deltaonefour 4y ago
    It's the same thing right? flatMap or Map must call the has_value method to work without crashing.
    - masklinn 4y ago
      It's not because (I assume) even the shitty optional gives you a signal that the value is nullable and that you have to check. The important part is moving `null` out of every type in the language, and into its own little box that the compiler can tell you about. It's nice if you can make it a "library" utility without holes, but it's also fine if it's not perfect, or even if you have to make it a builtin magic thing, like C# &co. > flatMap or Map must call the has_value method to work without crashing. The implementation details don't really matter to the caller, what matters is that they're always operating in a safe environment without being bothered.
      - deltaonefour 4y ago
        >The implementation details don't really matter to the caller, what matters is that they're always operating in a safe environment without being bothered. It matters because it's not true safety. flatMap is a higher level operation, I can make >=> or >>= work for values with null but that's not true safety. True safety as you said, is no null. But an optional that still generates a runtime error is basically isomorphic to a null. The point of getting rid of null is not null itself, but the associated runtime error that comes with it.
Spivak 4y ago
Optional or Maybe is just “type or null” which is the implicit type of every language with nullable by default types. It’s worse in every way to null. If your language can’t enforce non-nullable references then you have to worry that your Optional might be null. And if your language can enforce non nullable references then you’re boxing your types for no reason because inside if x != null you could just use x unboxed instead of x.getValue(). The only thing you miss is that None<A> and None<B> are distinct types but Go solved that with a typed nil. For example Python with mypy is so much more ergonomic. def foo() -> Optional[int]: return None if coinflip() else 4 x = foo() if x is not None: print(x + 5) # no error y = x * 2 # error None doesn’t have a __mul__ operator.
- ebingdom 4y ago
  > It’s worse in every way to null. No, Optional is actually better than null because it's functorial. That means it obeys some common sense laws that one might intuitively expect. Instead of reciting the functor laws, I'll give you a concrete example. Consider a `HashMap<K, V>` type with the following API: get(key: K) -> Option<V> So, `get` returns `None` if the key is not found in the map. That's the proper API one would expect. It forces the caller to acknowledge the possibility that the key might not be in the map. However, if you try to do that with nulls instead of with Optional, it breaks if the value type is nullable, because nulls don't nest. For example, if your `get` method looks more like this: get(key: K) -> V? and you use it with a nullable valuable type like HashMap<String, Int?>, then when the `get` method returns null you have no idea if it's because the value was null or the key was not in the map. Then, every time you want to look something up in the map, you have to first check if it's in the map with a different method and then do your lookup. This is error prone, because if you forget to do the check first, your program now has a silent bug that the type checker does not detect. You might think to yourself, "that's silly, why would I ever want to store nulls in a map?" Well, here's one of many possible use cases: suppose you are using the map as a cache, and you want to cache the fact that something doesn't exist. This is called negative caching, and it's occasionally useful. Or maybe you're building some generic code (like a collections library) that happens to use hash maps internally. If the hash map's get method uses a nullable type instead of Optional for its result, then it's likely that your library does not work correctly for nullable types, because it's easy to accidentally assume that null indicates that the key was not found in the map. That kind of bug won't be caught by the type checker. Nulls are bad. Optional is good. We really need to teach category theory to programmers so people can stop making this mistake which leads to error-prone APIs and code with hidden bugs.
User23 4y ago
Tony Hoare called null his billion dollar mistake[1] for good reason. It’s especially remarkable given that Mr. Hoare is easily one of the finest computing scientists ever. Even the most brilliant can get it wrong. And only the most brilliant will admit it. Hats off to Sir Tony. [1] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...
- KMag 4y ago
  He said that he knew it was a kludge at the time, but it was seductively easy to implement... just add a special case to the type checker so that if the type being assigned to a reference is wrong, allow it if it's null. Properly working nullable and non-nullable references (or making optionality and references orthogonal concepts) would have been a much deeper change to the language and the compiler.

deleted 4y ago

[deleted]

I want to specify Option<T> with exhaustive pattern matching as the only way to extract the value out of the container is the safest way. Optionals without this feature/restriction are actually the same as a null. if(optional_value.has_value()) if(value != NULL) Both of the above checks are STILL required or it's an error. Optionals only propagate the null to another method call. There has to be exhaustive pattern matching for this feature to truly shine.

blacksmithgu 4y ago
Even optionals with bad 'is null / get' assessors are better than nulls, because they come with nullsafe operators like map / flatMap and the 'get' call usually always errors or panics on failure.
- deltaonefour 4y ago
  It's the same thing right? flatMap or Map must call the has_value method to work without crashing.
  - masklinn 4y ago
    It's not because (I assume) even the shitty optional gives you a signal that the value is nullable and that you have to check. The important part is moving `null` out of every type in the language, and into its own little box that the compiler can tell you about. It's nice if you can make it a "library" utility without holes, but it's also fine if it's not perfect, or even if you have to make it a builtin magic thing, like C# &co. > flatMap or Map must call the has_value method to work without crashing. The implementation details don't really matter to the caller, what matters is that they're always operating in a safe environment without being bothered.
    - deltaonefour 4y ago
      >The implementation details don't really matter to the caller, what matters is that they're always operating in a safe environment without being bothered. It matters because it's not true safety. flatMap is a higher level operation, I can make >=> or >>= work for values with null but that's not true safety. True safety as you said, is no null. But an optional that still generates a runtime error is basically isomorphic to a null. The point of getting rid of null is not null itself, but the associated runtime error that comes with it.

Spivak 4y ago

Optional or Maybe is just “type or null” which is the implicit type of every language with nullable by default types. It’s worse in every way to null. If your language can’t enforce non-nullable references then you have to worry that your Optional might be null. And if your language can enforce non nullable references then you’re boxing your types for no reason because inside if x != null you could just use x unboxed instead of x.getValue(). The only thing you miss is that None<A> and None<B> are distinct types but Go solved that with a typed nil. For example Python with mypy is so much more ergonomic. def foo() -> Optional[int]: return None if coinflip() else 4 x = foo() if x is not None: print(x + 5) # no error y = x * 2 # error None doesn’t have a __mul__ operator.

ebingdom 4y ago
> It’s worse in every way to null. No, Optional is actually better than null because it's functorial. That means it obeys some common sense laws that one might intuitively expect. Instead of reciting the functor laws, I'll give you a concrete example. Consider a `HashMap<K, V>` type with the following API: get(key: K) -> Option<V> So, `get` returns `None` if the key is not found in the map. That's the proper API one would expect. It forces the caller to acknowledge the possibility that the key might not be in the map. However, if you try to do that with nulls instead of with Optional, it breaks if the value type is nullable, because nulls don't nest. For example, if your `get` method looks more like this: get(key: K) -> V? and you use it with a nullable valuable type like HashMap<String, Int?>, then when the `get` method returns null you have no idea if it's because the value was null or the key was not in the map. Then, every time you want to look something up in the map, you have to first check if it's in the map with a different method and then do your lookup. This is error prone, because if you forget to do the check first, your program now has a silent bug that the type checker does not detect. You might think to yourself, "that's silly, why would I ever want to store nulls in a map?" Well, here's one of many possible use cases: suppose you are using the map as a cache, and you want to cache the fact that something doesn't exist. This is called negative caching, and it's occasionally useful. Or maybe you're building some generic code (like a collections library) that happens to use hash maps internally. If the hash map's get method uses a nullable type instead of Optional for its result, then it's likely that your library does not work correctly for nullable types, because it's easy to accidentally assume that null indicates that the key was not found in the map. That kind of bug won't be caught by the type checker. Nulls are bad. Optional is good. We really need to teach category theory to programmers so people can stop making this mistake which leads to error-prone APIs and code with hidden bugs.

User23 4y ago

Tony Hoare called null his billion dollar mistake[1] for good reason. It’s especially remarkable given that Mr. Hoare is easily one of the finest computing scientists ever. Even the most brilliant can get it wrong. And only the most brilliant will admit it. Hats off to Sir Tony. [1] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...

KMag 4y ago
He said that he knew it was a kludge at the time, but it was seductively easy to implement... just add a special case to the type checker so that if the type being assigned to a reference is wrong, allow it if it's null. Properly working nullable and non-nullable references (or making optionality and references orthogonal concepts) would have been a much deeper change to the language and the compiler.