3 ms·

This post seems somewhat strawman-ish to try and sell the author's language. No one has ever argued that the reason for nulls being a problem is because the id

This post seems somewhat strawman-ish to try and sell the author's language. No one has ever argued that the reason for nulls being a problem is because the idea of 'nothing' isn't valid; the argument has always been that they are completely invisible to the client function; that is, if you tell me functionA returns a string, I don't know if it -always- returns a string, or if it might also return a null. And you as the writer of functionA might not even know, if you're dependent on still other functions whose contracts are also ambiguous. To that end, to fix it, a type system to make the implicit null explicit, has always been the necessary answer. It -is- in fact what Option/Maybe/etc are intended to do, and provided they're used in a language that has a sufficiently robust type system, and that the language checks for non-exhaustive patterns in case matches (or similar), are still 100% effective. All of this author's issues with an Option type are explicitly with Java's implementation of it, a fact he himself notes. When he's able to show why his language provides better null protection than Haskell or Ocaml or something, I'll be interested. But as it stands, it sounds like he's just making an Option type that is a keyword in the language ("nullable a" rather than simply "a"), rather than a natural extension of the type system (Maybe a = Nothing | Just a). EDIT: This is especially galling as he's clearly aware of at least Haskell (he mentions that Haskell has the Maybe type), but then dismisses Option/Maybe at large for the reasons he dismisses Java, despite none of the arguments used against Java applying. Were the author to rewrite this, detailing the basic problem of null being that of no contractual check for it (rather than a strawman of there being no reason to have an 'empty' value), were to rewrite the Option/Maybe bit to show he understands it works fine so long as the language literally does not allow null, except as the Nothing part of the Optional/Maybe type, and instead sell PPL as being an imperative (so no need to drink the functional koolaid), simply typed (no ADTs, no covariant/contravariant OOness) language that has the same no NPE guarantees as Haskell or similar (using effectively the same mechanism; that nulls can only exist when the function contract explicitly declares them as a possibility, and that any consumer of the function must have a code branch to check for it and handle it in some way), it would actually be somewhat interesting; I could see a language like that making headway on the JVM, as it basically would come across "As simple as Java, without the NPEs", which would be a pretty easy sell.

judk 12y ago
The remaining mystery is why someone's undergraduate-homework-level mistake got voted to the front page.
- manojlds 12y ago
  That's Sunday at HN.
toolslive 12y ago
Indeed. The author does not seem to appreciate (or comprehend) the difference between types 'a' and 'a option'. This is not surprising: I have seen architects that never did anything else than java|python struggle with the basic types in OCaml| Haskell because they could not translate the concept of a value into Java. They always ask "yeah, but what if it's None?" and the answer "It can't be None as that is of a different type" does not seem to compute.
- wisty 12y ago
  As a Pythoneer with a vague knowledge of Haskell, that's odd. None is not an int. Or a float. Or a string. It's None. Python is nothing like C, where a string is a pointer that might point to null ... it just can't happen. Variables are untyped (so you can, in theory, return an open file when the function usually returns a float), but generally that's not how things work. I'd think Python programmers would get more upset about when stuff gets computed. "So ... it computes that next?". "Um, that's up to the compiler". "The what?"
  - lostcolony 12y ago
    I think the misunderstanding goes like this - "Okay...so you return either Maybe (value), or Nothing. But what if they return Maybe (Nothing/null)?" "Can't happen." "What do you mean it can't happen?" "It literally can not happen. The compiler's type checking enforces that when a function returns Maybe A, it really is of type A, which can not be null or nothing.". And that's where both sides sometimes break down; Pythonistas can, yes, have a hard time understanding that the compiler can enforce that, and Java people can have a hard time getting past the idea of null being a possibility everywhere. I find it easier to explain coming from the other direction. "When does a value get assigned null?" "Umm..." "Either you have a variable that has never been given a value, if the language lets you, so is defaulted to null, or you assign the variable to null." "Ok." "Now, you can only assign the variable to null if either you do that explicitly (a = null), or, you are calling out to another function that returns null (a = func()). But then, that function can only return null in the same cases; either the author explicitly assigns null, or he calls another function that returns null." "Right..." "So eventually, to have a null bubble up, someone had to assign or return a null. So your two cases, really, are either you left something uninitialized, or someone assigned/returned a value of null" "Gotcha." "So what if our language prevents you from leaving variables uninitialized, -and- there is no null value?" "You can't have an NPE. But what if there is no valid value? Do you just throw an exception or something?" "You -could-, but that's not ideal. What we do instead, is we change the function signature. That's where the Maybe comes in. Rather than just returning (type), we return Maybe (Type), where the actual values when run are either Just (value), or Nothing. Nothing, in this case, is the equivalent of null, but the caller of the function knows to check for it, and the compiler can be told to MAKE them check for it. And because we have no uninitialized values anywhere, we can't unexpectedly come across a null, and because there are no nulls to assign, anywhere that might be a null is itself a Maybe, and it's handled as such everywhere."

