In some sense, all this was inevitable, I think. Lisp—the notion of writing your code directly in tree form—is an idea that’s discovered time and again. People have tried all sorts of crazy alternatives, writing code in XML or in opaque binary formats or using cumbersome code generators. But their artificial Byzantine empires always fall into disrepair or crush themselves into collapse, while Lisp, the road that wanders through time, remains simple, elegant, and pure. All we needed to get back on that road was a modern approach, and Rich Hickey has given it to us in Clojure.

Again, I can think of no other Clojure book that has brought as much joy to me as this one has; once you’re reasonably comfortable in finding your way around Clojure code, you’ll be ready to start partaking in the joy of Clojure as embodied in the pages of The Joy of Clojure!

Often the best way to learn is to dig straight into the nitty-gritty of how a language is used in the real world. If that sounds appealing, the hope is that you will find that at least a couple of the practicums resonate with what you do on a day-to-day basis, so that you can readily draw parallels between how you solve certain categories of problems in your current language( s) and how they may be solved using Clojure. You’re going to bump into a lot of potentially foreign concepts and language constructs in those chapters—when you do, use that context within the domain in question as your entry point for understanding those concepts using the relevant instructional material in the first part of the book.

Writing code is often a constant struggle against distraction, and every time a language requires you to think about syntax, operator precedence, or inheritance hierarchies, it exacerbates the problem. Clojure tries to stay out of your way by keeping things as simple as possible, not requiring you to go through a compile-and-run cycle to explore an idea, not requiring type declarations, and so on. It also gives you tools to mold the language itself so that the vocabulary and grammar available to you fit as well as possible to your problem domain. Clojure is expressive. It packs a punch, allowing you to perform highly complicated tasks succinctly without sacrificing comprehensibility.

There are millions of Java developers in the world, but some fewer number are working in demanding environments solving nontrivial, often domain-specific problems. If this describes you, you’re probably always on the hunt for better tools, techniques, and practices that will boost your productivity and value to your team, organization, and community. In addition, you’re probably at least somewhat frustrated with the constraints of Java compared to other languages, but you continue to find the JVM ecosystem compelling: its process maturity, massive third-party library selection, vendor support, and large skilled workforce is hard to walk away from, no matter how shiny and appealing alternative languages are.

Both Scala and Clojure run on a Java virtual machine (JVM), so they interoperate well with existing Java libraries and have no issues being dropped into the JVM infrastructure. This makes them ideal to run alongside existing Java codebases. Finally, while both Scala and Clojure have functional features, they’re quite different from each other. Learning to use both of them exposes us to a very broad range of functional programming paradigms.

Functional Programming Patterns in Scala and Clojure

Aren’t we lucky to have in Clojure a Lisp that runs on the stellar piece of software engineering that is the JVM? A blessing counted 🙂

Essential complexity is the core of the problem we have to solve, and it consists of the parts of the software that are legitimately difficult problems. Most software problems contain some complexity. Accidental complexity is all the stuff that doesn’t necessarily relate directly to the solution, but that we have to deal with anyway.

…generations of programmers who have struggled with C++’s quirks of syntax and features overload… A useful programming language should be what computer scientists call an abstraction of the underlying complexity of control flows and data structures. C++ preserves for programmers the maximum possible freedom of expression; but as ­”JLeslie” (another Slashdot commentator) admitted, “The cost was that it wasn’t much of an abstraction.”

C++ is notoriously hard to learn and use. Partly, this is owing to the difficulty of mastering the language’s paradigmatic method… But mainly it is because software developers are free to express their ideas in C++ in a bewildering variety of forms.

5. Mastering Clojure Macros (The Pragmatic Bookshelf), by Colin Jones 🎃

I found a gem of a book in this title: Mastering Clojure Macros (The Pragmatic Bookshelf), by Colin Jones. I say petite because it’s length is merely 100 pages. But appearances are deceptive, though… This happens to be a fast-moving, densely-packed introduction to Clojure macros, with plenty of mind-expanding ideas. In fact, this very paradox has got me waxing lyrical about its contents to the point where I’m taking poetic license and saying that

While this book may well be petite and slender
Trust me, it’s in every way a true mind-bender

Hmm… Coming on the heels of the prior review, you’re likely forming the impression of Clojure being a language unlike any other that you’ve encountered—assuming that you’re a newcomer to the Lisp paradigm. In this regard, the following comments about this book, Mastering Clojure Macros, by legendary programmer, Robert “Uncle Bob” Martin will hopefully help clarify

Much as its title heralds, this book is all about macros, up close and personal 😉

