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”.
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 :)
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)
I love this!
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”.
Just wanted to pop in and say thanks for Leiningen :D
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 :)
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)