1. 9
  1. 4

    All of those design decisions (of earlier Lisps) don’t make sense today.

    Nil should be the empty list, and nothing else. Not a boolean (use #t and #f), not a symbol, not a marker for an uninteresting value (as returned by an empty (progn) for example; use #void). IF and other conditionals should only accept booleans. You shouldn’t be able to take the car/cdr of an empty list.

    While I’m at it, you shouldn’t use nil-punning. Use options/maybes instead. Yes, they work just fine in a dynamic language. See Taylor Campbell’s blag for 2006-02-03: https://mumble.net/~campbell/blag.txt

    1. 4

      I’ve had this opinion after going through liking truthiness & hating it in js & and then i tried clojure and I’m back in the way loving it.

      I think it takes more work to properly design truthiness into a language but god damn it is nice when it just works.

      1. 2

        Came here to say essentially this. Strict bool’s vs. truthiness are just different ways of looking at the world, both can be nice or terrible depending on the details and the situation. I think the key to doing truthiness well is to have one and only one value that is false, and don’t allow random things to silently coerce into it. CL does that pretty well, though you could easily imagine a world where it didn’t.

    2. 3

      I’d argue that Smalltalk/Ruby/Clojure(!)/etc. got this better: You have true, false, nil/null, and the empty list.

      Some scheme code uses false as a sentinel value, which means you have trouble passing “optional” bools around. And the empty list is often not a suitable sentinel value as it’s a value in it’s own right. You end up having n different sentinel values and no convenient if and need to map them around all the time.

      1. 2

        Some scheme code uses false as a sentinel value, which means you have trouble passing “optional” bools around.

        I’ve been working with SRFI 189: Maybe and Either: optional container types lately and appreciating it.