Hacker News Reader

Comment by Slackwise | Hacker News Reader

Clojure, like Ruby, does falseyness correctly in that there's only 2 cases of false: nil and false. Everything else is true. This is easy to reason about, and it allows for nils to "flow" through your logic (especially with nil-punning where in the context of collections, nil is also an empty sequence).

View on HN

Something even easier to reason about: Only true is true, and only false is false!

I disagree - presence/absence allows reuse of clear and terse operators, reduces the need for an extra null coalescence operator when logical or can do the job as well, and enables better developer experience in places like options hashes where "not set" always means the same thing as "false".

I think modern languages have demonstrated that the dev UX difference between allowing "falsey"/"truthy" and not allowing it can be reduced to be quite small. Meanwhile, consider that the bugs introduced by implicitly considering things false/true are arguably a type of "bad dev UX".

I can't think of a case, personally, where conflating false and nil/null/undefined has created a bug. I can think of many for, like, JS treating the empty string or zero as false, but not for specifically null/undefined. Can you provide an example?

You're talking about hard true/false, in which you are correct. The person you're replying to is talking about "Truthy"/"Falsy", which is different than the hard true/false you're talking about.

I read the parent as, slightly sarcastically, saying "it's easiest to reason when the concept of truthy/falsy is completely absent".

I do not agree that treating nil (or zero, or an empty collection) as false is "correct".

Colloquially, “nil” and “zero” are the same thing. Presumably not the case in clojure.

True, however in software there are many cases in which they're different. Simple example:

How many checked luggage items do you have?

nil means the user hasn't answered the question

0 means they saw the question and don't have any checked luggage.

in your example, the end result is the same. the user is not interested in luggage.

The difference between an answered and unanswered question is absolutely not the same. Nil means the user has not told us how much luggage they have. 0 means the user has 0 luggage. We can assume a lack of response means zero, or we can mark the field as required, in which case the UI needs to prompt the user for a response in the nil case but not the 0 case. This is an extremely simple, common example. There are many cases where nil is not equivalent to 0 semantically or logically.

no that's you assuming since that part was not filled.

Add Lua to the languages which chose to be sensible about this.

And Toit. Only null and false are falsey.

That's doing it almost correctly. The correct way to do truthiness is not to do it at all. `nil` should not be automatically coerced to `bool`.

Reply on news.ycombinator.com