Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NULL: The worst mistake of computer science? (2015)

lucidchart.com

Post reply on HN
Print view View original

151–160 of 377 posts

Re: NULL: The worst mistake of computer science? (2015)

#151

Post by porpoisely »

NULL can mean and be different things in different domains of computer science. NULL in the database world isn't the same thing in the programming world. In the programming world, null is a result of the system architecture, systems programming, etc. In SQL, NULL is a result "lack of data". There have been debates on whether there should be different types of NULL. A NULL type for "data that is available but we don't have it yet" - like car make and model for a car owner. A NULL type for "data that does not apply" - like car make and model for an adult who doesn't own a car. A NULL type for "data that never applies" - like car make and model for a child. Then you get into the philosophical debate on whether a NULL can ever equal a NULL. Does it even make sense to even think of NULL in terms of equality. How can an unknown entity ever equal another equality? But what if you are just asking "are they both unknown"? Then you probably can think of two NULLs as "equal".

In higher level programming, the consensus seems to be the less nulls the better. Which is why languages like C++, C#, etc are introducing Option-like syntax ( mostly to accommodate the database world and their NULLs ).

NULL exists to solve particular problems in computer science. It can also cause a lot of problems. You can argue it's the best solution and worst mistake depending on the situation.

Re: NULL: The worst mistake of computer science? (2015)

#152

Post by bfrydl »

ummonk wrote: post #131
cyphar wrote: post #124

Earlier quoted context omitted.

> another thing that's frequently criticised by those who don't actually understand how computers work and try to "solve" problems by merely slathering everything in thicker and thicker layers of leaky abstraction I think that you're being quite unkind. Haskell's Maybe type and Rust's Option types are very far from "leaky abstractions" and were developed by people who definitely understand how computers work. In fact…

Well, a better comparison would be Typescript with strict null type checking enabled. You just use algebraic data types to specify whether a value can be null.

`Option` in Rust is basically identical to `T | null` in TypeScript.

Re: NULL: The worst mistake of computer science? (2015)

#153

Post by [deleted] »

captainmuon wrote: post #107

I've made my peace with null. Null is basically just an implicit assert(valid(x)) before every time you call a method on x. Similary, I think of exceptions as explicit "crash-unless-caught" commands. If you write your program with the "blow up early" mentality anway, or use static checking tools and a bit of discipline, I've found that null looses it's terror.

[deleted]

Re: NULL: The worst mistake of computer science? (2015)

#154

Post by da_chicken »

cmrdporcupine wrote: post #81

NULL in 'relational' databases in particular is a disaster. Or at least according to the notorious Fabian Pascal. http://www.dbdebunk.com/2017/04/null-value-is-contradiction-... Codd never proposed it in his original relational model. For good reason.

Nonsense.

First of all, Codd's early work didn't propose it because Codd's propositions were idyllic and rooted in mathematics and not software engineering. In Codd's world, you would never create a FirstName/GivenName and a LastName/Surname field. You'd just create a Name field. The fact that you might want to sort by last name or the fact that someone named "Alice Taylor Smith" has a surname of "Smith" while "Robert Taylor Smith" has a surname of "Taylor Smith" isn't relevant. In Codd's world, you'd just define Name as a Name type, and the Name type itself would know everything about the entire domain of names. It would be about as complicated as working with a DATETIME. The same would be true for an Address type. Such a type would support both Western and Japanese addresses, which are wildly different. Codd doesn't need NULL because he has complex types which perfectly and comprehensively represent their domains. That's not realistic. Parsing Names and Addresses for even a single culture is notoriously difficult.

Second of all, Codd's later major work, The Relational Model for Database Management, includes his Twelve Rules (numbered 0 to 12) for database design in order for a DBMS to be considered relational[0]. Rule number 3 is:

> Rule 3: Systematic treatment of null values:

> Null values (distinct from the empty character string or a string of blank characters and distinct from zero or any other number) are supported in fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type.

So Codd clearly thought that nulls were essential.

[0]: https://en.wikipedia.org/wiki/Codd%27s_12_rules

Re: NULL: The worst mistake of computer science? (2015)

#155

Post by bfrydl »

rusk wrote: post #92
Dylan16807 wrote: post #42

