Hacker News Reader

Comment by paulhodge | Hacker News Reader

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?

View on HN

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

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

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.

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.

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

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

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.

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

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.

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

Can you show an example of linked list data structure without pointers?

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

Using std::list which uses pointers is using pointers.

... no it's not. Else by that logic you'd be using pointers through any programming language.

My C++ is rusty but you'd do it exactly like you do in ML. Something like:

    template<typename T> class List<T> {
      protected:
        List();
      template<typename U> class Visitor<U> {
        public:
          U visitNil();
          U visitCons(T current, U accumulator);
      }
      public:
        virtual <U> U visit(Vistor<U> visitor);
    }
    template<typename T> class Nil<T> extends List<T> {
      U visit(Visitor<U> visitor) = visitor.visitNil();
    }
    template<typename T> class Cons<T> extends List<T> {
      private:
        T head;
        List<T> &tail;
      public:
        Cons(T head, List<T> &tail) {
          this.head = head;
          this.tail = tail;
        }
      U visit(Visitor<U> visitor) = visitor.visitCons(head, tail.visit(visitor));
    }

Thanks, that neat. But how would you build a list of arbitrary length and free it later? You'll use pointers, one way or another. The only way to avoid pointers I could imagine is to use stack with recursion, but that's completely crazy and limited programming style.

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.

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

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.

Why is null in Go unsafe?

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.

    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]

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

Yes we did.

Reply on news.ycombinator.com