Higher-Order Perl: Transforming Programs with Programs

Non-Lisp programmers, I think, fundamentally misunderstand the appeal of Lisp, and why it is superior to other programming languages. Lisp is not superior because it offers higher order functions or any of the other things, it is superior because it does not get in the way: Lisp meets problems, rather than forcing problems to meet it. This book serves two purposes: on the one hand it helps Perl programmers to move the center of gravity of their solutions further away from Perl, and a bit closer to their problems (quite a bit closer, actually), and on the other it provides a good introduction to Perl for Lisp programmers, and for that it gets an effortless five stars. I suspect that it is maybe more successful for the second purpose than the first: a relaxed read for someone who knows what a closure is, but for someone who does not know what a closure is, most likely not a relaxed read. Further, anyone who masters the contents may find that his newly refined coding style is somewhat caviary to the general, something that would be a problem in any IT/ORG that I have experienced. Small quibbles: A Pratt Precedence parser might have fitted the discussion better than the recursive descent parser that is developed, and a deeper discussion of the ways that Perl nevertheless falls short of Lisp, instead of just a passing reference to Norvig's list, would actually have made the arguement stronger - for instance you cannot add a macro facility similar to that of Lisp to Perl, and you cannot add the general continuations available in Scheme (or the limited continuations that Graham, e.g., shows how to add to Common Lisp). In short, Higher Order Perl makes a good case for the the aesthetics of haiku, but one should understand that (in spite of what my cousin, Leontia Flynn, thinks) it is haiku written with a typewriter, not with a caligrapher's brush. P.S. One minor repeated irritation for me was the way the author, in spite of everything, insisted on emphasising how input functions should read input files one line at a time. This is a bizarre mindset holdover from the seventies, that is inconsistent with the general argument of the book: if you have a computer with hundreds of megabytes, or gigabytes, of core, then the efficient way to read a text file is not line by line, but in one go.