4 ms·

Tony Hoare, who introduced null in Algol in 1965, calls it his $1b mistake https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-H

by abraae 9y ago

Tony Hoare, who introduced null in Algol in 1965, calls it his $1b mistake https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare https://www.infoq.com/presentations/Null-References-The-Bill....

MarkusWinand 9y ago
Yes, because it is a null reference. SQL's null is a value. The difference is that processing null values does not cause exceptions in SQL.
- rixed 9y ago
  It doesn't cause early terminations but it certainly does cause errors.
  - MarkusWinand 9y ago
    *Edit: exceptions :)
- hjjiehebebe 9y ago
  The problem with nulls in c++ etc. is that every reference type is forced to be nullable. There is no opt out of that semantics. You get passed in an object of type O and it is really a sum type of O + Nothing. It means you need to do runtime checks everywhere and reason across call boundaries. You need to look at he code inside that method! That so un-OO! In Db land you can make a column not nullable. Bit the SQL languages like PLSQL TSQL etc have the same issue.
  - Sharlin 9y ago
    C++ references are non-nullable by design. They are sane in that regard. Pointers are nullable, of course, but at least they are syntactically conspicuous and anyway pretty rare in modern C++.
  - heavenlyblue 9y ago
    I would add: the reason it is a issue in C++ is because the algebra around pointers doesn’t support the NULLs explicitly: - the results of any operations over nulls run as if the pointer were not null - while anyhing you do in SQL with NULL would explicitly have a mapping to either a correct value or another NULL This is all said knowing that it’s quite easy to understand why is that the case.
- techno_modus 9y ago
  > SQL's null is a value. It is known to be one of the major controversies because originally NULL means the absence of a value which entails that it is not a value. Hence, if there are no values, then we cannot do any operations. Yet, for whatever reason (avoiding exceptions etc.) expressions with NULL need to be evaluated and hence NULL is treated as a value. So we get a problem: NULL is not a value AND NULL is a value. There are different views on this problem and the solution implemented in SQL (and three-valued logic) is probably not the best one.
  - MarkusWinand 9y ago
    This is a controversy outside of SQL. SQL is pretty clear what null is: > “Every [SQL] data type includes a special value, called the null value,”[0] “that is used to indicate the absence of any data value”[1] (http://modern-sql.com/concept/null http://modern-sql.com/concept/null) [0] SQL:2011-1: §4.4.2 [1] SQL:2011-1: §3.1.1.12
- lmm 9y ago
  Which is worse. Null references are at least relatively fail-fast. SQL null propagates and so you get the error a long way away from the original source, like with Javascript's "foo is not a property of undefined".
  - default-kramer 9y ago
    Exactly. I've wondered why no SQL implementation (that I know of) has optional assertions like "join exactly 1 some_table" or "select assert-not-null(some_column)". I don't see any reason why this would be a performance killer; in fact, it might even be possible to prove and then cache with the query plan.
  - abiox 9y ago
    I'd guess that propagation is by design, such as for use in outer joins.
ghusbands 9y ago
Algol's null and SQL's null are unrelated. In SQL it allows many operations to pass through an out of scope value without exceptions, like the Maybe monad. In Algol, it serves as a broken reference causing exceptions on any use.
zkomp 9y ago
(As the other comments already said:) null references are not the same as null values. A database sometimes needs to model this case: the value is unknown: maybe the paper file you digitized was corrupted or destroyed, or other valid reasons this value is not known. Whereas null references can be avoided, like in rust etc.
- lmm 9y ago
  You sometimes need to model absence of a reference as well - that's why rust etc. have option/maybe types. Making every reference in the language possibly null was a terrible design mistake for algol, and making every value in the language possibly null was a terrible design mistake for SQL.
  - zkomp 9y ago
    I disagree. It is not at all a design mistake in sql. You can have or forbid null values in tables. And you need that for many things. It is properly designed. Rust or functional languages show you do not generally need null references, you have options instead. It is completely different. Null in C or C++ is much more a very costly misstake. Missing data is just reality. Data may be incomplete, the values unknown. SQL is designed for that. It is designed to handle reality. Whereas null references are not, they cause problems you do not need... Data != reference you can avoid the issue of allowing invalid references everywhere you can not avoid incomplete data.

by abraae 9y ago

MarkusWinand 9y ago

Yes, because it is a null reference. SQL's null is a value. The difference is that processing null values does not cause exceptions in SQL.

rixed 9y ago
It doesn't cause early terminations but it certainly does cause errors.
- MarkusWinand 9y ago
  *Edit: exceptions :)
