3 ms·

This is exactly the 'null' bug, and the problem that's solved with a strongly-typed language and an `Optional<T>` or `Maybe T`. Then you are forced to deal wit

• didibus 5y ago
  Optional<T> actually has the same issue I think. Clojure properly handles "nil", the problem is not that you need something to force you to deal with not having a value right away, the problem is that Clojure automatically deals with the value not having a value right away for you. Imagine you have this: Optional<String> get(String k) { ... } get("fooo").orElse("not found"); This is the same bug, the bug being it's normal that "fooo" is missing, you should have written "foo" which is the real place where the data is supposed to be. Or imagine for any other reason `get` returns an Optional.empty() when it shouldn't. It's kind of the flip side of "null". Normally nulls are bad because of nullPointerException and people forgetting to handle null. Clojure in general handles null everywhere, and so you won't get nullPointerException, instead things will just work with whatever defaults makes sense for everything that comes after and is getting the null. That makes it harder to realize that the null is there not because it missing, but because you have a bug which makes it look like something is missing when it should be there.