As a side-note, and if you want to stash away a data point on the topic of macros… When you really, really want to knock yourself out on macros—once you’ve got enough understanding of Clojure under your belt—look into tackling the meta mind-bender of a book entitled Let Over Lambda: 50 years of Lisp, by Doug Hoyte. This book by Hoyte will be a rich source of insights, of which the following is a mere sample. In introducing the topic of “Closure-Oriented Programming”, Hoyte quotes Guy Steele on the design of Scheme, when Guy Steele observed that

Hold on to that thought when you contemplate doing OO programming, and then some, in a Lisp such as Clojure…

OK, getting right back now to Mastering Clojure Macros! What I liked the most about this book is how the author thoughtfully presents considerable explanations to help the reader conceptualize exactly what happens behind the scenes to make macros possible in the first place. And as I mentioned in the preamble to this post: Yes, other languages also have macros, but all macros have not been created equal.

Basically, you can do meta-programming with Clojure macros that is simply impossible in other fine languages—including Ruby, C++, and even Scala, though there is an ongoing effort towards bringing compile-time meta-programming to Scala. Much as I love programming in Scala, I matter-of-factly have to confess that Lisps—because they are the only homo-iconic languages on this planet—provide the accruing raw programming power which you, as a Clojure programmer, can wield to bend programs to your will.

Very briefly, to help you assimilate my preceding remark on homo-iconicity, here’s a remarkably compelling round-up of this concept, as described in the pages of Clojure Programming (O’Reilly) by  by Chas Emerick et al, and which I also review in this post—the authors point out that

Circling back now to my earlier remark about how the author thoughtfully presents considerable explanations in Mastering Clojure Macros to help the reader conceptualize exactly what happens behind the scenes to make macros possible in the first place… Here are a couple of brief pointers from the book to give you a flavor of the intriguing discussions strewn across its pages, for example this one where the author tellingly notes that

And a bit more nuts-and-bolts point—super helpful, of course—is when the author invites the reader to imagine like so

Be prepared to re-read Mastering Clojure Macros many times over; its brevity utterly belies the amount of knowledge that’s packed in this slender book. Finally, to end this book’s review, I leave you with an evocative quote, which could well be applied to undertaking the journey to grok Clojure macros

In the end, here’s a brief rundown of the contents in Mastering Clojure Macros

1. Build a Solid Foundation
2. Advance Your Macro Techniques
3. Use Your Powers Wisely
4. Evaluate Code in Context
5. Speed Up Your Systems
6. Build APIs That Say Just What They Mean
7. Bend Control Flow to Your Will
8. Implement New Language Features 

6. On Lisp: Advanced Techniques for Common Lisp (Prentice Hall), by Paul Graham 🎈

In my mind—and it’s a coincidence that we were talking about the Pulitzer prize earlier—here we have a Lisp hacker of the highest order, in the fine tradition of Timothy Hart and Guy Steele, besides being a writer extraordinaire whose writings could easily garner a Pulitzer. But oh well, founding the path-breaking Y Combinator is perhaps a decent-enough consolation prize 😉

We’re of course talking about Paul Graham. I’ve written about Paul Graham and his stellar work in some of my earliest posts that you can find on this blog-site. And it’s his book On Lisp: Advanced Techniques for Common Lisp (Prentice Hall) that I review here. This review is immediately followed by the review of another gem from him—I wish for Paul Graham to have the last word, so to say, because I can think of no other modern writer who brings as much wit and grace to the written page as he does with his works on Lisp and other diverse subjects.

With that, let’s dive right into this tour de force 🙂

But first, allow me to fulfill a promise I had made earlier, while reviewing Peter Seibel’s Practical Common Lisp, to be precise. I had noted then that a sublime quote from Paul Graham totally nails down the idea that Lisp programmers get to define their own domain-specific languages (DSLs) to suit their needs…

So I circled back to a post that I had published much earlier—you can read it in its entirety in an earlier post, entitled On Paul Graham’s Essays, and of Y Combinator—I found the section, including the sublime quote that I wished to cite. Look in this quote, too, for the sublime metaphors that the author uses in the second of the following two paragraphs with the cue sentence Language and program evolve together

I hasten to clarify that while I’ve read numerous portions of this utterly endearing book—many of them, several times over—but I don’t in any way claim to have mastered its contents; mastering the art of macro-writing takes years of practice, and I’ve got merely a handful under my belt 😉

