4 ms·

I have a pet peeve whenever people bring up the old "Billion dollar mistake" quote. Calling it a mistake means that it could have been avoided. But we couldn't

I have a pet peeve whenever people bring up the old "Billion dollar mistake" quote. Calling it a mistake means that it could have been avoided. But we couldn't have avoided null pointer errors (or some other name for the same thing) any more than humans could have avoided the bronze age. In the 60s and 70s we didn't have the "technology" to avoid null errors. By technology I mean production-ready languages with a static typing layer sophisticated enough to implement a Maybe/Optional type. Those languages weren't production ready until maybe around the 80s. And most of those compilers were themselves implemented in unsafe-null languages like C. But anyway, that's history, now we have nice languages that have safe nulls, so the interesting questions moving forward are: why are people still creating new languages that have unsafe nulls (looking at you Go), and why are people still choosing to use languages with unsafe nulls?

wvenable 8y ago
The real billion dollar mistake was nullable references in Java and C#. By then we should have known these things need an extra type-specifier. But Java was meant to be simple and easy. References in C++ are non-nullable so the precedent already existed. I hope C# gets around to solving this problem -- Microsoft is working on it -- but it's much harder to retroactively solve it.
- zvrba 8y ago
  > References in C++ are non-nullable so the precedent already existed. Wrong analogy. References in C++ are not first-class entities. Conceptually, they're _alias names_ for existing objects. Unlike C# and Java "references", you cannot "reset" a C++ reference to "point" to another object. Because it's not a pointer. It does not "point". It's an alias. `void f(int& ref)` in C++ is the same as `void f(ref int x)` in C# (the equivalent doesn't exist in java). Inside `f`, you cannot change `x` to "point to some other int" because it's not a pointer! C# and Java "references" are semantically the same as C++ pointers minus arithmetic.
  - AstralStorm 8y ago
    Yes, C++ can have nonnullable smart pointers just fine if that is what you want. They will lose reset call, throw on assigning null T*, static assert on nullptr_t, require full initialization on construction, have maximum exception safety. This could've been done since 2003 but wasn't. There are attempts to bring it into language as part of C++ Core Guidelines project. This is possible because unlike Java and C# not everything can be null.
  - jcelerier 8y ago
    > C# and Java "references" are semantically the same as C++ pointers minus arithmetic. But you can entirely write a shitton of C++ programs that won't use pointers at all - not even shared / unique. In contrast, you can't avoid C# and Java references.
    - vbezhenar 8y ago
      Can you show an example of linked list data structure without pointers?
      - jcelerier 8y ago
        In more than ten years of programming in C++ I never had once to implement a linked list. That's 100% irrelevant to programming practice. The only reason to implement one is whether it's for academic purposes, else just use `std::{s,}list`.
        vbezhenar 8y ago
        Using std::list which uses pointers is using pointers.
        jcelerier 8y ago
        ... no it's not. Else by that logic you'd be using pointers through any programming language.
ychen306 8y ago
Why is null in Go unsafe?
- seandougall 8y ago
  Presumably because there’s no language-level way to guarantee a pointer to be non-nil at compile time, combined with nil dereferencing being a crash. Not unsafe in the security sense, but definitely unsafe in the “can I count on my program to run” sense.
- Freaky 8y ago
  res, err := http.Get("wcpgw") defer res.Body.Close() ... panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x5ed9af]
tpush 8y ago
There really isn't anything sophisticated about having sum types, ALGOL 68 had them in some form for crying out loud.
smadge 8y ago
You don’t even need fancy static type checkers to avoid this. You literally just have to not have a null and not allow initialization of variables without values. It is more work to add null to your language than to not have null.
- xamuel 8y ago
  >not allow initialization of variables without values Then you've thrown in the towel when it comes to optimality. Not saying this is necessarily bad (maybe you're inventing the next Python), but acknowledge this isn't really an acceptable option for the next C.
