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

301–310 of 377 posts

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

#301

Post by setr »

userbinator wrote: post #110

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.…

In general, it's difficult to make the case that runtime errors are preferable over compile-time errors, unless the difficulty to enable compile-time errors is significant. In the case of Optional as a language/DB type, I can't imagine much effort involved, except for uptake.

Especially given that it can trivially be optimized out, since the eventual assembly should very well make use of the 0x0 property. But if you can encode the guarantee in your "high-level" language, why would you not want it?

In fact, I'm not sure how anyone could imagine assert(n != null) scattered throughout the codebase is a pleasant situation, unless of course, as most do, you're skipping the safety check for unsafe reasons.

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

#302

Post by mehrdadn »

gnulinux wrote: post #139
mehrdadn wrote: post #94

Earlier quoted context omitted.

If my pointer already supports NULL, why would I put std::optional on top of it? I was saying I don't need a null for anything but a pointer.

Because it's a 0 overhead abstraction and guard against the case when you (or a coworker) forget to check for null. Are we seriously gonna pretend like you never caused a null pointer exception?

I don't see how it's zero overhead? And honestly while it's obviously not never, it's not exactly frequent either.

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

#303

Post by masklinn »

basil-rash wrote: post #285
masklinn wrote: post #240

Earlier quoted context omitted.

std::optional doesn't do that though, you can deref an empty optional and the result's the same as deref'ing an empty unique_ptr or a null pointer: UB.

But it makes you stop and thing before doing so. Thats the whole point.

It doesn't do that any more than a pointer

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

#304

Post by gambler »

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.

That's exactly what he says. People might disagree that this is the right approach, but I'm not sure what other ways anyone could interpret that talk.

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

#305

Post by HumanDrivenDev »

SpicyLemonZest wrote: post #210
davemp wrote: post #205

Earlier quoted context omitted.

Yes, option types are awesome. No, they are not nulls. Algebraic data types are not direct support "no data found at the type level". Algebraic types are really just a fancier enum/union type. It just so happens that inventing special sentinel values is awesome when you have an algebraic type system to check your work.

They’re not direct support, but option types only work in languages with the right syntax and tooling to make them work. C union types, for example, aren’t really capable of providing a null replacement simply because they’re so complex to use.

They’re not direct support, but option types only work in languages with the right syntax and tooling to make them work.

I strongly disagree.

You don't need pattern matching syntax to use option types effectively. All you need are the right methods - map, flatMap, getOrElse etc etc. Any language with inheritance and dynamic dispatch can implement a good option type.

Even in languages with pattern matching, I never reach for it when dealing with options.

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

#306

Post by lmm »

jstimpfle wrote: post #289
lmm wrote: post #263

Earlier quoted context omitted.

> Sure, what's bad about it? A logic bug was detected, so the program should be terminated. Or how do you intend to continue? I intend to not have the logic bug in the first place, by encoding my invariants in the type system. If you "know" that the value is present rather than absent, you must have a reason for knowing it, so explain that reason to the compiler. E.g. maybe you took the first element of a list value…

> by encoding my invariants in the type system the way I program that is nothing but a pipe dream. > If you "know" that the value is present rather than absent, you must have a reason for knowing it, so explain that reason to the compiler. I might know that it exists for example because it is computed in a post-processing step after a first stage but before a second stage. So it exists in the second stage but not in…

> I might know that it exists for example because it is computed in a post-processing step after a first stage but before a second stage. So it exists in the second stage but not in the first.

So the first stage could create a handle to it, or even just a phantom "witness" that you treat as proof that the value is present.

> And that's not a problem at all. I simply don't access that data table in the first stage... Trying to explain my processing strategy to a compiler would amount to headaches and no benefits.

Shrug. I found that errors would make it into production, because human vigilance is always fallible. And the level of testing that I needed to adopt to catch errors was a lot more effort than using a type system.

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

#307

Post by dragonwriter »

davemp wrote: post #205
SpicyLemonZest wrote: post #199

Earlier quoted context omitted.

It needs to be supported at the type level, whether by null or by options, simply because “data not available” is a common value people need to use. When there’s no good way to express it, they’re forced to invent special sentinel values, and you end up in the situation where array index -1 means “value not found in the array”.

Yes, option types are awesome. No, they are not nulls. Algebraic data types are not direct support "no data found at the type level". Algebraic types are really just a fancier enum/union type. It just so happens that inventing special sentinel values is awesome when you have an algebraic type system to check your work.

> Yes, option types are awesome. No, they are not nulls.

No, but they serve a superset of the semantic functions of nulls, better than nulls do.

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

#309

Post by icedchai »

da_chicken wrote: post #290
icedchai wrote: post #272

Earlier quoted context omitted.

NULL is an alias for UNKNOWN on many systems (like MySQL.) Other DBs don't even have UNKNOWN. UPDATE table set col=value1 and value2 works fine IF value1 and value2 are booleans.

That's a great example of MySQL creating a proprietary extension of ANSI SQL that does little more than deliberately mislead users.

According to https://en.wikipedia.org/wiki/Null_%28SQL%29#BOOLEAN_data_ty... NULL is the same as UNKNOWN. The standard also asserts that NULL and UNKNOWN "may be used interchangeably to mean exactly the same thing"

In 20+ years of DB work, I have NEVER seen anyone use UNKNOWN. It is always NULL. Always.

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

#310

Post by lugg »

crooked-v wrote: post #278
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.

Consider Javascript, where undefined and null are both unique primitive values.

Is anyone aware of a situation that code would fault if we replaced all undefineds with nulls in JS?

General code, not things specifically testing differentiation between undefined and null.

Post reply on HN