6 ms·

This is probably a stupid question, but why do we have null as a concept? Nullable booleans especially grate on me. Surely it is true or false, but not null. Ot

by junto 11y ago

This is probably a stupid question, but why do we have null as a concept? Nullable booleans especially grate on me. Surely it is true or false, but not null. Otherwise you surely have the wrong type? Does anyone else have these deep down feeling that null feels wrong?

Athas 11y ago
Null is wrong. It was implemented because it was easy, as it maps directly to how object references are typically implemented in memory: http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186
- Sanddancer 11y ago
  That is null as a reference. Null as a type, however, is useful. An off the top of the head situation is suppose you have a ballot. On this ballot, one can vote for one of x, or they can choose to not vote for any at all. In verifying and tabulating the votes, having a null value makes a lot of the rest of the process easier.
jasode 11y ago
>Surely it is true or false, but not null. If that's surely what you have, then you have a regular "bool" and not nullable "bool?". In C#, "bool" and "bool?" are not the same type. (Although C# provides some convenient implicit conversions that minimize tedious verbosity when working with both -- but that convenience also has the effect of blurring the lines. Nevertheless, they are different types.) A "bool" can represent 2-states. A "bool?" can represent 3-states: true -or- false -or- unknown/empty/indeterminate/invalid/etc. Your premise that I quoted is constrained to 2 states -- therefore use the 2-state type which is plain "bool". Unless you think nullable "bool?" as a syntax seems to defy some kind of airtight mathematical logic? What would be the alternative?!? Have everyone create a custom enum that with 3 enum values "{falsy = 0; truthy = 1; unknown = 2}"? Why would reinvention of those semantics in everyone's redundant code snippets be better than C#'s standard nullable "bool?"? (Another issue that may confuse the "null" discussion is the 2 separate concepts of "null": #1 is "null" as an indicator of pointing to invalid memory and #2 is "null" as deliberate semantic placeholders for application/business logic of unknown values. The #2 concept is what is modeled by C# nullable<T> and SQL database fields.)
- CuriousSkeptic 11y ago
  This view isn't without criticism though. http://www.alternativetech.com/publications/copper.pdf http://www.alternativetech.com/publications/copper.pdf Edit: "Logicians have proved that a large class of MVLs are not truth-functionally complete[.] They have also proved that if such an MVL is made complete (for instance, by adding the Slupecki T-function), it becomes inconsistent! Therefore[,] we can have either truth-functional completeness or consistency, but not both."
  - jasode 11y ago
    The last time I looked at this, most of the arguments were focused on mathematical rigor of comparing NULL to NULL. Are they the equal or not? (The RDBMS of Oracle, MSSQL, etc don't all agree.) It doesn't matter which interpretation one favors, it will eventually lead to a logical contradiction. If you took away the Nullable<T> concept to conveniently add 3-value logic to value types, the same philosophical problem still remains. If you force programmers to manually reinvent their own 3-value logic (e.g. manually add in an extra bool variable "HasValue" to signify whether another variable's content is "valid", you still have the same conceptual problem your pdf is grappling with.
    - CuriousSkeptic 11y ago
      I was merely adding context. The arguments mostly boils down to - the mathematical rigor, as you suggest, which besides the issue of contradictions also introduces problems for the implentattion of things like query optimization. - non-null solutions are possible, f.ex. normalization, which besids avoiding the null-issue also comes with other benefits. However, I'm not sure Nullable<T>, is problematic in the same sense. It is, after all, an explicit value domain, and not part of any logic at all. Notice how the debate about relational systems doesn't talk of a Boolean value domain (MSSQL doesn't even have a Boolean type, only a single bit number type) but of the predicate logic resulting from existing and non-existing rows. I guess a comparable situation would rather be, if you have a Nullable<T> where T:class, how do you treat the difference between boxed and unboxed nulls? In, Scala, f.ex., it's perfectly valid to have Some(null) != None, which means you need to handle the null value even for non-None values.
Dylan16807 11y ago
For a type of "an object" or "a value", null is wrong. For a type of "maybe an object" or "maybe a value", null is not wrong. There is nothing fundamentally wrong with letting null exist in some form, especially if you hide it behind an Option<> interface. The problem is when people use the wrong type. > Surely it is true or false, but not null. Otherwise you surely have the wrong type? Nullable boolean is not the same type as boolean. Problem solved. The deep sense of wrongness is probably because so many languages force you to use nullable objects even when that's the wrong type. Not because nullables are inherently nonsensical.
spion 11y ago
Yes Making null assignable to anything results with all kinds of nonsense. For example, to say that any class implements an interface is now nonsense - as long as nullable values are assignable to that type, there is no guarantee at all. You now have this nice and fancy type system... with this giant gaping hole that lets all hell break lose. And then we wonder why people are skeptical of the claim that statically typed languages help with correctness.
- jasode 11y ago
  >For example, to say that any class implements an interface is now nonsense - as long as nullable values are assignable to that type You're talking about a different concept of "null" from the parent you're replying to (junto). You're talking about "null" as invalid object reference (similar to uninitialized pointer in C/C++). junto was asking about "null" as a sentinel value for semantics of "missing" or "unknown" data. This is a very desirable language feature to have. Your complaint about "null references" is valid but it's further confusing the misunderstanding junto appears to have about Nullable<T>. Nullable<T> isn't about invalid object references. Instead, it's a convenient language feature that combines two booleans to expose the desirable semantics of a tri-state boolean. The 1st bool is the user named variable. The 2nd bool is the .HasValue property. Instead of explicitly setting .Hashvalue=false, C# just lets programmer use "null".

by junto 11y ago

Athas 11y ago

Null is wrong. It was implemented because it was easy, as it maps directly to how object references are typically implemented in memory: http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186

Sanddancer 11y ago
That is null as a reference. Null as a type, however, is useful. An off the top of the head situation is suppose you have a ballot. On this ballot, one can vote for one of x, or they can choose to not vote for any at all. In verifying and tabulating the votes, having a null value makes a lot of the rest of the process easier.

jasode 11y ago

>Surely it is true or false, but not null. If that's surely what you have, then you have a regular "bool" and not nullable "bool?". In C#, "bool" and "bool?" are not the same type. (Although C# provides some convenient implicit conversions that minimize tedious verbosity when working with both -- but that convenience also has the effect of blurring the lines. Nevertheless, they are different types.) A "bool" can represent 2-states. A "bool?" can represent 3-states: true -or- false -or- unknown/empty/indeterminate/invalid/etc. Your premise that I quoted is constrained to 2 states -- therefore use the 2-state type which is plain "bool". Unless you think nullable "bool?" as a syntax seems to defy some kind of airtight mathematical logic? What would be the alternative?!? Have everyone create a custom enum that with 3 enum values "{falsy = 0; truthy = 1; unknown = 2}"? Why would reinvention of those semantics in everyone's redundant code snippets be better than C#'s standard nullable "bool?"? (Another issue that may confuse the "null" discussion is the 2 separate concepts of "null": #1 is "null" as an indicator of pointing to invalid memory and #2 is "null" as deliberate semantic placeholders for application/business logic of unknown values. The #2 concept is what is modeled by C# nullable<T> and SQL database fields.)

CuriousSkeptic 11y ago
This view isn't without criticism though. http://www.alternativetech.com/publications/copper.pdf http://www.alternativetech.com/publications/copper.pdf Edit: "Logicians have proved that a large class of MVLs are not truth-functionally complete[.] They have also proved that if such an MVL is made complete (for instance, by adding the Slupecki T-function), it becomes inconsistent! Therefore[,] we can have either truth-functional completeness or consistency, but not both."
- jasode 11y ago
  The last time I looked at this, most of the arguments were focused on mathematical rigor of comparing NULL to NULL. Are they the equal or not? (The RDBMS of Oracle, MSSQL, etc don't all agree.) It doesn't matter which interpretation one favors, it will eventually lead to a logical contradiction. If you took away the Nullable<T> concept to conveniently add 3-value logic to value types, the same philosophical problem still remains. If you force programmers to manually reinvent their own 3-value logic (e.g. manually add in an extra bool variable "HasValue" to signify whether another variable's content is "valid", you still have the same conceptual problem your pdf is grappling with.
  - CuriousSkeptic 11y ago
    I was merely adding context. The arguments mostly boils down to - the mathematical rigor, as you suggest, which besides the issue of contradictions also introduces problems for the implentattion of things like query optimization. - non-null solutions are possible, f.ex. normalization, which besids avoiding the null-issue also comes with other benefits. However, I'm not sure Nullable<T>, is problematic in the same sense. It is, after all, an explicit value domain, and not part of any logic at all. Notice how the debate about relational systems doesn't talk of a Boolean value domain (MSSQL doesn't even have a Boolean type, only a single bit number type) but of the predicate logic resulting from existing and non-existing rows. I guess a comparable situation would rather be, if you have a Nullable<T> where T:class, how do you treat the difference between boxed and unboxed nulls? In, Scala, f.ex., it's perfectly valid to have Some(null) != None, which means you need to handle the null value even for non-None values.

Dylan16807 11y ago

For a type of "an object" or "a value", null is wrong. For a type of "maybe an object" or "maybe a value", null is not wrong. There is nothing fundamentally wrong with letting null exist in some form, especially if you hide it behind an Option<> interface. The problem is when people use the wrong type. > Surely it is true or false, but not null. Otherwise you surely have the wrong type? Nullable boolean is not the same type as boolean. Problem solved. The deep sense of wrongness is probably because so many languages force you to use nullable objects even when that's the wrong type. Not because nullables are inherently nonsensical.

spion 11y ago

Yes Making null assignable to anything results with all kinds of nonsense. For example, to say that any class implements an interface is now nonsense - as long as nullable values are assignable to that type, there is no guarantee at all. You now have this nice and fancy type system... with this giant gaping hole that lets all hell break lose. And then we wonder why people are skeptical of the claim that statically typed languages help with correctness.

jasode 11y ago
>For example, to say that any class implements an interface is now nonsense - as long as nullable values are assignable to that type You're talking about a different concept of "null" from the parent you're replying to (junto). You're talking about "null" as invalid object reference (similar to uninitialized pointer in C/C++). junto was asking about "null" as a sentinel value for semantics of "missing" or "unknown" data. This is a very desirable language feature to have. Your complaint about "null references" is valid but it's further confusing the misunderstanding junto appears to have about Nullable<T>. Nullable<T> isn't about invalid object references. Instead, it's a convenient language feature that combines two booleans to expose the desirable semantics of a tri-state boolean. The 1st bool is the user named variable. The 2nd bool is the .HasValue property. Instead of explicitly setting .Hashvalue=false, C# just lets programmer use "null".