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.<p>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.<p>It avoids taking sides on the editor war, by just ignoring it altogether and <i>teaching Lisp</i>. This is refreshing compared to most books, which hit you with the Emacs cinderblock to the face right in the preface.<p>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).<p>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.<p>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.
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".<p>I would really like to meet Conrad Barski and give him a great hug. And invite him a good beer.<p>Be sure to read the comic that is on the bottom of the page!!<p>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!
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.<p>It's goofy, has bad jokes, and you learn something.<p>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.
The music video is what really sold me on buying the book several years back:<p><a href="https://www.youtube.com/watch?v=HM1Zb3xmvMc" rel="nofollow">https://www.youtube.com/watch?v=HM1Zb3xmvMc</a>
There's also Realm of Racket <a href="https://realmofracket.com/" rel="nofollow">https://realmofracket.com/</a>
Which maybe is shorter? I don't recall.
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!)<p>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).<p>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.<p>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.<p>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.<p>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.<p>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.
I was greatly disappointed with this book because none of the 'Game' examples had a graphical interface to them. They are all text based.<p>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: <a href="https://realmofracket.com/games.html" rel="nofollow">https://realmofracket.com/games.html</a>
This looks great!<p><i>Why's Poignant Guide to Ruby</i> 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...
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.
I've learned LISP and Scheme, gained some useful insights, used them on a few random projects, and then dropped them.<p>I recommend learning them, but then switching to something like Reason / OCaml / F# / Haskell.
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.<p>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.<p>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 <i>could</i> be written in Lisp.
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.
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.
I'll get hammered for this, but there are better books.<p>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.<p>I do like the Period Table though.<p>And maybe it's just me? I have the book on my shelf, and it's dusty.<p>I do feel using a comic book format to convey technical information is the way to go. It should be used more often.