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

101–110 of 377 posts

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

#101

Post by [deleted] »

peteretep wrote: post #97
thaumasiotes wrote: post #93

Earlier quoted context omitted.

It's already there, if you know enough to recognize it: > The degree Celsius (°C) can refer to a specific temperature on the Celsius scale or a unit to indicate a difference between two temperatures In other words, you can add a quantity of °C to a temperature value and you'll get another temperature value. But you can't measure a temperature in °C. Compare how, for example, the python datetime library uses a datetim…

> It's already there, if you know enough to recognize it "As an SI derived unit", "or a unit to indicate", "the unit was called" Three mentions of it being a unit in the first paragraph, alone. I understand the point being made; the conclusion that "celsius is not a unit" is bogus, however, by any common definition, including NIST's. In a now-deleted comment, you linked to a Wikipedia page on Dimensional Analysis, wh…

[deleted]

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

#102

Post by fmjrey »

based2 wrote: post #60
AJRF wrote: post #28

Do people generally agree that Java Optional == Scala Maybe / Haskell's Maybe? Java's Optional seems fundamentally flawed in that Java allows any reference to hold a null value and Optional can still throw a NPE when calling isPresent on it so it still gives people a footgun.

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 I was going to mention that video in which Rich makes an important point in my opinion: database tables, or objects, or structs, still live within the Place Oriented Programming (PLOP) mindset. That mindset was born in a time where disk and RAM were the expensive resource therefore update-in-place was the default. I insist on the "in-place": you need to know where something is so you can update it. The downside of PLOP is that if you have no value for one of the slot in your generic form (be it a table, object or struct) then what can you put there?

The alternative is to use data shapes that do not require something to be in a certain place. Hence the use of maps as the most basic data shape: you either have an entry in it, or you don't, no need to have a null entry. Expanding that thinking to databases, and you realise tables is not the right aggregate, instead you need to go one level down to something that datomic calls datom, or RDF calls a fact.

To summarise, PLOP forms that package together a set of slots to be filled magnify the issue of NULL/null/nil. Instead make the slot your primary unit of composition and make sure you use aggregation of slots that does not force you to have slots filled with a null value when there is no value in the first place.

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

#103

Post by jstimpfle »

virtualized wrote: post #61
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.…

It's the worst mistake because it made you believe that its atrocious ergonomics are actually superior to more sensible solutions. Implicit nullability doesn't really save you any null checks. It just makes it possible to forget necessary checks. It was fine to design a language with nullable pointers in the 70s. It's unacceptable nowadays. nil in Go is a major mistake.

> Implicit nullability doesn't really save you any null checks.

It sort of does, because explicit nullability forces you to do many redundant null checks when you actually knew that something could not possibly be null.

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

#104

Post by [deleted] »

axilmar wrote: post #87

NULL is certainly a mistake, but even more of a mistake is not allowing distinct states in variables. NULL is just another case of a state of a variable. Other states are 1, 15, 0xffffffff, etc. That mainstream languages don't handle this is the worst mistake of the computer industry.

[deleted]

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

#105

Post by boomlinde »

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.

No, 0 is definitely a number.

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

#106

Post by molf »

cmrdporcupine wrote: post #81

NULL in 'relational' databases in particular is a disaster. Or at least according to the notorious Fabian Pascal. http://www.dbdebunk.com/2017/04/null-value-is-contradiction-... Codd never proposed it in his original relational model. For good reason.

I think it would be nice if `NOT NULL` was set by default on columns. However there are a lot of legitimate use cases that can't be (practically) solved by restructuring.

Data can be incomplete. Maybe only because it is not (yet) known. If NULL values were impossible it would create the need for one additional table with a foreign key relationship for every attribute that can be independently NULL. Sometimes this pattern is a good idea, but I don't think I can be convinced it should be the only possible solution.

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

#107

Post by captainmuon »

I've made my peace with null. Null is basically just an implicit

    assert(valid(x))
before every time you call a method on x. Similary, I think of exceptions as explicit "crash-unless-caught" commands.

If you write your program with the "blow up early" mentality anway, or use static checking tools and a bit of discipline, I've found that null looses it's terror.

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

#108

Post by zxczxc111 »

rusk wrote: post #96
axilmar wrote: post #87

NULL is certainly a mistake, but even more of a mistake is not allowing distinct states in variables. NULL is just another case of a state of a variable. Other states are 1, 15, 0xffffffff, etc. That mainstream languages don't handle this is the worst mistake of the computer industry.

Most languages do. Java will always initialise a non-initialised value to NULL for instance (EDIT or 0 or false for primitives). It's simply a reality of how computers operate that when you allocate a piece of memory (a variable) it will have something in it that you'll need to clear or initialise. In this respect, NULL is doing you a favour.

Only for field variables. Local variables most definitely have to be initialised by the programmer, otherwise it's a compiler error

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

#109

Post by xvzxvzxdfg »

goto11 wrote: post #90
cmrdporcupine wrote: post #81

NULL in 'relational' databases in particular is a disaster. Or at least according to the notorious Fabian Pascal. http://www.dbdebunk.com/2017/04/null-value-is-contradiction-... Codd never proposed it in his original relational model. For good reason.

Disagree that it is a disaster. Nullability is explicit in the column type, so it doesn't have the "billion dollar mistake". Furthermore you need to represent missing values somehow if you perform a left join.

A database "null" is not the same thing as being discussed in the article though. But its so cute that you web devs go all in commenting anyway.

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

#110

Post by userbinator »

To someone who has been using Asm and C for decades, these arguments just make no sense. Reading this article reminds me of the arguments against pointers, another thing that's frequently criticised by those who don't actually understand how computers work and try to "solve" problems by merely slathering everything in thicker and thicker layers of leaky abstraction. It's not far from "goto considered harmful" either.

any reference can be null, and calling a method on null produces a NullPointerException.

...which immediately tells you to go fix the code.

There are many times when it doesn’t make sense to have a null. Unfortunately, if the language permits anything to be null, well, anything can be null.

That's not an argument. See above.

3. NULL is a special-case

...because it indicates the absence of a value, which is a special case.

though it throws a NullPointerException when run.

...and the cause is obvious. I'm not even a regular Java user (and don't much like the language myself, but for other reasons) and I know the difference between the Boxed types and the regular ones.

NULL is difficult to debug

Seriously? A "nullpo crash" is one of the more trivial things to debug, because it's very distinctive and makes it easy to trace the value back (0 stands out; other addresses, not so much.) What's actually hard to debug? Extraneous null checks that silently cause failures elsewhere.

The proposed "solution" is straightforward, but if you reserve the special null value to indicate absence then you can make do with just one value instead of a pair, of which half the time half of the value is completely useless. If you can check for absence/null, you will have no problems using Maybe/Optional. If you can't, Maybe/Optional won't help you anyway --- because it's ultimately the same thing, using a value without checking for its absence.

Post reply on HN