On Lisp is a highly literate, engaging, down-to-earth, and precise discussion of all things Lisp macros. With the exception of one other book, I’m not aware of any other books that cover this topic half as substantially; the other superb book I allude to is entitled Let Over Lambda: 50 years of Lisp, by Doug Hoyte. I would strongly suggest, though, that you first read the former, which will prepare you to tackle the latter.

Wrapping up that ever-so-brief segue into an allied gem as I did—Hoyte’s book Let Over Lambda—here’s an eloquent tribute from that book (to On Lisp), with its author’s italicization kept intact

On Lisp is one of those books that you either understand or you don’t understand. You either adore it or you fear it. Starting with its very title, On Lisp is about creating programming abstractions which are layers on top of lisp. After we’ve created these abstractions we are free to create more programming abstractions which are successive layers on earlier abstractions.

And speaking of this book of Lisp lore—the magnum opus, On Lisp—pay close attention to how Paul Graham marvelously captures in the Preface the essence of what it means to program in Lisp

When someone asked Louis Armstrong what jazz was, he replied “If you have to ask what jazz is, you’ll never know.” But he did answer the question in a way: he showed people what jazz was. That’s one way to explain the power of Lisp—to demonstrate techniques that would be difficult or impossible in other languages. Most books on programming—even books on Lisp programming—deal with the kinds of programs you could write in any language. On Lisp deals mostly with the kinds of programs you could only write in Lisp. Extensibility, bottom-up programming, interactive development, source code transformation, embedded languages—this is where Lisp shows to advantage. 

I hoped to do more than simply demonstrate the power of Lisp, though. I also wanted to explain why Lisp is different. This turns out to be a subtle question—too subtle to be answered with phrases like “symbolic computation.” What I have learned so far, I have tried to explain as clearly as I can. 

I hope reading this book will be fun. Of all the languages I know, I like Lisp the best, simply because it’s the most beautiful. This book is about Lisp at its lispiest. I had fun writing it, and I hope that comes through in the text.

I don’t know about your reaction, but when I giddily read this passages, I sure fell for it, hook, line, and sinker—I’m a sucker for ravishing prose like that and, of course, for beautiful code.

Again, it’s nearly impossible to convey a sense for the precision and elegance with which Paul Graham dissects, nay vivisects, the various topics he covers in the course of his wide-ranging discussions of all things Lisp macros. But I’ll try some more and paraphrase what Jeremy Ashkenas—creator of CoffeeScript, Backbone.js, and Underscore.js—says about Clojure programmer extraordinaire Michael Fogus’ book entitled Functional JavaScript: Introducing Functional Programming with Underscore.js (O’Reilly) in that book’s Foreword

This is a terribly exciting book… It breaks down… Lisp programming into its basic atoms, and builds it back up again into edifices of terrifying cleverness that will leave you wondering. It’s rare that a programming book can take you by surprise, but this one will.

Again, I paraphrased above the words of Jeremy Ashkenas to reflect my own, near-identical, sentiments toward On Lisp.

What’s quite amazing, too, about On Lisp is the exposure to a plethora of Lisp technique you’ll get by poring over its pages. In fact, as the author himself notes, “Just as a tour of New York could be a tour of most of the world’s cultures, a study of Lisp as the programmable programming language draws in most of Lisp technique”.

Speaking of Lisp technique, when you’re ready for exposure to additional mind-expanding technique, albeit with far less focus on Lisp macros—for which On Lisp and Let Over Lambda remain the champs—you simply can’t go wrong with perusing the gem from Peter Norvig entitled Artificial Intelligence Programming: Case Studies in Common Lisp, affectionately known to its adherents by the acronym PAIP.

At the moment, while I don’t have room to delve into my opinions on the intriguing content of Peter Norvig’s PAIP, I’ll leave you with a couple of points that its author makes about Lisp, the programmable programming language, specifically about Common Lisp

Lisp’s flexibility allows it to adapt as programming styles change, but more importantly, Lisp can adapt to your particular programming problem. In other languages you fit your problem to the language; with Lisp you extend the language to fit your problem. 

Because of its flexibility, Lisp has been successful as a high-level language for rapid prototyping in areas such as AI, graphics, and user interfaces. Lisp has also been the dominant language for exploratory programming, where the problems are so complex that no clear solution is available at the start of the project. Much of AI falls under this heading.

With a blend of rigor and writing virtuosity permeating the pages of On Lisp—awash as this book is, in the Kool Aid of Lisp goodness—I wonder whether the superb light rock artist Steve Winwood, in his song Don’t You Know What The Night Can Do?, perhaps had Lisp in mind when he sang mellifluously, intoning that 😉

Now’s the time that our dreams are finally coming true
Feels so good, we’re crying 

