NULL: The worst mistake of computer science? (2015) • Hacker News Board

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

#131

Post by ummonk » Tue, Dec 04, 2018, 2:15 PM UTC

cyphar wrote: post #124

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

> 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 I think that you're being quite unkind. Haskell's Maybe type and Rust's Option types are very far from "leaky abstractions" and were developed by people who definitely understand how computers work. In fact…

Well, a better comparison would be Typescript with strict null type checking enabled. You just use algebraic data types to specify whether a value can be null.

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

#132

Post by lawn » Tue, Dec 04, 2018, 2:15 PM UTC

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.

Oh I'm fairly disciplined. But we use a 15 year old code base which should've been made with more discipline than it was.

Additionally the program shouldn't "blow up early" but it was in many ways coded that way.

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

#133

Post by ummonk » Tue, Dec 04, 2018, 2:17 PM UTC

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…

Yup, this is what happens when you use Typescript with strict null checking.

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

#134

Post by gre » Tue, Dec 04, 2018, 2:32 PM UTC

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.

“Looses its terror” here means the opposite of “loses its terror”.

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

#135

Post by cultus » Tue, Dec 04, 2018, 2:32 PM UTC

TickleSteve wrote: post #112

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

Completely agree, this is CS theory gone off the deep end...

A simple, safe way of tracking nulls like option is "CS theory going off the deep end?"

Implicitly allowing all code to return nothing, and manually trying to remember what can return null and what can't, and checking that value, is incredibly error prone. It's really crazy that this has been the dominant way of handling the problem for many decades when their is a dead-simple way of ensuring it can't happen.

Null pointer errors, contrary to many claims, show up in production code all the time. Eliminating them is of huge value.

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

#136

Post by chongli » Tue, Dec 04, 2018, 2:33 PM UTC

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

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

#137

Post by gnulinux » Tue, Dec 04, 2018, 2:33 PM UTC

TickleSteve wrote: post #112

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

Completely agree, this is CS theory gone off the deep end...

Calling this "CS Theory" is intellectual dishonesty.

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

#138

Post by cultus » Tue, Dec 04, 2018, 2:35 PM UTC

chc wrote: post #122

goto11 wrote: post #57

Earlier quoted context omitted.

The major criticism towards NULL's does not apply to dynamic languages. The problem in languages like Java is that nullability is not represented in the type. This criticism is not relevant in a language without static type checking. The criticism is also not relevant in a language like TypeScript where nulls are specified in the type. In short, the problem is not nulls per se, the problem is static type systems whic…

The OP specifically calls out ways that nulls cause problems in dynamic languages. In fact, they're very similar to the problems nulls cause in statically typed languages, just ignoring some of them because danger is already priced in with a dynamic language. Dynamically typed programs are usually informally "duck typed," since it's impossible to do something meaningful with truly arbitrary types most of the time. Bu…

The way Clojure handles nulls is ideal for a dynamically typed language. In Clojure, a nil is a perfectly valid object, and it is also a sequence (it's the empty list equivalent). That means that most standard library functions have no problems letting nil flow through them, returning nil. It winds up being quite similar to monadic Option/Maybe, although with no guarantees.

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

#139

Post by gnulinux » Tue, Dec 04, 2018, 2:35 PM UTC

mehrdadn wrote: post #94

cmrdporcupine wrote: post #85

Earlier quoted context omitted.

std::optional has the potential to eliminate many of the null-pointer uses.

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?

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

#140

Post by adrianN » Tue, Dec 04, 2018, 2:35 PM UTC

nsajko wrote: post #129

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

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

Nobody does full path coverage, not even NASA.