Earlier quoted context omitted.

> Or what do you even do about it? All you need is a list of what width each type is. > A handful of solutions already exist: - Use a higher-level language - Java It doesn't require being "higher level". If anything it pushes code to a slightly lower level.

> All you need is a list of what width each type is. This is exactly the kind of minutiae that GP was bemoaning. > If anything it pushes code to a slightly lower level Yeah by way of higher-level abstractions ...

> This is exactly the kind of minutiae that GP was bemoaning.

How is this “minutiae”? You should always know the possible range of a numeric variable or field when you create it, so why not just write what size it is? In Rust the main numeric types look like this: i32, u64, u8. You just pick the one you want.

Re: NULL: The worst mistake of computer science? (2015)

#156

Post by tjoff »

flipgimble wrote: post #125
userbinator wrote: post #110

To someone who has been using Asm and C for decades, these arguments just make no sense. Reading this article reminds me of the arguments against pointers, another thing that's frequently criticised by those who don't actually understand how computers work and try to "solve" problems by merely slathering everything in thicker and thicker layers of leaky abstraction. It's not far from "goto considered harmful" either.…

If your whole world is asm and C, then I take it you don't care much about type systems. Bless your heart, you lonely programmer of ephemeral software, may you be employed gainfully fixing your own bugs for decades. The saltiness if mostly for entertainment, please don't take too much offense. For everyone else working at a level of complexity where mistakes are inevitable and costly, types are an essential bicycle f…

Not sure what world you are from. But here on earth apparently garbage collection and javascript is all the rage ;)

Issues with null doesn't even register in comparison.

Re: NULL: The worst mistake of computer science? (2015)

#157

Post by kiriakasis »

TickleSteve wrote: post #112
userbinator wrote: post #110

To someone who has been using Asm and C for decades, these arguments just make no sense. Reading this article reminds me of the arguments against pointers, another thing that's frequently criticised by those who don't actually understand how computers work and try to "solve" problems by merely slathering everything in thicker and thicker layers of leaky abstraction. It's not far from "goto considered harmful" either.…

Completely agree, this is CS theory gone off the deep end...

Cannot understand this position... a non-nullable pointer is pretty much just a normal pointer but the compiler checks if you have tested for null. In rust (and I believe Swift) optional references also have the same size as normal pointer. In some version of non-nullables you only need checks for dereferencing and not for other handling.

Re: NULL: The worst mistake of computer science? (2015)

#158

Post by Nullabillity »

laichzeit0 wrote: post #44

So how does NaN in Python and NA in R relate to NULL? I know Python has the None type, but it's not the same as NaN. One of the most annoying things in Numpy is that there is no way to indicate that an integer value is "missing", similar to NaN for floats. In R both integers and strings can be NA (if I remember correctly). So for numeric types at least, there is definitely the need to somehow indicate that a value is…

NaN is not the same as None/null, and using it that way is asking for bugs.

None/null is for missing/unknown values (which may be a reasonable thing in your domain), while NaN is for the result of an illegal/undefined operation (which is definitely a bug, such as division by 0).

Re: NULL: The worst mistake of computer science? (2015)

#159

Post by kiriakasis »

kiriakasis wrote: post #157
TickleSteve wrote: post #112

Earlier quoted context omitted.

Completely agree, this is CS theory gone off the deep end...

Cannot understand this position... a non-nullable pointer is pretty much just a normal pointer but the compiler checks if you have tested for null. In rust (and I believe Swift) optional references also have the same size as normal pointer. In some version of non-nullables you only need checks for dereferencing and not for other handling.

I might have confused optionality and non-nullability...

Re: NULL: The worst mistake of computer science? (2015)

#160

Post by sharpercoder »

Yet `Maybe | Option | ...` is not an option (pun intended), as Rich Hickey explains here: https://www.youtube.com/watch?v=YR5WdGrpoug.

In effect, his argument is: 1) You have `public X Do(Y y)` changed into `public X Do(Option y)`. This will break your API. 2) You have `public X Do(Y y)` changed into `Option Do(Y y)`. This will break your API.

Thus, do not use Option or equivalent in your API's. Only use a language-supported construct such as C#8's upcoming `string?` and `string`.

Post reply on HN