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

331–340 of 377 posts

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

#331

Post by AnimalMuppet »

giornogiovanna wrote: post #247
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.

Zero's behavior is totally consistent with the other numbers, though - it doesn't break associativity, commutativity, or any of the other stuff you'd expect. On the other hand, NULL takes every type I've ever written and adds an instance whose behavior with every function is, at best, to crash my program, and at worst, completely undefined. Its behavior is not at all consistent with the other instances.

0 breaks division, though...

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

#332

Post by smadge »

dpcx wrote: post #311
nayuki wrote: post #198

Earlier quoted context omitted.

NULL in SQL really isn't great. For one, nullable table columns is a bad default, and you have to explicitly write out "NOT NULL" to avoid this behavior. I'd say that 90% of the time I want not-null table columns, and only 10% of the time do I want a nullable column. Secondly, NULL has weird arithmetic. It turns out that NULL=NULL is false, and NULL NULL is also false. (This is unlike C/Java/Python/etc. by the way.)…

I can get behind your first statement. Having NULLable as a default on columns is "probably" a bad idea. I'm not so sure I can agree with the other two. NULL NULL (and NULL=NULL) both return false for a very simple reason: truly missing data _can't_ be equal to anything, including missing data... Because it's missing. You cannot with certainty say that value1 is or is not equal to each other. For the third point... W…

For example, if it were the case that NULL = NULL, really counterintuitive stuff would happen on joins because a null cell would match with every other null cell you are joining on:

        person
   name      home_address
   ---------------------------
   "Alice"   NULL
   "Bob"     "123 Jump Street"

                letter
   return_address     description
   ----------------------------------
   NULL               "Ransom Letter"
   NULL               "Spy Document"
   "123 Jump Street"  "Hello, from Bob"
Then

    SELECT name, description FROM person INNER JOIN letter ON home_address = return_address
would return

    name     description
    ------------
    "Alice"  "Ransom Letter"
    "Alice"  "Anonymous Spy Document"
    "Bob"    "Hello from Bob"
So now Alice is associated with a bunch of letters she didn't necessarily write because she doesn't have a home address.

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

#333

Post by CuriousSkeptic »

ArchTypical wrote: post #276
yxhuvud wrote: post #271

Earlier quoted context omitted.

> NULL is a value that inhabits every type. Not in all type systems. Particularly, type systems which has union types may chose to simply create a separate type for NULL. There are also variants that have separate NULL types for different base types, which also invalidate your claim.

> Not in all type systems I think this is inaccurate. We are talking about computer science, which is important and a constraint around the general type theory. A type system is different than how you interact with it, so dispensing with language-specific symbolic representation further normalizes the discussion. Fundamentally, a (computer science) type is a representation of binary, for the most part, data. That rep…

I’m not sure I buy this definition of type even in theory.

From a category theoretic point of view a type would be nothing more then the constraints on how terms may be composed.

Either you simply view types as as objects in some category or, perhaps a bit more interesting, as a functor. See f.ex http://noamz.org/papers/funts.pdf

Or rather it seems to be a common theme in language design to conflate these two notions of types, and we should probably stop doing that.

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

#334

Post by cyphar »

jchw wrote: post #273
cyphar wrote: post #229

Earlier quoted context omitted.

Don't get me wrong, Go does nil a lot better than some other languages (being able to call methods on a nil is sometimes a good thing depending on how your methods handle it -- most methods don't handle it well at all). The fact that even most map operations (access and deletion) also "just work" is really useful. But I think you're over-selling the zero values feature of Go. It is very rare to see third-party librar…

I'm not overselling zero values in Go. Simply try to envision the cascading consequences on the language if you removed the zero values; no existing Go code would work, and I think the language would need to shift so much that even hello world couldn't be automatically translated to such a language. All to prevent a single type of runtime error among many, one that Go developers are not complaining about the way that…

Nobody is arguing that Go should have algebraic types and ditch zero values, so I don't know why you're harping on this point. Now -- it would be somewhat nice because errors would be much more reasonable to handle (the new "check" proposal is okay but still quite flawed) but you're right that it would either be far too complicated or old code wouldn't work anymore. Go has already made it's bed when it comes to nil values, but that doesn't mean that all new languages should follow suit -- because Go's nil handling isn't all sunshine and roses (nil interfaces -- for obvious reasons -- cause NPEs).

