On: A case study on strict null checks

[CraigJPerry]

There’s another approach - where null takes on contextual meaning.

   List<Integer> f = null;
   f.add(1);

This is clearly a NullPointerException in Java but in a language with Nil punning, f is automatically a list containing 1.

    (conj nil 1)
    ;;=> (1)

[monoideism → CraigJPerry]

Sure, I’m not asserting it’s the only way to handle nulls.

That said, for me personally, nil punning is uncomfortably close to the kind of weak typing (like in traditional JS) that can be catastrophic in large code bases.

However, I’ve never worked with a large code base in a Lisp - whereas I have with various statically-typed functional and non-functional languages - and I find static typing, particularly Option types, very valuable.

[shhsshs → monoideism]

> That said, for me personally, nil punning is uncomfortably close to the kind of weak typing (like in traditional JS) that can be catastrophic in large code bases.

I think it would be totally fine and safe if “nil” is identical to an empty list in every scenario. In other words, nil is just a shorthand/synonym for an empty list.

Go kind of does that, for example. The only time it’s actually handled differently in my experience is in JSON serialization (which I personally believe was a terrible decision)

[monoideism → shhsshs]

> I think it would be totally fine and safe if “nil” is identical to an empty list in every scenario

Yes, I agree. But even in Scheme, that's not the case. I'm not familiar enough w/Go to comment - I'll have to check it out.

[kazinator → monoideism]

I've only ever carved out solutions with stone knives and bearskins. I find stone knives very valuable.

[monoideism → kazinator]

Yes, noted caveman technology Haskell.

In terms of dynamic languages, I’ve also worked with a great deal of Python and JavaScript, with significantly less success on large codebases (which could be due to selection bias, admittedly).