Live data from Hacker News

What is wrong with NULL

lucidchart.com

11–20 of 147 posts

Re: What is wrong with NULL

#11
NULL is okay as long as you pretend it doesn't exist. I mean, in these languages, uninitialized variables exist at some point (fields start uninitialized in constructor bodies, etc), and that's why there's null, instead of defining them with some garbage value that has undefined behavior. But the right solution for users is to just pretend that it can't exist, and that uninitialized variables have a garbage value.

Of course, that's idealistic, most languages don't have some Option type without a performance penalty, and pre-existing libraries exist. (Usually you should design around needing Option too.)

The right language design decision for these languages (managed languages like Java) might have been to make uninitialized references have a garbage value that reliably throws an exception when used (i.e. null) -- you can copy the reference and pass it around, but you can't compare it for equality and any attempt to inspect its value results in an exception.

Re: What is wrong with NULL

#12
post #4

For statically typed languages this is definitely an issue, but for dynamic languages less so. In Python, I wouldn't use an optional value, x is None seems to be just fine. I'm still waiting for std::optional for C++.

It's only not an issue in dynamic languages in the sense that you have the same issue anyway without null because you have no type safety at all.

Re: What is wrong with NULL

#13

The mistake is an unsafe null: making every object type carry a value in its domain which says "Oops, though my type says I'm a Foobar, I'm not actually an object, la la la! Have a free exception on me, in your face!" Lisp's NIL is brilliant. It's in its own type, the null type! And it's the only instance of that type. No other type has a null instance. Null references in the language simply reflect the tension betwe…

NIL is fine ... as long as you have some container for the opposite.

There should be a way to express Maybe>, aka an optional optional value.

The Store article in the article is an example of when this would be needed: a cache optionally has an optional phone number for a person.

If Lisp has the equivalent of Maybe> (perhaps a singleton list of a singleton list?), then the optionality is composable. Otherwise, the optionality is not really composable, and you will have problems.

Re: What is wrong with NULL

#14

The mistake is an unsafe null: making every object type carry a value in its domain which says "Oops, though my type says I'm a Foobar, I'm not actually an object, la la la! Have a free exception on me, in your face!" Lisp's NIL is brilliant. It's in its own type, the null type! And it's the only instance of that type. No other type has a null instance. Null references in the language simply reflect the tension betwe…

ruby nil is similar in that it's an instance of the Nil class. though, calling a method on nil that isn't there is a common error. I like how swift handles things. strong type system that makes it a little painful to do things unsafely. guarantees some things that make it a powerful and more safe language than objective c. I think they lost a few dynamic patterns though in the transition but that's just what i recall…

I agree, Swift's optionals are really great. But I also like Objective-C's nil: you can send messages to it and it won't do anything. That too solves a ton of problems with NULL.

Re: What is wrong with NULL

#15
post #6
post #3

This mistake is fixed in Haskell.

That's mentioned in the article. It gives Haskell's null handling a score of 5 stars, along with OCaml and Standard ML. EDIT: The articles definition of 5 star null handling is "Does not have NULL." :)

[deleted]

Re: What is wrong with NULL

#17
post #4

For statically typed languages this is definitely an issue, but for dynamic languages less so. In Python, I wouldn't use an optional value, x is None seems to be just fine. I'm still waiting for std::optional for C++.

boost::optional and call it a day.

http://www.boost.org/doc/libs/1_59_0/libs/optional/doc/html/...

Re: What is wrong with NULL

#18
post #5

The mistake is an unsafe null: making every object type carry a value in its domain which says "Oops, though my type says I'm a Foobar, I'm not actually an object, la la la! Have a free exception on me, in your face!" Lisp's NIL is brilliant. It's in its own type, the null type! And it's the only instance of that type. No other type has a null instance. Null references in the language simply reflect the tension betwe…

nil really isn't any better than null-pointers/references. In the end, you need to check for nil-ness anyway, and there's no mechanism that will help you ensure the check is made. Algebraic data types with pattern matching, that is, Maybe/option is really the proper solution.

NIL is objectively, unquestionably safer than a raw machine pointer that is null. It's a first class object with a type; a symbol with a name, and instance of the NULL class and so on.

Of course, if you want to use NIL as a character string or floating-point value, there is an exception. That's your fault: you needed a way to indicate "I don't have a string here" or "I don't have a number", and you bungled the logic.

Re: What is wrong with NULL

#19
I agree with the article, yet, despite what the table at the end suggest I got significantly less problems with NullPointerExceptions since I switched from Java to C++ for my work.

C++ has an inbuilt alternative: references. References in conjunction with the Null Object Pattern have solved my problems until now.

References simply cannot be null -- and I generally do not use raw pointers in my code unless some library forces me to.

Re: What is wrong with NULL

#20
post #3

This mistake is fixed in Haskell.

The star chart at the end of the article lists Haskell, OCaml, and Standard ML as languages that omit NULL. (Where no null means five stars, of course.)

I think Rust should also have 5 stars in this comparison as it forbids null pointers.

Post reply on HN