
The Land of Lisp - adgasf
http://landoflisp.com/
======
stevelosh
This book comes up in #lisp on freenode every so often, and the channel is
generally split on whether or not to recommend it. I generally do.

It's fun and lighthearted. Using games as a medium to teach the language is
something some people enjoy, and is a lot less dry than most programming
books.

It avoids taking sides on the editor war, by just ignoring it altogether and
_teaching Lisp_. This is refreshing compared to most books, which hit you with
the Emacs cinderblock to the face right in the preface.

It also stays away from ASDF and Quicklisp and even the entire package system
in general, which is a lot of extra complexity that can be overwhelming to
beginners at first (though they'll eventually need to learn about this if they
want to continue using Common Lisp).

The main issue people have with the book is that it uses CLISP-specific code
in a few places. CLISP's last release was seven years ago, and because it
hasn't really been maintained it's beginning to bitrot. Folks in #lisp
generally don't recommend using CLISP these days, instead recommending
actively-maintained implementations like SBCL, CCL, ECL, ABCL, etc.

Using CLISP-specific code does allow the book to sidestep the issue of the
library ecosystem, which is a plus. But a revamped version (or even a
collection of errata) that ported the CLISP bits to a maintained
implementation would make it a lot easier to recommend these days.

~~~
flavio81
> _The main issue people have with the book is that it uses CLISP-specific
> code in a few places._

This makes sense for a tutorial book, since CLISP is easy to install, very
small to download (compared to SBCL), and is a fully featured (ANSI compliant)
implementation. So i don't think it was a mistake to choose CLISP.

The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer
to the programmer, offering more features. Also, code runs very fast under
SBCL; although i suspect that CLISP compiles code faster.

(If any is interested, here is a quick overview on _some_ of the Lisp
implementations available and their salient features. (Most implementations
are free)

    
    
        ECL - Embeddable Common Lisp
            allows you to compile Lisp into any 
            other system by compiling to C
    
        SBCL - Steel Bank Common Lisp
            Produces very fast code, 
            allows static type checking and other niceties
            a fork from the CMU CL impl.
    
        CLISP
            Small, easy to install and use, 
            includes readline REPL and X11 features
    
        ABCL - Armed Bear Common Lisp
            Allows you to run Lisp under the Java JVM 
            and call Java code, or call Lisp code from Java.
    
        CLASP 
            Compiles Lisp to the LLVM, provides C++ interop
    
        ACL - Allegro Common Lisp
            Commercial Lisp, fast, feature rich
            includes a Prolog implementation, CLIM GUI
            and other nice stuff.
    
        LispWorks
            Commercial Lisp, fast, feature rich,
            includes an IDE, Java Interface, 
            and CLIM 2.0 implementation, more features. 
    
        ParenScript
            This is a small subset of CL that gets translated
            (in the server) to javascript
    
        JSCL
            A Lisp implementation that runs under Javascript,
            providing a REPL and Lisp interpretation on the
            browser, for a subset of the CL language.
    )

~~~
nextos
CLASP is for me the most exciting CL implementation right now. Compilation to
the LLVM is a huge advantage.

Sadly, it's a one-man thing. And CL seems quite stagnant.

I wish one implementation triumphed over the others, and CL progressed beyond
its ANSI standard.

Clojure has many interesting things. So does Racket. The Lisp landscape is too
fragmented. And thus libraries are a huge problem.

~~~
flavio81
_> I wish one implementation triumphed over the others_

That would be terrible. Part of the nice things of CL is that you can choose
the implementation according to what you need. For example ECL if you want to
embed your lisp code with C code. ABCL if you really need to call lots of Java
libs (or have Java code call your Lisp code easily), and so on. We're talking
about mature, proven, tested implementations.

If one implementation triumphed over others, over time we'd be in a position
similar to, say, Python or Clojure, where there is only one or two
implementations, besides some experimental implementations, and nothing else.

Something that needs to be mentioned is that CL is truly standardized; if you
have a code written in Common Lisp, chances are it will compile straight away
on most of the implementations (ECL, ABCL, SBCL, etc), with no change needed.
So having many implementations does not mean there is any kind of
fragmentation in the language.

 _> and CL progressed beyond its ANSI standard._

CL is one of the most extensible languages out there, so it has already
progressed way beyond the ANSI standard. The standard doesn't need
modification to support new things. There are already many libraries giving
you things that are not in the standard (like sockets or threads) but in a
portable and standarized way.

