Hacker News Reader

Comment by SeanLuke | Hacker News Reader

This is a baloney C-biased question. The real question is why nil is falsey (ALONG with false) in Clojure.

To my mind this is an incredibly boneheaded mistake in a modern language. Common Lisp can be excused as it is old and has an even older ancestry. nil has been false in common lisp and its ancestors since forever, but this is an accident of history, and nobody claims it to be a good idea, as it is a source of many bugs. And indeed some lisp functions have to have additional gizmos added to them to work around it.

Scheme fixed this with real true and false constants. And then clojure, um, decided to combine the worst of both worlds, by making TWO things be false.

View on HN

> as it is a source of many bugs

Citation needed.

I worked with two languages that have exactly this same behavior (Clojure and Ruby), and both of them this is not the source of any bug that I can remember [1].

Also, I would argue that Clojure as a language is much more ergonomic thanks to `nil` being `falsey`, so this is all about the trade-offs between safety and ergonomics. Considering that, IMO, Clojure without nil being falsey would lose much more than Clojure being a more safe language, I really don't seem much problem.

[1]: well, there is one, where one of our internal tooling had this function called `assoc-if` that it would assoc a key to a map if truthy, however this also meant that when the key was of boolean type and false we would also not assoc this; but we eventually introduced `assoc-some` that does what you expect.

Two things being false can be quite pleasant, but making the empty list nil isn't worth it.

Lua gets this right, `nil` is the Ground State of Being, you get it back in lieu of a value any time you try to find one.

This requires also having a `false` because logical conditions have to be streamed sometimes and you can't transport a key with a nil value by definition.

But an empty list/table being 'false' is convenient right until it isn't. It's a kludge.

Scheme's explicit #f is false and everything else is truthy takes some getting used to, but conversely look at Tcl where boolean values are any numeric value (0 is falsy) or the strings: true, false, yes, no, on, off

False and nil being two distinct values isn't Clojure's fault though. Or not directly. There are a bunch of trade offs that Clojure makes to have very direct interop with its host languages.

Clojure sits on the JVM. Why can't false be false and nil be NULL?

I know of no other JVM-based lisp system which makes this "tradeoff". Indeed Kawa, which is rather faster than Clojure in my experience, does not.

Clojure's nil on the JVM and Java's null are the same value. Are we misunderstanding each other, or am I missing something?

I think we're talking past each other. Clearly in Clojure nil and false are different as NULL and false are different in Java. But in Clojure, they're both falsey, a really stupid design decision: but in Java they are NOT both falsey, only false is.

Nope, it's a great design decision.

Reply on news.ycombinator.com