Are most Perl programmers ignorant of the camel book? For the others I might agree. For myself, I learned a little bit of HTML "on the fly" (and had the help of

Are most Perl programmers ignorant of the camel book? For the others I might agree. For myself, I learned a little bit of HTML "on the fly" (and had the help of a short web series to teach me a few tags, this was before w3schools, or at least before I knew about it) but a friend who was letting me host and FTP onto a subdomain of his shared server noticed I could trivially get rid of a ton of repetition by using PHP just to include a header, write the unique content, and then a footer. He wrote an example for me to apply and recommended a PHP book and that's how I learned programming. If you're a beginner, a beginner focused book makes a world of difference. I think the main trouble is that it's hard to know what the good books are for your particular needs, and most people aren't going to want to try exploring some alternatives to find a good one, or maybe haven't been given a good recommendation yet, so they don't bother reading books at all unless really curious or forced to... When you're just messing around or just need to edit relatively simple business logic in whatever language without making a bunch of new stuff, you can get away without understanding most things in enough detail that a book would cover. Lots of books exist for different needs (references, subject-focused, beginner focused, general tour of the language...), so again it's hard to pick out in advance the one you need right now. Some of the more generic language level ones targeted at professionals still manage to leave out crucial sections like "How do professionals actually develop in this thing, and what alternatives are there? What's the simplest way? How are things deployed to production?" For Common Lisp in particular the problem is two-fold. People get recommended SICP all the time, which is a good book, but they read as far into it as they can and then assume they know Lisp and wonder what the big deal is when compared to modern dynamic languages that let them loop without recursion or use infix math. But if they then go on to try and learn about Common Lisp, so many references (including Practical Common Lisp) don't show the good stuff for way too long, if ever, but begin by saying it's basically a waste of time without emacs. Now the reader has to learn emacs and like it. It's not a waste, yet books don't always address that. On the other hand if you're tool-agnostic like some Lisp books you might give a similar impression of SICP and leave out some of the cool bits because they can be hard to convey in text. The Debugging Lisp series at http://malisper.me/debugging-lisp-part-1-recompilation/ http://malisper.me/debugging-lisp-part-1-recompilation/ is my favorite at the moment to show people what makes Lisp different. It's emacs focused but it shows you why you might want to use emacs, or some other editor that can hook into the same underlying commands like 'COMPILE that aren't emacs-specific. The REPL is like a constantly present gdb (and all that implies like the possibility of better viewers than the text terminal, such as emacs) but way better.