------
flavio81
This book is destined to be a classic programming book, just as "The C
programming language", "The Little Schemer" or "Operating systems: Design and
implementation".

I would really like to meet Conrad Barski and give him a great hug. And invite
him a good beer.

Be sure to read the comic that is on the bottom of the page!!

Now, to be honest, a quicker or more practical introduction to Lisp would be
the "Practical Common Lisp" book which is also superb. However, Land of Lisp
is a charming book that makes you smile and feel like a nerdy (in a good way)
12 years old kid in 1982 who just got as a birthday present a brand new
Commodore-64 and is eager to read the manuals!

~~~
drcode
Thanks for the kind words! Glad you enjoyed my book!

~~~
flavio81
Hi doctor!

The comic at the bottom of the web page got me laughing and in tears at the
same time, in particular the line: "Back in the 80s we showed you how to
program _without ANY bugs_ ". Also, Java as a little tank, C# as a plane,
Python as an helicopter... just brilliant. I almost rolled in the floor
laughing by looking at that part of the strip.

Certainly it is prophetic, it seems we're almost reaching the point of being
enslaved by bugs...

You're a good man, mr. Lisperati!

 _" As you know, we're in the 8th year of the Great Northern Wars against the
Haskellers (there are rumors that more of our troops are defecting to the
other side)!! Don't be tempted to break ranks!"_

~~~
doktrin
> Java as a little tank, C# as a plane, Python as an helicopter... just
> brilliant. I almost rolled in the floor laughing by looking at that part of
> the strip.

Is there a special significance to the Java / Python / Ruby / C#
representations? I feel like I missed the joke here, even though I enjoyed the
strip as a whole.

~~~
flavio81
Java as a tank - that is, slow (in development time) although resilient and
all-terrain

Python as a helicopter - far more manuverable but slower than a plane and
easier to take down

C# as a plane, fast and carries more cargo than an helicopter.

Ruby like some sort of convoluted laser beam weapon

Lisp dialects (on the strip) are all spaceships done using "secret alien
technology". Even then, the insectoids are harder to kill than back in the
80s! What will the human+lispers alliance do? Read the strip for knowning what
happens next!

------
midgetjones
I've read this book, and what I love about it is that it really brings to mind
the programming books of my youth, when nobody would argue that programming
should be fun.

It's goofy, has bad jokes, and you learn something.

Having said that, the code style seemed quite idiomatic compared to some of
the other Lisp I've seen (although I'm no expert), so I wasn't sure how
valuable the lessons were.

~~~
amake
> seemed quite idiomatic

I'm not sure how that would be a bad thing. Did you mean _un_ idiomatic?

