This book won't be a very strong ally against the stereotype of the elitist Lisper...

"Notice how the text we enter is in lower-case but the text returned from lisp is in upper-case. This is a feature of COMMON LISP that allows us to easily scan a REPL print-out and know which expressions we entered versus which were printed out by lisp."

Ah, I always thought it was a bug graciously bestowed by our ancestors.

Not to mention that CL reader can be configured to have any kind of case behavior you want, and turning symbols to upper case just happens to be the default.

I'm aware of that but I've always been wary of doing (setf print-case :downcase) globally because it can break code. Consider this example:

  (let ((*print-case* :downcase)
        (my-symbol 'mine))
    (intern (format nil "IT-IS-~A" my-symbol)))
  => |IT-IS-mine|, :INTERNAL

Let's say print-case has been setf'd globally and my-symbol is an argument to a macro. The macro wants to derive a new symbol from my-symbol. But the result is ugly because the macro assumed print-case :upcase. There are many such examples in my and other people's code.

edit: How do I prevent asterisked variable names from indicating italics?

Is it awesome or just unfortunate that the book's title abbreviates to LOL?

If it were a Haskell book then clearly they'd need one of these on the cover: http://arcanux.org/lambdacats.html

It's certainly deliberate in either case.

In chapter 2:

"Some programmers follow a convention of prefixing and postfixing special variable names with asterisks, like temp-special. This is called the earmuff convention. For reasons explained in section 3.7, Duality of Syntax, this book does not use earmuffs so our special variable declarations look like this:

(defvar temp-special)"

Double-U Tee Eff!! I challenge you to find 5 serious lispers that don't use the convention and/or justify going against said convention convincingly.

edit: In chapter 3:

"So lexical and dynamic variables are actually completely different, deservedly distinct concepts that just happen to share the same syntax in COMMON LISP code. Why on earth would we want this so-called duality of syntax?"

What?! You're asking why we want this duality of syntax just after saying it's because they're completely different concepts that just happen to have the same syntax... (edit: oh, I misread that. You confused me because you said there was a duality of syntax when you probably meant there's a duality of semantics (edit: wait, I reread it a couple times and I think I may not have misread it after all. It simply doesn't seem to make any sense.))

And you seem to imply using the stars convention reduces the power of macros, while this is absolutely not the case.

"A traditional convention in COMMON LISP code is to prefix and postfix the names of special variables with asterisk characters. For example, we might've chosen to name our temp-special variable temp-special. Since this convention is almost like having another namespace for dynamic variables, diminishing their duality with lexical variables, this book does not follow it exactly."

Diminishing duality? That's diminishing unity and increasing duality. The stars convention establishes a duality of syntax where there is a duality of semantics and that's a good thing. Removing the stars only makes things more confusing because you're conflating two, in your words, "actually completely different" concepts.

* (function '(lambda (x) (+ 1 x)))

That looks wrong... Let's see what my REPL thinks:

  Execution of a form compiled with errors.
 Form:
   #''(LAMBDA (X) (+ 1 X))
 Compile-time error:
   '(LAMBDA (X) (+ 1 X)) is not a legal function name.
    [Condition of type SB-INT:COMPILED-PROGRAM-ERROR]

I thought so.

"Which is a lesser fashion crime: lexical variables with asterisks or special variables without? I tend to think the less verbose of the two."

Why not lexical variables without asterisks and dynamic variables with them, then? Lexical scope is used pretty much everywhere while special scope is used seldom in comparison (it's even hidden in expansions of "with-" style macros a lot).

Your objections seem reasonable, but one of them bothers me more than the others. The error using the special form could be a typo (I'd have had to look up whether to write (function mapcar) or (function 'mapcar).) The oxymoronic use of "duality" is kind of odd, but given that the author probably hasn't had an editor (or even many proofreaders), I'll cut him some slack.

What really worries me is the dropping of and carping against well-established conventions of the CL world. There's a long tradition of solitary, intelligent but self-thwarting types who take up Lisp and "improve" on it and proclaim how everyone else is wrong. Lisp attracts these kinds of quacks, so this last example is a bad sign. It's not that existing Lisps can't be improved on; the capacity for such improvement is what makes Lisp so great. But the threshold for doing so is high, and I don't think the author meets it here. He's picked a decades-old CL convention that exists for good reason, made a rather weak case against it and summarily excised it... from a CL book whose only audience will be CL enthusiasts? That doesn't seem like very good judgment. Oh well, perhaps the book will still be worthwhile.

This relates to something else that's been on my mind lately. Almost every time I've thought of a "better" way to do something in CL than the standard or conventional way, I've later discovered that it created more problems than it solved and dropped it. Eventually it dawned on me that the designers of CL weren't stupid. More than that, they were cognizant of a broad range of issues when making the decisions they did. It's true that some highly informed people believe that CL is kludgey because of the compatibility constraints that it was designed under, but I think the fact that CL was a generalization over various Lisps and millions of lines of existing code (in many different domains) is also one source of its amazing strength for building production systems. In some fundamental way, the tradeoffs that were made in creating CL seem optimized for what programmers actually do when building complex applications. It's not the most concise or modern language at the code snippet level, but at a systems level CL is so beyond anything else I've seen that I've learned to give its designers the benefit of the doubt. When something seems wrong, it's probably (though not necessarily) because I'm unfamiliar with some of the issues involved.

We use the "earmuff" convention with good results and no plans to change it.

Incidentally, it's not called the "earmuff" convention, if Google is to be believed:

http://www.google.com/search?q=earmuff+convention+lisp

... other, that is, than in the book Let Over Lambda.

Edit: I agree with you about the convention - I find it valuable in my code (along with special variables in general, which are a great example of how CL is optimized for building working systems).

(You know, Canada is kind of an 'Island', and many Canadiens are, too.)

I'm reading the available chapters and I like it! It is well written. Can't wait to have the dead tree copy!

I just ordered it. I'm a little skeptical, but if the book is half as good as its stated goal, it'll be worth a lot.

Actually, I'd probably buy any credible new Lisp book at this point.

I don't think there's any automatic credibility here. It's a book by an unknown author published by a vanity press.

You're quite right, and I see that my comment was unclear. What I meant by "credible" was "not obviously not credible"; in other words, I read the first chapter and it didn't obviously suck. It's basically an expected value calc: the probability of the book being very good is low, but my interest in the topic is so high that it's worth the bet.

After I saw the author's blog (which could be described as a poster child for the "Bipolar Lisp Programmer") my probability estimate got a little lower.