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

121–130 of 130 posts

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

#121

Post by bitwize »

asguy wrote: post #26
LanceH wrote: post #5

Earlier quoted context omitted.

Which would all be a rounding area if C gets to take credit for everything produced using it.

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

1) Connery's character's attempt to out-chad Cage's character failed because the latter replied: "Carla was the prom queen."

2) The proportion of prom queen fuckers among systems programming experts is probably much lower than among the general population.

3) The real Unix philosophy is a perverse form of "worse is better", i.e., it prefers making it easy to slap together something that kinda sorta works without worrying about "edge cases" that people are likely to run into, over crafting a reasonably complete, responsible solution. C is the result of this philosophy applied to language design. If it hadn't been for Unix becoming ubiquitous, we wouldn't have made that disastrous choice.

(Come to think of it, under this rubric, Electron is a Unix philosophy exemplar.)

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

#122

Post by LorenPechtel »

pjmlp wrote: post #113
LorenPechtel wrote: post #73

Earlier quoted context omitted.

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…

Easily solved by making an error to read before write, several languages do it.

But that's runtime expensive, or else very restrictive on the compiler.

Bad data should fail fast and null is good at doing that.

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

#123

Post by lmm »

GoblinSlayer wrote: post #104
lmm wrote: post #80

Earlier quoted context omitted.

> 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…

In C++ std::optional ::value throws an std::bad_optional_access exception when the value is missing. How is this different from a NullPointerException?

> How is this different from a NullPointerException?

It's different because most things can't throw it. The problem isn't that your language has a way to implement a value that might be absent, the problem is that your language does't have a way to implement a (heap) value that won't be absent, except by convention.

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

#124

Post by mhh__ »

Arch-TK wrote: post #119
mhh__ wrote: post #109

Earlier quoted context omitted.

The length is there but you can't access it.

Okay, so you agree that the array hasn't decayed, disappeared or otherwise stopped existing and that the word "decay" is a poor choice to describe what is happening?

Nope, Walter is right.

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

#125

Post by asguy »

bitwize wrote: post #121
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

1) Connery's character's attempt to out-chad Cage's character failed because the latter replied: "Carla was the prom queen." 2) The proportion of prom queen fuckers among systems programming experts is probably much lower than among the general population. 3) The real Unix philosophy is a perverse form of "worse is better", i.e., it prefers making it easy to slap together something that kinda sorta works without worr…

> 1) Connery's character's attempt to out-chad Cage's character failed because the latter replied: "Carla was the prom queen."

Your calibration is off: he wasn’t trying to put-Chad him.. he was telling him to “git gud”

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

#126

Post by pjmlp »

LorenPechtel wrote: post #122
pjmlp wrote: post #113

Earlier quoted context omitted.

Easily solved by making an error to read before write, several languages do it.

But that's runtime expensive, or else very restrictive on the compiler. Bad data should fail fast and null is good at doing that.

It is done at compile time.

For example in C#, you would get something like "Use of unassigned local variable xyz".

If the performance cost of initilizing the variable is such an unberable cost, there is [SkipLocalsInit].

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

#127

Post by GoblinSlayer »

lmm wrote: post #123
GoblinSlayer wrote: post #104

Earlier quoted context omitted.

In C++ std::optional ::value throws an std::bad_optional_access exception when the value is missing. How is this different from a NullPointerException?

> How is this different from a NullPointerException? It's different because most things can't throw it. The problem isn't that your language has a way to implement a value that might be absent, the problem is that your language does't have a way to implement a (heap) value that won't be absent, except by convention.

If the value won't be absent, then it won't throw.

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

#128

Post by LorenPechtel »

pjmlp wrote: post #126
LorenPechtel wrote: post #122

Earlier quoted context omitted.

But that's runtime expensive, or else very restrictive on the compiler. Bad data should fail fast and null is good at doing that.

It is done at compile time. For example in C#, you would get something like "Use of unassigned local variable xyz" . If the performance cost of initilizing the variable is such an unberable cost, there is [SkipLocalsInit] .

Which works in *most* cases. I forget the details but I do recall running into a case where it was griping erroneously (it couldn't reach the use without having reached the initialization) so I gave it a harmless initial value--and it turned around and complained (correctly) that the assignment would never be used. I insist on removing all such warnings so I ended up restructuring the code so the compiler wouldn't get confused.

(Fundamentally, this was a case of a child operation that *might* be needed. It could have been rewritten polymorphically but that would have involved a fair amount of refactoring.)

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

#129

Post by lmm »

GoblinSlayer wrote: post #127
lmm wrote: post #123

Earlier quoted context omitted.

> How is this different from a NullPointerException? It's different because most things can't throw it. The problem isn't that your language has a way to implement a value that might be absent, the problem is that your language does't have a way to implement a (heap) value that won't be absent, except by convention.

If the value won't be absent, then it won't throw.

I'd like to know that the value won't be absent when I build the code rather than when I execute it.

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

#130

Post by pjmlp »

LorenPechtel wrote: post #128
pjmlp wrote: post #126

Earlier quoted context omitted.

It is done at compile time. For example in C#, you would get something like "Use of unassigned local variable xyz" . If the performance cost of initilizing the variable is such an unberable cost, there is [SkipLocalsInit] .

Which works in *most* cases. I forget the details but I do recall running into a case where it was griping erroneously (it couldn't reach the use without having reached the initialization) so I gave it a harmless initial value--and it turned around and complained (correctly) that the assignment would never be used. I insist on removing all such warnings so I ended up restructuring the code so the compiler wouldn't ge…

Declare the variable closer to its definition point.

Also such kind of situations are usually a sign that code blocks should be moved into a separate function.

Post reply on HN