Clojure for the Brave and True (2015)

Having been a novice programmer in the past, as a natural starting point, trying to start with clojure as a blank slate using this book as an introduction was also ineffective. When I tried to read the book and approach clojure on its own terms, as if I knew nothing and would not be aided by prior experience, the book's attempts at cuteness were tangential and distracting. It's examples did not build on each other.

This was one of the first books on the book shelf at the book store that I noticed as being specifically about clojure. After getting nothing out of the book, I went elsewhere and searched other books that gave me the information that I needed.

After gaining further awareness of the language, and establishing competancy through the use of other resources, I revisited the book, to figure out why it didn't help me.

One of the books that did bootstrap my core concepts was:

https://pragprog.com/book/btlang/seven-languages-in-seven-we...

In the first sentence it plainly states clojure is a lisp. In its forty pages on clojure, that book gave me most of what this book did not provide in 300 pages.

Knowing now that clojure is a lisp, I went and got Land of Lisp:

http://landoflisp.com

That is an example of a book with jokes that are clever and informative. I was able to approach lisp on its own terms in isolation with that book. That book's table of contents are properly structured for reference, rather than as a framework for layered jokes.

Only after I was able to bootstrap the fundamentals of lisp, and drawn parallels with java, was I able to see where this book goes wrong. It is not written for new or non developers. It is not written for developers familiar with other languages.

It's written for people who already know clojure, and might applreciate the cute inside jokes it makes, that you might get if you already know clojure. I don't envision anyone else gaining anything from it.

New developers are not informed of why data structures are useful and when. Things like primitive data types (booleans, integers, characters, strings) are not highlighted as foundational building blocks. Execution scoping is not properly addressed. Project structure and source code files trees, and namespacing are poorly explained. An entire chapter on emacs is inadequate for practical learning, and actual essentials for handling lisp or clojure, within an editor like emacs is beyond the scope of the book.

Based on these details, I have no use for the book as a reference manual, and I also cannot recommend it as starting point for first time programmers, or even inexperienced programmers searching for more learning exercises.

I can't even recommend it to other clojure developers for the jokes, because even the jokes are not funny.

https://www.manning.com/books/the-little-elixir-and-otp-guid...

I've been slow to this, but yes this summarises why this particular language is good to use as a better JavaScript.

I think this book and a lot of others fall into the _why's Poignant Guide to Ruby which i still totally don't understand the appeal of if you already know how to program.

I mean, _why is an interesting dude, who did a lot of interesting things, but (1) the whole 'chunky bacon' thing just is not my cup of bacon smoothie and (2) it was not really a great book for people who already know a lot about programming.

More broadly, I feel like _why's Poignant Guide to Ruby is an example of what I call John Bonhamization. John Bonham plays drums in Led Zeppelin. His whole style is crazy: rope-a-dope with the beat, playing mostly with the singer, playing "lead drums" and it's awesome! It's so good! It really, really works in the context of Led Zeppelin because John Bonham was a freak of nature and it just went along with their band in a magical way.

But it works for almost no one else ever. It's exactly the wrong thing to copy. It's like when people in Silicon Valley are like "well, Steve Jobs was rude as shit, I'LL be rude as shit and then *I'LL invent the next iPod!!" And then you have generation after generation of people trying to copy someone else's magic and not hitting it, when they'd've been better served trying to do the normal thing and, maybe, if they were lucky, finding their own magic.

I also think there's a bigger problem with people not writing books for people who know about programming. Odds are, if you are reading a book about a programming language, you already know a fuck ton about programming languages, but most programming language books fall into one of two categories: - Books that try to teach programming via the language in question. - Books about advanced techniques or exhaustive library documentation, cookbooks, etc. for people who already know the language.

The overwhelmingly most common case of someone reading a PL book (for a language that's not one of the world's ten most popular) is "I know a dozen other programming languages but don't know this one." Only fairly advanced programmers even bother reading books about Clojure, or D, or Rust, or Dylan, or Self, or Racket, or Julia...

Personally, I really like the Joy of Clojure. If I had to compare it to another PL book tough it would be the Matz Ruby book, not Crockford. It's pretty good though.