Lisp and Haskell (2015)

Lisp and Haskell (2015)
markkarpov.com

I'm always a little frustrated whenever I see this aphorism perpetuated since I think it gives the impression that a static type system is doing more than it is actually doing. In type systems that are used outside of academia, the main thing your static types are doing is checking whether the shapes of your data and functions all line up. With some small exceptions, that's it: the compiler will tell you if your LEGOs fit together, but not if you've built a knife instead of a fork.

I know what this aphorism is getting at, which is that in some domains and circumstances a lot of your bugs are "shape" errors, and it's gratifying when you're writing OCaml or Java and you can, say, refactor without hesitation, knowing the compiler will find even the most unused paths where you need to modify an invocation of your function. But it's been my and others' experience that there are many times where this isn't your most pressing concern, and could in fact be a pretty boring concern that you don't even want to pay the type annotation tax for. (I also think there's something to the idea that a static type system can instill too much confidence and encourage the pursuit of bad abstractions like 18-arg functions that can no longer be effectively reasoned about by an unaided human mind, but that's another topic.)

That being said, having worked professionally in Lisp, the “un-lispy” macros like Loop are some of the worst parts of that language. They completely violate the otherwise standard-ish syntax of Lisp, are very poorly documented, impossible to memorize, and are really hard to debug despite the otherwise excellent tooling available for top tier implementations like SBCL. It was our standard practice to replace these macros with more verbose but idiomatic lisp whenever possible.