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

291–300 of 377 posts

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

#291

Post by taco_emoji »

TickleSteve wrote: post #281
cultus wrote: post #252

Earlier quoted context omitted.

>The most trivial pointer issue is a NULL pointer. This is such a trivial issue to catch its hardly even an error, yet people use that case as the exemplar for NULL issues. How can you claim that NPEs are "hardly ever an error." NPEs are the most common error there is! They are indeed easy to catch, but you need to do so nearly everywhere, obscuring the code and introducing potential for error. There is no real, conc…

"hardly even an error" not "hardly ever an error". in other words, NULL pointer errors are a trivial error to deal with.

They're even easier to deal with if your type system guarantees you can never get them in the first place.

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

#293

Post by da_chicken »

lmm wrote: post #268
da_chicken wrote: post #254

Earlier quoted context omitted.

Yeah, but saying "I want to use SQL" and "I don't want to use NULL or ternary logic" is a bit like saying "I want to use the existing datetime types" and "I want all years to have 10 months, all months to have 30 days, etc." Or like saying, "I want everything to use integers" and "I need fractional components." Your requirements break the abstraction not because the system is constrained, but because you're breaking…

> Your requirements break the abstraction not because the system is constrained, but because you're breaking the conceptual model that's the foundation of what you're trying to use. How so? Elsewhere in the thread it's claimed that the original relational model didn't have nulls, which is what I'd expect.

Relational algebra doesn't have nulls, but there's a difference between the mathematical theory and concepts and the reality of a relational system.

As I mention elsewhere, Codd's own list of rules for a relational database [0] explicitly require nulls (see Rule 3).

[0]: https://en.wikipedia.org/wiki/Codd%27s_12_rules

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

#294

Post by cultus »

TickleSteve wrote: post #281
cultus wrote: post #252

Earlier quoted context omitted.

>The most trivial pointer issue is a NULL pointer. This is such a trivial issue to catch its hardly even an error, yet people use that case as the exemplar for NULL issues. How can you claim that NPEs are "hardly ever an error." NPEs are the most common error there is! They are indeed easy to catch, but you need to do so nearly everywhere, obscuring the code and introducing potential for error. There is no real, conc…

"hardly even an error" not "hardly ever an error". in other words, NULL pointer errors are a trivial error to deal with.

But yet it is the most common type of bug, even in production. Clearly, it's not that easy to deal with for human programmers. What's the problem with letting the compiler help you?

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

#295

Post by smrq »

dtech wrote: post #223
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.

Take a look at Kotlin or Typescript†. Basically, they decided to fully design the language with support for null-as-option. That means several things: * T (non-nullable) and T? (nullable) are different types. T? = T | null * Where T is expected T? is not accepted, but where T? is specified T is also accepted * T? is automatically cast to T in the places where it's asserted to be not null, e.g. within an if(x != null)…

> * There's syntax for providing a value in case of null. (x ?: fallback) in Kotlin, (x || fallback) in Typescript.

Well, uh, unless T can be falsy. 0 || fallback === fallback. A proper ?? operator a la C# would be great, but they've pushed back against it because it doesn't entirely mesh well with nulls in the JS world.

JS is still probably my favorite language to work in despite stuff like this. But that's one footgun that everyone should be aware of.

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

#296

Post by setr »

da_chicken wrote: post #209
lmm wrote: post #168

Earlier quoted context omitted.

NULL in SQL is a notorious source of errors and confusion (particularly when it comes to e.g. tri-state boolean logic). It certainly can come from nowhere and surprise you - if anything the behaviour is even worse than in Java or C#. So I don't think there's anything to learn from there. (Rather what modern languages should have done - and increasingly do - is follow ML practice and avoid null entirely, implementing…

That's not really NULL's fault that it causes confusion in SQL. That's just ternary logic. People who don't handle NULLs in SQL aren't really mishandling the NULL. NULL is just a value. They're simply failing to understand the Boolean value of UNKNOWN and what that means. They're so used to thinking only in bivalent logic that the additional complexity throws them off. However, "It's more complex for me to think abou…

>That's not really NULL's fault that it causes confusion in SQL. That's just ternary logic

The problem is that its not simply ternary logic. It's a ternary logic that gets mapped onto a boolean algebra, which leads to the usual strange repercussions (particularly, the presence of nulls creates both false positives, and false negatives, silently).

The SQL language goes out of its way to pretend its not ternary, though in fact it is. You have to actively keep in mind when writing SQL that the database is trying to trick you. This is not a good thing, and it's hard to blame the programmer when they get tricked.

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

#297

Post by taco_emoji »

jchw wrote: post #195
cyphar wrote: post #41

Earlier quoted context omitted.

I would recommend looking Haskell's Maybe and Rust's Option type to get a better idea of how this can be solved -- and how this article isn't really overrated (just commonly misunderstood). They allow for explicit NULL-ness (which is a necessary concept) without falling into the trap of making everything implicitly possibly NULL. And when NULL-ness is explicit you are then forced to explicitly handle it in order for…

I dunno why everyone's assuming I don't know about the common solutions to the problem. TypeScript does explicit nullness without needing monads, and I actually mentioned that one. I still disagree that this is not overrated. Go's idea of nil, for example, seems OK to me, and the language would need to be way more complex to fix it. For example, it would need a type system with explicit nullness, or maybe even actual…

But nobody's talking about "getting rid of nil" wholesale. They're talking about getting rid of null/nil reference exceptions via the mechanisms of non-nullability (having the option to define some variables as non-nullable) and null guards (a compiler which forces a null check before any operation which requires a non-null value). This way you still have null, but with compile-time guarantees that you'll never get null when you didn't expect it.

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

#298

Post by syrrim »

enriquto wrote: post #53
doubletgl wrote: post #34

Isn't there an inherent need in programming to express an explicit "nothing" value? Coming from Python and JS, I never found None/null to be much of a problem. I in fact like the distinction of null and undefined in JS. Using null allows you to distinguish from the accidental undefined.

> Isn't there an inherent need in programming to express an explicit "nothing" value? In numerical calculus: yes, most certainly. What do you expect the result of log(-1) to be? The alternative is to use specially tagged particular numbers as "no-data", and pray so that they do not appear naturally as the result of computations.

>What do you expect the result of log(-1) to be?

i pi, or more generally i pi n for odd n.

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

#299

Post by mhh__ »

kzrdude wrote: post #141
chongli wrote: post #136

Earlier quoted context omitted.

No, the problem with null is the inability to enforce, at the type level, that a particular value is not null. C simply does not have a type for "guaranteed valid pointer to x".

C allows defining new types though, so it can be done.

It can only really be done on a per codebase level, really.

By which I mean, in my highly sensitive and correct program xyz I can (say) abstract all access to a type (A struct?) through a macro which would contain null checking/assert-ing. This could work perfectly well and even be static checked for (in principle).

However, if I tried to package this type up in a library it all basically falls flat - or at least it would be very easily broken.

Doing this like this is to static analysis(/The Type system) as foreplay is to sex.

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

#300

Post by empath75 »

revskill wrote: post #20

The problem is in tooling. If all compilers/builders out there could detech null for us, those kinds of error could be taken care with much more ease.

A higher level programming language is a kind of tooling. Use a language that doesn't have NULL and problem solved.
Post reply on HN