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.
Even worse if the examples were for the Spectrum, which had an even more peculiar dialect!
I'm not sure how that would be a bad thing. Did you mean unidiomatic?
In reality, yes, at least because of two differences:
1. Lisp is a significantly more powerful language, compared to most non-Lisp languages. Thus, many patterns and practices that are needed in other languages, are simply not needed at all in Lisp, or become far simpler.
2. Lisp is a "programmable programming language" where code is a "first class citizen" and can be manipulated as well as any other kind of data such as numbers. This opens a very different approach to programming, with its own, different "best practices".
The more I program, the more I'm convinced that - unless you've coded identical software many times before - code needs to grow organically and stay as focused and close to the problem as possible. Abstractions should follow naturally and be done "just in time". If they're needed, they have to be written either way, and you're not saving time by writing them up front (focused code is easy to refactor).
Of course with experience, you learn that some patterns of change are likely to occur, or that some touches of abstractions here and there are very beneficial. But beyond that, I feel the best way is to write simplest code possible, wait for it to be needed elsewhere, and then DRY up semantics.
I liked the posts of Casey Muratori, which explain roughly this mindset, calling it "semantic compression" and "compression-oriented programming": https://mollyrocket.com/casey/stream_0019.html.
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...
>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....
Speaking about another lisp, Clojure, it is a goal that each program finds its own design pattern. That's kinda the whole idea. Design patterns can really get in the way, unless your language requires them, which some languages do (i.e. Java where everything must be an object, so OO it is, or Apple's platforms where the MVC pattern is deeply interwoven into all the APIs).
Lisp in general is about exploring a particular problem using only the constraints of that problem, without concern for how different problems get solved. By contrast, design patterns are about forcing a common solution onto a range of different problems.
This is one of the best criticisms of Design Patterns i've ever read. Great point.
I always viewed design patterns as providing a shared name for common solutions to common problems. And that forcing a common solution to a range of different problems was a misuse of them.
But maybe I'm wrong.
Exactly, a design pattern is just that: a pattern of design, that shows up organically after you have enough systems designed in the same language. Many of the design patterns that occur in languages like C++ and Java don't show up in Lisp because Lisp is a rather different language, but then we have our own design patterns as well, things like with- macros.