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

What is wrong with NULL

lucidchart.com

Post reply on HN
Print view View original

141–147 of 147 posts

Re: What is wrong with NULL

#141

Post by bcheung »

dragonwriter wrote: post #138
bcheung wrote: post #125

Earlier quoted context omitted.

You're conflating the meaning of NULL in that case. That's not a problem of NULL, you're using NULL to represent multiple different things. You can use exceptions to handle that scenario. cache = {} getFromCache = (key) -> return cache[key] if cache[key]? throw "not found" doSomethingWithValue = (key) -> try value = getFromCache(key) catch value = getValueFromNonCache(key) return _doSomethingWith(value)

You can, but resorting to exceptions for what may not be an exceptional circumstance is a workaround for not being able to think of a way to communicate results correctly through the return value. Which illustrates the need here as effectively as the ambiguous use of null in the article.

You don't like exceptions so your solution is creating an instance of a specialized class that holds my variable that has a method that acts like an "if" statement that I need to pass an anonymous function to that receives the value I already have?

Re: What is wrong with NULL

#142

Post by azth »

dradtke wrote: post #67
geofft wrote: post #34

It's worth noting that having a NULL, somewhere, is not so much a problem as forcing types to have a NULL. In this respect, e.g. Python and Rust both get it right: while Python has a None, and Rust has std::ptr::null(), an object that is a string cannot be any of those, because those are different types (NoneType and raw pointer, respectively). C's problem is that a string could be null, and there's no syntax for a n…

I also think that Go did pretty well to fix NULL. It didn't get rid of it completely, but it (nil) is only valid for pointers and interfaces, so it's not possible to use it in place of a string, integer, etc. It's not as bulletproof as Rust or Haskell, but something as simple as disallowing nil strings can make a world of difference.

Go didn't really fix anything when it comes to NULL. The defense the Go authors gave to keep it around was laughable.

Re: What is wrong with NULL

#143

Post by 15155 »

xamuel wrote: post #54

>NULL is a terrible design flaw, one that continues to cause constant, immeasurable pain Exaggeration much? Certainly not "the worst mistake of computer science". IPv4 is much worse, just for one example. NULL isn't even visible to end-users, many mistakes in CS are quite visible and really impact non-programmers' lives. NULL is just the color of the wallpaper in the engine room.

> IPv4 is much worse

How is it worse, technically, beyond a constrained keyspace?

IPv4 is an unfortunate, entrenched reality.

NULL doesn't need to be, and isn't, in some ecosystems.

Re: What is wrong with NULL

#144

Post by ant6n »

astral303 wrote: post #17
ant6n wrote: 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/...

Well, for now we're using something like

    template
    using std::optional = boost::optional;

Re: What is wrong with NULL

#146

Post by ursus_bonum »

paulddraper wrote: post #116
ursus_bonum wrote: post #115

I was with the article until the part about null terminators on strings. Null terminators are nothing like a NULL reference. We could just as easily have dollar-sign-terminated strings and no one would be conflating that idea with the concept of NULL. Also, NULL pointers are the least problematic type of pointer if you ask me. If a pointer is NULL it is not likely a security problem, and certainly not on its own. Acc…

To quote the article: > This is a bit different than the other examples, as there are no pointers or references. But the idea of a value that is not a value is still present, in the form of a char that is not a char. It has nothing to do with the similarity in name (NULL / NUL). As you said, it could be terminated with $. The similarity is that they are both sentinel values. NULL is a sentinel for types; NUL is a sen…

I know the author claims that there's a meaningful similarity beyond the names. But that's where I disagree.

I get that a NULL pointer is in some meaningful way not a pointer. Because it literally isn't pointing to anything. It is not the case that NUL is a char that is not a char. NUL is a perfectly good char. Some functions treat it specially, but other than that it's just a regular char.

Even the sentinels similarity is quite weak. NULL is a sentinel that indicates "no valid object" whereas NUL is a sentinel that indicates the end of a perfectly valid object. Notice how we're not having this discussion about '\n' or the whitespace chars in general, even though they're also treated as sentinels by some functions.

Re: What is wrong with NULL

#147

Post by lmm »

kazinator wrote: post #65
lmm wrote: post #12

Earlier quoted context omitted.

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.

You have a ton of type safety in Python, which is one reason why Python programmers are cranking out large bodies of working code representing all kinds of applications that Just Work. "No type safety at all" means you can misuse a value of one type using an operation that is appropriate for a different type, and some nonsensical behavior silently occurs (or perhaps some nonportable behavior that you sneakily intende…

Python has some safety checks that are missing in other languages, and this is a good thing. But it's misleading to call them "type safety", because they aren't connected to anything that can be meaningfully called a type system - all those checks happen at the value level (e.g. you can make a particular integer amenable to string_length, by monkeypatching the relevant methods onto it).
Post reply on HN