5 ms·

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 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.
    - wtetzner 12y ago
      As far as I understand, the only way to get a type that's not nullable is to make a struct. How do you specify that a function can take a non-nullable string?
      - dragonwriter 12y ago
        > As far as I understand, the only way to get a type that's not nullable is to make a struct. Well, any value type -- but, yes, a custom type has to be a struct to not be nullable. > How do you specify that a function can take a non-nullable string? "string" in C# is the name of a particular reference (and hence, nullable) type. If you want a function that takes a non-nullable sequence of characters, that's quite possible, but the type of its argument won't be string. (The fact that there is no such type predefined and the entire .NET framework library is built around the assumption that if you want a sequence of characters you are going to use the built-in, reference -- and therefore nullable -- string type is an issue with the cost, in programmer-time, of doing this for any substantial use, but its not a "the language doesn't let you have a non-nullable type for any kind of data you want" issue.)

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.
  - wtetzner 12y ago
    As far as I understand, the only way to get a type that's not nullable is to make a struct. How do you specify that a function can take a non-nullable string?
    - dragonwriter 12y ago
      > As far as I understand, the only way to get a type that's not nullable is to make a struct. Well, any value type -- but, yes, a custom type has to be a struct to not be nullable. > How do you specify that a function can take a non-nullable string? "string" in C# is the name of a particular reference (and hence, nullable) type. If you want a function that takes a non-nullable sequence of characters, that's quite possible, but the type of its argument won't be string. (The fact that there is no such type predefined and the entire .NET framework library is built around the assumption that if you want a sequence of characters you are going to use the built-in, reference -- and therefore nullable -- string type is an issue with the cost, in programmer-time, of doing this for any substantial use, but its not a "the language doesn't let you have a non-nullable type for any kind of data you want" issue.)