judk 12y ago

The remaining mystery is why someone's undergraduate-homework-level mistake got voted to the front page.

manojlds 12y ago
That's Sunday at HN.

toolslive 12y ago

Indeed. The author does not seem to appreciate (or comprehend) the difference between types 'a' and 'a option'. This is not surprising: I have seen architects that never did anything else than java|python struggle with the basic types in OCaml| Haskell because they could not translate the concept of a value into Java. They always ask "yeah, but what if it's None?" and the answer "It can't be None as that is of a different type" does not seem to compute.

wisty 12y ago
As a Pythoneer with a vague knowledge of Haskell, that's odd. None is not an int. Or a float. Or a string. It's None. Python is nothing like C, where a string is a pointer that might point to null ... it just can't happen. Variables are untyped (so you can, in theory, return an open file when the function usually returns a float), but generally that's not how things work. I'd think Python programmers would get more upset about when stuff gets computed. "So ... it computes that next?". "Um, that's up to the compiler". "The what?"
- lostcolony 12y ago
  I think the misunderstanding goes like this - "Okay...so you return either Maybe (value), or Nothing. But what if they return Maybe (Nothing/null)?" "Can't happen." "What do you mean it can't happen?" "It literally can not happen. The compiler's type checking enforces that when a function returns Maybe A, it really is of type A, which can not be null or nothing.". And that's where both sides sometimes break down; Pythonistas can, yes, have a hard time understanding that the compiler can enforce that, and Java people can have a hard time getting past the idea of null being a possibility everywhere. I find it easier to explain coming from the other direction. "When does a value get assigned null?" "Umm..." "Either you have a variable that has never been given a value, if the language lets you, so is defaulted to null, or you assign the variable to null." "Ok." "Now, you can only assign the variable to null if either you do that explicitly (a = null), or, you are calling out to another function that returns null (a = func()). But then, that function can only return null in the same cases; either the author explicitly assigns null, or he calls another function that returns null." "Right..." "So eventually, to have a null bubble up, someone had to assign or return a null. So your two cases, really, are either you left something uninitialized, or someone assigned/returned a value of null" "Gotcha." "So what if our language prevents you from leaving variables uninitialized, -and- there is no null value?" "You can't have an NPE. But what if there is no valid value? Do you just throw an exception or something?" "You -could-, but that's not ideal. What we do instead, is we change the function signature. That's where the Maybe comes in. Rather than just returning (type), we return Maybe (Type), where the actual values when run are either Just (value), or Nothing. Nothing, in this case, is the equivalent of null, but the caller of the function knows to check for it, and the compiler can be told to MAKE them check for it. And because we have no uninitialized values anywhere, we can't unexpectedly come across a null, and because there are no nulls to assign, anywhere that might be a null is itself a Maybe, and it's handled as such everywhere."