~~~
dwringer
A common complaint about Lisp code in general is that programmers tend to
write code that is idiosyncratic [ED: I previously used the word "idiomatic"
here in reply to the OP but was conflating terms, making this post rather
irrelevant but at least it provoked a discussion] (i.e. rather than looking
like templated design patterns with standard names, the program is
heirarchically built of modules in a domain-specific language of the
programmer's own design). This is both one of Lisp's greatest strengths to
those who like it, and (I think, based on comments I've seen here and
elsewhere) one of the greatest reasons it doesn't have more widespread
adoption.

~~~
felideon
I know what you are saying, but that is not what is meant by idiomatic Lisp.
Not by Lispers at least.

Non-idiomatic Lisp is typically written by beginners whose code looks more
like the language they are accustomed to using previously. For instance,
leaning heavily on a procedural style. And not just beginners, but also
seasoned programmers that write object oriented Lisp more akin to static OOP.
In other words, designing class hierarchies rather than protocols (using
generic functions).

What you describe is more of a side effect of the Bipolar Lisp Programmer[1]:

> This is a BBM attitude; it works for me and I understand it. It is also the
> product of not needing or wanting anybody else's help to do something.

I haven't read Land of Lisp yet, so I can't really comment as to whether I'd
consider it idiomatic Lisp or not. (OP meant "idiosyncratic" anyway, it
seems.) Not that I'd be a good judge, anyway.

[1]
[http://www.shenlanguage.org/lambdassociates/htdocs/blog/bipo...](http://www.shenlanguage.org/lambdassociates/htdocs/blog/bipolar.htm)

~~~
sverige
God, that link and the comic strip for the Land of Lisp are both so great! I
might have to try Lisp again.

>Writing in C is like building a mosaic out of lentils using a tweezer and
glue.

I cannot describe the memories and associated feelings this evokes....

------
mslate
The music video is what really sold me on buying the book several years back:

[https://www.youtube.com/watch?v=HM1Zb3xmvMc](https://www.youtube.com/watch?v=HM1Zb3xmvMc)

~~~
junke
I don't even have to click, I remember it after all those years. Something
unique in many aspects. Beware.

------
panglott
There's also Realm of Racket
[https://realmofracket.com/](https://realmofracket.com/) Which maybe is
shorter? I don't recall.

~~~
vanderZwan
The real question is whether it has a sequel to Grand Theft Wumpus in it

~~~
flavio81
"The most violent programming example ever put on a textbook!"

[http://w3.sista.arizona.edu/classes/ista450/spring15/project...](http://w3.sista.arizona.edu/classes/ista450/spring15/projects/wumpus/figs/grand-
theft-wumpus.jpeg)

------
hellofunk
When I discovered lisp several years ago, it was indeed the textbook moment of
enlightenment that you've heard about. This book was a part of that
introduction for me (along with Practical Common Lisp). After working in
C-like languages, I had no idea that programming could work this way as in
lisp, the idea of code and data being inseparable, I even had dreams at night
about run-time data structures getting expressed as quoted lists! (I kid you
not!)

It is now several years later and I have earned my living ever since by
working in another lisp, Clojure. And I have indeed learned a lot along the
way and what I've learned does indeed translate to how I work in other
languages (even C++, which I also love).

However -- it is not all roses and nicely-flavored toothpaste after a savory
feast. There is one aspect to lisp programming that, by virtue of its dynamic
typing, I still find myself struggling to reconcile. No matter how much I
marvel at what I can do in one or two lines of lisp, I do still often find
myself making dumb mistakes that a compiler would catch instantly. Without
type annotations and checked structured data for everything, it can also be
hard to remember what a function does, or what its variables represent, when
you read the code later.

One aspect of this that has made a big difference is naming -- how you name
things in lisp and dynamic languages is a skill in its own right that helps
guide the readability of code in the absence of types. When I look at C++ code
I've written, the verbosity of naming is a clear influence from lisp. And it
is an improvement.

The other feature that occurs more often is in-line documentation. It is a joy
to read Clojure programs (the good ones, anyway) where every (non-trivial or
meaningful) function has a little paragraph summarising what it does. This is
just good in any language, but somewhat essential in a dynamic one.

Finally, run-time contracts and things like Clojure.spec come about to help
fill the void of static typing. The problem I have there is that you add back
into your code a fair amount of the verbosity that was removed in the first
place by using a dynamic language (just look at Clojure.spec's lengthy
annotations for a function signature, and I find myself wondering... why god
oh why?). At which point, I then wonder why not just go back to using a static
language.

So using lisp taught me perhaps one final, frustrating lesson: there are just
great things about both dynamically typed and statically typed languages, and
I've learned that the fence is an awkward place to sit.

~~~
default-kramer
My first go at lisp was working through SICP. I loved it. But I couldn't see
myself using it for a medium-sized project just because static typing is that
valuable to me.

Now I'm learning Racket, and Typed Racket feels great so far (despite a few
awkward spots). You don't have to sit on that fence; you can switch between
typed and untyped code at will.

~~~
flavio81
> _But I couldn 't see myself using it for a medium-sized project just because
> static typing is that valuable to me._

See my comment above, you can have static-typing in Lisp with no problem: Type
declarations are part of the Common Lisp standard[1], and implementations like
SBCL (one of the best Lisp implementations out there, and free) will do static
type checking.

[1] type declarations:
[http://clhs.lisp.se/Body/d_type.htm](http://clhs.lisp.se/Body/d_type.htm)

"the" (type specifier for return values):
[http://clhs.lisp.se/Body/s_the.htm#the](http://clhs.lisp.se/Body/s_the.htm#the)

EDIT: a good example here:

[https://news.ycombinator.com/item?id=8598149](https://news.ycombinator.com/item?id=8598149)

~~~
hellofunk
As with my comment about typed racket, I can't really use common lisp in my
work, however clojure is very portable and I can use it (as clojurescript) as
a first class language on iOS, and Mac, and the web.

------
Vekz
I was greatly disappointed with this book because none of the 'Game' examples
had a graphical interface to them. They are all text based.

Reading further in this thread people are suggesting Realm of Racket as an
alternative and it looks like that book has much more visual game examples:
[https://realmofracket.com/games.html](https://realmofracket.com/games.html)

~~~
flavio81
> _I was greatly disappointed (...) They are all text based._

That's not really a bad thing...

If you want graphical games in Lisp, take a look at the series called "Pushing
pixels with Lisp":

[https://www.reddit.com/r/lisp/comments/6d5nht/pushing_pixels...](https://www.reddit.com/r/lisp/comments/6d5nht/pushing_pixels_with_lisp_episode_1_perlin_noise/)

~~~
Vekz
I've been following this series and its great! I'm not saying it was a "bad
thing" I'm saying it didn't meet my personal expectations for a "lets build
games" book

------
macawfish
This looks great!

 _Why 's Poignant Guide to Ruby_ really got me started in thinking for myself
as a programmer. I'm looking at this book and seeing that if I read it I might
fall in love with Lisp...

~~~
the_gastropod
Yea, this definitely seems inspired by Why's style. The art is similar, the
story is absurd, metaphorical, and fun. Man, I miss that guy!

------
xedrac
I loved this book! I've always enjoyed retro text-based games and this was a
fun way for me start learning a more functional style of programming (and
Lisp). It was a nice contrast to my daily C++ work.

------
swlkr
I’m so glad that this exists. Lisp (Clojure) has really brought the joy of
programming back for me after 20 years.

------
fernandohur
"Simple but refined, guaranteed to blow your mind, the land of lisp"

This guy is a genius :D

------
etatoby
I've learned LISP and Scheme, gained some useful insights, used them on a few
random projects, and then dropped them.

I recommend learning them, but then switching to something like Reason / OCaml
/ F# / Haskell.

~~~
davexunit
counter anecdote: I use and contribute to a number of Scheme programs that I
use daily and would never want to switch to any static language. Life at the
REPL is too good.

------
krylon
I am currently working on an interpreter for a Lisp-like language (it's too
early to call it a dialect of Lisp) in Go.

I have not used Lisp at all over past couple of years, except for tweaking
emacs, and I am beginning to understand that I have subconsciously missed
Lisp.

It is amazing how little - if one really wants to - of Lisp one needs to
implement in the host language before one can go on and write the rest in
Lisp. Efficiency-wise, I expect that I will implement many things in Go for
performance that _could_ be written in Lisp.

------
throwaway7645
I've read most of it too, but not sure it shows a lot of lisp's strengths. A
lot of the programs I read them over and thought that I could do the same
thing in significantly less Python code. I'm not sure what should be fixed if
anything though.

~~~
baldfat
> A lot of the programs I read them over and thought that I could do the same
> thing in significantly less Python code.

My racket code is usually many time smaller then my Python code. The nice
thing about Racket/Lisp is you can just make your own tools when in Python you
copy thousands of lines of code into a one line code.

The real fix that Lisp/Racket gives over Python is deployment.

~~~
throwaway7645
Agreed on deployment.

------
avocad
This is the book i give as a present to the most geeky of my friends.

------
freedomben
I love this book and it certainly deserves some attention, but is there
anything new that is newsworthy? Has a new edition been released? Just
wondering if I missed something.

------
tempodox
Nicely explained.

On a side note, I noticed with deep satisfaction that “git” is used as some
kind of curse in the land of Lisp.

~~~
bitwize
"Git" in British slang roughly means "jerk". See also Linus's joke about
naming software after himself, mentioned elsewhere in thread.

The Monkees had a song called "Randy Scouse Git" (after a catchphrase from the
britcom _' Til Death Do Us Part_) the title of which was considered so vulgar
in the UK that they had to release the song there under an alternative title
(I think they actually used "Alternative Title").

------
ggm
the cons chain of arrows certainly reminded me of why deep nested structural
syntactic sugar is a pain..

------
avodonosov
Wow, new comic?

Previously it was a different one.

------
B1narySunset
The dude on the right looks like an older version of Doug Funny.

------
garamirez
I really enjoyed the book. An awesome intro to lisp!

------
byron_fast
Making good comics is hard.

------
icantdrive55
I'll get hammered for this, but there are better books.

I still haven't figured out if this book is a vanity project written by a
bored Doctor, or a sincere attempt to convey information.

I do like the Period Table though.

And maybe it's just me? I have the book on my shelf, and it's dusty.

I do feel using a comic book format to convey technical information is the way
to go. It should be used more often.

~~~
mmel
Can you suggest some of these "better books" ?

~~~
mollusk
Not him, and I adore the geekiness/goofiness of Land of Lisp, but I found
Practical Common Lisp much more helpful.

------
misterHN
I think you want to read the cartoon guide to the computer

