1. 16

      Clojure: Its inconsistent treatment of nil remains hands-down the most common source of errors for the codebases I work on. Also tends to be a memory hog. Also bizarrely omits pattern matching from the core language, which is very silly.

      Fennel: Shame that the runtime doesn’t support concurrency. The zero-overhead design goal means that it can’t add creature comforts like map/filter/etc; you need to bring in a library for that.

      Elisp: Having functions split out into the lisp-2 namespace makes higher-order functions usually too tedious to be worth it. The built-in functions are inconsistently named with weird historical quirks.

      Racket: No matter what the question is, the answer will always be “write a macro”.

      1. 6

        Just wanted to pop in and say thanks for Leiningen :D

        1. 2

          Racket: No matter what the question is, the answer will always be “write a macro”.

          Hello, I’m a relatively new Racketeer here and I’ve yet to find a good reason to write a macro and in fact, have read a section of a delightful blog post that suggested reasons to prefer core Racket library functions over macros.

          In your opinion, how and why are macros the answer to questions with Racket? Thanks :)

          1. 2

            There are a lot of things which can be done at runtime in other lisps which have to be done at compile-time for Racket. For instance, Racket wants you to use structs instead of hash tables, which means you can’t do things like deeply nested updates with arbitrary field names; the fields need to be known at compile time. (Lenses help a lot with this, but Lenses don’t ship with Racket; they’re a 3rd-party library) For the most part it’s worth the trade-off to not have to deal with nil and for the errors it catches, but it’s awkward coming from languages that offer more flexibility. (I wrote a bit about it at https://technomancy.us/185)