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

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

#231

Post by giornogiovanna » Tue, Dec 04, 2018, 5:33 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…

Yep! It's worth restating the fact that wrapping a pointer in an Option in Rust actually takes up NO extra space, because Rust's smart enough to just optimize it back into a nullable pointer.

https://doc.rust-lang.org/std/ptr/struct.NonNull.html

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

#232

Post by trophycase » Tue, Dec 04, 2018, 5:33 PM UTC

I don't write business software that needs many 9s of uptime so I find null to be fine. Yes, returning null is kind of throwing your hands up but I find that to be kind of the point. It allows my software to fail fast if it does and makes it incredibly obvious where things are going wrong. Generally if a reference has a value of null where it shouldn't, I can pinpoint the location of the bug within a few minutes or even seconds.

IMO it makes the program much easier to reason about compared to returning some sort of empty value and then failing much much later in the program.

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

#233

Post by rusk » Tue, Dec 04, 2018, 5:34 PM UTC

icebraining wrote: post #215

rusk wrote: post #189

Earlier quoted context omitted.

Which is the same as if I go and ensure a default "noop" value is assigned ... it's logically a NULL. I don't know anything about it except that it hasn't been assigned.

It's not a NULL. A NULL is a value that is considered by the type system to be a valid instance of a given type, except it doesn't actually fulfill the type's contract. A Maybe is a completely different type, much like a list or a map or a tree.

Well at this stage you're just being narrow minded.

I think if you read back over this thread it should be clear what I mean.

I proposed that NULL has a purpose. You proposed that Option obviates this. I stress that it's just a neater way to manage the conditions you don't need to model. You point out that in terms of implementation it's different, where I explain that still, logically it's the same thing.

Of course NULL has a very specific meaning in the structure of the language, and when you start using things like Options it makes managing NULL easier, but it's a rose by another name, gift-wrapped, and bundled with some plant food.

Logically however, at the point where you're modelling your problem it's the same.

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

#234

Post by kybernetikos » Tue, Dec 04, 2018, 5:39 PM UTC

based2 wrote: post #60

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.

Maybe Not - Rich Hickey (clojure), 29 nov. 2018 https://www.youtube.com/watch?v=YR5WdGrpoug https://dotty.epfl.ch/docs/reference/intersection-types.html

Yes, 'maybe not' is very relevant to this discussion, but few people seem to agree with my understanding of what he says about the right solution:

Optionality doesn't fit in the type system / schema, because it's context dependent. For some functions, one subset of the data is needed, for others a different subset. Trying to mash it into the type system / schema is just fundamentally misguided.

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

#235

Post by masklinn » Tue, Dec 04, 2018, 5:40 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.

> I've made my peace with null. Null is basically just an implicit

That very much depends on the language:

1. it can be a compile-time error (Swift)

2. it can be a runtime error (java, C#)

3. it can depend on what you're actually using (Python, Ruby, and on runtime extensions you might have loaded in the latter case)

4. it can be a no-op (objective-c)

5. it can depend on the combination of platform, compiler and surrounding code going from a segfault to deleting your program's security and/or causality (C, C++)

6. it can depend on the implementation and exact codepaths (Go)

etc...

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

#236

Post by davemp » Tue, Dec 04, 2018, 5:40 PM UTC

giornogiovanna wrote: post #228

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…

NULL isn't the uninhabited type, that's the bottom type. NULL is a value that inhabits every type.

Thank you. I got confused on nomenclature because of a null pointer's similarity to the bottom type.

I was trying to say that having a NULL value that inhabits every type seems silly as not every set of values has the NULL value. Considering that NULL can be represented as a special case of sum types, it seems even sillier to mandate such a value on all types.

Using both NULL and nullable seems very confusing as well.

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

#237

Post by masklinn » Tue, Dec 04, 2018, 5:41 PM UTC

cmrdporcupine wrote: post #85

mehrdadn wrote: post #83

Earlier quoted context omitted.

In C++ I practically never feel like I need a null for anything but a pointer. A null string or integer makes no sense to me.

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

std::optional is a null-pointer use, it has the exact same semantics.

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

#238

Post by giornogiovanna » Tue, Dec 04, 2018, 5:41 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...

Just look at the example on Wikipedia[0]. Tagged unions are super-simple, and make NULL completely unnecessary. NULL causes lots of headaches, while tagged unions have never caused anyone headaches, so removing NULL is kind of the obvious thing to do. In a sufficiently advanced language, such as Rust, they get optimized to equivalent code anyway, so there isn't even any performance loss.

[0]: https://en.wikipedia.org/wiki/Tagged_union#Examples

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

#239

Post by rusk » Tue, Dec 04, 2018, 5:41 PM UTC

bfrydl wrote: post #155

rusk wrote: post #92

Earlier quoted context omitted.

> All you need is a list of what width each type is. This is exactly the kind of minutiae that GP was bemoaning. > If anything it pushes code to a slightly lower level Yeah by way of higher-level abstractions ...

> This is exactly the kind of minutiae that GP was bemoaning. How is this “minutiae”? You should always know the possible range of a numeric variable or field when you create it, so why not just write what size it is? In Rust the main numeric types look like this: i32, u64, u8. You just pick the one you want.

I'm sorry, I misunderstood you.

These typedefs as I'm used to them do address cross-platform issues.

Storage classes are "minutiae" however when all you want is just a straight up number.

Python gives me an Integer type when I want a whole number, or a Float when I want to represent partials.

I don't really care to be honest how that gets represented in memory in this case.

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

#240

Post by masklinn » Tue, Dec 04, 2018, 5:41 PM UTC

gnulinux wrote: post #139

mehrdadn wrote: post #94

Earlier quoted context omitted.

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?

std::optional doesn't do that though, you can deref an empty optional and the result's the same as deref'ing an empty unique_ptr or a null pointer: UB.