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

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

#261

Post by jchw » Tue, Dec 04, 2018, 6:39 PM UTC

orblivion wrote: post #250

jchw wrote: post #201

Earlier quoted context omitted.

Okay. So let's say we get rid of nil in Go. Now, structs with pointers have no zero value. Slices and maps have no zero value. Funcs have no zero value. Reflect can no longer create objects because it can't possibly enforce that you initialize the pointers. Functions that return either an error or a value now need a new pattern, probably requiring generics or another special type. Map access needs to return this spec…

> Now, structs with pointers have no zero value. A zero value is much better than undefined value, I'll grant you that. I prefer the forced initialization approach (Haskell, presumably Rust and many others). If I add a new field, I want to know where I need to populate it. Or if you must, maybe a default value defined on the struct (perhaps that's also "considered harmful" for reasons I can't think of at the moment).…

Easy: default zero is simple. It's predictable behavior. It's consistent.

By convention, you should design your code to also treat zero values as empty. In Go, the zero value of bytes.Buffer is a ready to use, empty buffer.

If you drop default zero, you lose a lot of convenience and gain a lot of ceremony. It's not the end of the world, but neither is the null pointer error. It's just another runtime error. Just like divide by zero.

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

#262

Post by lmm » Tue, Dec 04, 2018, 6:40 PM UTC

AJRF wrote: post #28

Do people generally agree that Java Optional == Scala Maybe / Haskell's Maybe? Java's Optional seems fundamentally flawed in that Java allows any reference to hold a null value and Optional can still throw a NPE when calling isPresent on it so it still gives people a footgun.

> Java's Optional seems fundamentally flawed in that Java allows any reference to hold a null value and Optional can still throw a NPE when calling isPresent on it so it still gives people a footgun.

The existence of Optional makes it possible to migrate away from using "null". E.g. Map#get could be replaced with a method that returns Optional.

Calling isPresent is the wrong way to use an Optional. But yes, it's an ordinary Java value, it can be null as long as Java-the-language permits null. That's not a problem with Optional, it's a problem with Java, and introducing Optional as a plain old normal Java class is the first step to fixing it.

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

#263

Post by lmm » Tue, Dec 04, 2018, 6:43 PM UTC

jstimpfle wrote: post #179

cultus wrote: post #166

Earlier quoted context omitted.

I haven't drank all my coffee yet this morning, but are you saying that throwing a segfault can be a good thing? Either you unwrap the Option, or you have to remember to do an manual null check. The second option is more verbose.

> but are you saying that throwing a segfault can be a good thing? Sure, what's bad about it? A logic bug was detected, so the program should be terminated. Or how do you intend to continue? Segfault is not so different from what happens if you do "fromJust Nothing" in Haskell or get a NullPointerException in Java. You can even write a handler for the segfault, but I guess that's rarely a good idea.

> Sure, what's bad about it? A logic bug was detected, so the program should be terminated. Or how do you intend to continue?

I intend to not have the logic bug in the first place, by encoding my invariants in the type system.

If you "know" that the value is present rather than absent, you must have a reason for knowing it, so explain that reason to the compiler. E.g. maybe you took the first element of a list value that you know is non-empty - so maybe you need to change the type of that value to a non-empty list type. That way the compiler can check your reasoning for you, and will catch the cases where you thought you "knew" but were actually wrong.

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

#264

Post by lmm » Tue, Dec 04, 2018, 6:44 PM UTC

cphoover wrote: post #169

Option monad fixes null reference problems. Does not fix the ambiguity between not found vs doesn't exist.

If you have multiple possible reasons for a value to be "absent", that sounds like a case for an "either" or "result" type.

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

#265

Post by lmm » Tue, Dec 04, 2018, 6:46 PM UTC

rusk wrote: post #89

knocte wrote: post #31

Earlier quoted context omitted.

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 see these as a more sophisticated way of dealing with NULL. It allows me to define alternative default behaviour beyond just throwing an undeclared exception. They are still NULLs however under the hood and I still need to do the work of defining what I want to happen when they occur. It's just neater.

They're not null. You might use them to represent the same thing that you use null to represent, but the type system won't let you use them in expressions that aren't explicitly built to accept them.

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

#266

Post by piyh » Tue, Dec 04, 2018, 6:47 PM UTC

gre wrote: post #134

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

Cry havoc and let loose the null pointer exceptions

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

#267

Post by bootlooped » Tue, Dec 04, 2018, 6:48 PM UTC

SpicyLemonZest wrote: post #199

davemp wrote: post #196

Earlier quoted context omitted.

This is hard to reconcile with type theory for me. NULL, to me, implies and uninhabited type, i.e. there can never be a value with a NULL type. Using null for a "data isn't there, apply, available, etc" seems like an abuse of the type system. I see no reason that the former needs to be supported at the type level. These properties are just responses to queries, not some mystical, uninhabitable oblivion. Unnecessary t…

It needs to be supported at the type level, whether by null or by options, simply because “data not available” is a common value people need to use. When there’s no good way to express it, they’re forced to invent special sentinel values, and you end up in the situation where array index -1 means “value not found in the array”.

I have worked with a MySQL database where the designer(s) decided that, on many of the tables, -1 should represent no value instead of null. As you can imagine, this has caused some problems when they've done this with columns representing dollar amounts.

This was done because of their belief that having any nulls in the table is the kiss of death for performance; they've used the phrase "tablescan" a lot. I have not been able to find a basis for these claims.

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

#268

Post by lmm » Tue, Dec 04, 2018, 6:48 PM UTC

da_chicken wrote: post #254

lmm wrote: post #221

Earlier quoted context omitted.

> Or arguments about zero-based array indexing. These concepts aren't difficult. They're just more complex. Negative numbers aren't difficult, but they're more complicated than just cardinal numbers. Fractions and decimals aren't difficult, but they're more complex than integers. Multiplication and division aren't difficult, but they're more complex than addition and subtraction. We usually consider it a good thing w…

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.

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

#269

Post by bunderbunder » Tue, Dec 04, 2018, 6:59 PM UTC

tatut wrote: post #227

bunderbunder wrote: post #171

Earlier quoted context omitted.

This is a spot where I've got to respectfully disagree with Mr. Hickey. Changing a public API call that used to guarantee that it returned a value so that it might now return nothing is a breaking change, and, as an API consumer, I want my APIs to broadcast that change loudly. Compiler errors are a good (but not the only) way to do that. Changing a public API member so that its arguments are now `Maybe[T]` is just si…

This is backwards. Rich did not advocate for changes that break promises. The point in the talk is that "strengthening a promise" should not be a breaking change. Changing return type from "T or NULL" to always returning T. The case where you previously couldn't guarantee a result, but now you can. The other case "relaxing a requirement" also should not be a problem. The case where you previously had to give me a val…

TBH, I'm happy with that being a breaking change, too. Just keep returning a T? that happens to always have a value until the next major version # increment (or whatever), and then make the breaking change, and then I get a clear signal that I can delete some lines of code.

The alternative seems like a path that, in any decently complex software project, ultimately leads to an accumulation of useless cruft that'll probably continue to grow over time as people keep copy/pasting code that contained the now-useless null-handling logic.

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

#270

Post by yxhuvud » Tue, Dec 04, 2018, 7:05 PM UTC

Honestly, I feel that the problem isn't null but that type systems (at least earlier on) tended to allow other types to be null, willy-nilly. Null is best considered a separate type to non-null values, and is basically not a problem if the type system handles that in some way. Be it option or union types - both solve it and it mostly stops being an issue.