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

41–50 of 377 posts

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

#41

Post by cyphar »

jchw wrote: post #23

This tidbit gets a ton of mileage but I think it's overrated. There are a lot of unsafe shortcuts we take to get better ergonomics and NULL is one of them. I think it's a bit unlikely we'll fully get rid of null, but we can get rid of some of the pitfalls. TypeScript for example pretty much fixes the problem, by enforcing you check for null when needed, though TypeScript takes a handful of other soundness shortcuts.…

I would recommend looking Haskell's Maybe and Rust's Option type to get a better idea of how this can be solved -- and how this article isn't really overrated (just commonly misunderstood).

They allow for explicit NULL-ness (which is a necessary concept) without falling into the trap of making everything implicitly possibly NULL. And when NULL-ness is explicit you are then forced to explicitly handle it in order for your program to compile (in the case of Haskell and Rust).

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

#42

Post by Dylan16807 »

rusk wrote: post #33
saagarjha wrote: post #13

Earlier quoted context omitted.

> null terminated strings This is mentioned. > machine dependent integer widths What exactly do you dislike about this?

> What exactly do you dislike about this? Or what do you even do about it? A handful of solutions already exist: - Use a higher-level language - Java

> 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.

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

#43

Post by paulhilbert »

rusk wrote: post #30
BlackFly wrote: post #21

Earlier quoted context omitted.

I can assure you that the number 0 in 0℃ is a number and not the absence of temperature. But other than that, excellent point about the wonkiness of special values.

> the number 0 in 0℃ is a number If we're going to get pedantic ... 0 in this case is an offset . The number is what's behind it: The point at which water freezes (aka 273 °K). In this case 0 indicates the absence of any offset .

I wonder why this gets downvoted - seems pretty reasonable to me...

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

#44

Post by laichzeit0 »

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 "missing".

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

#45

Post by TheOtherHobbes »

skgoa wrote: post #9

I wonder whether the author also hates the 0 and 1 elements of natural numbers. Since they have the same flaw of having weird, special semantics that all other other numbers don't share. In fact 0 is not even a number, but a placeholder for the concept of the absence of a number. Just like NULL.

That's exactly the point the author isn't making - which is that there should be an explicit distinction between Exists But Holds No Value and Does Not Exist.

0 is neither. It's clearly a number which can be used in arithmetic and defines a specific integer quantity. (Unless you think 0 is identical to NaN...)

The problem is that in some languages it's used for either or both of the above logical definitions, when it shouldn't be used for either.

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

#46

Post by pjc50 »

skgoa wrote: post #9

I wonder whether the author also hates the 0 and 1 elements of natural numbers. Since they have the same flaw of having weird, special semantics that all other other numbers don't share. In fact 0 is not even a number, but a placeholder for the concept of the absence of a number. Just like NULL.

They have all the same semantics as regular numbers? They all derive naturally from the Peano axioms.

You may be thinking of NaN.

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

#47

Post by pjc50 »

paulhilbert wrote: post #43
rusk wrote: post #30

Earlier quoted context omitted.

> the number 0 in 0℃ is a number If we're going to get pedantic ... 0 in this case is an offset . The number is what's behind it: The point at which water freezes (aka 273 °K). In this case 0 indicates the absence of any offset .

I wonder why this gets downvoted - seems pretty reasonable to me...

It's a rather odd argument and it falls apart as soon as you ask about 0 Kelvin.

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

#48

Post by pjc50 »

thwy12321 wrote: post #4

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike" When d…

Prevention of user error is a good design principle: https://justuxdesign.com/blog/poka-yoke-design-the-art-of-er...

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

#49

Post by pjc50 »

saagarjha wrote: post #13
ohazi wrote: post #8

Other candidates: - null terminated strings - machine dependent integer widths

> null terminated strings This is mentioned. > machine dependent integer widths What exactly do you dislike about this?

It's an area of the language which can produce "works on my machine" bugs?

It becomes less important as we all converge on 64-bit machines with 32-bit "int" types, but it's still a monumental pain point for portability.

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

#50

Post by pdkl95 »

> NULL is a value that is not a value. And that’s a problem.

The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Option can still be NULL ("None" in rust), wrapping NULL in a struct doesn't provide any safety. The safety of Option wrapper types is from the other language features (like rust's "match") and a stricter compiler that forces the programmer to write the NULL check.

NULL would be fine if C required you to write this:

    foo_t *maybe_get_foo(/*...*/) {
        if (/*foo_is_available*/) {
            return foo;
        } else {
           return NULL;
        }
    }

    foo_t *f = maybe_get_foo();
    if (!f) { /*...*/ }   // REQUIRED or compile error
    do_something(f->bar); // only allowed after NULL check
Obviously implementing that requirement would be difficult in C. Languages like Rust were designed with enforcement features (match + None, much stronger type/borrow checking), but lets your have "a value that is not a value".
Post reply on HN