Land of Lisp (2010)
landoflisp.com
landoflisp.com
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)
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.
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.
Land of Lisp is great, been years since I touched it.
On the other hand, [Hissp][1] has a pretty good tutorial for anyone coming from a Python background.
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.
https://medium.com/@MartinCracauer/static-type-checking-in-t...
> Coalton is an efficient, statically typed functional programming language that supercharges 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.
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.
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, ...).
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.
Clojure's native thread-safe data structures are a significant difference, though.
* 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.
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.
That's pretty damn far from "no difference"! Once again, rules are non obvious, do not follow the principle of least surprise.
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.
$ sbcl
* (defvar a (list))
A
* a
NIL
* (defun x (v) (push 'b v) v)
X
* (x a)
(B)
* a
NIL
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.
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.
Value. Value, value, always value. However, it seems that maybe you don't understand exactly what the value is that you're passing.
> Notice how, in my example, the resultant list is updated in the function parameter
No [0]. It makes a new list (really a new cons cell, which contains the new item and then points to the old list [1]), and assigns that to v. And your example doesn't actually show this update happening, it just shows the return value of push (it so happens that it is updated, however). The original list --- passed in or otherwise --- is never changed. You say that you're "updating" a list, but you're not mutating or updating your data structure at all --- you're making something new, and assigning that to v.
> These are two logically different behaviors!
They are two logically different operations. Are you sure that you understand the data structures you're working with, and the operators that you're calling on them? Did you perhaps try to map concepts from another language into Common Lisp, find functionality that looked similar on the surface, then become surprised when the results were not identical?
Linked lists differ fundamentally in structure from arrays, and so the operators which are commonly used with them differ in turn. Perhaps you would like to compare arrays to vectors, as a closer approximation in data structures, with similar typical strategies of manipulation?
> does not follow the principle of least surprise.
You keep saying this, as if that is that. But nothing about your example is surprising to me, so I suppose this is a matter of perspective.
This is a distinction without a difference.
> ...you're making something new, and assigning that to v.
Yes, I know that. The point is that the behavior seen by the user for similar operations is entirely different between lists and other pieces of Common Lisp.
> They are two logically different operations.
Yes, obviously. The point is that Common Lisp does an absolutely crap job of making these things actually consistent from the point of view of the user. The language is littered with entirely inconsistent behavior and choices.
Common Lisp provides a decently designed sequences abstraction which allows the encapsulated vectors and traditional unencapsulated lists, as well as strings, to be manipulated not just similarly, but by exactly the same code.
This was developed in recognition of the exactly the issue that you are getting at. Forty years ago, the group of people designing Common Lisp were aware of this desire to have a consistent access method for different kinds of sequences and they did something about it.
The charge of "absolutely crap job" can only be fairly leveled at a language that make no effort to provide for uniform treatment of encapsulated vectors and unencapsulated lists.
What looks "surprising" depends on your background. I agree that Lisp contains surprises for someone who has programming experience, but that experience is limited to Python or Javascript which provide only encapsulated arrays as the principal sequence aggregation mechanism.
I had two decades of programming experience coming to Lisp, and had written C programs which used both unencapsulated lists:
list_node *list = NULL;
list_block list = LIST_EMPTY_INITIALIZER(list); // eg circular, expanding to { &list, &list }
So, I wasn't surprised in any way. From the description of NIL and the cons cell linkage in the book I was reading, I instantly recognized it instantly as the unencapsulated style of lists, like "list_node *list = NULL".
In C, it would be obvious that this can't work:
list_node *list = NULL;
list_append(list, list_node_new(42));
// wrongly expecting list to have changed from NULL to non-null!
list_block *list = list_new();
list_append(list, list_node_new(42));
I remember that was intriguing to me how Lisp is getting away with the unencapsulated single linkage for everything: like how that is the list structure for the entire language. In the light of the functional programming (you can always just keep consing up new conses to transform lists) together with the garbage collection, it very soon clicked for me. I remember thinking that if we could just keep mallocing new nodes and not worry about freeing, that would be pretty nice to work with in C.
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.
Component, Mount, Integrant, System, Clip.
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.
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?
https://susam.net/blog/lisp-in-vim.html
It would be better if it was ihtroduced then.
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...
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).
Do you have a link or reference I could learn more about it from?
I'm not going to say that's true, but that's one of the points of the comic.
Preaching to the choir.
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.