7 ms·

Maybe they don't throw an exception immediately. Maybe that null value gets stored somewhere, and you don't hit it until three hours later, when the system goes

by scott_s 12y ago

Maybe they don't throw an exception immediately. Maybe that null value gets stored somewhere, and you don't hit it until three hours later, when the system goes to save data to disk. Now your exception gets thrown far away from where the error occurred, both in terms of code and actual time. (For the record, I'm assuming an interface such as: fileOpen -> FileHandle Where the FileHandle object can be null, and it being null is used to indicate that the call to fileOpen failed.)

taeric 12y ago
Couldn't that happen with an optional type, as well? Especially if you let it get inferred. Only when you go to use it would you realize you have to map over the value. And then you are back in the world of messed up.
- scott_s 12y ago
  It depends on the language, and the API of the libraries you use. If we have a Haskell-like Maybe type, you should be able to create functions that refuse to take a Maybe. That would force you to determine soon after the fileOpen call: did it succeed or not? To be clear, this would involve the static type system for your language forcing certain things to happen, or not compiling. The sequence: 1. fileOpen returned a Maybe<FileObject> 2. You want to store the FileObject somewhere, and it expects an actual FileObject. 3. Maybe<FileObject> is not itself a FileObject, so you have to figure out: is it Nothing, or a FileObject? 4. You have to handle the Nothing case (language forces you to, even if you do nothing about it - you explicitly decided to do nothing). 5. If it is indeed a FileObject, you store it for later use, and you are guaranteed it is, indeed, a FileObject.
  - taeric 12y ago
    Right. This makes sense. Though, I would have thought the lazy semantics of Haskel would trip you up here. Ultimately doesn't matter, my main argument is that I see people proliferate "Optional" values all over the bloody place. So, I would expect to find that they just put the optional ref up and used it later when necessary. And I should note that I don't necessarily dislike the optional types and such. I just also don't have the major disdain for null that the internet seems to send through a massive echo chamber nightly.
    - wtetzner 12y ago
      The problem with languages that have null is that they don't let you write non-nullable types. That means any variable at any time could be null. You don't have the option of guaranteeing something won't be null.
      - dragonwriter 12y ago
        > The problem with languages that have null is that they don't let you write non-nullable types. That's a problem with Java (because it doesn't let you do that) and a similar problem exists with dynamic languages (because types aren't attributes of variables, so any variable could be null -- or any other value, null isn't particularly exceptional in dynamic languages for being a source of this kind of problem), but its not a problem "with languages that have null", as there are statically typed languages that have null but distinguish nullable and non-nullable types (C# and other static .NET languages are probably the most well-known examples, though there are others.)
        wtetzner 12y ago
        C# only kind of gives you this. When I said "the problem with languages that have null", that's really what I meant. There definitely could be a static language that let you choose if something is nullable or not. But really, at that point it's just sugar for an option type.
        dragonwriter 12y ago
        C# is absolutely a static language that lets choose if something is nullable or not, there is no "kind of" about it. > But really, at that point it's just sugar for an option type. No, having a the free choice not use nullable types doesn't make the languages nullable types into sugar for option types. Nullable types don't compose the way option types do -- the issue in the article this thread is about isn't about whether or not you have the choice for nullable types, its about the fact they don't compose so you can distinguish a function returning a null as a substantive value because the thing you tried to store was also a nullable type and had a null value (Just None, in a world with Options instead of nullable types) or where the null is a result of the lookup failing (None, in a world with Options instead of nullable types.) The deficiency of nullable types in C# compared to Options isn't the lack of choice of writing non-nullable types -- as you certainly have that choice for any data you need to represent -- its that nullabe types don't compose the way Options do.

by scott_s 12y ago

taeric 12y ago

Couldn't that happen with an optional type, as well? Especially if you let it get inferred. Only when you go to use it would you realize you have to map over the value. And then you are back in the world of messed up.

scott_s 12y ago
It depends on the language, and the API of the libraries you use. If we have a Haskell-like Maybe type, you should be able to create functions that refuse to take a Maybe. That would force you to determine soon after the fileOpen call: did it succeed or not? To be clear, this would involve the static type system for your language forcing certain things to happen, or not compiling. The sequence: 1. fileOpen returned a Maybe<FileObject> 2. You want to store the FileObject somewhere, and it expects an actual FileObject. 3. Maybe<FileObject> is not itself a FileObject, so you have to figure out: is it Nothing, or a FileObject? 4. You have to handle the Nothing case (language forces you to, even if you do nothing about it - you explicitly decided to do nothing). 5. If it is indeed a FileObject, you store it for later use, and you are guaranteed it is, indeed, a FileObject.
- taeric 12y ago
  Right. This makes sense. Though, I would have thought the lazy semantics of Haskel would trip you up here. Ultimately doesn't matter, my main argument is that I see people proliferate "Optional" values all over the bloody place. So, I would expect to find that they just put the optional ref up and used it later when necessary. And I should note that I don't necessarily dislike the optional types and such. I just also don't have the major disdain for null that the internet seems to send through a massive echo chamber nightly.
  - wtetzner 12y ago
    The problem with languages that have null is that they don't let you write non-nullable types. That means any variable at any time could be null. You don't have the option of guaranteeing something won't be null.
    - dragonwriter 12y ago
      > The problem with languages that have null is that they don't let you write non-nullable types. That's a problem with Java (because it doesn't let you do that) and a similar problem exists with dynamic languages (because types aren't attributes of variables, so any variable could be null -- or any other value, null isn't particularly exceptional in dynamic languages for being a source of this kind of problem), but its not a problem "with languages that have null", as there are statically typed languages that have null but distinguish nullable and non-nullable types (C# and other static .NET languages are probably the most well-known examples, though there are others.)
      - wtetzner 12y ago
        C# only kind of gives you this. When I said "the problem with languages that have null", that's really what I meant. There definitely could be a static language that let you choose if something is nullable or not. But really, at that point it's just sugar for an option type.
        dragonwriter 12y ago
        C# is absolutely a static language that lets choose if something is nullable or not, there is no "kind of" about it. > But really, at that point it's just sugar for an option type. No, having a the free choice not use nullable types doesn't make the languages nullable types into sugar for option types. Nullable types don't compose the way option types do -- the issue in the article this thread is about isn't about whether or not you have the choice for nullable types, its about the fact they don't compose so you can distinguish a function returning a null as a substantive value because the thing you tried to store was also a nullable type and had a null value (Just None, in a world with Options instead of nullable types) or where the null is a result of the lookup failing (None, in a world with Options instead of nullable types.) The deficiency of nullable types in C# compared to Options isn't the lack of choice of writing non-nullable types -- as you certainly have that choice for any data you need to represent -- its that nullabe types don't compose the way Options do.