Now’s the time when it’s down to me and you
Spread these wings, we’ll be flying

OK, maybe my imagination ran away with me a bit, but you get the idea of how you get to be the language designer even as you wear your programmer hat? Yep, that’s what Lisp buys you—Oh, and substitute the word ‘Clojure’ for wherever I used either ‘Lisp’ or ‘Common Lisp’ above, and you’ll be good, for the most part 🙂

To round out this review, here then are the jewel-like chapters of On Lisp, each resplendent in its own shimmering lights, awaiting to irradiate the reader

1. The Extensible Language
2. Functions
3. Functional Programming
4. Utility Functions
5. Returning Functions
6. Functions as Representation
7. Macros
8. When to Use Macros
9. Variable Capture
10. Other Macro Pitfalls
11. Classic Macros
12. Generalized Variables
13. Computation at Compile-Time
14. Anaphoric Macros
15. Macros Returning Functions
16. Macro-Defining Macros
17. Read-Macros
18. Destructuring
19. A Query Compiler
20. Continuations
21. Multiple Processes
22. Nondeterminism
23. Parsing with ATNs
24. Prolog
25. Object-Oriented Lisp

There you have it, a radiant gem of a book. And a first-class companion for On Lisp, should you wish to keep a reference handy while you study it, will be the following: So I also have a copy of Paul Graham‘s ANSI Common Lisp (Prentice Hall), which is another remarkably good book in its own right. What’s really cool about the book ANSI Common Lisp is that it combines a top-notch—albeit, somewhat briefer, though not terse—introduction to Lisp programming, and a convenient, up-to-date reference manual for the standardized, ANSI Common Lisp language. Rounding out the second chapter of his book ANSI Common Lisp is, Paul Graham notes on p.28 that

Richard Gabriel once half-jokingly described C as a language for writing Unix. We could likewise describe Lisp as a language for writing Lisp. But this is a different kind of statement… It opens up a new way of programming: as well as writing your program in the language, you can improve the language to suit your program. If you want to understand the essence of Lisp programming, this idea is a good place to start.

Enough said. There are a ton of substantial, extremely high-quality programming examples in ANSI Common Lisp, which bear the trademark virtuosity of its expert author-programmer-entrepreneur.

7. Hackers & Painters: Big Ideas from the Computer Age (O’Reilly), by Paul Graham ⛱

Last, but certainly not the least, is this beguiling and highly entertaining book, Hackers & Painters: Big Ideas from the Computer Age (O’Reilly), by Paul Graham. In fact, if you recall my remark at the very outset of this post—where I had noted that “I wish for Paul Graham to have the last word, so to say”—I can think of no other modern writer who brings as much wit and grace to the written page as he does.

This charming book will be especially helpful to someone completely new to the Lisp family of languages, including Clojure. While there isn’t much nuts-and-bolts programming advice at all in this book, there’s definitely a hefty dose of eminently accessible material that’ll help you appreciate and understand the Lisp philosophy. Two additional resource will also be worthy of your attention, so I mention them in the same breath

• Eric Raymond’s wise post entitled How To Become A Hacker 
• Peter Norvig’s riotously entertaining and wise take on how to Teach Yourself Programming in Ten Years

The careful reader may have noted that one of the quotes that kicks things off in this post is from Eric Raymond’s helpful post cited above. Let’s now dive right into our final book review. But first let’s disabuse ourselves of any vagueness that might surround the sense in which the overloaded word hacker is used here, both by the authors—in their respective books, which I’m reviewing here—and by myself. Here’s how Paul Graham introduces this word in the Preface to Hackers & Painters

With that definition to level-set our understanding of exactly who hackers are, I draw your attention to the fact that there’s so much brilliantly endearing and accurate observations—including those on the role and impact of computing on the larger world, but more on that later—jam-packed into this book that you’ll want to pore over every nook and cranny. And I literally mean, like, right down to the Notes section—which everyone, including myself, skips when reading a typical book—because Hackers & Painters is not your typical book. You don’t want to miss the nuggets of wisdom tucked away in the recesses of this fantastic book. And I didn’t even mention the top-notch Glossary, which appears before the Index.

To that end, here’s the author’s delightful observation on the topic of interruptions, which appears—see I told you to avoid skipping anything—in the Notes section 😉

Enough said.

What makes Hackers & Painters truly special is the exceptionally cultivated writing skill that the author wields in sharing insights, which of course are based on his equally exceptional programming skills. To get a sense for this virtuosity on display, in both spheres—the one where man communicates with fellow readers, the other where man communes with the computer—there’s no substitute for reading the book itself. My impressions notwithstanding, and which I’ve tried to convey here, you really have to read this book and form your own assessment.

