3 ms·

Count me amongst those who do not think they're a mistake. You need to indicate no-data-here in some fashion. If you try to use that no-data in some fashion h

Count me amongst those who do not think they're a mistake. You need to indicate no-data-here in some fashion. If you try to use that no-data in some fashion having your program blow up from a null reference is a feature to me--in the vast majority of cases it's better go boom than silently continue doing something wrong. In the few where that's not the case you can trap the exception and go on. The real solution is what has been done with C# in recent years--have the compiler track whether a field can contain a null or not and squawk if you try to dereference something you haven't checked. That causes it to blow up in the best place--compile time rather than runtime.

kroltan 7y ago
Yes, which is where types like `Optional` come in. If you make a language where null doesn't exist by default, but still provide a standard way of indicating non-presence, you get the advantage of compile-time correctness checking. Also, the compiler can still optimize the `(hasValue, value)` tuple into a possibly-0 pointer when the type of the value is a pointer. (which by the way, is exactly what Rust does, among others)
- iCarrot 7y ago
  They are called Nullable types in C# and must be declared with `?` after the type. But, Nullable<T>.HasValue check is not forced and Nullable<T>.Value will throw a different exception instead if it is null (InvalidOperationException).
  - to11mtm 7y ago
    Well, Depends on which type you are referring to (Which is part of what pains me with nullable ref types, as nice as it is to have) If it's a value type (T), ? will make it Nullable<T> and provide the behavior described. Reference types however can always be null, and do not have a .HasValue as exampled above. However newer versions of C# let you declare nullable references on a compiler level, but rather than HasValue/Value you still have to do the null check and instead can bypass via the new deref operator (!)
    - LorenPechtel 7y ago
      Which is what I was talking about. I haven't had the opportunity to put it to use yet (converting an existing project is a big headache, it's something to do from the start) so I didn't remember the terms, only the ability.
philwelch 7y ago
I think it's perfectly fine to have option types, and that's exactly what languages without null references end up doing. What null references end up doing is accidentally turning all types into option types and making it impossible to have non-option types.
- deleted 7y ago
  [deleted]
littlecranky67 7y ago
> You need to indicate no-data-here in some fashion. Well languages that have non-nullable types still allow you to do that - you just have to be explicit about it. In TypeScript (using --strict mode which disables nullables), youd need to define the type as union type and make use of the "null" type: `let a: string | null`. So you tell the compiler that either "null" is a valid value for a or a string. The compiler will assist you and catch possible bugs (such as dereferencing a without checking it against null first)
paulddraper 7y ago
No one thinks that non-existence can't be represented, and all but the most extreme proof languages have the possibility of runtime error. Null is a mistake because it is (1) ubiquitously permitted in types and (2) non-composable. (Point #2: This caused JavaScript to have "undefined" which is a second level of nonexistence) The Maybe/Option pattern solves both these problems. Nullable at least solves the first one. When people criticize "null, the billion dollar mistake", they criticize the ubiquitous, non-composable form of null. https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

kroltan 7y ago

Yes, which is where types like `Optional` come in. If you make a language where null doesn't exist by default, but still provide a standard way of indicating non-presence, you get the advantage of compile-time correctness checking. Also, the compiler can still optimize the `(hasValue, value)` tuple into a possibly-0 pointer when the type of the value is a pointer. (which by the way, is exactly what Rust does, among others)

iCarrot 7y ago
They are called Nullable types in C# and must be declared with `?` after the type. But, Nullable<T>.HasValue check is not forced and Nullable<T>.Value will throw a different exception instead if it is null (InvalidOperationException).
- to11mtm 7y ago
  Well, Depends on which type you are referring to (Which is part of what pains me with nullable ref types, as nice as it is to have) If it's a value type (T), ? will make it Nullable<T> and provide the behavior described. Reference types however can always be null, and do not have a .HasValue as exampled above. However newer versions of C# let you declare nullable references on a compiler level, but rather than HasValue/Value you still have to do the null check and instead can bypass via the new deref operator (!)
  - LorenPechtel 7y ago
    Which is what I was talking about. I haven't had the opportunity to put it to use yet (converting an existing project is a big headache, it's something to do from the start) so I didn't remember the terms, only the ability.

philwelch 7y ago

I think it's perfectly fine to have option types, and that's exactly what languages without null references end up doing. What null references end up doing is accidentally turning all types into option types and making it impossible to have non-option types.

deleted 7y ago
[deleted]

littlecranky67 7y ago

> You need to indicate no-data-here in some fashion. Well languages that have non-nullable types still allow you to do that - you just have to be explicit about it. In TypeScript (using --strict mode which disables nullables), youd need to define the type as union type and make use of the "null" type: `let a: string | null`. So you tell the compiler that either "null" is a valid value for a or a string. The compiler will assist you and catch possible bugs (such as dereferencing a without checking it against null first)

paulddraper 7y ago

No one thinks that non-existence can't be represented, and all but the most extreme proof languages have the possibility of runtime error. Null is a mistake because it is (1) ubiquitously permitted in types and (2) non-composable. (Point #2: This caused JavaScript to have "undefined" which is a second level of nonexistence) The Maybe/Option pattern solves both these problems. Nullable at least solves the first one. When people criticize "null, the billion dollar mistake", they criticize the ubiquitous, non-composable form of null. https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...