Land of Lisp (2010)(landoflisp.com)
landoflisp.com
Land of Lisp (2010)
http://landoflisp.com/
84 comments
Simple but refined, guaranteed to blow your mind!
https://www.youtube.com/watch?v=HM1Zb3xmvMc
https://www.youtube.com/watch?v=HM1Zb3xmvMc
Thanks for the link! So funny.
This book is probably the most fun I have had with a programming book. I remember going through most of it the first day I cracked it open.
Curious if anyone knows other books that take a similar approach: fun but not dumbed down.
I tried a few from nostarch, in general I love their books, but i haven’t found one as engaging as land of lisp.
Curious if anyone knows other books that take a similar approach: fun but not dumbed down.
I tried a few from nostarch, in general I love their books, but i haven’t found one as engaging as land of lisp.
Why's guide to Ruby is the only other book of that ilk that I'm aware of.
https://poignant.guide/
https://poignant.guide/
Realm of Racket
https://nostarch.com/realmofracket
https://nostarch.com/realmofracket
Not as fun, but there is a Rust book that teaches you Rust through teaching you to programming 2D games. It is called Hands-On Rust [0], and it is from PragPub.
When learning a language, I always look for books that actually make you do something rather than tediously, boringly walk you through the user-facing API.
[0]: https://pragprog.com/titles/hwrust/hands-on-rust/
When learning a language, I always look for books that actually make you do something rather than tediously, boringly walk you through the user-facing API.
[0]: https://pragprog.com/titles/hwrust/hands-on-rust/
Plus one, going through this now.
Land of Lisp is great, been years since I touched it.
Land of Lisp is great, been years since I touched it.
“The Little Schemer”, by Daniel Friedman, takes a different tack, but, like LoL, is entertaining while teaching you the scheme language using the Socratic method.
Lisp is awesome, but I wish more places used regional pricing for online purchases. It's kinda crazy paying 40 dollars for an ebook since it's almost 1/5 of our minimum monthly wage (Brazil)
When you can’t afford you can download pirated version and donate if you feel that the book gave you value.
2021 was the 2nd year in a row that there was sales on Apress where they throw out great Lisp books for 6/7/8 Euro printed or digital. Subscribe to r/lisp or r/common_lisp and you will get the news.
Books like this sometimes feature in humble bundles.
It is a fun book to get started with (Common) Lisp! We need more fun, but instructive, books like this.
Yes, books introducing languages by implementing fun applications, like games in this case, usually helps me keep motivation and interest longer than other kinds of “Introduction to ..” books.
Same goes for me. I get tired when a book is practically a boring walkthrough of the user-facing API of a language. So, I look for something that actually makes me do something fun with the language that is being taught.
I wonder if Hylang can be used to work on this book, for someone approaching Lisp from a Python background, or the impedance mismatch between Hylang and CL is too high to allow that.
I think LoL is too CL-specific. If you know both languages first, you can pretty much translate, but since they'd be trying to learn Lisp in the first place, this is a bad idea.
On the other hand, [Hissp][1] has a pretty good tutorial for anyone coming from a Python background.
[1]: https://github.com/gilch/hissp
On the other hand, [Hissp][1] has a pretty good tutorial for anyone coming from a Python background.
[1]: https://github.com/gilch/hissp
On the subject of creative Lisp tutorials, I like Manga de Wakaru Lisp:
http://lambda.bugyo.tk/cdr/mwl/
http://lambda.bugyo.tk/cdr/mwl/
Great. I even had a copy of Japanese translation of the land of lisp. Quite fun to see lisp in another language.
Funny, but the premise is insane: that Lisp is ful of things that are done better elsewhere and that Lisp is the weapon against bugs. I worked professionally in Lisp (Scheme) and this is 100% false. In my experience dynamically typed languages (incl. Lisp, Python, and Smalltalk) will absolutely be more bug prone than a good typed language (like Haskell or Rust) on non-trivial programs.
You can have type checking in Common Lisp:
https://medium.com/@MartinCracauer/static-type-checking-in-t...
https://medium.com/@MartinCracauer/static-type-checking-in-t...
I was slightly surprised to learn how well Common Lisp had implemented its types. I keep wondering why CL almost completely failed to break into the minds of people in early 2000s. That was about the time I first learned about python, which kind of seemed to be everywhere. It took 5-10 years before I even heard of Common Lisp.
And now it seems to me that the Common Lisp which was pretty much fixed in 90s is superior in many ways (runtime, programming environments, typing -- to mention a few) to even the revised python3 of 2021. And then Javascript, essentially a bad clone of Lisp, got popular? Makes absolutely no sense.
And now it seems to me that the Common Lisp which was pretty much fixed in 90s is superior in many ways (runtime, programming environments, typing -- to mention a few) to even the revised python3 of 2021. And then Javascript, essentially a bad clone of Lisp, got popular? Makes absolutely no sense.
I’m also surprised by this and I continue to love Common Lisp over all other languages. But I think one reason is that languages aren’t just languages. The amazing parts of Common Lisp were all standardized in 1992 or whatever. By people who are not at all involved in any kind of Unix, Linux, open source, web, scripting, etc. It’s like a beautiful cultural legacy that’s maintained by some enthusiasts and a couple of insular commercial vendors. Now what I really wonder is why nobody outside of some Scheme dialects have stolen the restartable condition system, which is so amazing and straightforward to implement.
> By people who are not at all involved in any kind of Unix, Linux, open source, web, scripting, etc.
Common Lisp on UNIX appeared in the mid 80s, long before the ANSI CL standard.
Scott Fahlman was one of the five designers of the early Common Lisp. He headed the CMU CL project, which was a) on UNIX since around 1984 and b) public domain. Code from CMU CL was used in a dozen other implementations.
Other well known CL implementations for UNIX which were developed before 1994, when the ANSI CL standard was published: Allegro CL, GNU CLISP (free), (A)KCL (no cost, free, later renamed to GNU Common Lisp), LispWorks, Lucid CL, ...
Three large commercial implementations of CL were developed initially exclusively for UNIX and were available end 80s: Allegro CL, Lucid CL and LispWorks.
Generally the language came out of well funded research labs and companies and was designed to be portable across a large variety of operating systems (like UNIX variants, VMS, LISPMs, DOS/Windows, Mac OS, ...).
Common Lisp on UNIX appeared in the mid 80s, long before the ANSI CL standard.
Scott Fahlman was one of the five designers of the early Common Lisp. He headed the CMU CL project, which was a) on UNIX since around 1984 and b) public domain. Code from CMU CL was used in a dozen other implementations.
Other well known CL implementations for UNIX which were developed before 1994, when the ANSI CL standard was published: Allegro CL, GNU CLISP (free), (A)KCL (no cost, free, later renamed to GNU Common Lisp), LispWorks, Lucid CL, ...
Three large commercial implementations of CL were developed initially exclusively for UNIX and were available end 80s: Allegro CL, Lucid CL and LispWorks.
Generally the language came out of well funded research labs and companies and was designed to be portable across a large variety of operating systems (like UNIX variants, VMS, LISPMs, DOS/Windows, Mac OS, ...).
First issue : Access for simple project …
Ex a simple programming web site: if you want to use your iphone, working copy on you Gh-pages, edit test and publish a web pages with js,css&html —- you can. With full version control and even use library external if you have to.
Second issue : external integration which python as script and c (and c++) as os level “script” …
Third issue : hard to use it’s package system.
I am not anti-lisp, just spend $700 to get a Casio ai-1000 and trying to use ulisp.
Just not main stream like.
God’s programming language as said not used God and by mortal.
Ex a simple programming web site: if you want to use your iphone, working copy on you Gh-pages, edit test and publish a web pages with js,css&html —- you can. With full version control and even use library external if you have to.
Second issue : external integration which python as script and c (and c++) as os level “script” …
Third issue : hard to use it’s package system.
I am not anti-lisp, just spend $700 to get a Casio ai-1000 and trying to use ulisp.
Just not main stream like.
God’s programming language as said not used God and by mortal.
> Makes absolutely no sense.
Well, for me, it's just not ergonomic. Unlike something like Python.
I solved this year's Advent of Code in Common Lisp in an attempt to learn it better. I determined in the process that the language was awful by 2021 standards and if you wanted a Lisp that was actually usable, go with Clojure or a decent Scheme.
Well, for me, it's just not ergonomic. Unlike something like Python.
I solved this year's Advent of Code in Common Lisp in an attempt to learn it better. I determined in the process that the language was awful by 2021 standards and if you wanted a Lisp that was actually usable, go with Clojure or a decent Scheme.
I can see how Python is clearly more ergonomic than Common Lisp, but I really don't see any significant differences between CL, Clojure and Schemes. Just ergonomic micro-optimizations.
Clojure's native thread-safe data structures are a significant difference, though.
Clojure's native thread-safe data structures are a significant difference, though.
My biggest issues with Common Lisp were:
* Absolutely nothing is consistent. When you mutate something, is the place it goes the first or last argument? No consistency here. * When you pass a value to a function, is it by value or by reference? Who knows? Rules are non obvious, do not follow the principle of least surprise. * Lisp-2 just makes working with higher order functions obnoxious.
One thing it has going for it though is the loop macro, that's admittedly pretty neat.
* Absolutely nothing is consistent. When you mutate something, is the place it goes the first or last argument? No consistency here. * When you pass a value to a function, is it by value or by reference? Who knows? Rules are non obvious, do not follow the principle of least surprise. * Lisp-2 just makes working with higher order functions obnoxious.
One thing it has going for it though is the loop macro, that's admittedly pretty neat.
There is no "by reference" in Common Lisp; everything is a value. Some values have reference semantics. This makes no difference unless you're mutating, or making unwarranted assumptions about the eq function.
To understand most code, you can just pretend that all values have reference semantics. If mutation is going on and/or the eq function is being used, you have to prick up your ears and pay attention to that detail.
To understand most code, you can just pretend that all values have reference semantics. If mutation is going on and/or the eq function is being used, you have to prick up your ears and pay attention to that detail.
> Some values have reference semantics. This makes no difference unless you're mutating, or making unwarranted assumptions about the eq function.
That's pretty damn far from "no difference"! Once again, rules are non obvious, do not follow the principle of least surprise.
That's pretty damn far from "no difference"! Once again, rules are non obvious, do not follow the principle of least surprise.
If you're mutating any object, it is necessarily a value with reference semantics, period. Objects that do not have reference semantics are immutable.
Some objects that cannot be mutated (like numbers) can have reference or value semantics depending on how they are implemented. For instance, a bignum integer always has reference semantics. Small integers usually have value semantics: they fit into a machine word with no heap part. In that case, all instances of the number 0 or 1, and some range beyond that in both directions, will always be the same object according to eq.
If you're mutating an object (and, thus, something that has reference semantics), the difference that the reference semantics makes is that other parts of your program may hold a reference to that object; your code has not received a copy. If you haven't accounted for that, you probably have a bug.
Sure, this stuff isn't obvious; unless you already know another dynamic language like Ruby, Javascript, Python, ...
Complete neophytes have to be taught it from the fundamentals.
Some objects that cannot be mutated (like numbers) can have reference or value semantics depending on how they are implemented. For instance, a bignum integer always has reference semantics. Small integers usually have value semantics: they fit into a machine word with no heap part. In that case, all instances of the number 0 or 1, and some range beyond that in both directions, will always be the same object according to eq.
If you're mutating an object (and, thus, something that has reference semantics), the difference that the reference semantics makes is that other parts of your program may hold a reference to that object; your code has not received a copy. If you haven't accounted for that, you probably have a bug.
Sure, this stuff isn't obvious; unless you already know another dynamic language like Ruby, Javascript, Python, ...
Complete neophytes have to be taught it from the fundamentals.
No, there really is no consistency to Common Lisp's mutation.
$ sbcl
* (defvar a (list))
A
* a
NIL
* (defun x (v) (push 'b v) v)
X
* (x a)
(B)
* a
NIL
> Now if you were to do similar with something like an array, the original variable would be mutated.
That is false. To do a similar thing with an array, we need a non-mutating operation which returns a new array which is like an existing array, but with an element prepended.
Then we need a macro to mutate a place to replace an existing array in that place with a new such an array.
Then, exactly the same kind of behavior will be reproduced:
It makes less sense to treat arrays that way. It's possible, but you need an exotic data structure to do it even halfway efficiently; that structure will never be as efficient as an ordinary mutable array for ordinary array work.
Whereas, treating singly linked lists this way is almost free of additional cost.
That is false. To do a similar thing with an array, we need a non-mutating operation which returns a new array which is like an existing array, but with an element prepended.
Then we need a macro to mutate a place to replace an existing array in that place with a new such an array.
Then, exactly the same kind of behavior will be reproduced:
(defun array-cons (obj array)
(let ((new-array (make-array (list (1+ (length array))))))
(replace new-array array :start1 1)
(setf (aref new-array 0) obj)
new-array))
(defmacro apush (val array-var)
(assert (symbolp array-var) (array-var)
"fixme: simple implementation: ~a must be symbol")
`(setf ,array-var (array-cons ,val ,array-var)))
[1]> (defvar a #())
A
[2]> (defun x (v) (apush 'b v) v)
X
[3]> (x a)
#(B)
[4]> a
#()
[5]> (apush 1 a)
#(1)
[6]> (apush 2 a)
#(2 1)
[7]> (apush 3 a)
#(3 2 1)
It makes less sense to treat arrays that way. It's possible, but you need an exotic data structure to do it even halfway efficiently; that structure will never be as efficient as an ordinary mutable array for ordinary array work.
Whereas, treating singly linked lists this way is almost free of additional cost.
> That is false.
No, it's not. Notice how, in my example, the resultant list is updated in the function parameter, but not the initial var defined by defvar. Whereas if I made an array via (make-array), passed it into the function, and updated that by the way the language documentation tells you to (setf and one of the aref functions), you'd end up with both the function parameter and initial var both pointing to the updated value. These are two logically different behaviors! And that's exactly what my criticism stated: "When you pass a value to a function, is it by value or by reference? Who knows? Rules are non obvious, do not follow the principle of least surprise."
> Lists work this way because... It makes less sense to treat arrays that way.
Yes, that's exactly the point. The language is inconsistent and does not follow the principle of least surprise.
No, it's not. Notice how, in my example, the resultant list is updated in the function parameter, but not the initial var defined by defvar. Whereas if I made an array via (make-array), passed it into the function, and updated that by the way the language documentation tells you to (setf and one of the aref functions), you'd end up with both the function parameter and initial var both pointing to the updated value. These are two logically different behaviors! And that's exactly what my criticism stated: "When you pass a value to a function, is it by value or by reference? Who knows? Rules are non obvious, do not follow the principle of least surprise."
> Lists work this way because... It makes less sense to treat arrays that way.
Yes, that's exactly the point. The language is inconsistent and does not follow the principle of least surprise.
Maybe the reason is Marketing ?
Are there any implementations of good type systems on top of lisp (let's say approaching Haskell's in capability)?
There is! Coalton: https://github.com/coalton-lang/coalton
> Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp
> Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp
Typed Racket is getting steady development and focus but more closely resembles Scheme.
I've always wanted to try Lisp but the fact that it is dynamically typed has always scared me away (and my experience with dynamically typed languages is the same - they are bug magnets). Rust is my go to and I don't think that will change any time soon.
As I'm sure you know, there's a few good strong typing libraries that you can use at any layer of code.
A bit like how python has type hinting + libraries to have static typing.
But there is something to be said about it not being standard. Library code and existing codebases generally (in my experience) don't do that.
It really is the incredibly weird problem of a language being more extendable and capable than anything else.
But because of that it's really hard to work on existing code as you have to enter with 0 assumptions if you want to avoid getting "tricked" while catching up.
A bit like how python has type hinting + libraries to have static typing.
But there is something to be said about it not being standard. Library code and existing codebases generally (in my experience) don't do that.
It really is the incredibly weird problem of a language being more extendable and capable than anything else.
But because of that it's really hard to work on existing code as you have to enter with 0 assumptions if you want to avoid getting "tricked" while catching up.
sorry that premise (and reality) is for Common Lisp ;)
I never understood why that video didn't make it onto MTV.
I thought there was some interesting history in the book and certain common lisp implementations like SBCL are incredibly fast and powerful (some real secret alien technology there), but I thought that I could generally make shorter and clearer programs in just about any common scripting language (Python, Perl, PowerShell...etc). Granted, I know those languages better, but the book honestly didn't want to make me write Lisp. Homoiconicity is insanely powerful, but I find that specific syntax for certain things is easier for me to read and write up to a certain point.
The best part of Land of Lisp is learning to use SLIME. Except that learning it (and REPL-driven development) makes all other language/editor integrations seem inadequate! (one exception I know is CIDER for Clojure, also excellent)
Not as that book. In fact it is after nearly 1 decade after I finished that book and finally do this REPL and live code editing in lisp via
https://susam.net/blog/lisp-in-vim.html
It would be better if it was ihtroduced then.
https://susam.net/blog/lisp-in-vim.html
It would be better if it was ihtroduced then.
Not my experience at all. I have spent enough time doing REPL-driven development to know that I most definitely do not prefer it. It might be superior for you. But that doesn’t automatically mean that it will also be superior for anybody else. We are all different, with different preferences and work styles.
Would you mind shedding some light on how you do development and the pros and cons you experienced comparing to REPL-driven development?
Sure. I think REPL-driven development is great for what I call exploratory programming. When you are playing around with ideas and want to quickly try out different approaches and quickly test if a new function is working. However the code that I normally deal with are very large code bases where a lot of the code is not written by myself. And I find it a lot easier to navigate and build a mental model of where things are and how it works using an IDE. It simply works better for my brain but of course YMMV.
Why not both? Are the two concepts somehow incompatible?
A REPL is a (very) powerful tool for testing, probing, inspecting (etc) code; but it is only one tool. It should be a part of your IDE (if you go for such things), not replace it.
A REPL is a (very) powerful tool for testing, probing, inspecting (etc) code; but it is only one tool. It should be a part of your IDE (if you go for such things), not replace it.
Wouldn't it make more sense to automate the tests instead of doing it manually? I have 9000+ auto tests for the large complex C++ code base I am currently maintaining. And the result is zero customer production bugs in the last 5+ years. And I routinely refactor and rewrite large parts of the code without worrying about it.
Yes, automated test suites are great! I don’t know that they need all the things some people stuff into them, but the idea is a useful one.
If you take my comment in the context of REPL-driven development, it’s going to seem tangential at best. But you mentioned that you prefer IDEs over REPLs; I’m merely suggesting that the two need not be exclusive.
Unless you’re advocating for TDD, in a strict sense?
If you take my comment in the context of REPL-driven development, it’s going to seem tangential at best. But you mentioned that you prefer IDEs over REPLs; I’m merely suggesting that the two need not be exclusive.
Unless you’re advocating for TDD, in a strict sense?
Not OP, but I would venture that REPL-driven development encourages a style that is essentially trial and error programming.
This may be good for small scale, short lived scripts and projects but it does not scale.
My experience from a somewhat large (400+ people) Clojure project is that people would be better off building a test suite as a checked-into-source-control REPL substitute to drive their experiments and make sure the expected application behaviour stays the same over time.
REPLs may be useful, but don’t use them as your only tool.
This may be good for small scale, short lived scripts and projects but it does not scale.
My experience from a somewhat large (400+ people) Clojure project is that people would be better off building a test suite as a checked-into-source-control REPL substitute to drive their experiments and make sure the expected application behaviour stays the same over time.
REPLs may be useful, but don’t use them as your only tool.
Yep a good match for how I am thinking. One of the large projects I work on is written in C++ and it has more than 90000 use case tests to make sure it is safe to deploy into production. I haven’t had a customer production bug in the last 5+ years.
For me, the biggest problem with REPL-driven development is the handling of global state. That's why there's no fewer than 5 (!) actually-being-used Clojure libraries for handling it.
What "handling of global state" are you referring to? The state of "vars" or the state of actual application data (a la "atom"s)? The former being solved with the various ns-* functions, the latter depends on the application and how state is being used. If you could, could you share the libraries you're referring to too?
> If you could, could you share the libraries you're referring to too?
Component, Mount, Integrant, System, Clip.
Component, Mount, Integrant, System, Clip.
My reaction as well. The exaggerated claims of Lisp programs being bug free and non-Lisp programmers being slaves/prisoners/drones etc. doesn’t give me confidence in anything the author claims. I know it is supposed to be funny, and I do enjoy the humour, but I would prefer some real life stories about how complicated problems were fixed in Lisp better than what I could have been done in other languages. Lisp has cool features, but that doesn’t necessarily result in better software being developed in Lisp. Certainly looking around there doesn’t seem to be a lot of successful software written in Lisp. The world runs on other languages.
Lilypond (http://lilypond.org/index.html) is music typesetting software that is not for everyone, but can be a joy to use if you have a software background.
It makes extensive use of Scheme under the hood, because C++ proved "too inflexible". I've never looked at the details of what the authors meant by that.
They have some notes on it here if you're curious:
http://lilypond.org/doc/v2.22/Documentation/essay/building-s...
It makes extensive use of Scheme under the hood, because C++ proved "too inflexible". I've never looked at the details of what the authors meant by that.
They have some notes on it here if you're curious:
http://lilypond.org/doc/v2.22/Documentation/essay/building-s...
Thanks for the link! That was a great read. And a good example I think of using Lisp embedded in a C++ program to give the user more power and flexibility. I think it is the right way to do it when your UI is basically code. A lot of games do something similar (using embedded Python, Lua or Lisp) to make it possible for gamers to extend the game. I think Factorio use Lua for this. But Lisp would have been another good choice I think.
You're welcome! Glad to hear you enjoyed it.
I'm familiar with game engines embedding scripting languages, but using Lisp for that honestly hadn't occurred to me (despite being an Emacser that has written several small elisp packages).
I'm familiar with game engines embedding scripting languages, but using Lisp for that honestly hadn't occurred to me (despite being an Emacser that has written several small elisp packages).
Are you aware that Crash Bandicoot for the Playstation and a bunch of follower games were originally written in a Scheme dialect, with the development environment written in Common Lisp (on SGIs)?
Yep and I think it is super cool. More stories like that would do more to improve Lisp adaption than yet another “Lisp is great” article. Don’t make empty claims. Do something cool and then talk about it.
Not at all. That's fascinating.
Do you have a link or reference I could learn more about it from?
Do you have a link or reference I could learn more about it from?
See 'GOOL' and later 'GOAL':
https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...
https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...
https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
Very neat. Thank you!
Ha - that neat little music video is good marketing. I'm half tempted to try the book based on that. The only thing really stopping me is that I hate dynamically typed languages, but still I wonder if I shouldn't try Lisp just to "complete my education".
Be aware that SBCL does pretty good compile-time type checking. It helps a lot during dev. And there's the new https://github.com/coalton-lang/coalton to have like Haskell atop CL.
Lisp also has run-time type checking. In contrary to statically compiled languages, lisp doesn't throw away it's types at run-time, and is always type-safe.
I will consider learning Lisp when it offers a free compiler that builds for Android/iOS. The server space has already a surfeit of languages.
What was the point of that comic? That Lisp has no bugs?
That the methodology of lisp coding leads to less bugs.
I'm not going to say that's true, but that's one of the points of the comic.
I'm not going to say that's true, but that's one of the points of the comic.
I would phrase it a bit differently: Lisp gives you great tools for fighting bugs (which most code initially will have). In that sense, the comic i right.
Also, given all the powerful features, the programmer is more productive and can spend more time on bug-hunting.
Personally I didn't get that message amid all the cutesiness, and I don't see how anyone would get that message if they weren't coming to the comic with that belief already.
Preaching to the choir.
Preaching to the choir.
Can you elaborate on what Lisp gives you to fight bugs that other languages doesn’t have? I know Lisp quite well and I am not sure what specifically you are thinking about?
just wow! great comic
Somehow lisp reminds me of Android and Linux. Too much flexibility and openness makes for a fractioned ecosystem that is hard to adopt by the masses.
Agreed with the sibling that this is an odd take.
As I often point out, though; I don't think we have any real insights as to what makes something that will be adopted by the masses. Outside of throwing effort at it.
Too many of us in the technical space get caught on the idea of throwing that effort at the solution and the problem. You can also throw effort at the actual adoption by the masses. That is, market outreach and general sales.
As I often point out, though; I don't think we have any real insights as to what makes something that will be adopted by the masses. Outside of throwing effort at it.
Too many of us in the technical space get caught on the idea of throwing that effort at the solution and the problem. You can also throw effort at the actual adoption by the masses. That is, market outreach and general sales.
Land of Lisp (2010) - https://news.ycombinator.com/item?id=19677292 - April 2019 (80 comments)
The Land of Lisp - https://news.ycombinator.com/item?id=15417735 - Oct 2017 (135 comments)
How Lisp is Going to Save the World - https://news.ycombinator.com/item?id=5030803 - Jan 2013 (229 comments)
Land of Lisp - https://news.ycombinator.com/item?id=3481456 - Jan 2012 (7 comments)
Land of Lisp - https://news.ycombinator.com/item?id=3013673 - Sept 2011 (6 comments)
Land of Lisp is finally out...and has a music video. - https://news.ycombinator.com/item?id=1836935 - Oct 2010 (108 comments)