cdoxsey 8y ago
Ironically you can make nullsafe methods in Go type X struct{} func (x *X) y() {} func main() { var x *X = nil x.y() // no error } Also its not unsafe. Go doesn't allow unsafe memory access unless you use the unsafe package. It is incorrect though. An Go does allow you to write bugs.
icebraining 8y ago
The creator has a different story; he portrays it as very much avoidable: "My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement."
alkonaut 8y ago
There were better languages but Unix won, and with that - C. A mistake we (whoever “we” are) repeated with JavaScript - we let the language win that was “there”, not the one we really needed. Worse is better. Ease of deployment over ease of development. As for the Q: why design languages with null (that is - incomplete or flawed type systems) now? I have o idea. I think the reasoning is that “worse is better” succeeded for JS, php, C, so it’s a viable path. “Maybe an X” and “Definitely an X” are more different than string and number. If a language pretends string and number are distinct but at the same time has no distiction for “maybe X” - then it doesn’t have a very good type system. Note that it doesn’t necessarily need to avoid null values for this. Non-nullables is mostly equivalent although less elegant. That is, “String s” means a string or null, while “String! s” means a non-null string (example from a C# vNext syntax).
- ItsMe000001 8y ago
  > we let the language win that was “there”, not the one we really needed. Different explanation of history: Something "wins" because it is precisely what is needed.
  - alkonaut 8y ago
    It does - but I think sometimes somethinb should have “won” that solved the short term problem 95% as well, but solves the problems over the next 4 decades better The Q is why individuals and companies would pay short term for gains to others.
- peoplewindow 8y ago
  Kotlin has null, but also nullability in the type system. They kept it in for interop purposes. Also, optionality is very common, so having it integrated into the language makes it more convenient and efficient.
kadenshep 8y ago
> In the 60s and 70s we didn't have the "technology" to avoid null errors. Yes we did.

wvenable 8y ago

The real billion dollar mistake was nullable references in Java and C#. By then we should have known these things need an extra type-specifier. But Java was meant to be simple and easy. References in C++ are non-nullable so the precedent already existed. I hope C# gets around to solving this problem -- Microsoft is working on it -- but it's much harder to retroactively solve it.

zvrba 8y ago
> References in C++ are non-nullable so the precedent already existed. Wrong analogy. References in C++ are not first-class entities. Conceptually, they're _alias names_ for existing objects. Unlike C# and Java "references", you cannot "reset" a C++ reference to "point" to another object. Because it's not a pointer. It does not "point". It's an alias. `void f(int& ref)` in C++ is the same as `void f(ref int x)` in C# (the equivalent doesn't exist in java). Inside `f`, you cannot change `x` to "point to some other int" because it's not a pointer! C# and Java "references" are semantically the same as C++ pointers minus arithmetic.
- AstralStorm 8y ago
  Yes, C++ can have nonnullable smart pointers just fine if that is what you want. They will lose reset call, throw on assigning null T*, static assert on nullptr_t, require full initialization on construction, have maximum exception safety. This could've been done since 2003 but wasn't. There are attempts to bring it into language as part of C++ Core Guidelines project. This is possible because unlike Java and C# not everything can be null.
- jcelerier 8y ago
  > C# and Java "references" are semantically the same as C++ pointers minus arithmetic. But you can entirely write a shitton of C++ programs that won't use pointers at all - not even shared / unique. In contrast, you can't avoid C# and Java references.
  - vbezhenar 8y ago
    Can you show an example of linked list data structure without pointers?
    - jcelerier 8y ago
      In more than ten years of programming in C++ I never had once to implement a linked list. That's 100% irrelevant to programming practice. The only reason to implement one is whether it's for academic purposes, else just use `std::{s,}list`.
      - vbezhenar 8y ago
        Using std::list which uses pointers is using pointers.
        jcelerier 8y ago
        ... no it's not. Else by that logic you'd be using pointers through any programming language.

ychen306 8y ago

Why is null in Go unsafe?

seandougall 8y ago
Presumably because there’s no language-level way to guarantee a pointer to be non-nil at compile time, combined with nil dereferencing being a crash. Not unsafe in the security sense, but definitely unsafe in the “can I count on my program to run” sense.
Freaky 8y ago
res, err := http.Get("wcpgw") defer res.Body.Close() ... panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x5ed9af]

tpush 8y ago

There really isn't anything sophisticated about having sum types, ALGOL 68 had them in some form for crying out loud.

smadge 8y ago

You don’t even need fancy static type checkers to avoid this. You literally just have to not have a null and not allow initialization of variables without values. It is more work to add null to your language than to not have null.

xamuel 8y ago
>not allow initialization of variables without values Then you've thrown in the towel when it comes to optimality. Not saying this is necessarily bad (maybe you're inventing the next Python), but acknowledge this isn't really an acceptable option for the next C.

cdoxsey 8y ago

Ironically you can make nullsafe methods in Go type X struct{} func (x *X) y() {} func main() { var x *X = nil x.y() // no error } Also its not unsafe. Go doesn't allow unsafe memory access unless you use the unsafe package. It is incorrect though. An Go does allow you to write bugs.

icebraining 8y ago

The creator has a different story; he portrays it as very much avoidable: "My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement."

alkonaut 8y ago

There were better languages but Unix won, and with that - C. A mistake we (whoever “we” are) repeated with JavaScript - we let the language win that was “there”, not the one we really needed. Worse is better. Ease of deployment over ease of development. As for the Q: why design languages with null (that is - incomplete or flawed type systems) now? I have o idea. I think the reasoning is that “worse is better” succeeded for JS, php, C, so it’s a viable path. “Maybe an X” and “Definitely an X” are more different than string and number. If a language pretends string and number are distinct but at the same time has no distiction for “maybe X” - then it doesn’t have a very good type system. Note that it doesn’t necessarily need to avoid null values for this. Non-nullables is mostly equivalent although less elegant. That is, “String s” means a string or null, while “String! s” means a non-null string (example from a C# vNext syntax).

ItsMe000001 8y ago
> we let the language win that was “there”, not the one we really needed. Different explanation of history: Something "wins" because it is precisely what is needed.
- alkonaut 8y ago
  It does - but I think sometimes somethinb should have “won” that solved the short term problem 95% as well, but solves the problems over the next 4 decades better The Q is why individuals and companies would pay short term for gains to others.
peoplewindow 8y ago
Kotlin has null, but also nullability in the type system. They kept it in for interop purposes. Also, optionality is very common, so having it integrated into the language makes it more convenient and efficient.

kadenshep 8y ago

> In the 60s and 70s we didn't have the "technology" to avoid null errors. Yes we did.