5 ms·

Don't let the title fool you - 90% of the advice given in this book isn't specific to Clojure, and boy is it good advice. This book contains some of the deepes

by valw 7y ago

Don't let the title fool you - 90% of the advice given in this book isn't specific to Clojure, and boy is it good advice. This book contains some of the deepest programming insights I've encountered, to be put on the same level as SICP or the Pragmatic Programmer. The discussions on naming and abstraction are particularly illuminating, exposing some fundamental tradeoffs like synthetic vs natural names, or principled vs adaptable systems of abstractions. Were these notions more widespread, a lot of the pointless rants and debates we hear in programming circles would disappear. I would not recommend this book to beginners - this book is most useful when you are experienced enough that your struggle is to make choices, not to get things to work.

turk73 7y ago
Then why use 'Clojure' in the HN post except to advertise for that mostly dead programming language? It's not 2014 anymore, the world moved on. I'm as upset about it as anyone.
tosh 7y ago
the sample chapter on naming is a great example https://leanpub.com/elementsofclojure/read_sample https://leanpub.com/elementsofclojure/read_sample
- aggerdom 7y ago
  As someone who is currently picking up Clojure, that chapter just sold me on the book. I really liked the sign/referent/sense distinction and discussion. I knew it from philosophy/semiotics, but every other place I come across it instantly goes down another rabbit trail. I'm sure the balance you strike will vary language to language, but it really was useful seeing it discussed in terms of naming in software.
kccqzy 7y ago
Contrarian opinion here: I've instead found the constant philosophizing tiring. But I still commend his effort because as he explained, he's trying to articulate the inarticulate and the visceral. Most programmers would probably benefit from reading a book in the style of Effective C++ (Scott Meyers) or Effective Java (Joshua Bloch), where recommendations are more concrete and more unequivocal. Once you've done that, the matter of software design only really comes with experience—experience designing software and having an almost tactile reaction to the future maintainability and readability of the code; it doesn't really come from reading a book like this.
- macando 7y ago
  I can't recommend Effective Java enough. Even if one hates Java with passion. I haven't managed to find a better book on how to design an API in any language. It learned me to think about the consumers of my code all the time (even if I'm the only author on a given project) The chapters on exceptions, defensive coding, generics are brilliant. The whole book is written in an effective manner. Dense with information, short and still readable. The second best: Eloquent Ruby. Brilliantly written and mature. Instead of hyping everything up, the author elaborates the downsides of each described technique and power tool.
esfandia 7y ago
> experienced enough that your struggle is to make choices, not to get things to work. I think you summarized beautifully the difference between design ("make choices") and implementation ("get things to work"). Am I correct in that?

by valw 7y ago

turk73 7y ago

Then why use 'Clojure' in the HN post except to advertise for that mostly dead programming language? It's not 2014 anymore, the world moved on. I'm as upset about it as anyone.

tosh 7y ago

the sample chapter on naming is a great example https://leanpub.com/elementsofclojure/read_sample https://leanpub.com/elementsofclojure/read_sample

aggerdom 7y ago
As someone who is currently picking up Clojure, that chapter just sold me on the book. I really liked the sign/referent/sense distinction and discussion. I knew it from philosophy/semiotics, but every other place I come across it instantly goes down another rabbit trail. I'm sure the balance you strike will vary language to language, but it really was useful seeing it discussed in terms of naming in software.

kccqzy 7y ago

Contrarian opinion here: I've instead found the constant philosophizing tiring. But I still commend his effort because as he explained, he's trying to articulate the inarticulate and the visceral. Most programmers would probably benefit from reading a book in the style of Effective C++ (Scott Meyers) or Effective Java (Joshua Bloch), where recommendations are more concrete and more unequivocal. Once you've done that, the matter of software design only really comes with experience—experience designing software and having an almost tactile reaction to the future maintainability and readability of the code; it doesn't really come from reading a book like this.

macando 7y ago
I can't recommend Effective Java enough. Even if one hates Java with passion. I haven't managed to find a better book on how to design an API in any language. It learned me to think about the consumers of my code all the time (even if I'm the only author on a given project) The chapters on exceptions, defensive coding, generics are brilliant. The whole book is written in an effective manner. Dense with information, short and still readable. The second best: Eloquent Ruby. Brilliantly written and mature. Instead of hyping everything up, the author elaborates the downsides of each described technique and power tool.

esfandia 7y ago

> experienced enough that your struggle is to make choices, not to get things to work. I think you summarized beautifully the difference between design ("make choices") and implementation ("get things to work"). Am I correct in that?