enlivend (enlivend) wrote,

Things This Book Will Not Do

The message of this book is going to be:

you can do more or less "anything" in lisp, and here are some examples.

The message will not be:

here's how to do everything.

As one of my reviewers has put it: The book is not a reference, nor could it be. Common Lisp alone is far too big to cover at reference detail in a book this size and whose subject extends far beyond the language itself. It's more of an informal look at how practical lisp is - as a tool for today's programmer. It will miss stuff out, it will skirt around tricky areas, it will allude sketchily and unevenly to fine details. The reference material is already available - in the HyperSpec, in CLtL2, in Graham and in Seibel, in the documentation with implementations. This book will point to that material, but isn't going to try to reproduce it.

Each topic I've looked at so far could be made the subject of its own book. ("Persistence in Common Lisp - the Definitive Guide"; "Multi-tasking in Common Lisp - the Definitive Guide"; "Memory Management in Common Lisp - the Definitive Guide"; and so forth. Dream on.) In particular, there are going to be several libraries worthy on mention in each chapter, several different solutions to each problem, and it was never an option to give them all proper coverage. I have to limit myself.

By and large I'm choosing one solution under each heading and giving it some fresh air. It's right and proper to include a mix of proprietary and non-proprietary libraries, to show off a variety of lisp implementations, and to filter the candidates so that the book is balanced and "works" as a whole. I'm always grateful for suggestions received and I certainly intend to give mention to worthy alternatives, but I cannot include everything.


[1] Chapter overflow

There isn't even the space to fully document any single library within its chapter. I give a flavour, an assurance that: if you commit your organisation to developing in lisp, you won't regret it later.

As an example: my original plan for Part 3 was some permutation of

  1. Persistence
  2. Iteration
  3. Threads
  4. Memory

The iteration chapter was to include (non exhaustive list): AllegroCache's support for walking over instances of persistent classes; and Richard Waters' "series" package. I was looking forward to having an excuse to finally get my head round that. But I found while writing 13 that I had about 50% more material than I could fit into my budget of about 4000 words per chapter. So I took the decision to drop "Iteration" and merge the AC material for that chapter into the overflow from 13 to create a new chapter 14 ("Further Persistence").

This decision may have been a mistake - it's unbalanced to devote two chapters to a single topic when overall space is under such contention - and I intend to revisit it at the end of first draft. I'll be guided then by how badly other chapters have overflowed. So far: "Threads" is a couple of pages over budget; "Memory" is bang on.

[2] Comprehensive Survey

I did toy early on with the idea of proposing to O'Reilly that the book should be a comprehensive directory of lisp libraries.

Let's leave aside the questions of whether such a volume could ever sell enough copies to justify itself before it became out of date, and whether it would be bought by anyone who wasn't already a committed lisper. I suspect O'Reilly would have rejected such a proposal on both these grounds, but as a thought experiment let's ignore that for now.

Under each heading in such a book we'd try to locate all the available libraries. For example, under "Persistence" we would expect to be thorough about listing all the SQL clones as well as all the "in lisp" solutions: Elephant, Rucksack, AllegroCache,....

We'd then want to list which libraries worked on which platforms, which ones were currently maintained, how to get them up and working, what license they ran under, what the pros and cons were for each, all that fine stuff. Quite a research project in its own right.

I think it's reasonably widely acknowledged that this is something the lisp community really needs to see done. Indeed some efforts have been made to get this or similar off the ground. I've been wondering whether the solution is for the community to find a way to pay some individual to spend a year or so on this doing it properly.

But it really didn't feel like something I could just fit in as a background activity while getting a book written (and still spending the odd hour on the side keeping myself fed).

Tags: book, lisp
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened