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

141–150 of 377 posts

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

#141

Post by kzrdude »

chongli wrote: post #136
pdkl95 wrote: post #50

> NULL is a value that is not a value. And that’s a problem. The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Option can still be NULL ("None" in rust), wrapping NULL in a struct doesn't provide any safety. The safety of Option wrapper types is from the other language features (like rust's "match") and a stricter compiler that forces the programmer to write the NU…

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.

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

#142

Post by empath75 »

pdkl95 wrote: post #50

> NULL is a value that is not a value. And that’s a problem. The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Option can still be NULL ("None" in rust), wrapping NULL in a struct doesn't provide any safety. The safety of Option wrapper types is from the other language features (like rust's "match") and a stricter compiler that forces the programmer to write the NU…

Since every type can be NULL that’s a lot of verbosity.

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

#143

Post by cultus »

nsajko wrote: post #130
hesselink wrote: post #119

Earlier quoted context omitted.

The thing is, you're focusing on when you've detected that there is an issue (a crash). A lot of the issues with NULL are the fact that you can't easily detect if beforehand. It's not indicated in the types, or the syntax. That means that it's incredibly easy for a NULL issue to sneak into an uncommon branch or scenario, only to be hit in production.

But why was the scenario not tested before production? Should that not be the case anyway?

You can never guarantee you really have 100% test coverage in all scenarios in complex software.

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

#144

Post by kzrdude »

captainmuon wrote: post #107

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.

If it's C, it's far more terrifying than that.. there is no assertion! just a vauge threat that something will go wrong if you stick a null in there, with no guarantees and no checks.

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

#145

Post by danesparza »

masklinn wrote: post #58
pdkl95 wrote: post #50

> NULL is a value that is not a value. And that’s a problem. The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Option can still be NULL ("None" in rust), wrapping NULL in a struct doesn't provide any safety. The safety of Option wrapper types is from the other language features (like rust's "match") and a stricter compiler that forces the programmer to write the NU…

> The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Talking about "NULL" pretty much implies that. When Tony Hoare talks about null references, it's about every reference being nullable in languages like Java or C#, not about the ability to conceptually wrap/opt non-nullable references in a nullability thingie.

Psst: I think the thingie you're referring to is called a 'monad': https://en.wikipedia.org/wiki/Monad_(functional_programming)

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

#146

Post by empath75 »

nsajko wrote: post #130
hesselink wrote: post #119

Earlier quoted context omitted.

The thing is, you're focusing on when you've detected that there is an issue (a crash). A lot of the issues with NULL are the fact that you can't easily detect if beforehand. It's not indicated in the types, or the syntax. That means that it's incredibly easy for a NULL issue to sneak into an uncommon branch or scenario, only to be hit in production.

But why was the scenario not tested before production? Should that not be the case anyway?

It’s cute that you think tests find all problems.

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

#147

Post by jhomedall »

pdkl95 wrote: post #50

> NULL is a value that is not a value. And that’s a problem. The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Option can still be NULL ("None" in rust), wrapping NULL in a struct doesn't provide any safety. The safety of Option wrapper types is from the other language features (like rust's "match") and a stricter compiler that forces the programmer to write the NU…

> Option can still be NULL ("None" in rust)

'None' in Rust is part of the Option enum, not an equivalent to null.

  pub enum Option {
      None,
      Some(T),
  }

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

#148

Post by plopz »

adrianN wrote: post #140
nsajko wrote: post #129

Earlier quoted context omitted.

Also, when you are aiming for full test coverage null dereferences will be caught during testing.

Nobody does full path coverage, not even NASA.

sqlite is 100% branch test covered

https://www.sqlite.org/testing.html

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

#149

Post by bunderbunder »

You know who works on a platform with NULL but doesn't have quite so many problems with it? DBAs.

There's some need to draw a distinction between the basic idea of NULL, and the way that NULL has been implemented in most high-level programming languages.

In most RDBMSes, values can't be null unless you say they are. Sometimes explicitly, as in table definitions, sometimes implicitly, when you select a JOIN type. Either way, though, the fact that the developer is in control of when it can and cannot happen means that it always has a knowable meaning. (Or should, anyway.)

The problem with many programming languages is, you're given it whether you want it or not. In a low-level language like C, that's reasonable, because it takes a sensible approach to how it works: Only pointers can be null, and all pointers are nullable for obvious (especially in the 1970s) reasons.

More generally, I'm not going to fault languages from that era for trying it out, because this stuff was new, and things were still being felt out. So I don't really fault Tony Hoare for giving null references a try in ALGOL W.

What seems much more bothersome is high level languages like Java and C# cargo culting this behavior. They could have followed the lead from languages like SQL and let the programmer be in control. They should have. They already throw exceptions when a memory allocation fails, and they allow inline variable initialization, and declaring variables at the point of usage, and composite data types have constructors, so they lack all of (early) C's reasons why ubiquitous nulls were a good idea. They could have, I think quite easily, made nullability optional. At which point it'd have basically the same semantics as optional types from functional programming, so I doubt we'd be worrying about it anymore.

But they didn't.

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

#150

Post by bfrydl »

danesparza wrote: post #145
masklinn wrote: post #58

Earlier quoted context omitted.

> The problem isn't NULL, it's languages not enforcing the necessary checks for the "no data" condition. Talking about "NULL" pretty much implies that. When Tony Hoare talks about null references, it's about every reference being nullable in languages like Java or C#, not about the ability to conceptually wrap/opt non-nullable references in a nullability thingie.

Psst: I think the thingie you're referring to is called a 'monad': https://en.wikipedia.org/wiki/Monad_(functional_programming)

It isn't. There exists a common monad that solves this problem but a wrapper type like Option or Maybe need not be a monad. For example, `Nullable` in C# is not a monad.
Post reply on HN