What's your favorite book about Lisp?
Re: What's your favorite book about Lisp?
My favorite is PAIP but from the list all are pretty good books.
Re: What's your favorite book about Lisp?
OOP does not suit how I think at ALL.findinglisp wrote:The one place where ANSI Common Lisp lacks versus Practical Common Lisp is with respect to CLOS. PG is not a fan of CLOS and doesn't really cover it. In contrast, Peter Siebel uses is heavily in PCL. That's one reason I recommend both to people. You'll definitely learn something from each.
Once he starts using it he loses me completely, so I stopped reading it.
A Gentle Introduction is pretty much all functional.
BTW, I grabbed an old copy (1984) of "Lisp: A Gentle..." for 11usd but is it worth it to spend another 25usd for one that fits the CL spec? I have the digital version, but I can never concentrate reading a digital book...
Re: What's your favorite book about Lisp?
I'm surprised to see no mention of Successful Lisp here. I finished most of Practical Common Lisp, but found it somewhat hard going. Perhaps too much exposure and too much detail before I was ready and I wasn't doing much practical work. I paused at Chapter 24 and decided to go back to basics, which is when I started reading Successful Lisp. So far it seems to be composed of smaller, more cohesive chunks which makes it a pleasure for me to read (perhaps I'm just a poor reader, but that's another matter Or it may be because I already read most of PCL and am just more familiar with the stuff). It also makes it easier to manage on my PDA (I spider a (section of a) site with a program called Sunrise, which then converts and compresses the files into one smallish archive I can bluetooth to my Tungsten T3 and read whenever I'm idling/waiting/walking etc).
Also, Paul Graham's "On Lisp" has a html mirror, which some may prefer than the PDF/etc versions.
Also, Paul Graham's "On Lisp" has a html mirror, which some may prefer than the PDF/etc versions.
Re: What's your favorite book about Lisp?
My favourite Lisp book is my copy of Lisp In Small Pieces, partly because it is signed by Kathleen Callaway and partly because it's the book I'd most like to have read entirely and fully grokked (and it's set using TeX, like all proper Computer Science books should be).
My favourite Lisp book that I've actually read is On Lisp, partly because I had to print & "bind" it myself and thus it felt like when I taped The Hitch-hikers Guide to the Galaxy off the radio as a kid, and partly because of Paul Graham's wonderfully demonstrative voice.
I also really like PAIP because it is, like On Lisp, clearly packed full of The Lisp Way. I hope to one day make it through to the end of the book, in time to steal a march on some of the next "new ideas" in programming.
To paraphrase THHGTTG:
My favourite Lisp book that I've actually read is On Lisp, partly because I had to print & "bind" it myself and thus it felt like when I taped The Hitch-hikers Guide to the Galaxy off the radio as a kid, and partly because of Paul Graham's wonderfully demonstrative voice.
I also really like PAIP because it is, like On Lisp, clearly packed full of The Lisp Way. I hope to one day make it through to the end of the book, in time to steal a march on some of the next "new ideas" in programming.
To paraphrase THHGTTG:
Of course the book from which I actually learned Lisp was ANSI Common Lisp and my indispensable reference is Practical Common Lisp.Much has been written on the subject of Lisp, most of which stresses the many practical functions it can serve for the modern programmer.
Two seminal books are Peter Norvig's compendious tome Paradigms of Artificial Intelligence Programming, which is far too large to carry, but sits magnificently on fashionable coffee tables, and Paul Graham's handbook, On Lisp, an altogether terser work for masochists.
Re: What's your favorite book about Lisp?
Practical Common Lisp.
It won't get into deep/hairy/complex/advanced stuff, BUT it's something Lisp was needing badly: a book that is easy to read and focus on practical, real world problems. The Haskell community just got something similar with "Real World Haskell". Check google trends for "Lisp". You'll see that interest in Lisp grew since PCL was published. Even though Seibel and his book are not the only causes for the new interest in Common Lisp, his book certainly made a big difference.
It won't get into deep/hairy/complex/advanced stuff, BUT it's something Lisp was needing badly: a book that is easy to read and focus on practical, real world problems. The Haskell community just got something similar with "Real World Haskell". Check google trends for "Lisp". You'll see that interest in Lisp grew since PCL was published. Even though Seibel and his book are not the only causes for the new interest in Common Lisp, his book certainly made a big difference.
Re: What's your favorite book about Lisp?
Hi folks, about Practical Common Lisp I'm going through the book I'm currently reading chapter 13 and I wonder why this is considered to be a great book, so far it hasn't conveyed any original idea about programming and it seems to be just a boring list of lisp functions without going into any detail about them, but I'm only half way through the book so I hope it's going to get better ^___^
Re: What's your favorite book about Lisp?
I felt kind of the same way when I was reading it. It just felt like an overwhelming snow of API specifics (especially the headaches with pathnames and the slightly excessive focus on CLOS IMO).lukasjob wrote:Hi folks, about Practical Common Lisp I'm going through the book I'm currently reading chapter 13 and I wonder why this is considered to be a great book, so far it hasn't conveyed any original idea about programming and it seems to be just a boring list of lisp functions without going into any detail about them, but I'm only half way through the book so I hope it's going to get better ^___^
Currently I'm reading SICP (only in section 2.2 or something so far) and it's very enjoyable and enlightening - lots of opportunities and ideas about the power of higher-order functions and such. It's based on Scheme but that's ok by me.
Re: What's your favorite book about Lisp?
Hi Exolon, glad to hear that so I'm not the only one thinking PCL is not a great bookExolon wrote:I felt kind of the same way when I was reading it. It just felt like an overwhelming snow of API specifics (especially the headaches with pathnames and the slightly excessive focus on CLOS IMO).lukasjob wrote:Hi folks, about Practical Common Lisp I'm going through the book I'm currently reading chapter 13 and I wonder why this is considered to be a great book, so far it hasn't conveyed any original idea about programming and it seems to be just a boring list of lisp functions without going into any detail about them, but I'm only half way through the book so I hope it's going to get better ^___^
Currently I'm reading SICP (only in section 2.2 or something so far) and it's very enjoyable and enlightening - lots of opportunities and ideas about the power of higher-order functions and such. It's based on Scheme but that's ok by me.
I read the first 3 chapters of SICP and completed all the exercises from those chapters great book loved that
Check this out http://eli.thegreenplace.net/category/p ... lisp/sicp/
Re: What's your favorite book about Lisp?
Personally I am finding chapter 24 in PCL to be almost impossible to understand. In comparison, I thought SICP was pretty easy until the latter half where it required a think-while-reading approach instead of just reading it like a novel and solving examples as they came up. Except the one where you had to make a nested table and the functions ended up like (set-car! (set-cdr! (set-car! (car (cdr (car lol)))) omg) rofl) -- that one was tricky to debug.
The problem for me is that PCL went from the early chapters:
a very easy this is a function to slightly more complex this is a macro which could one day be a function
to let's take a break and talk about lists, CLOS, conditions, etc. without gaining any real experience using the language or getting better with it
to now everything is suddenly written in macros that write macros (using hardly used macros at that point in the book such as with-slots and eval-when) which may be contained in classes that have inherited macros from other macro-generated classes..................................
At no point was it ever clear what code might actually be executed at run-time (or load time or compile time or interpreted time or fun time or wtf time). Now of course there is macroexpand-1 which I used as much as possible, and in the very beginning of the chapter it was fairly obvious what was going on. I in fact jumped ahead and wrote the macro to generate the first version of define-binary-class except for not knowing how to convert a symbol to a keyword. But after that the chapter gets pretty ridiculous.
Maybe there is like a 175 IQ requirement to use LISP, and I seem to have fallen short of it.
It could be just an entirely different way one must think. Perhaps instead of trying to figure out why the code works, I should just pretend the names of the functions do what they say they do and use them as one would have to use them. Maybe it can work by abstract magic. "So if this function that appends slot specifier names to other names that were inherited to get a list of every possible slot name in the inherited class, then 'of course' I would put the function as the first argument to with-slots if I want to be able to access every slot." ....
And that's just 1/10 of that one particular class-generating macro--a function that depends on about 5 other function definitions to do almost nothing:
Why the hell isn't there a built-in function/macro to list every slot in a class anyway? One could just append new names to (find-slots 'superclass) or some such.
I hesitate to progress further with this book when I still have to learn python, bash, perl, every new C++ and C# language feature from whatever came before .net to .net 9.2 or whatever it's at now, not to mention Haskell's template thing which is supposed to somehow compare to macros, just so that one day I might be able to be somewhat of a slightly qualified modern programmer (?) Of course, I don't have the slightest clue about the STL-equivalent for all of these languages, so at the end of the day I still can't write a single program that really does ANYTHING except games in C++ which is how I got started. The point is, PCL isn't helping and in fact is further diluting my ability to focus on learning something that might one day be helpful. It seems books in general are pretty passe and one should just use google to learn what function they need RIGHT NOW and go ahead and use it. Programs of the future will be written in a language learned on the fly! (if not present already)
The problem for me is that PCL went from the early chapters:
a very easy this is a function to slightly more complex this is a macro which could one day be a function
to let's take a break and talk about lists, CLOS, conditions, etc. without gaining any real experience using the language or getting better with it
to now everything is suddenly written in macros that write macros (using hardly used macros at that point in the book such as with-slots and eval-when) which may be contained in classes that have inherited macros from other macro-generated classes..................................
At no point was it ever clear what code might actually be executed at run-time (or load time or compile time or interpreted time or fun time or wtf time). Now of course there is macroexpand-1 which I used as much as possible, and in the very beginning of the chapter it was fairly obvious what was going on. I in fact jumped ahead and wrote the macro to generate the first version of define-binary-class except for not knowing how to convert a symbol to a keyword. But after that the chapter gets pretty ridiculous.
Maybe there is like a 175 IQ requirement to use LISP, and I seem to have fallen short of it.
It could be just an entirely different way one must think. Perhaps instead of trying to figure out why the code works, I should just pretend the names of the functions do what they say they do and use them as one would have to use them. Maybe it can work by abstract magic. "So if this function that appends slot specifier names to other names that were inherited to get a list of every possible slot name in the inherited class, then 'of course' I would put the function as the first argument to with-slots if I want to be able to access every slot." ....
And that's just 1/10 of that one particular class-generating macro--a function that depends on about 5 other function definitions to do almost nothing:
Why the hell isn't there a built-in function/macro to list every slot in a class anyway? One could just append new names to (find-slots 'superclass) or some such.
I hesitate to progress further with this book when I still have to learn python, bash, perl, every new C++ and C# language feature from whatever came before .net to .net 9.2 or whatever it's at now, not to mention Haskell's template thing which is supposed to somehow compare to macros, just so that one day I might be able to be somewhat of a slightly qualified modern programmer (?) Of course, I don't have the slightest clue about the STL-equivalent for all of these languages, so at the end of the day I still can't write a single program that really does ANYTHING except games in C++ which is how I got started. The point is, PCL isn't helping and in fact is further diluting my ability to focus on learning something that might one day be helpful. It seems books in general are pretty passe and one should just use google to learn what function they need RIGHT NOW and go ahead and use it. Programs of the future will be written in a language learned on the fly! (if not present already)
Re: What's your favorite book about Lisp?
I started out reading Practical Common Lisp, but I didn't really like his style of explaining things. Then I tried ANSI Common Lisp and I think it's great. It may be a little hard to follow for complete programming beginners but for people who have already programmed in other languages it's just right.