[monoideism]

Because it’s very easy to write code that fails to check for null or undefined, which usually leads to errors since subsequent code often expects to find a non-null and non-undefined value.

The beauty of a type checker here is that it can check to make sure you properly handle the nullable/undefinable type.

[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]

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]

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

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

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

[monoideism]

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

[kazinator]

This is also why capital letters are bad.

It's easy to write code which fails to check for a capital letter, which leads to errors when subsequent code requires a lower-case letter.

Capital letters are a billion dollar boondoggle.

It behooves languages to have a lower-case (or non-capital) character type which cannot be constructed with or assigned a capital letter.

[smichel17]

I always interpreted that quote to mean that implicit nullability was a mistake. It's fine to have nulls, but not five to have them pop up anywhere randomly.

Capital letters are fine, but not if they randomly pop up when you thought you were only working in lowercase, and now suddenly all your string comparisons need a .toLoweR() on each side of the ==.

[thrower123]

In all seriousness, after nulls, I think I've seen more issues caused by case-sensitivity in string comparisons than by any other class of error.

Domain names. Email addresses. Windows UPNs. Windows filenames... All manner of LDAP shit.

[kazinator]

Must have been before Unicode. :)

[monoideism]

Mocking Tony Hoare - bold move:

https://www.infoq.com/presentations/Null-References-The-Bill...