As I've said, Go does nil basically as well as you can without having algebraic types. But given the semi-anecdotal evidence that I've definitely seen my fair share of NPEs in production Go code in the past 5 years, it's clear that it's not sufficient.

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

#335

Post by bytematic »

porpoisely wrote: post #151

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…

NULL should mean an intended lack of data. Undefined should be unintended.

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

#337

Post by knocte »

jstimpfle wrote: post #65
knocte wrote: post #31

Earlier quoted context omitted.

Have you ever dealt with the Maybe(Haskell)/Option(F#) types? If not, then you don't understand what's wrong with NULL and how to easily avoid it without much work.

I find Maybe a bad idea. It forces me to write denormalized code when I know that something is not NULL. It's not possible to specify this knowledge as a data structure since data structures are static but context is dynamic. I much prefer the simple NULL sentinel that blows up like an assertion when I made a mistake. That said, there's not very often a need for NULL at all if you structure the code correctly.

> I much prefer the simple NULL sentinel that blows up like an assertion when I made a mistake

Are you nuts? I prefer the compiler gives me an error instead of blowing up in production.

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

#338

Post by giornogiovanna »

yxhuvud wrote: post #271
giornogiovanna wrote: post #228

Earlier quoted context omitted.

NULL isn't the uninhabited type, that's the bottom type. NULL is a value that inhabits every type.

> NULL is a value that inhabits every type. Not in all type systems. Particularly, type systems which has union types may chose to simply create a separate type for NULL. There are also variants that have separate NULL types for different base types, which also invalidate your claim.

Sorry, I was talking specifically about C++ and friends, which is the set of languages for which NULL is considered problematic. For the languages you're talking about, NULL is much more well-behaved, so there's less reason to complain.

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

#339

Post by Twisell »

nostrademons wrote: post #323
Twisell wrote: post #282

Earlier quoted context omitted.

NULL in databases have many properties that save a shitload of coding time and help write more secure code. To cite only one of theses useful properties NULL automatically propagate through all operations and aggregations.

Is that the behavior you actually want, though? In many cases "this value is explicitly unknown" has dramatically different semantics from "the computation that produced this value had an unexpected NULL input", and if you interpret the latter as the former, you've likely just corrupted your data. Monadic Maybe (in higher-level languages like Haskell or Rust) has the semantics you describe, but the advantage that you…

Yes of course when I deal with data if I compute an average of over 20 record and one have a NULL value I want to know that something is wrong with that specific operation. Silently returning something wrong would be really bad. Crashing whole query would be anoying as well because if you compute 3Billion aggregates at the same time and only 0.1% return NULL you might want to filter them out instead of doing nothing at all or correcting input.

Of course all of this would be feasible with an arbitrary no data value, but you’d have to basically rewrite all propagation functions that are built in with NULL. As a DB admin I would consider a database without NULL handling as utterly flawed.

In fact with modern SQL database you often get twice the fun because there is a second propagating special value for numeric type called NaN (not a number) to further distinguish lake of data from invalid data if need be!

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

#340

Post by fmjrey »

kybernetikos wrote: post #234
based2 wrote: post #60

Earlier quoted context omitted.

Maybe Not - Rich Hickey (clojure), 29 nov. 2018 https://www.youtube.com/watch?v=YR5WdGrpoug https://dotty.epfl.ch/docs/reference/intersection-types.html

Yes, 'maybe not' is very relevant to this discussion, but few people seem to agree with my understanding of what he says about the right solution: Optionality doesn't fit in the type system / schema, because it's context dependent. For some functions, one subset of the data is needed, for others a different subset. Trying to mash it into the type system / schema is just fundamentally misguided.

Yes, he's rather explicit in saying Maybe is a poor tool. I'll have to watch the talk a second time to be sure, but I'm not sure he proposes any solution at the level of type systems. Not using Maybe or using Union is not what he is advocating. For him (and me too) types are the wrong thing to put data in because, among other things, it forces you back into PLOP. His point is to remove entirely the need to fill slots with nothing. Obviously the talk is more about specs than types. While tactfully avoiding the debate around types, he's still starting the talk with types to help those that are only there to decomplect their thinking.
Post reply on HN