
Practical Common Lisp (2005) - tosh
http://www.gigamonkeys.com/book/
======
lukego
The Lisp world is really lucky that Peter came along and wrote this book. It
was amazing to watch him tease out, soak up, and internalize Lisp culture from
all the available sources and then write such a canonical book to share it all
with the rest of us.

I wish that he would write some more books :).

~~~
gigamonkey
I plan to. Some day.

~~~
chris_wot
Dear God man, please do! I'm into the start of chapter 3 and have suddenly
discovered that in fact lisp is not obscure or hard or _anything_ like I was
told years ago in high school.

I mean, my introduction to lisp was something to do with concat but it was so
divorced from reality that I literally found an early book on C programming
and semi-self taught myself it, then found a book called C Pointers and
Dynamic Memory Management that literally changed my life.

I have a feeling if I'd read this book I'd have actually done something
awesome by now. Frankly, this book might allow me to do something that I've
been itching to do for months now.

I can't really express my appreciation enough... but I'll try right now: thank
you! A million times over, thank you!

Edit: so Arc - is that like a Webserver based on lisp?

~~~
KingMob
Arc was Paul Graham's take on a modern Lisp. There are some cool essays on it,
but I don't think the software itself ever moved much past alpha stage.

~~~
brudgers
It's the language in which Hacker News is implemented and currently developed.

~~~
krapp
Doesn't HN use a proprietary fork of Arc?

I've never been entirely certain what the relationship is between YCombinator
and the Arc community, if any, but one experimental and partially black-boxed
forum doesn't signal a mature language, just one adequate to a particular
task.

What _else_ have people done in Arc?

~~~
Immortalin
Arc has served as material for a lot of speculative blogposts and helped
create buzz for the lisp community.

------
aidenn0
If anyone is using windows and wants to go through PCL, I believe the lisp box
linked to is way out of date. I've generated a portable zips that are more up
to date:

[https://github.com/jasom/lispstick-
automate/releases/downloa...](https://github.com/jasom/lispstick-
automate/releases/download/0.1/lispstick-sbcl-1.3.9-emacs-24.5.7z)

[https://github.com/jasom/lispstick-
automate/releases/downloa...](https://github.com/jasom/lispstick-
automate/releases/download/0.1/lispstick-sbcl-1.3.9-emacs-24.5.zip)

------
nabla9
Practical Common Lisp is intro + recipes.