By the way, even as I wrote the second-half of the preceding point above—the sphere wherein man communes with the computer his codified logic—I was acutely aware of the following excellent advice shared by MIT professors Harold Abelson and Gerald Jay Sussman who, along with Julie Sussman, crafted the classic tome, The Structure and Interpretation of Computer Programs, from which to learn the fine art of programming (in the Lisp called Scheme). The authors note, in the Preface to the First Edition, that

So I’ve read Hackers & Painters at least six times since I bought it, way back when I lived in wintry Minnesota. And unlike my experience with the assembly-language-on-steroids that is the C++ language, I positively warmed up to the Lisp philosophy enshrined in its pages.

Each time I re-read this delicious book, I seemed to find anew yet another insight, and this circling back continues as a virtuous cycle to this day, illuminating and informing me, deepening my appreciation for the role of computing—especially his stellar coverage of (Common) Lisp—in the digital world whose infrastructure is unerringly gravitating toward embracing the complexity-taming foundational work with which John McCarthy enlightened the functional world in 1958.

Here is Paul Graham’s sparkling-with-wit take on this very topic

Hackers & Painters was published back in 2004, but it remains every bit as relevant and vibrant as it was when it was published. Here’s a brief rundown of the topics which awaits the reader in the pages of this entertaining book

1. Why Nerds Are Unpopular
2. Hackers and Painters
3. What You Can’t Say
4. Good Bad Attitude
5. The Other Road Ahead
6. How to Make Wealth
7. Mind the Gap
8. A Plan for Spam
9. Taste for Makers
10. Programming Languages Explained
11. The Hundred-Year Language
12. Beating the Averages
13. Revenge of the Nerds
14. The Dream Language
15. Design and Research 

Notes
Glossary

1. Conditionals.
2. A function type.
3. Recursion.
4. Dynamic typing.
5. Garbage-collection.
6. Programs composed of expressions.
7. A symbol type.
8. A notation for code using trees of symbols and constants.
9. The whole language there all the time.

Paul Graham’s take on the last idea in the preceding list—in his memorable words, “The whole language there all the time”—is in particular just plain ineffable, and worth lingering on!

Many languages have something called a macro. But Lisp macros are unique. And believe it or not, what they do is related to the parentheses. The designers of Lisp didn’t put all those parentheses in the language just to be different… 

…You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them. In Lisp, these programs are called macros. They are programs that write programs. 

Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp.

So there, I’ve done my level best to give you a flavor of this marvelous book, Hackers & Painters, and a highly opinionated one at that, likely tinged by my subjective impressions. You are on to something if you think—well, I do so, anyway—that we have in this book an expert chiseling away at ideas plus some amazing conceptual artistry…

Lambda calculus (λ-calculus), the inspiration behind functional programming

Oh, goodness. I wasn’t quite planning on this… So I dwell in a world powered by the duo dynamos of Java and Scala, along with their respective frameworks each. But my fondness for Clojure in particular, and the Lisp philosophy in general, never really left me, I realize. Functional programming, math, oh my!

In putting together my thoughts for these reviews—in particular while reviewing the last two books, where I let Paul Graham have the last word—I’m grippingly reminded, yet again, how some things just never go out of style. Ever.

We keep coming back to the basics. Functional programming is inspiring a renaissance in the way we craft software. MapReduce, Domain-Specific Languages, and Lambda Architecture, anyone?

This point is underscored by Michael Fogus and Chris Houser in their stellar book, The Joy of Clojure, where they invite the reader to

And yes—Clojure, Common Lisp, Scheme—long live all the Lisps of the world!

And so we come to the end. Much as I mentioned at the outset, I invite your comments—Having now read my brief take each on the preceding half-dozen books…

• Do you find that your experience of reading any of these books was different than mine? 
• Perhaps some qualities that I didn’t cover are the ones that you found the most helpful as you learned Clojure and its ecosystem. 
• Did I leave out any of your favorite Clojure book(s)? 
• If so, what could I also review, perhaps in a future blog post.
• I’ve covered only a partial list of the Clojure books that I’ve read, necessarily limited by the time available…

My hope is that these brief vignettes will help you in your journey to grokking Clojure—meandering out of necessity through its close cousin, Common Lisp—otherwise, you will miss out on some evergreen classics that inform how Clojure has been put together.

Bon voyage, and I leave you with a photo of a pseudo-random section of one of my bookshelves—heavens behold, I do confess this section se a tad biased toward Clojure material 😉