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

101–110 of 147 posts

Re: What is wrong with NULL

#101

Post by _Ogre »

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.

It is vastly more destructive than IP v4. This affects end users directly, every single day. The number of times applications have crashed due to NULL related errors is probably in the tens or maybe hundreds of billions. Each time is an interruption of people's work and in some cases it destroys hours of work.

Re: What is wrong with NULL

#102

Post by pmelendez »

mcguire wrote: post #40
kazinator wrote: post #18

Earlier quoted context omitted.

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.

" 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. " And there's the rub: Just like NULL. And, in fact, that's the major problem with NULL. NIL is better than NULL, but not by much.

> NIL is better than NULL, but not by much.

NIL is probably the best you can get once you realize that the empty state is unavoidable. My personal problem with this kind of rant is that is full of hate but lacking in general in alternatives to represent an empty state.

The author mention optional types as an alternative. That's fine for parameters but that doesn't cover when you need to have an empty reference.

Re: What is wrong with NULL

#103

Post by dragonwriter »

bcheung wrote: post #97

Here is what is wrong with Option. option.ifPresent(x -> System.out.println(x)); So instead of just checking to see if it is NULL you want me to create 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? Why not just do: x && System.out.println(x) or: System.out.println(x) if x…

> The one benefit I see is type safety but it is certainly not easier

Type safety is one benefit, but composability is an important benefit (as, you know, is extensively discussed in the source article.)

Re: What is wrong with NULL

#104

Post by arielby »

Strilanc wrote: post #83
arielby wrote: post #74

NUL-terminated strings aren't that bad: * unlike Pascal-style strings, they can be usefully sliced, especially if you can modify them strtok-style. * unlike (ptr,len) "Modern C buffers"/Rust-style strings, references to them are pointer-sized, and they can be used as a serialization format. This makes the kind of application that is based on cutting pieces of a string and passing them around a good measure faster, es…

> unlike Pascal-style strings, they can be usefully sliced, especially if you can modify them strtok-style. Slicing Pascal-style strings is also easy and constant-time: just track the buffer, offset, and length of the slice of characters you want. Java used to do it implicitly whenever you called `substring`. > unlike (ptr,len) "Modern C buffers"/Rust-style strings, references to them are pointer-sized, and they can…

> Slicing Pascal-style strings is also easy and constant-time: just track the buffer, offset, and length of the slice of characters you want. Java used to do it implicitly whenever you called `substring`.

That's just coercing into a "modern C buffer" and slicing it. It has the disadvantage that coercion is not equality or subtyping - i.e. you will have to do lots of wrappings and unwrappings in mixed code.

> Every C method that takes a character buffer either a) has a corresponding length parameter or b) is avoided because of the security risks. In practice this means that C also stores the length information, just on the side instead of combined into a struct with the buffer.

You are surely talking about the buffer's capacity, not the string's length. These are distinct concepts. Anyway, functions that only read strings, and structs that only store them read-only, aren't interested in the capacity of any buffer.

Anyway, C strings aren't responsible for the fixed-size buffers of Cold War-era code - that code uses fixed-size buffers for everything. Their main claim to fame is their popularity in parsing code, which is edge-case- and bug-prone.

Re: What is wrong with NULL

#105

Post by arielby »

tines wrote: post #84
arielby wrote: post #74

NUL-terminated strings aren't that bad: * unlike Pascal-style strings, they can be usefully sliced, especially if you can modify them strtok-style. * unlike (ptr,len) "Modern C buffers"/Rust-style strings, references to them are pointer-sized, and they can be used as a serialization format. This makes the kind of application that is based on cutting pieces of a string and passing them around a good measure faster, es…

std::string isn't reference-counted in a conforming implementation (that doesn't do atomic ops just for fun).

well C++11 strings are just "reallocate when you look at them funny". Or you use shared_ptr and are back to square 1.

Re: What is wrong with NULL

#106

Post by justthistime_ »

bcheung wrote: post #97

Here is what is wrong with Option. option.ifPresent(x -> System.out.println(x)); So instead of just checking to see if it is NULL you want me to create 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? Why not just do: x && System.out.println(x) or: System.out.println(x) if x…

I think your failure to use Option correctly cannot be blamed on Option alone, given that many people use it successfully.

Re: What is wrong with NULL

#107

Post by dragonwriter »

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.

> NULL isn't even visible to end-users

In the same way HIV isn't visible; sure, the cause isn't visible to most people, but the adverse effects are.

Re: What is wrong with NULL

#108

Post by greggyb »

No mention of SQL, where NULL's behavior in the standard can lead to some quirky behavior that I've seen bite back in poorly designed systems. I've included a brief illustrative example. The expectation is that the UNION of two WHERE clauses, one using IN and the other using NOT IN should be equivalent to the same SELECT without any WHERE:

    WITH NullCTE AS
        (SELECT a.*
        FROM
            (VALUES (NULL), (1), (2)) a (Number)
        )
    ,One AS
        (SELECT Number = 1)

    SELECT *
    FROM NullCTE nc
    WHERE nc.Number NOT IN
        (SELECT Number
        FROM One)
    UNION
    SELECT *
    FROM NullCTE nc
    WHERE nc.Number IN
        (SELECT Number
        FROM One)
Running this will give you back a two-row table, containing 1 and 2, but the NULL is excluded from both WHERE conditions.

The naive expectation is that the combination of a condition and the NOT of that condition cover all possible circumstances.

Re: What is wrong with NULL

#109

Post by bcoates »

lmartel wrote: post #75
bcoates wrote: post #49

Earlier quoted context omitted.

Not completely. non-nullable by default is nice, ignoring possible nulls is nice, but Haskell's Maybe still suffers from premature generality by conflating all forms of absence. A 'Maybe T' is fundamentally, context-sensitively, not equivalent to any other 'Maybe T' in the same way all 'T's are. This is bad. edit: carsongross beat me to what I'm talking about with a better explanation: https://news.ycombinator.com/it…

Can't you just handle this with something like `Either ErrCode T`? (And if not, please do explain why!)

You can, but the existence (and use in libraries!) of Maybe is still bad for the same reason having 'null' is bad. It's an anti-feature that would enrich the language by not existing.

Re: What is wrong with NULL

#110

Post by bcheung »

ffn wrote: post #92

lol the null / undefined issue in javascript is further exacerbated by the fact there is no int type and everything is just a "number".... yet the number 0 is still treated the same as null/undefined by js special forms like "if" and "==". This is particularly hilarious because it leads to some null-check bugs like: if ( user.getScrollPosition() ) { whatever(); } else { die(); } 99% of the time, the code would be fin…

Why would you check the value instead of the presence of the value? Rookie mistake.

user.getScrollPostion() != undefined

or in CoffeeScript just use:

user.getScrollPosition()?

Arrays have various types of ints and floats of various word lengths and signs.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...

Post reply on HN