I think Paul Grahams ANSI Common Lisp is the best if you are learning Common
Lisp and Lisp. The language reference in the end is the extremely handy
compact reference for CL.
[http://www.paulgraham.com/acl.html](http://www.paulgraham.com/acl.html)

Common Lisp Recipes is better as a pure recipe book. [http://weitz.de/cl-
recipes/](http://weitz.de/cl-recipes/)

~~~
bsder
> I think Paul Grahams ANSI Common Lisp is the best if you are learning Common
> Lisp and Lisp.

I disagree, and here's why:

Practical Common Lisp is the _SINGLE_ Lisp reference I have ever found that
talks about how to use real data structures instead of stupid cons pairs.

That's really, really huge. And it's probably why so many people actively
dislike Lisp. And it's probably why Clojure achieved such popularity.

~~~
nabla9
>SINGLE Lisp reference I have ever found

Then you haven't read many Lisp books, including Common Lisp Recipes and ANSI
Common Lisp. There are so many of good ones.

~~~
bsder
This is my pet peeve you are arguing into. Beware. :)

Here's my point: People can build amazing programs with just Vectors or
Hashes. People can build amazing programs without understanding recursion,
evaluation, macros, or metalinguistic abstraction. And, in fact, before memory
became cheap (roughly 1995) recursion was a _negative_ , not a positive.

So, guess which things Lisp taught and which it didn't? Yeah, they got it
precisely _BACKWARDS_ and then wondered why Lisp wasn't more popular.

Go back, and look at Lisp books prior to the web--call it 1995-1996.

I 1987, I had a version of Touretzky's "Common LISP: A Gentle Introduction to
Symbolic Computation". I do not remember any discussion of Hashes, Vectors,
etc., but I see that even the 1990 version confines them to the next to the
last chapter and the discussion qualifies as cursory, at best.

SICP doesn't even mention it. Nor does Little Schemer (nee Little Lisper).

"On Lisp" (1993) just drops hashes and vectors in your lap as it expects you
to already know about them. "ANSI Common Lisp" by Graham doesn't appear until
1995.

CLtL and R4RS are references. You sure aren't going to learn Lisp/Scheme from
those.

Sure, once Perl taught the universe how useful hash tables were, everybody
started going "Hey, we have those too...", but prior to that is a big hole.

~~~
lispm
>People can build amazing programs with just Vectors or Hashes. People can
build amazing programs without understanding recursion, evaluation, macros, or
metalinguistic abstraction.

That's what Common Lisp provided back in 1984. Basic data structures like
strings, characters, vectors, various numbers, I/O streams, records and
hashes. It offer a lot of Lisp-stuff additionally, but it had everything to
write plain programs.

> recursion was a negative, not a positive

That's why real-world Common Lisp usually avoided recursion early on and
Common Lisp has lots of non-recursive iteration facilities. Scheme made some
forms of recursion 'cheap' by introducing tail call optimisation (TCO) - which
often is provided by Common Lisp implementations, too. But TCO was not
standardised because it was difficult to integrate it with the rest of the
language back then.

> I do not remember any discussion of Hashes, Vectors, etc.,

There were some books with more interesting examples, like the then popular
LISP from Winston/Horn, where the 3rd edition from 1989 was fully moved to
Common Lisp.

For key-value data structures Lisp traditionally used property lists,
association lists and forms of search trees. Later some forms of object
systems, which also map keys to values - like Frame systems. Larger Lisp
systems used hash arrays (Interlisp) or hash tables (Common Lisp). Hash-tables
were indeed not that often topic in the literature.

> CLtL and R4RS are references

The CLtL1 was quite good for learning Common Lisp. It's an nicely readable
book and not the dense R4RS. CLtL2 made thinks difficult, because it was
presenting the then defined ANSI CL (before it was actually finished) and all
the deltas to the older CLtL1.

------
Shorel
I'm sorry but I never liked PCL that much.

It certainly shows some impressive Lisp techniques, and surely it will impress
anyone who reads it about Lisp capabilities. The PCL made me feel awe about
what Lisp can do. But not about what I could do with Lisp myself.

PCL doesn't really help the reader to really understand how all that code
works to the point where the reader could write it without the writer's help.

I found this book: Lisp, An Interactive Approach
[https://www.cse.buffalo.edu/~shapiro/Commonlisp/](https://www.cse.buffalo.edu/~shapiro/Commonlisp/)
a better pedagogical tool to learn Lisp, and it guides the reader all the way,
tests him, and makes him write all the needed code before going to the next
chapter. It's not a showcase like the PCL book, but it imparts the reader with
the ability to write a similar showcase himself.

The 'An Interactive Approach' book made me grok the power of Lisp in a way no
other book could. It made me feel powerful and confident about what I could do
with Lisp.

------
_ph_
Over 10 years old, but still the best modern Common Lisp book. It helps, that
it has been written by someone who had a lot of experience with other
languages (Java), so less captured in a Lisp ivory tower, showing a truly
practical approach.

Highly recommended!

~~~
lispm
There is one important thing not covered in the book:
[https://www.quicklisp.org/](https://www.quicklisp.org/)

Quicklisp was first published in 2010 and is a library manager for Common
Lisp.

~~~
armitron
Quicklisp is not panacea, even though it simplifies matters to a substantial
degree for people new to Common Lisp.

On the other hand Quicklisp has serious issues:

\+ Minimal if any documentation of internals.

\+ A substantial chunk of the codebase can only be described as spaghetti
code. To make matters even worse, most functions lack documentation strings. A
sad state of affairs given the interactive and self-documenting nature of CL.

\+ Is vulnerable to man-in-the-middle attacks since it verifies neither
certificates nor checksums. This means that using Quicklisp can get you owned.
Unacceptable these days.

\+ Operates over a 'curated repository' model that Xach is managing. The
repository has been found to be vulnerable to man-in-the-middle attacks in the
past since packages were fetched over plain HTTP or git://. Even if that
wasn't the case, it's yet another element in the chain of things to trust.

\+ Few if any people besides Xach are working on quicklisp-client to mitigate
these issues. Lack of documentation and spaghetti code is not helping to
attract new talent.

\+ Xach is employed by Clozure Associates. I understand that they've allotted
him some time to work on Quicklisp while on the job, but it's still a side-
project. Look at the number of open issues at Github. Many have been there for
years.

For these reasons, I don't use Quicklisp myself. I also advocate against it to
friends and colleagues who share my views on software distribution mechanisms.

~~~
zachbeane
I hope to improve the documentation and security of Quicklisp in the next few
months. It will depend on funding.

The core of Quicklisp is in dist.lisp. Understanding the protocol of the
generic functions at the start of that file will help clarify Quicklisp as a
whole. Almost everything else Quicklisp does is in support of that protocol.

~~~
armitron
That's great to hear. On your donations page you have indicated that there
will be a special fundraiser. If that's not the case still, I suggest you
remove it as people could be waiting for it and not donating.

------
Koshkin
A wonderful book, well worth studying. If only in order to gain a wider
perspective on programming languages, and perhaps forget, at least for a
while, about the language wars and the ongoing "C bashing."

It may be not obvious to those who may only have had a limited experience with
it, Common Lisp, in itself, is an extremely expressive and powerful
programming language. Also, there are compilers, such as SBCL, that generate a
very efficient machine code; others, such as ECL ("embeddable Common Lisp"),
make it very easy to combine lisp code with code written in C, thereby
providing the ability to seamlessly integrate high-level and easy-to-use
constructs with low-level, performance-critical pieces of code.

~~~
qwertyuiop924
Indeed. As much as I dislike CL's quirky inelegance (I prefer the scheme side
of the Lisp family tree), it's a tremendously powerful and effective language,
and one of the best choices for Getting Stuff Done Right Now using Lisp. In
fact, probably _the_ best choice.

~~~
Koshkin
> _quirky inelegance_

On the other hand, quoting Einstein's quote found in the famous book by
Sussman and Wisdom who use Scheme to teach Classical Mechanics, "I adhered
scrupulously to the precept of that brilliant theoretical physicist L.
Boltzmann, according to whom matters of elegance ought be left to the tailor
and to the cobbler.”

~~~
dleslie
Tailors and cobblers do practical tasks day in and day out; whereas physicists
stretch their imagination to dream of the yet-known.

Somehow I think the analogy falls apart on close consideration. ;)

~~~
taeric
All analogies fall apart on close consideration.

In this case, though, I think it still works. It says nothing of the work they
do, but more to the goal of their work. Tailors/coblers (fashion, in general)
are tasked with making elegant attire. It is true that some are tasked with
making practical attire.

Physicists, however, are never tasked with making elegant physics. It is
rewarded. But it is not directly their task.

~~~
jasonm23
I always enjoyed this take on analogies, and their consistent property of
falling apart upon close consideration.

> An analogy is like a finger pointing at the moon, pay too much attention to
> the finger and you miss out on all the heavenly glory.

------
lisper
I started working on this a while back:

[https://github.com/rongarret/BWFP](https://github.com/rongarret/BWFP)

Currently very low on my priority list but it would not take a lot of
encouragement for me to pick it back up again.

~~~
mablap
In chapter 1 you mention that Petzold's book is underrated. If that's any
consolation, I have bought the book when it came out and have talked about it
to many of my friends since. I wouldn't say it's under _rated_ , but just not
well known. Great book!

~~~
lisper
Maybe I'll change that to "under-appreciated"

~~~
mablap
I forgot to say that I'm reading your text now :) I had a compiler class with
Marc Feeley, author of Gambit-C, and I've been sold on Lisps ever since. I
really love the simplicity of Scheme, but I found that it's much easier to get
going (i.e. not having to re-write even basic things such as for-loops) in CL
than Scheme. I can write/read some basic macros but my end goal is being able
to write a read-macro for a DSL. I can't really envision doing this as easily
without a Lisp.

------
znpy
The biggest problem in spreading lisp nowadays is the fragmentation of the
documentation.

"Lisp" means so little when you're writing real code.

Each implementation has its own quirks and even venerable books fall when
confronted with real world code at learning.

For example: I was reading the SICP and using racket that looks like an
interesting runtime nowadays. Turns out that a while a go the dev team made
cons immutable and that's okay I guess but it broke (at least for me) the
experience of reading SICP because I now have to pause and learn this quirk of
this specific lisp implementation.

And don't even get me started on common lisp. There are at least 5 or 6 major
common lisp runtimes, each of them incompatible somehow (try and read some of
the StumpWM "makefiles" and you'll have a taste of what I'm talking about).

Also, common things (threads, for example) are still not provided in a uniform
way across all of the implementations, and are often more or less quick hacks.

Scheme? Cool! Srfi! What part of scheme does your scheme actually implements?
Would you use a C compiler without structures? And write code so that it can
be compiled with another C compiler that has structures but doesn't have foot
loops (only while loops are provided).

Lisps are awesome languages, but for me, no wonder they remain niche
languages.

And before you downvote, please keep in mind that I am now booing Lisp, I
would just love it to be more "sane" minded and less schizophrenic as a
language/runtime, and more real-world-usable.

~~~
lispm
For portable thread APIs in Common Lisp see:

[https://github.com/sionescu/bordeaux-
threads](https://github.com/sionescu/bordeaux-threads)

and

[https://github.com/binghe/portable-
threads](https://github.com/binghe/portable-threads)

~~~
znpy
Follow the first link in the github description of Bordeaux-threads and you
reach a 404 error.

I guess this pretty much sums up the state of many common lisp libraries.

Also, if it is so portable and so useful, why hasn't it made part of the
language and of the various implementations?

Why there are no updates to the standard?

~~~
lispm
The page is here. Send the author a bug report...

[https://common-lisp.net/project/bordeaux-threads/](https://common-
lisp.net/project/bordeaux-threads/)

> Also, if it is so portable and so useful, why hasn't it made part of the
> language and of the various implementations?

You make it a part of the language by loading it in.

    
    
        CL-USER 23 > (ql:quickload "bordeaux-threads")
        To load "bordeaux-threads":
          Load 1 ASDF system:
            bordeaux-threads
        ; Loading "bordeaux-threads"
        [package bordeaux-threads]...
        ("bordeaux-threads")
    

> Why there are no updates to the standard?

Because it is too expensive (it's an ANSI Standard, which makes things
difficult), there are no sponsors for it and not enough are interested to do
the work.

The language evolves in libraries, portable substrates and implementations
since some time.

Note that the language has a lot of flexibility for change built in: reader
macros for the s-expression syntax, macros for the Lisp syntax, meta-object
protocol for the object-system, packages enable new Lisp dialects, ...

------
wtbob
Practical Common Lisp, along with pg's essays on Lisp, can be credited with
inspiring the Lisp renaissance of the mid-2000s. It's an incredibly good book,
showing Lisp (unlike Scheme) is a practical programming language, with the
ability to go from low-level bit-twiddling all the way up to very high levels
of abstraction.

Reading it was eye-opening. I had no idea up until that point that Lisp is a
real, industrial-grade language (as opposed to a very interesting didactic
tool).

Even if you don't have an intention of programming in Lisp, you should read
PCL for an idea of how much better the language you're programming in _could_
be. Hopefully, it'll inspire you to write some Lisp, but even if it doesn't
you'll be a better programmer for it. You'll be able to understand why static
languages like Java have such arcane ecosystems; you'll be able to see how
very little new there is under the sun.

------
fovc
I've been working in JS full time for a couple of months now, except for a
short break to build a JSX parser for Emacs. Switching to lisp was such a
breath of fresh air. The code was denser, and every line took longer to write,
so not sure about overall productivity, but man was it more enjoyable to
write!

I wish there were an update to this book. I seriously looked into giving up on
JS and using Parenscript and Wookie or Hunchentoont but it seemed like I'd be
taking on a lot of yak hair. Does anyone here use any lisp for Web
Development? What's the modern lisp (CL or otherwise) stack?

~~~
jlg23
> Does anyone here use any lisp for Web Development?

I do.

> What's the modern lisp (CL or otherwise) stack?

There is no fixed stack, though people want to make you believe there is.

I use cl-who for html generation, my own lib for css generation (basically
sass with lisp syntax), a bastard of cl-json for json generation and a heavily
patched hunchentoot as a web server and in very rare cases parenscript - but
only to generate js class definitions from cl classes since transpilation of
business logic usually places too many constraints on what you can implement
how on the lisp side. For database access I mostly use cl-postgres but fall
back to cl-sql if the client insists on another DB than pg.

~~~
aidenn0
I also use lisp for web development, and want to second this:

> There is no fixed stack, though people want to make you believe there is.

My stack:

I use parenscript[5] fairly heavily (to the point where I'm now a
contributor). Note that parenscript is mostly javascript semantics with lisp
syntax, _but_ macros for it are written in common-lisp, which makes a lot of
the javascript annoyances go away.

Like jlg23, I use cl-who for html generation.

I spent a while experimenting with css generation, but now just use something
prepackaged (currently Pure[1]). If I had need for a custom look, I would pay
someone who knows graphic design to generate a layout, and I'd code to that.

I've rotated between several JSON libraries to the point that I couldn't say
which one I used for my last project; for JSON I'm very opinionated on the
proper mapping from JS types to lisp, and none of the libraries do the Right
Thing out of the box, so I wrap them with something that will.

As users expect something less like "fill out a form and hit submit" and more
like "Instantly responsive web application that saves my work as I go" I
started experimenting with using parenscript with various JS application
libraries. I found React to be okay[2], but much prefer the simplicity of
Mithril[3].

For webserver, I use clack[4] which is in roughly the same space as WSGI is
for python or Ring is for clojure. It is sadly severely lacking in
documentation (at least in English). A clack tutorial is on my "todo" list.

I happen to run clack behind mongrel2, but that's because it's the server I'm
most familiar with; it has backends for FastCGI and several native lisp web
servers, and adding new backends is very easy (the mongrel2 backend is under
200 lines of code).

For a database I use postmodern[6] (a library for pgsql) and I use cl-redis[7]
for quick & dirty projects, as a key/value store tends to make for more rapid
prototyping.

1: [http://purecss.io/](http://purecss.io/)

2:
[https://github.com/jasom/parenscriptx](https://github.com/jasom/parenscriptx)

3:
[https://github.com/jasom/parenscriptm](https://github.com/jasom/parenscriptm)

4: [https://github.com/fukamachi/clack](https://github.com/fukamachi/clack)

5: [https://common-lisp.net/project/parenscript/](https://common-
lisp.net/project/parenscript/)

6:
[http://marijnhaverbeke.nl/postmodern/](http://marijnhaverbeke.nl/postmodern/)

7: [https://github.com/vseloved/cl-redis](https://github.com/vseloved/cl-
redis)

~~~
fovc
Thanks! Lots of great reading here. The React piece looks interesting, but
would definitely like to hear more about Clack. My biggest hangup is around
infrastructure. I wouldn't mind terribly re-inventing the wheel a bit in terms
of client-side and business logic (if I can use lisp), but dealing with a
FastCGI deploy makes me cringe a bit. Maybe it's just bad memories from a site
I took over that was on shared hosting.

~~~
aidenn0
You can always use one of the lisp http servers, though I believe most people
put those behind a reverse proxy when doing so.

------
qwertyuiop924
PCL is still one of the best books for learning Lisp. Although I actually got
my start with Conrad Barski's The Land of Lisp, which is also excellent.

------
chris_wot
Is it just me, or is there a typo in the following?

    
    
      CL-USER> (remove-if-not
        #'(lambda (cd) (equal (getf cd :artist) "Dixie Chicks")) *db*)
      ((:TITLE "Home" :ARTIST "Dixie Chicks" :RATING 9 :RIPPED T)
       (:TITLE "Fly" :ARTIST "Dixie Chicks" :RATING 8 :RIPPED T))
    

It seems to be missing a single quote... shouldn't it be:

    
    
      CL-USER> (remove-if-not
        #'(lambda (cd) (equal (getf cd :artist) "Dixie Chicks"))' *db*)
      ((:TITLE "Home" :ARTIST "Dixie Chicks" :RATING 9 :RIPPED T)
       (:TITLE "Fly" :ARTIST "Dixie Chicks" :RATING 8 :RIPPED T))
    

If this is a typo, it merely shows how incredibly well written this is,
because I have literally never read lisp code in any seriousness in my life!

~~~
martinflack
In your example, the LAMBDA form is preceded by a sharpquote. So #'FORM is
syntactic sugar for (FUNCTION FORM). This is a way to reference a value in the
function namespace instead of the variable namespace (Common Lisp is a
"Lisp-2"... actually more than that, but that's the common terminology.)
Usually this sharpquote would precede names of functions when they are passed
as a value. (Interestingly, they are optional on the LAMBDA form.)

Generally, preceding single quotes in Common Lisp e.g. 'FORM are syntactic
sugar for (QUOTE FORM) which has the meaning of reading in the form without
evaluating it. You'll see lots of single quotes used for that purpose as well.

~~~
chris_wot
Oh, I see. In that case, I was a little confused by the following:

    
    
      CL-USER> (remove-if-not #'evenp '(1 2 3 4 5 6 7 8 9 10))
      (2 4 6 8 10)
    

The author explained what #'evenp did (FUNCTION '(1 2 3 4 5 6 7 8 9 10)) but
not that '(1 2 3 4 5 6 7 8 9 10) is just (1 2 3 4 5 6 7 8 9 10).

In other words, the above evaluates to:

    
    
      (FUNCTION evenp (1 2 3 4 5 6 7 8 9 10))
    

Or didn't explain it unless, of course, I missed a bit :-)

~~~
bluefox
You can see how an expression is read this way:

    
    
        (defun how-is-it-read? (string)
          (write-to-string (read-from-string string)
                           :pretty nil))
        ==> HOW-IS-IT-READ?
    
        (how-is-it-read? "#'foo")
        ==> "(FUNCTION FOO)"
    
        (how-is-it-read? "(remove-if-not #'evenp '(1 2 3 4 5 6 7 8 9 10))")
        ==> "(REMOVE-IF-NOT (FUNCTION EVENP) (QUOTE (1 2 3 4 5 6 7 8 9 10)))"
    

You can see that this does not match your expectation. Are you actually trying
to type that code and evaluate it at a Lisp listener? If not, you should.

Now, FUNCTION is a special operator that in this case returns the function
named EVENP.

QUOTE is a special operator that just returns the object it is passed.

So REMOVE-IF-NOT will get called with two arguments: the function named EVENP,
and a list of integers from 1 to 10.

------
int_19h
What is the current state of affairs with regard to Common Lisp on Windows?

I remember that when I was last trying to explore it, that was the single
biggest hurdle - all the recommended freely available "industrial strength"
implementations (SBCL, CMUCL) were either unavailable on Windows outright, or
considered experimental and highly unstable there. The stuff that was
available was either proprietary (and costly), or its performance was not
deemed sufficient for production use (e.g. CLisp).

But that was several years ago. Did anything change?

~~~
frobbo
I use CCL on Windows, and at times SBCL. SBCL does have a large warning about
lack of maintenance and potential instability or something like that, but I
haven't used it heavily enough to expose such behavior.

CCL has no interpreter, so any code you write gets compiled to native code.
People worry too much about performance too prematurely in my opinion.

I hate windows in general and try to avoid using it and targeting it whenever
I can, but for the past year I did use windows+ccl+emacs to successfully get
work done, which I was able to easily transition back over to macos+ccl+emacs
just recently.

I would say that at the very least, the hurdles you ran into in the past are
gone. Binaries for sbcl on windows are supplied, and I'm pretty sure that
threading is enabled in recent builds so no need to recompile yourself (I
remember wasting so much time on this a few years ago and moved to ccl).

I recently ran into a workflow that ccl easily accommodated that sbcl didn't,
which was specifically such that when you ran out of heap, ccl automatically
allocated more, whereas with sbcl it seems to be fixed upon startup and
requires more than a command line flag to fix (I couldn't figure it out in the
hour or so I spent working on it)

~~~
int_19h
Clozure looks very interesting, thank you! Got it up and running in a few
minutes, and the docs look promising. I think it wasn't around last time I
tried to seriously explore CL. Good to see more options!

------
gaurav-gupta
This is an awesome book. I read it online back in 2006 (one of the few books I
followed from start to end). Even though I mostly programmed in other
languages, the approach and techniques in this book enormously improved me as
a programmer.

Thank you for writing this book and sharing it with the world!

------
sealedmail
If I may suggest, please add 'next' and 'previous' links within the chapters
of the online book. It's a little annoying to have to navigate back and then
click on the next chapter to read on.

------
saurabhjha
This book looks good from a cursory glance. Can anyone please tell me if I
should read this one or Paul Graham's ANSI common lisp. I have some background
in scheme due to SICP.

Thanks!

~~~
z0ltan
Definitely this book. I would recommend keeping Graham's books for later.

Practical Common Lisp + Land of Lisp + Common Lisp recipes + the Lisp
Hyperspec = Profit!

Additional readings: Successful Lisp (Lamkins - very underrated), Paul
Graham's books, and Hoyte's Let Over Lambda (advanced).

------
spdegabrielle
A great(fun!) book.

I wonder if it can take any credit for the resurgence of lisps! (especially
Clojure)

It certainly was an influence on the student writen 'Realm of Racket'.

------
Qwertystop
Tried to use this to learn Lisp (previous experience: one semester of Racket).
Couldn't really motivate to keep going. Might just be me, though.

~~~
tosh
I'm currently going through the advent of code challenges
([http://adventofcode.com](http://adventofcode.com)) with Clojure and watch a
few talks
([https://www.youtube.com/user/ClojureTV](https://www.youtube.com/user/ClojureTV))
next to it.

The cool thing about the challenges is that they are language agnostic so you
can try whatever you're interested in (CL, Scheme, Racket, Clojure, …). A bit
like Project Euler ([https://projecteuler.net](https://projecteuler.net)) but
more fun.

~~~
qwertyuiop924
Hey tosh! Funny seeing you here (especially mere hours after I replied to you
on Reddit)

AoC is great. I've been doing it in Scheme. Except today's challenge, which I
did in AWK, because it was perfectly suited for the task (although I could
have also used the AWK scheme macro). Plus, in Scheme, you don't wind up with
code like this

    
    
      {if(($1+$2>$3)&&($1+$3>$2)&&($2+$3>$1)) count++;} END {print count}
    

Aren't one-liners fun?

------
splesjaz
Recently bought ; Land of Lisp and it should arrive next week. Heard it's a
pretty good book to do some fun with Common Liso

------
wyclif
What's the current best CL implementation on macOS/OS X? Is it still SBCL or
something else?

~~~
kbp
SBCL is very good and what most of the open source community uses. Clozure CL
is also very good, reasonably popular, and has good Cocoa support. LispWorks
is excellent, but proprietary; the paid versions are very expensive but there
is a free 'Personal' edition as well.

I would recommend SBCL unless you want to do GUI stuff.

------
Annatar
Is there any material exploring the possibility of using LISP as a systems
programming language?

~~~
rini17
Mostly dead projects:
[http://web.archive.org/web/20000418011820/http://www.hex.net...](http://web.archive.org/web/20000418011820/http://www.hex.net/~cbbrowne/lisposes.html)

Some ideas: [https://github.com/robert-
strandh/LispOS](https://github.com/robert-strandh/LispOS)

~~~
lispm
[https://github.com/froggey/Mezzano](https://github.com/froggey/Mezzano)

------
z0ltan
It's a good book in parts, but very dry and almost reference-like in others.
All in all, pretty decent.

I much preferred Land of Lisp by Barsky for the basics and Edi Wietz' Common
Lisp recipes for specific use cases.

