3 ms·
I've written a great deal of Common Lisp and the only "easy things hard" I've encountered are fast matrix multiplications -- because there are many ways to do t
by dreamcompiler 3y ago
I've written a great deal of Common Lisp and the only "easy things hard" I've encountered are fast matrix multiplications -- because there are many ways to do this and they each have different tradeoffs, and implementing symmetric crypto algorithms that assume 32-bit word sizes. Because Lisp integers automatically grow when necessary, forcing arithmetic to stay within a 32-but limit is hard do do in pure Common Lisp efficiently. The solution is to write bottleneck routines in assembly, which the Lisp compiler I use (CCL) facilitates.
- sshine 3y agoI haven't written Lisp professionally, but my impression is that one place Lisp comes short is forcing convention: Every program, every module, is potentially its own DSL, so good luck getting programmers to agree on a convention. At least with more rigid languages like Java or Rust, when you open a file, you'll agree what language it is. Haskell has this problem, too. You need things like "Boring Haskell Manifesto" to discourage too much magic. Haskell has "pragmas" that modify the language extensions that turn Haskell into a space language. Pragmas can be enabled on a per-file basis. I like how the Rust toolchain addresses this by letting you gather things like "stable/nightly", "feature flags", "linter suppressions" in a config file at the project root, so that a team can agree on a set of conventions and have the toolchain sync with those decisions made in one place. This isn't strictly speaking programming language, but tooling, but it plays a big role in team governance and cooperation.