--- a/content/blog/2018/08/a-road-to-common-lisp.markdown Fri Aug 24 19:27:03 2018 +0000
+++ b/content/blog/2018/08/a-road-to-common-lisp.markdown Mon Aug 27 14:57:58 2018 +0000
@@ -135,10 +135,10 @@
When programming applications in Common Lisp people will often 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 (preferably zero, if
-possible), but I'm probably a bit more conservative than most folks. I *really*
-don't like the Hamster Wheel.
+I try to stick to fewer than ten or so dependencies for my applications and no
+more than two or three for my libraries (preferably zero, if possible), but I'm
+probably a bit more conservative 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.
@@ -215,7 +215,7 @@
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 (which,
-don't get me wrong, is *certainly* useful).
+don't get me wrong, 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.
@@ -260,9 +260,9 @@
#### Ugliness
-It's also important to realize that while Common Lisp might be incredibly
-practical, the need to accommodate existing users and dialects means that there
-are ugly parts. If you buy a paper copy of the second edition of Common Lisp:
+It's also important to realize that while Common Lisp might be very practical,
+the need to accommodate existing users and dialects means that there are plenty
+of ugly parts. If you buy a paper copy of the second edition of Common Lisp:
the Language and look up "kludges" in the index you'll find this:
[](/media/images/blog/2018/07/lisp-kludge.jpeg)
@@ -307,10 +307,10 @@
If you search around on the internet for Common Lisp tutorials and guides,
you're not going to find as much as you might expect. This is because a lot of
-Common Lisp reference material was created before or during the infancy of
-the internet. There are a *lot* of books about Common Lisp out there. Some are
-better than others. I'll recommend the ones I personally think are the best,
-but don't hesitate to browse around and find others.
+Common Lisp reference material was created before or during the infancy of the
+internet. There are a *lot* of books about Common Lisp out there. Some are
+better than others. I'll recommend the ones I think are the best, but don't
+hesitate to browse around and find others.
### Get a Lisp
@@ -424,12 +424,12 @@
* When do I need the god damn quotation mark?
If you find the book is moving too slow, just skim forward a bit. Skimming is
-a very useful skill to practice as a programmer. I personally think it's
-better for authors to err on the side of explaining too much when writing books
-and documentation — expert readers should be comfortable skimming if you
-explain too *much*, but new users will be stuck wallowing in confusion if
-you're too terse. Creating hours of newbie misery and confusion to save a few
-flicks of an expert's scroll wheel is a poor tradeoff to make.
+a very useful skill to practice as a programmer. I think it's better for
+authors to err on the side of explaining too much when writing books and
+documentation — expert readers should be comfortable skimming if you explain too
+*much*, but new users will be stuck wallowing in confusion if you're too terse.
+Creating hours of newbie misery and confusion to save a few flicks of an
+expert's scroll wheel is a poor tradeoff to make.
You should also join the `#clschool` channel on the Freenode IRC network so you
can ask questions if you get stuck. For the most part people there are friendly
@@ -722,7 +722,7 @@
have docstrings. If you look at most other programming books they omit the
documentation strings, presumably for space reasons and because they feel the
surrounding text is documentation enough. But writing helpful docstrings is an
-art in and of itself, and I think books that omit them train users that "good
+art in and of itself, and I think books that omit them train readers that "good
code omits docstrings", which is a bad habit to get into.
The book contains *plenty* of exercises, conveniently categorized by how
@@ -750,7 +750,7 @@
in it.
This may seem a bit like running in place, but making sure your code runs in
-more than one implementation will keep you honest. I will force you to write
+more than one implementation will keep you honest. It will force you to write
portable code that doesn't rely on anything implementation-specific that might
change in the next decade or two. And you might even discover that you like
this other implementation better than the original — maybe CCL's super-fast
@@ -836,7 +836,7 @@
### Low-Level Programming
Low-level programming can mean a lot of different things, so I'll just mention
-two possibilities here.
+one possibility here.
If you're interested in writing emulators for old computers, I wrote [a series
of posts][chip8posts] on making a [CHIP-8][] emulator in Common Lisp.
@@ -844,10 +844,6 @@
things) and has a really nice [literate programming][cl-6502-book] version
that's wonderful to read through.
-If you want to interface with C libraries, [CFFI][] is what you want to use.
-The manual is worth reading, though I wish it were a little gentler to start
-with.
-
[chip8posts]: http://stevelosh.com/blog/2016/12/chip8-cpu/
[CHIP-8]: https://en.wikipedia.org/wiki/CHIP-8
[cl-6502]: https://github.com/kingcons/cl-6502
@@ -925,7 +921,7 @@
Despite the lack of heavy unit testing in the community, there are almost as
many unit testing *frameworks* as there are Common Lisp programmers! This is
probably because making a unit testing framework is so easy with a few macros.
-I personally love [1am][], but there are *plenty* more to choose from.
+I love [1am][], but there are *plenty* more to choose from.
Whichever one you choose, please make sure to be a good citizen and create
a separate ASDF system for your unit tests, so people can use your library
@@ -944,19 +940,18 @@
* [CLASP][] is still under development, but is an implementation designed to be easy to interoperate with C++.
* [Lispworks][] and [Allegro CL][] are commercial implementations with a lot of extra features and support, but are not free.
-(I omitted CLISP because I'm sore about them choosing a name that confuses the
+(I omitted CLISP because I'm mad at them for choosing a name that confuses the
heck out of new people. Hey, I warned you this post would contain Opinions™.)
-I personally tend to use SBCL for my own projects, but I make sure the units
-tests for all my libraries run in SBCL, CCL, ABCL, and ECL. This keeps me
-honest and gives me a reasonable degree of confidence that I'm writing portable
-code.
+I tend to use SBCL for my own projects, but I make sure the units tests for all
+my libraries run in SBCL, CCL, ABCL, and ECL. This keeps me honest and gives me
+a reasonable degree of confidence that I'm writing portable code.
[ABCL]: https://common-lisp.net/project/armedbear/
[ECL]: https://common-lisp.net/project/ecl/main.html
[CLASP]: https://github.com/clasp-developers/clasp
[Lispworks]: http://www.lispworks.com/
-[Allegro]: https://franz.com/products/allegro-common-lisp/
+[Allegro CL]: https://franz.com/products/allegro-common-lisp/
## Modern Common Lisp
@@ -1238,7 +1233,7 @@
[Iterate][iterate] is a replacement for the `loop` macro. It works similarly,
but has a more Lispy syntax and a well-defined API for extending it with new
-iteration constructs. I personally really like it, but beware: if you get used
+iteration constructs. I really like it myself, but beware: if you get used
to `iterate` going back to vanilla `loop` will feel painful.
#### local-time
@@ -1284,7 +1279,7 @@
scripts in Common Lisp and compile them into binaries.
I used Roswell for a little over a year, but I eventually stopped and now
-I personally don't think it's worth the trouble, for a couple of reasons.
+I don't think it's worth the trouble, for a couple of reasons.
First: if you write portable code you generally don't need to worry running
a particular version of an implementation, because Common Lisp is so stable.
@@ -1295,11 +1290,11 @@
to upgrade, and whenever things broke it would spew an almost JVM-sized stack
trace without a decent error message.
-For me, the negatives outweighed the positives. I'd personally recommend simply
-using the latest version of the implementations you care about and writing
-portable code. For the compiling-into-binaries functionality I'd recommend
-using your implementation's built-in support for this, or using UIOP's wrapper
-around that, or using a separate library like [Deploy][].
+For me, the negatives outweighed the positives. I'd recommend simply using the
+latest version of the implementations you care about and writing portable code.
+For the compiling-into-binaries functionality I'd recommend using your
+implementation's built-in support for this, or using UIOP's wrapper around that,
+or using a separate library like [Deploy][].
Of course your mileage might vary. If you find yourself *really* needing to run
specific versions of specific Common Lisp implementations in rapid succession,