Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Null References: The Billion Dollar Mistake (2009) [video]

infoq.com

Post reply on HN
Print view View original

71–80 of 130 posts

Re: Null References: The Billion Dollar Mistake (2009) [video]

#71

Post by lmm »

AnimalMuppet wrote: post #64
lmm wrote: post #63

Earlier quoted context omitted.

Yes. Make illegal states unrepresentable.

And how exactly do you propose to do that? Here's a variable length array. Valid indexes are either [0...length-1] or [1...length], depending on which indexing arrangement you prefer. You can make -1 impossible by using an unsigned type. But for the index of a variable length array, how do you make length+1 unrepresentable?

Use some kind of range type, or, better, a type that represents "index into this array" (which needs some form of dependent typing, but is very much doable).

Re: Null References: The Billion Dollar Mistake (2009) [video]

#72

Post by [deleted] »

kristoff_it wrote: post #42
mjevans wrote: post #9

Earlier quoted context omitted.

I think golang's slices are a better solution than the linked article. https://go.dev/ref/spec#Slice_types Slices can still be nil (null), but it isn't an unsafe memory access operation, just another type of potentially useful or potentially errant invocation to handle.

Go's slices are more akin to ArrayLists / Vectors in other languages, since they also manage the underlying buffer.

[deleted]

Re: Null References: The Billion Dollar Mistake (2009) [video]

#73

Post by LorenPechtel »

lmm wrote: post #63
petilon wrote: post #7

If null references are a mistake, isn't initializing an array index variable to -1 a mistake too?

Yes. Make illegal states unrepresentable.

The problem is that you don't always have a legal state, especially at object creation.

If you forbid illegal states you end up with fake objects taking the place of non-existent real ones. (What's Find supposed to return if it's not there??) In most cases it's better to blow up when you try to work with a null than to mistakenly work with something that takes the place of a null. A null is easier to detect and thus the better solution.

Yeah, well implemented nullable and not-nullable types are good but the compilers didn't have that kind of smarts in the old days.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#74

Post by AnimalMuppet »

lmm wrote: post #71
AnimalMuppet wrote: post #64

Earlier quoted context omitted.

And how exactly do you propose to do that? Here's a variable length array. Valid indexes are either [0...length-1] or [1...length], depending on which indexing arrangement you prefer. You can make -1 impossible by using an unsigned type. But for the index of a variable length array, how do you make length+1 unrepresentable?

Use some kind of range type, or, better, a type that represents "index into this array" (which needs some form of dependent typing, but is very much doable).

A range type has the problem that it's not necessarily valid indexes for this array - it could be for some other array. "Index into this array" is, as you say, better (presumably it keeps a pointer or a reference or something to the array), but even that isn't bulletproof. Something like realloc could shrink the array but keep the same pointer, or the array could be deallocated and a new one allocated that happened to get the same address.

What you really need is that the array keeps track of its own limits - something like std::vector or Java's ArrayList. But then you're back to the overhead of checking each access.

So... I'm still not seeing how you're making illegal states unrepresentable.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#75

Post by HWR_14 »

kilgnad wrote: post #67
asguy wrote: post #26

Earlier quoted context omitted.

This is what C/C++ haters, anti x86/amd64 snobs, and Rust elitists always forget: what works, works. Sure, it could be a local maximum, hopefully there will be better, but who knows? To quote Sean Connery in The Rock: Losers always whine about their best. Winners go home and fuck the prom queen! https://m.youtube.com/watch?v=gXDSxgDUv-c

The prom queen fucked the only thing that was available. Nowadays the prom queen has tinder, loads of competing options and is woke.

Unless you went to a very small school, the prom queen always had lots of options. That's the point of the quote. Tinder is irrelevant. The winners are the people who eventually she chooses.

As for "is woke", I have no idea how to read that point.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#76

Post by WalterBright »

unxdfa wrote: post #49
nicoburns wrote: post #12

Earlier quoted context omitted.

They're probably BOTH quite literally billion dollars mistakes.

I can confirm I have fucked up on numerous occasions which resulted in NPEs which caused business processes to fail spectacularly and write off millions of dollars instantly. Fortunately in every case it was possible to recover, replay or repair the data so the only real cost was a little bit of reputation and time and money. But that adds up across tens of thousands of engineers, probably to billions by now globally…

> the real issue is that a process can fail spectacularly and do any damage at all

Yes, you nailed it!

Re: Null References: The Billion Dollar Mistake (2009) [video]

#77

Post by WalterBright »

im3w1l wrote: post #57
WalterBright wrote: post #51

Earlier quoted context omitted.

> Thankfully governments have finally start paying attention regarding software liability. And we'll see a great slowdown in the software industry.

For every year the industry becomes more mature. And with maturity comes less need for speedy innovation, and higher need for quality and reliability. It may happen in five years or in twenty, but it seems almost certain that it must happen.

Software naturally grows more reliable every year. Government intervention won't improve things.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#78

Post by WalterBright »

saagarjha wrote: post #61
WalterBright wrote: post #28

Earlier quoted context omitted.

D slices can be null, but they're not a mistake, as the runtime will not let you read/write a 0 length array.

What's the relation between a null slice and a 0-length array?

Neither can be successfully indexed.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#79

Post by WalterBright »

Arch-TK wrote: post #55
WalterBright wrote: post #30

Earlier quoted context omitted.

The article I referenced says how this is fixed. It is not harder to write at all.

Adding fat pointers to C is a major redesign and the fact that the explanation fits within a short blog post doesn't make it an easy fix. If you don't add fat pointers (thereby requiring a major re-design of the language and causing an endless amount of pain with regards to ABIs etc) then the solution, which involves removing the implicit conversion of an array to a pointer to its first element in expressions where i…

> Adding fat pointers to C is a major redesign

No, it isn't. I implemented it in D, and know what is involved. I've written two C compilers, as well.

> the fact that the explanation fits within a short blog post doesn't make it an easy fix.

Correct, but since I've actually done it, I'm in a good position to say it is an easy fix.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#80

Post by lmm »

LorenPechtel wrote: post #73
lmm wrote: post #63

Earlier quoted context omitted.

Yes. Make illegal states unrepresentable.

The problem is that you don't always have a legal state, especially at object creation. If you forbid illegal states you end up with fake objects taking the place of non-existent real ones. (What's Find supposed to return if it's not there??) In most cases it's better to blow up when you try to work with a null than to mistakenly work with something that takes the place of a null. A null is easier to detect and thus…

> If you forbid illegal states you end up with fake objects taking the place of non-existent real ones.

You don't use a fake object, you use a real one of a different type. In the cases where what you want is "maybe this thing, maybe nothing" you can use an option/maybe type. In the cases where you want something else (e.g. "either this thing or an error message") you can use a type that represents that.

> Yeah, well implemented nullable and not-nullable types are good but the compilers didn't have that kind of smarts in the old days.

ML had well typed optionals back in the '70s. There's no excuse for using a language that needs null today.

Post reply on HN