hjjiehebebe 9y ago
The problem with nulls in c++ etc. is that every reference type is forced to be nullable. There is no opt out of that semantics. You get passed in an object of type O and it is really a sum type of O + Nothing. It means you need to do runtime checks everywhere and reason across call boundaries. You need to look at he code inside that method! That so un-OO! In Db land you can make a column not nullable. Bit the SQL languages like PLSQL TSQL etc have the same issue.
- Sharlin 9y ago
  C++ references are non-nullable by design. They are sane in that regard. Pointers are nullable, of course, but at least they are syntactically conspicuous and anyway pretty rare in modern C++.
- heavenlyblue 9y ago
  I would add: the reason it is a issue in C++ is because the algebra around pointers doesn’t support the NULLs explicitly: - the results of any operations over nulls run as if the pointer were not null - while anyhing you do in SQL with NULL would explicitly have a mapping to either a correct value or another NULL This is all said knowing that it’s quite easy to understand why is that the case.
techno_modus 9y ago
> SQL's null is a value. It is known to be one of the major controversies because originally NULL means the absence of a value which entails that it is not a value. Hence, if there are no values, then we cannot do any operations. Yet, for whatever reason (avoiding exceptions etc.) expressions with NULL need to be evaluated and hence NULL is treated as a value. So we get a problem: NULL is not a value AND NULL is a value. There are different views on this problem and the solution implemented in SQL (and three-valued logic) is probably not the best one.
- MarkusWinand 9y ago
  This is a controversy outside of SQL. SQL is pretty clear what null is: > “Every [SQL] data type includes a special value, called the null value,”[0] “that is used to indicate the absence of any data value”[1] (http://modern-sql.com/concept/null http://modern-sql.com/concept/null) [0] SQL:2011-1: §4.4.2 [1] SQL:2011-1: §3.1.1.12
lmm 9y ago
Which is worse. Null references are at least relatively fail-fast. SQL null propagates and so you get the error a long way away from the original source, like with Javascript's "foo is not a property of undefined".
- default-kramer 9y ago
  Exactly. I've wondered why no SQL implementation (that I know of) has optional assertions like "join exactly 1 some_table" or "select assert-not-null(some_column)". I don't see any reason why this would be a performance killer; in fact, it might even be possible to prove and then cache with the query plan.
- abiox 9y ago
  I'd guess that propagation is by design, such as for use in outer joins.

ghusbands 9y ago

Algol's null and SQL's null are unrelated. In SQL it allows many operations to pass through an out of scope value without exceptions, like the Maybe monad. In Algol, it serves as a broken reference causing exceptions on any use.

zkomp 9y ago

(As the other comments already said:) null references are not the same as null values. A database sometimes needs to model this case: the value is unknown: maybe the paper file you digitized was corrupted or destroyed, or other valid reasons this value is not known. Whereas null references can be avoided, like in rust etc.

lmm 9y ago
You sometimes need to model absence of a reference as well - that's why rust etc. have option/maybe types. Making every reference in the language possibly null was a terrible design mistake for algol, and making every value in the language possibly null was a terrible design mistake for SQL.
- zkomp 9y ago
  I disagree. It is not at all a design mistake in sql. You can have or forbid null values in tables. And you need that for many things. It is properly designed. Rust or functional languages show you do not generally need null references, you have options instead. It is completely different. Null in C or C++ is much more a very costly misstake. Missing data is just reality. Data may be incomplete, the values unknown. SQL is designed for that. It is designed to handle reality. Whereas null references are not, they cause problems you do not need... Data != reference you can avoid the issue of allowing invalid references everywhere you can not avoid incomplete data.