4 ms·

> The logic-variant of Null usage for "unknown" "missing" "invalid" values is unavoidable in programming. On the contrary it’s perfectly avoidable. You just ne

> The logic-variant of Null usage for "unknown" "missing" "invalid" values is unavoidable in programming. On the contrary it’s perfectly avoidable. You just need to use an option type with a language that supports comprehensive pattern matching and won’t even compile if you don’t explicitly consider the case of a missing value. If your model is flawed and you don’t want to explicitly specify that some value is optional then the problem is in your way of thinking. And there is no need to invent a language that doesn’t support nulls, they already exist.

viraptor 8y ago
It's just another name for Null in practice. Or a "typed null" to be more precise. It's got some nice properties, but really it's the good old tri-state. As the op says - is a "logic-variant of Null"
- annabellish 8y ago
  That style of "null" has a _lot_ of advantages over the common null found today. The perfect is the enemy of the good - Option/Maybe types aren't perfect, but they're a lot better than null references.
- tomasz_bekas 8y ago
  >really it's the good old tri-state Yes it is, the point they make is that Option<Boolean> is explicitly tri-state in contrast to regular Boolean which should be two-state.
- dragonwriter 8y ago
  > It's just another name for Null in practice. No, it's not. > Or a "typed null" to be more precise. To the extent this is true, it is a fundamental difference. > It's got some nice properties, but really it's the good old tri-state. No, it's not. Because the Boolean type contains only True and False, not Null and the Option<Boolean> type (likewise, Option<Option<Boolean>>, etc.) does not contain True or False. There's no weirdness in doing logic operations on an Option<Boolean>, or a pair of them, because it is a type error to attempt it because Option<Boolean> is not Boolean.
  - viraptor 8y ago
    Sure, they're different things. The comment wasn't meant to be in vacuum, but as a response to option being a better logic 3-state. I agree that for other reasons it's better, but conceptually they are used to represent the same thing. (Logic variant of null)
xamuel 8y ago
In languages with pointers, it's not really possible for the compiler to know when null needs to be checked for. Consider this fragment: void f(char *x) {g(&x); printf(x);} It's possible that calling g(&x) might cause x to no longer be null, even if x originally was null. It would then be inappropriate for the compiler to complain that the next instruction attempts to use x without checking whether x is null.

viraptor 8y ago

It's just another name for Null in practice. Or a "typed null" to be more precise. It's got some nice properties, but really it's the good old tri-state. As the op says - is a "logic-variant of Null"

annabellish 8y ago
That style of "null" has a _lot_ of advantages over the common null found today. The perfect is the enemy of the good - Option/Maybe types aren't perfect, but they're a lot better than null references.
tomasz_bekas 8y ago
>really it's the good old tri-state Yes it is, the point they make is that Option<Boolean> is explicitly tri-state in contrast to regular Boolean which should be two-state.
dragonwriter 8y ago
> It's just another name for Null in practice. No, it's not. > Or a "typed null" to be more precise. To the extent this is true, it is a fundamental difference. > It's got some nice properties, but really it's the good old tri-state. No, it's not. Because the Boolean type contains only True and False, not Null and the Option<Boolean> type (likewise, Option<Option<Boolean>>, etc.) does not contain True or False. There's no weirdness in doing logic operations on an Option<Boolean>, or a pair of them, because it is a type error to attempt it because Option<Boolean> is not Boolean.
- viraptor 8y ago
  Sure, they're different things. The comment wasn't meant to be in vacuum, but as a response to option being a better logic 3-state. I agree that for other reasons it's better, but conceptually they are used to represent the same thing. (Logic variant of null)

xamuel 8y ago

In languages with pointers, it's not really possible for the compiler to know when null needs to be checked for. Consider this fragment: void f(char *x) {g(&x); printf(x);} It's possible that calling g(&x) might cause x to no longer be null, even if x originally was null. It would then be inappropriate for the compiler to complain that the next instruction attempts to use x without checking whether x is null.