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

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

#31

Post by knocte » Tue, Dec 04, 2018, 9:04 AM UTC

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.

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

#32

Post by rusk » Tue, Dec 04, 2018, 9:05 AM UTC

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 lot of static analysis tools will do this.

I can't speak for other IDEs, but Intellij will always warn me if I'm exposing myself to some NULL operations.

I do think better first class language support is the way to go though.

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

#33

Post by rusk » Tue, Dec 04, 2018, 9:06 AM UTC

saagarjha wrote: post #13

ohazi wrote: post #8

Other candidates: - null terminated strings - machine dependent integer widths

> null terminated strings This is mentioned. > machine dependent integer widths What exactly do you dislike about this?

> What exactly do you dislike about this?

Or what do you even do about it?

A handful of solutions already exist: - Use a higher-level language - Java

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

#34

Post by doubletgl » Tue, Dec 04, 2018, 9:06 AM UTC

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.

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

#35

Post by rusk » Tue, Dec 04, 2018, 9:08 AM UTC

jeromebaek wrote: post #7

At least C# has the syntactic sugar to easily check for null references which lets you avoid the horrors of code like `(if s != null && s.length)`. Instead you can type `s?.length`. Never have I appreciated syntactic sugar as much.

A lot of higher languages use the concept of truthiness such that null, or 0-length both evaluate to false:

    if (s) then do stuff with s;

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

#36

Post by ape4 » Tue, Dec 04, 2018, 9:08 AM UTC

edoo wrote: post #16

saagarjha wrote: post #11

Earlier quoted context omitted.

nullptr is actually "a prvalue of type std::nullptr_t" or something like that. Since C++11 NULL is the same as nullptr.

And it is directly convertible to a bool. The primary effectiveness seems to be with operator overloading where a NULL could trigger an integer method instead of a pointer method.

Yes that's the example given here. https://en.cppreference.com/w/cpp/language/nullptr So its an improvement but not exactly a game changer.

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

#37

Post by grive » Tue, Dec 04, 2018, 9:09 AM UTC

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.

This is only true in C, which is part of why C is less insane than C++.

The two languages should not be conflated anymore.

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

#38

Post by saurik » Tue, Dec 04, 2018, 9:10 AM UTC

saagarjha wrote: post #11

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.

nullptr is actually "a prvalue of type std::nullptr_t" or something like that. Since C++11 NULL is the same as nullptr.

To the small extent to which "since C++11" is even relevant to "from a C/C++ perspective", even in C++11 NULL is still allowed to simply be defined as 0.

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

#39

Post by zoul » Tue, Dec 04, 2018, 9:10 AM UTC

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.

The key word here is explicit. Explicit Maybe/Optional types from Haskell, Swift or Rust are wonderful. After my experience with Elm and Swift, the mere thought of going back to implicit nullability everywhere hurts.

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

#40

Post by sitharus » Tue, Dec 04, 2018, 9:12 AM UTC

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.

No, there’s no inherent need for every variable to allow a nothing.

There is a need for a nothing value in many cases and languages without an implicit null, such as Haskell, F# and Rust, employ an ‘option’ type. It’s a dedicated type that either contains a value or nothing. It forces you to declare when you expect a potential null and to check for it.