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

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

#61

Post by virtualized » Tue, Dec 04, 2018, 11:15 AM UTC

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.

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

#62

Post by r_c_a_d » Tue, Dec 04, 2018, 11:17 AM 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…

Or add exceptions like C++ did,

if (foo_is_available) return foo; else throw FooNotAvailable();

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

#63

Post by masklinn » Tue, Dec 04, 2018, 11:18 AM UTC

skgoa wrote: post #6

thwy12321 wrote: post #4

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike" When d…

It's the Java approach. Don't give people footguns and force them to write software in a readable, testable, maintainable style. It works extremely well in software engineering, because you want systems that work reliably and that can be maintained/extended by any other engineer at your org. In the professional software engineering world, "clever" programmers are almost always a horrible drag on their team.

It's not the Java approach at all. The first languages to remove ubiquitous nulls (e.g. MLs) were looking to increase expressivity and modeling abilities, not to force bondage and discipline upon developers.

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

#64

Post by masklinn » Tue, Dec 04, 2018, 11:20 AM UTC

kekzzz wrote: post #2

Why can't people just get over it and stop blaming the language for their own sloppy code?

Why can't people just get over it and stop blaming users for the tools failing them?

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

#65

Post by jstimpfle » Tue, Dec 04, 2018, 11:23 AM UTC

knocte wrote: post #31

rusk wrote: post #27

NULL is a convenient way to map singularities in your model of the problem. I have on a few occasions tried to write NULL-less code, and it adds a good bit of work. - model all possible states for a value - determine appropriate default actions for all types - meaningful place-holder values It's a good exercise, and I think more code should be written this way, but - as an Engineer I'm trying to model just enough of…

Have you ever dealt with the Maybe(Haskell)/Option(F#) types? If not, then you don't understand what's wrong with NULL and how to easily avoid it without much work.

I find Maybe a bad idea. It forces me to write denormalized code when I know that something is not NULL. It's not possible to specify this knowledge as a data structure since data structures are static but context is dynamic. I much prefer the simple NULL sentinel that blows up like an assertion when I made a mistake. That said, there's not very often a need for NULL at all if you structure the code correctly.

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

#66

Post by jmfayard » Tue, Dec 04, 2018, 11:27 AM UTC

Progress, it's now a solved problem in modern languages like Rust, Swift or Kotlin See for example: https://kotlinlang.org/docs/reference/null-safety.html

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

#67

Post by edoo » Tue, Dec 04, 2018, 11:29 AM UTC

masklinn wrote: post #59

edoo wrote: post #5

Nulls in strongly typed languages can get rather weird but from a C/C++ perspective it is the same as 0. nullptr is just a correctly casted 0.

That's not correct. In C, the literal "0" is a null pointer constant handled at the compilation stage, but casting a runtime zero is not specified to yield a null pointer (and the address zero can be perfectly valid and usable), nor are null pointers specified to be zero-valued (quite the opposite).

I disagree. nullptr is directly convertable to a boolean 0:

#include

int main(int argc, char *argv[]) {

  printf("%d\n", nullptr == 0);

  return 0;
}

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

#68

Post by coldtea » Tue, Dec 04, 2018, 11:29 AM UTC

thwy12321 wrote: post #22

coldtea wrote: post #18

Earlier quoted context omitted.

> When did computer science become about hand holding? When people with pragmatic goals want to get large teams of new programmers productive fast, and can't expect everyone to be able to fend on their own or can afford the cost of accumulated mistakes. > Look at react. It was designed to force functional programming concepts in an OOP manner. Whatever that means, as React has little to do with "OOP manner".

OOP meaning React.Component, functional meaning immutable html state, property inheritance, render(), etc

Component hierarchies != OOP. They are an inevitable part of UI, which is hierarchical.

React has move to stateless components and functions over classes.

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

#69

Post by jstimpfle » Tue, Dec 04, 2018, 11:30 AM UTC

turbinerneiter wrote: post #3

kekzzz wrote: post #2

Why can't people just get over it and stop blaming the language for their own sloppy code?

Because everybody is working on the limit of complexity they can comprehend, so there is no headspace left for dealing with bad ergonomics. We need all the help we can get.

> everybody is working on the limit of complexity they can comprehend

That's the problem right there.

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

#70

Post by masklinn » Tue, Dec 04, 2018, 11:41 AM UTC

edoo wrote: post #67

masklinn wrote: post #59

Earlier quoted context omitted.

That's not correct. In C, the literal "0" is a null pointer constant handled at the compilation stage, but casting a runtime zero is not specified to yield a null pointer (and the address zero can be perfectly valid and usable), nor are null pointers specified to be zero-valued (quite the opposite).

I disagree. nullptr is directly convertable to a boolean 0: #include int main(int argc, char *argv[]) { printf("%d\n", nullptr == 0); return 0; }

1. You're comparing a null pointer literal with a null pointer constant. You're literally comparing two things guaranteed to be equal. How, exactly, is it surprising that they do? Did you even attempt to understand what I wrote?

2. The specific implementation you have on hand could use zero-valued null pointers, I'm telling you what the standard doesn't say, confirmed by the C FAQ:

http://c-faq.com/null/varieties.html

http://c-faq.com/null/confusion4.html

http://c-faq.com/null/machexamp.html

3. The null pointer is not "directly convertible to a boolean 0", it's the literal 0 which expresses a null pointer: http://c-faq.com/null/ptrtest.html