What do you think?
Rate this book
Elements of Clojure
This book tries to put words to what most experienced programmers already know. This is necessary because, in the words of Michael Polanyi, "we can know more than we can tell." Our design choices are not the result of an ineluctable chain of logic; they come from a deeper place, one which is visceral and inarticulate.
Polanyi calls this "tacit knowledge", a thing which we only understand as part of something else. When we speak, we do not focus on making sounds, we focus on our words. We understand the muscular act of speech, but would struggle to explain it.
To write software, we must learn where to draw boundaries. Good software is built through effective indirection. We seem to have decided that this skill can only be learned through practice; it cannot be taught, except by example. Our decisions may improve with time, but not our ability to explain them.
It's true that the study of these questions cannot yield a closed-form solution for judging software design. We can make our software simple, but we cannot do the same to its problem domain, its users, or the physical world. Our tacit knowledge of this environment will always inform our designs.
This doesn't mean that we can simply ignore our design process. Polanyi tells us that tacit knowledge only suffices until we fail, and the software industry is awash with failure. Our designs may never be provably correct, but we can give voice to the intuition that shaped them. Our process may always be visceral, but it doesn't have to be inarticulate.
And so this book does not offer knowledge, it offers clarity. It is aimed at readers who know Clojure, but struggle to articulate the rationale of their designs to themselves and others. Readers who use other languages, but have a passing familiarity with Clojure, may also find this book useful.
Polanyi calls this "tacit knowledge", a thing which we only understand as part of something else. When we speak, we do not focus on making sounds, we focus on our words. We understand the muscular act of speech, but would struggle to explain it.
To write software, we must learn where to draw boundaries. Good software is built through effective indirection. We seem to have decided that this skill can only be learned through practice; it cannot be taught, except by example. Our decisions may improve with time, but not our ability to explain them.
It's true that the study of these questions cannot yield a closed-form solution for judging software design. We can make our software simple, but we cannot do the same to its problem domain, its users, or the physical world. Our tacit knowledge of this environment will always inform our designs.
This doesn't mean that we can simply ignore our design process. Polanyi tells us that tacit knowledge only suffices until we fail, and the software industry is awash with failure. Our designs may never be provably correct, but we can give voice to the intuition that shaped them. Our process may always be visceral, but it doesn't have to be inarticulate.
And so this book does not offer knowledge, it offers clarity. It is aimed at readers who know Clojure, but struggle to articulate the rationale of their designs to themselves and others. Readers who use other languages, but have a passing familiarity with Clojure, may also find this book useful.
120 pages, ebook
Published February 10, 2019
23 people are currently reading
361 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 30 reviews
July 31, 2019
Very solid book. Not exactly about Clojure, and there's its main value – the information here is very transferable to other languages and platforms. Just 100 pages, but by no means an easy read – the writing is incredibly dense and compact so that each sentence packs a distinct idea. You would be re-reading each paragraph over and over until it sinks in.
Four stars and not five because the latter chapters feel a bit rushed to me, but I completely understand how hard it is to write a book like that. Regardless of the rating, this is a must-read.
Four stars and not five because the latter chapters feel a bit rushed to me, but I completely understand how hard it is to write a book like that. Regardless of the rating, this is a must-read.
March 30, 2020
The most impressive aspect of this book its extensive bibliography. This adds a lot of weight to Tellman's well-reasoned arguments on broad subjects such as naming and composition patterns.
While he nails the big picture, my only criticism of this book is in its handling of the details. Tellman really shines when using Unix commands and the REPL as examples, but some of his home-spun Clojure programs feel obtuse. Tellman isn't building a full application in "Elements of Clojure," so I understand it's difficult to create grounded examples. Nonetheless, they feel like the book's weakest moments.
"Elements of Clojure" confronts the most abstract and difficult aspects of writing software and does a commendable job. Its unique combination of brevity and depth make it a no-brainer recommendation to any programmer.
While he nails the big picture, my only criticism of this book is in its handling of the details. Tellman really shines when using Unix commands and the REPL as examples, but some of his home-spun Clojure programs feel obtuse. Tellman isn't building a full application in "Elements of Clojure," so I understand it's difficult to create grounded examples. Nonetheless, they feel like the book's weakest moments.
"Elements of Clojure" confronts the most abstract and difficult aspects of writing software and does a commendable job. Its unique combination of brevity and depth make it a no-brainer recommendation to any programmer.
January 19, 2021
Very short read. I would put the book in the same category as Data and Reality by William Kent and A Philosophy of Software Design by John Ousterhout.
It's more about laying out foundational principles of software design and describing how does it all fit into the larger picture.
The chapter on indirection and abstraction is definitely worth re-reading multiple times.
2021 update: The author of the book appears to have a toxic "I'm a better developer than you" attitude towards people.
Ex:
https://twitter.com/ztellman/status/1...
https://twitter.com/ztellman/status/1...
In this context, I can't really recommend engaging with his work.
It's more about laying out foundational principles of software design and describing how does it all fit into the larger picture.
The chapter on indirection and abstraction is definitely worth re-reading multiple times.
2021 update: The author of the book appears to have a toxic "I'm a better developer than you" attitude towards people.
Ex:
https://twitter.com/ztellman/status/1...
https://twitter.com/ztellman/status/1...
In this context, I can't really recommend engaging with his work.
February 12, 2023
This read has been as rewarding as it has been challenging, and let me tell you it was challenging.
This is the kind of book I've been looking for for the longest of times. Even though it is in part about Clojure - the Idioms chapter in particular - it is really, emphatically, about the philosophy of software design (much) more generally. The approach Tellman has taken is admirable. He's done much reading, including in other fields than computer science, including philosophy of language, AI and about complex adaptive systems, and after having drawn influences from those works he's weaved everything together in a seamless philosophy on how to design software systems.
The book takes a very philosphical and abstract approach, but when you pay close attention you should notice it's always to-the-point and relevant with regards to software design. In fact, this approach simply serves to, fittingly, decouple these ideas from the concrete implementation that is one's language (such as Clojure), making them more or less universally applicable.
The first chapter on naming things is fantastic. It gives you both an interesting philosophical foundation to look at naming things, and practical advice on how to name things in Clojure. Really worthwile.
The second chapter is basically a list of Clojure idioms to help you write better code. This chapter is a bit of an odd one out in the book, but it's so good that I welcome it wholeheartedly.
The third chapter is about indirection and abstraction. This is a really challenging read, but it's probably also the one that provides the most. I know I still have lots of things to learn from this that I didn't comprehend this first time around, so I definitely plan to revisit this chapter at some point, perhaps several times.
The final chapter is about composition. Mostly this regards composing processes to build systems, not so much composing of functions, even though of course that is a similar and crucial form of composition to use as well.
Like I said, the book is definitely challenging, but Tellman's writing (although dense) is very clear so you should at least learn a lot from it. It's short and pretty well structured too, so revisiting illuminating or difficult parts at some later time is quite easy to do.
PS There's great talks you can find on YouTube that serve as very welcome supplement material. I've been watching the talk "On Abstraction" and it really helps grasping the concepts in the "Indirection" chapter.
This is the kind of book I've been looking for for the longest of times. Even though it is in part about Clojure - the Idioms chapter in particular - it is really, emphatically, about the philosophy of software design (much) more generally. The approach Tellman has taken is admirable. He's done much reading, including in other fields than computer science, including philosophy of language, AI and about complex adaptive systems, and after having drawn influences from those works he's weaved everything together in a seamless philosophy on how to design software systems.
The book takes a very philosphical and abstract approach, but when you pay close attention you should notice it's always to-the-point and relevant with regards to software design. In fact, this approach simply serves to, fittingly, decouple these ideas from the concrete implementation that is one's language (such as Clojure), making them more or less universally applicable.
The first chapter on naming things is fantastic. It gives you both an interesting philosophical foundation to look at naming things, and practical advice on how to name things in Clojure. Really worthwile.
The second chapter is basically a list of Clojure idioms to help you write better code. This chapter is a bit of an odd one out in the book, but it's so good that I welcome it wholeheartedly.
The third chapter is about indirection and abstraction. This is a really challenging read, but it's probably also the one that provides the most. I know I still have lots of things to learn from this that I didn't comprehend this first time around, so I definitely plan to revisit this chapter at some point, perhaps several times.
The final chapter is about composition. Mostly this regards composing processes to build systems, not so much composing of functions, even though of course that is a similar and crucial form of composition to use as well.
Like I said, the book is definitely challenging, but Tellman's writing (although dense) is very clear so you should at least learn a lot from it. It's short and pretty well structured too, so revisiting illuminating or difficult parts at some later time is quite easy to do.
PS There's great talks you can find on YouTube that serve as very welcome supplement material. I've been watching the talk "On Abstraction" and it really helps grasping the concepts in the "Indirection" chapter.
May 5, 2019
The ambitions of this book are immense and at its best moments it reaches them and you see the contours of a way of a thinking about programming that feels truly enlightened. However, there are perhaps just as many times when it becomes bogged down in writing about what it's trying to do and fails to get into the nitty gritty of examples and explication that would really step you through its argument.
Part of the problem is that you imagine Tellman started writing about the Clojure programming language before realising that what he really wanted to do was write about programming far more broadly. This leaves the book with an imbalance that affects the entire enterprise. Tellman's next book will apparently be focused on programming at a more generic level and I very much look forward to it: he's clearly got a lot to say.
Part of the problem is that you imagine Tellman started writing about the Clojure programming language before realising that what he really wanted to do was write about programming far more broadly. This leaves the book with an imbalance that affects the entire enterprise. Tellman's next book will apparently be focused on programming at a more generic level and I very much look forward to it: he's clearly got a lot to say.
December 19, 2022
Elements of Clojure is divided into 2 parts largely: Writing Clojure & writing Software in general.
The Writing Clojure lays down guidelines on naming, which I think is fantastic. Very few books talk about this, given that naming is such an important aspect of daily work.
Additionally, it also talks about some idioms & conventions of Clojure.
The second part, which is about writing Software is much more juicy than the first. It talks about Indirection, Modelling software, drawing boundaries, handling pull/transform/push of data, composing processes by reducing & aggregating them, etc.
For Clojure/FP enthusiasts, the entire book is worth reading. For non-Clojure devs, 2nd part on writing Software might be very appealing.
The Writing Clojure lays down guidelines on naming, which I think is fantastic. Very few books talk about this, given that naming is such an important aspect of daily work.
Additionally, it also talks about some idioms & conventions of Clojure.
The second part, which is about writing Software is much more juicy than the first. It talks about Indirection, Modelling software, drawing boundaries, handling pull/transform/push of data, composing processes by reducing & aggregating them, etc.
For Clojure/FP enthusiasts, the entire book is worth reading. For non-Clojure devs, 2nd part on writing Software might be very appealing.
March 22, 2019
This book challenges the way you write Clojure and software in general. It forces you to reconsider your conventions that you hold dear. It's not about language idioms, but about more fundamental properties of software. The writing has some formal qualities of Wittgenstein's Tractatus Logico-Philosophicus. It proceeds in outstandingly compact, sometimes bare sentences. The only quibble I have with this book is that some concrete examples are confusing to follow from the principles they are meant to exemplify. The book is very much worth re-reading and incremental reflection.
August 8, 2018
An awesome book, must read for an software Craftsman who wants to think deeper about the theory behind building software. Minimal to no knowledge of Clojure is needed. I think it should be called "Elements of Software" or "The Tao of Software" or "Aphorisms of Software" or you get the point. Will definitely read this again and check out its many references to books not necessarily related to software (I was surprised to see Deleuze referenced in this book).
February 7, 2019
I've read parts of this book multiple times. I bought it when it was still being written and think I've reread the entire thing every time a new section is released.
This book is good. You can tell that Zach has put a lot of thought into it. It is brief but offers a depth on some concepts not often covered by books.
This book has Clojure in the name but much of what it talks about can apply to many languages. I'd recommend it to most developers.
This book is good. You can tell that Zach has put a lot of thought into it. It is brief but offers a depth on some concepts not often covered by books.
This book has Clojure in the name but much of what it talks about can apply to many languages. I'd recommend it to most developers.
January 4, 2020
I loved this book.
So much than when I lost it I bought another copy.
It's one of the books of ideal length. When other authors usually decide to go into some sophisticated philosophy or framework this book elegantly stops, all things carefully considered. And it is not only about Clojure, most of it's content can be applied to any programming language and paradigm.
So much than when I lost it I bought another copy.
It's one of the books of ideal length. When other authors usually decide to go into some sophisticated philosophy or framework this book elegantly stops, all things carefully considered. And it is not only about Clojure, most of it's content can be applied to any programming language and paradigm.
March 28, 2019
The body of the book is 115 pages long. Its contents are pretty sparse and doesn't offer much to experienced programmers.
December 16, 2025
This is really interesting read! I've never tried to understand clojure besides seeing a random hello world, but along with the more 'esoteric' approach of questioning approach, naming and so on it really is fascinating.
I highly suggest to read this book, especially when you aren't at the beginning of your software engineering career and also especially, even if you aren't versed in the language.
I highly suggest to read this book, especially when you aren't at the beginning of your software engineering career and also especially, even if you aren't versed in the language.
December 29, 2020
One of the most succinct technical books I've read. Clear, concise and filled with insightful advice. An impressive undertaking to boil down many complex topics in software development.
Not a page turner, and I think it's best read with plenty of time to pause and reflect.
While the title contains Clojure, the language itself plays a small part of the book and the advice is applicable overall. Well, at least if you're interested in the functional mindset.
Not a page turner, and I think it's best read with plenty of time to pause and reflect.
While the title contains Clojure, the language itself plays a small part of the book and the advice is applicable overall. Well, at least if you're interested in the functional mindset.
June 24, 2019
It was very hard for me to get to the essence of the thinking presented in the book. I found ideas either to simple or to abstract to convert them in action. I must admit that I don't know Closure which could be a large source of my frustration.
September 15, 2020
Loved it. A harder read than most books on computation and programming, due to its philosophical depth. It reminded me of wonderful books like The Reasoned Schemer, Finite and Infinite Games, and Tractatus-Logicus-Philosophicus.
March 17, 2018
On programming style and philosophy. Recommended for intermediate and expert Clojurists.
June 11, 2018
A brisk, thoughtful take on typically nebulous issues in software construction.
July 15, 2019
The book is great and Zachary Tellman has a lot of interesting things to say. In my opinion, the theme is too open to call it "Elements of Clojure", though. As many have suggested, "Elements of Software Development" could be a better title. I couldn't find any clear and distinct examples why exactly Clojure. I felt like all the chapters just scratched the surface. Certainly there was more to say, explain, and picture with real-world examples.
Read
March 20, 2020Very philosophical book on Software design.
Amazing references to follow.
Short but very dense (I took three weeks to read/re-read it, I would stop and reflect on it to absorb the contents)
Amazing references to follow.
Short but very dense (I took three weeks to read/re-read it, I would stop and reflect on it to absorb the contents)
June 13, 2020
Such a good, to-the-point book. Super dense with insight. Even if you're not a Clojure programmer, you'll still find this book useful.
August 26, 2020
Clean in its approach and goal.
September 4, 2020
This book does not feel even half finished. Clojure relevance and examples missing.
February 2, 2021
A must read for anyone who wants to be a better programmer
April 27, 2021
Sometimes the book goes too abstract, I think, or just maybe I am too stupid.
But it is a good book.
But it is a good book.
February 1, 2023
Highly philosophical, but fairly applicable.
December 28, 2025
Excellent book. The first 2 chapters are great for programmers who are new to Clojure, and the latter 2 chapters will be useful for intermediate or above.
October 16, 2020
This is a strange book. At times it feels more a collection of philosophical essays than a tech book, and overall I feel that it lacks a cohesive structure. I was deceived by its short length (120 pages) and I didn't give it the time it requires to be fully digested. I have also just started writing Clojure, so I think I will have to come back to this book later this year to fully appreciate it.
The book is divided into 4 chapters: Names, Idioms, Indirection, Composition.
The chapter "Names" is really good. You can get a lot from it even if you don't know anything about Clojure.
The chapters "Idioms", "Indirection" and "Composition" require that you know Clojure and are quite though.
I really don't understand the reviews stating that you don't need to know Clojure to read this book. You do.
The book is divided into 4 chapters: Names, Idioms, Indirection, Composition.
The chapter "Names" is really good. You can get a lot from it even if you don't know anything about Clojure.
The chapters "Idioms", "Indirection" and "Composition" require that you know Clojure and are quite though.
I really don't understand the reviews stating that you don't need to know Clojure to read this book. You do.
Currently reading
August 9, 2016Finished as much of the book that was written. Will need to reread a few times to take it all in.
January 3, 2020
Great book on the fundamental principles for not only Clojure but beginners in programming. A page-turner!
March 16, 2021
Took me around 3x reads to get what Zachary is talking about, good job there Zach!!
Displaying 1 - 30 of 30 reviews