--- a/content/blog/2018/08/a-road-to-common-lisp.markdown Mon Aug 13 00:05:06 2018 +0000
+++ b/content/blog/2018/08/a-road-to-common-lisp.markdown Mon Aug 13 06:36:09 2018 +0000
@@ -127,13 +127,13 @@
index. You can get a surprising amount done by writing pure Common Lisp
without much extra support.
-When programming in Common Lisp people will tend to depend on a small(ish)
-number of libraries, and library writers often try to minimize dependencies by
-utilizing as much of the core language as possible. I personally try to stick
-to fewer than ten or so dependencies for my applications and no more than two or
-three for my libraries (and preferably zero, if possible), but I'm probably
-a bit more conservative here than most folks. I *really* don't like the Hamster
-Wheel.
+When programming applications in Common Lisp people will tend to depend on
+a small(ish) number of stable libraries, and library writers often try to
+minimize dependencies by utilizing as much of the core language as possible.
+I personally try to stick to fewer than ten or so dependencies for my
+applications and no more than two or three for my libraries (and preferably
+zero, if possible), but I'm probably a bit more conservative here than most
+folks. I *really* don't like the Hamster Wheel.
It's also worth noting that since Common Lisp has been around and stable for so
long, it has *libraries* older and more stable than many programming languages.
@@ -153,10 +153,8 @@
Part of Common Lisp's practicality comes from its extensibility. No one has
been clamoring for a new version of the specification that adds features because
-Common Lisp gives users enough power to add new features to the language without
-having to alter the core language as libraries.
-
-TODO tradeoffs
+Common Lisp gives users enough power to add new features to the language as
+plain old libraries, without having to alter the core language.
Macros are what might come to mind when you hear "Lisp extensibility", and of
course that's part of it. Macros allow users to write libraries that would need
@@ -174,7 +172,8 @@
Pattern matching syntax can make for some really beautiful, readable code.
Common Lisp doesn't include it, but of course [there's a library][trivia].
-Enjoying algebraic data types in Haskell or Scala? Here's your [library][cl-adt].
+Enjoying algebraic data types in Haskell or Scala? Here's your
+[library][cl-adt].
All of these libraries rely on macros to make using them feel seamless. Of
course you could *do* all of that without macros, but you've have to add a layer
@@ -191,20 +190,28 @@
((vector x y) (- x y)))
No one's up in arms trying to get a new revision of the Common Lisp standard to
-add pattern matching because you can write it as a library and get 95% or more
+add pattern matching because you can write it as a library and get 90% or more
of what you've get if it were built in. The language gives you enough power to
extend it in a way that feels like the extension was there from the beginning.
+Having things that are core features in other languages be provided by libraries
+might seem at odds with the previous section about minimizing dependencies, and
+to some extent that's true. But I think there's a happy medium where you can
+write stable libraries in the core language and then depend on a small number of
+those libraries in your applications to add exactly the features you need for
+any particular problem.
+
#### Power
-Macros are one of the things that make Lisp so incredibly extensible, because
-they let you transform arbitrary code into other arbitrary code. This is true
-for macros in languages like C too, but Common Lisp macros are fundamentally
-different because they're *part of the language*.
+Macros are one of the things that make Lisp so extensible, because they let you
+transform arbitrary code into other arbitrary code. This is true for macros in
+languages like C too, but Common Lisp macros are different because they're *part
+of the language*.
In C you have a layer of macros on top, written in a preprocessor macro
language. The macro layer and the language layer are separate from each other,
-with the macro layer providing one one extra level of abstractive power.
+with the macro layer providing one one extra level of abstractive power (which
+is certainly useful).
In Common Lisp, you write macros *in Common Lisp itself*. You can then use
those macros to write functions, and use those functions to write more macros.