4 ms·
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 t
by 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 agoAs 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 agoI 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."