Clojure for the Brave and True (2015)
braveclojure.com
braveclojure.com
If you always wanted to learn Clojure but never had the time, 2017 is the right year, and Clojure for the Brave and True is your companion. Buy it, or just read it for free on the website.
(Disclaimer: I'm not in any way associated to the book or the author, I'm just super thankful for all the times this book has helped me to learn new things and solve issues :)
Due Disclosure:
1. I was an experienced Haskell and Java programmer, when I read the books, so I didn't have to go through any culture shocks wrt either Java or FP.
2. I have used Clojure only for toy projects. My 'daily use' tools are Haskell, C and Lua.
3. I am not in the audience targeted by 'cute cartoons and corny jokes' books. the _why style, nothing wrong with that, I just find most of this 'cute' style to be wasting my time. If it works for you that is awesome
4. I found the tooling around Clojure weird and unintuitive, especially Leiningen. Apparently there are better alternatives now
All that said, if I had to work on the JVM again, I'd use Clojure in a heartbeat. If I start a Clojure based company, Clojure Programming would be what I ask new employees who are unfamiliar with Clojure to work through.
I can't recommend the book enough. There was some talk of an updated edition, which I'd buy the instant it came out.
I've found the writing of Clojure Programming to be very dull, to be honest.
Sure, it is clear and detailed, but it gets boring after a while.
I think the Joy of Clojure is a better read (at least for me). The upside about Clojure Programming is that it covers the language's syntax right upfront, which (IIRC) Joy of Clojure does not.
Though, for some reason, I've never seen many people recommending it.
Would you care to share your thoughts on that book? I'd really appreciate it!
It just doesn't click with me and the whole leinengen\ring\compojure just seems weird and backhanded.
But if you want to see how to build a larger webapp, the Luminus project [1] is an excellent source of documentation for how to build web applications with Clojure. I would also recommend the r/clojure subreddit where many of the library authors hang out and help new users of Clojure. We often have a "New Users: Ask Us Anything" thread.
Mine was a backup purge scheduling tool that read a user's (admin user) CSV file for dictating backup retention rules and then did analysis on the Bacula system, ultimately generating a shell script that would delete the appropriate backups.
In some worlds that would be considered insignificant, but it was a real world problem with great risks (deleting the wrong backups can be really bad).
When it was done, I did a code review with different Ruby and Python colleagues. That's where the benefits really began to show - I could illustrate the simple rules, the facts and behaviors, and we were able to build upon those solid rules. People who didn't know Clojure and who had no exposure to Lisp could confidently agree that the behavior of the program was to spec.
That, for me, is the beauty of Clojure (or perhaps Lisp).
I found the concepts in Clojure attractive and elegant but the implementation to be lacking.
The toolchain is extremely heavyweight and any promised performance, scalability and development improvements just don't materialise.
Like you, I've only tried toy projects, but Clojures weight and lack of real (as opposed to promised) improvement never occurred for me.
Also, there seems to be constant discussions on the Clojure forums about the lack of performance.... and they all get resolved by admitting that you need to fallback to non-idiomatic Clojure (i.e. just doing it the Java way).
I once heard C described as learning programming in the constraint of time (e.g A happens first then B) where lisp executes in distance or space (e.g A happens over here and B happens over there). It's probably the best way to describe it but it does not click to somebody that is still thinking in time. It just seems weird and painful. Because you can't do things the way your brain thinks they should do them in the constrain of time.
It finally clicked for me when I build a simple file parser and I think that is a great project to use to understand a lisp.
Not sure this is the right way... I mean, everything will "click" if you do the same, e.g. VB6, but do you want this?
I think a lot more people would take on learning the language if the day 1 experience was more friendly. Simple tooling, simple install, simple error messages. Something more like Racket offers. Then the initial learning could be more focused on functional programming, and the syntax, which is more rewarding.
To be beginner friendly, it would be good to have a packaged installer that pre configures and installs everything, or a single Clojure/ProtoREPL package that could be installed in Atom that includes all the dependent packages, and config changes.
As others have pointed out, there are more 'beginner friendly' options it seems. But, these seem overlooked, and I can see beginners not even being aware they exist.
If Clojure wants to see more mainstream success, the community is going to have to provide people with the things they want. Emacs is fantastic (I use it everyday) and I believe it is the best way to write Clojure, but the learning curve of Emacs + Clojure + Java is too great. Cleaning up the Java Stack Traces (I believe there are several projects that try to do this) in Clojure Core would also help with this.
When one needs to look under the hood to solve performance or FFI issues, it is a requirement to know the "systems" language of the host platform, regardless how much we might love/hate it.
compojure-api will get you going, and you can sort of back in to a fuller understanding of compojure and ring, which I agree is a bit confusing -- hard to know which of the zillion ring plugins to use, and where.
If you enjoyed the style of the book, it's also worth checking out his talk on parallel programming [1], I caught myself laughing out loud and actually learning something at the same time.
Thanks, Daniel!
Kind of a rant and off topic, but I think it's the bees knees and it's ace for clojure / common lisp / javascript / flow / anything else.
I did also have to stop smart-parens from auto-closing backticks, but that was a simple fix.
It's like... a detailed guide to the language, for people who already know clojure.
I recommend 'Living Clojure' by Carin Meier for new comers.
(Also, avoid the clojure cookbook; it's just a list of 'how to do X' for a bunch of X questions, kind of like a FAQ of best practices; it's in no way an introduction to the language)
Like rust, I feel if you want to push someone into using clojure you have to pitch it at them with more than just 'hey look at this syntax. So functional!'. I know the clojurescript people are all enthusiastic these days, but the strength of clojure is its concurrency and seemless interop with the java ecosystem; if you don't need those, it's just another lisp.
You lose both of those with clojurescript, and I fail to any benefit in it. /shrug
> I know the clojurescript people are all enthusiastic these days, but the strength of clojure is its concurrency and seemless interop with the java ecosystem; if you don't need those, it's just another lisp. You lose both of those with clojurescript, and I fail to any benefit in it.
No, it's not just another lisp. There are very compelling reasons why one would chose Clojure even if it didn't have those nice concurrency abstractions. Built in persistent data structures give you the ability to separate values with identities, because of awesome sequence abstraction you usually don't have to care about the exact type of some sequence, the same functions just seem to magically work on all of them, which enables you to think on a higher level, about data streams and transformations. Lazy sequences are also a big benefit, when you want to deal with data that is just too large to fit into memory. Then there are transducers, the decoupling that OO can only dream about.
So I beg to differ.
Sometimes developers are like children, they need to be force feeded their vegetables.
You see this specially in the games industry, where language adoption is driven by OS vendor SDKs.
Me, I'm fairly dumb and lazy, and basically at the point where I wish I'd stuck with something like Python all along.
"Another feature about this guy is his low threshold of boredom. He'll pick up on a task and work frantically at it, accomplishing wonders in a short time and then get bored and drop it before its properly finished. He'll do nothing but strum his guitar and lie around in bed for several days after. That's also part of the pattern too; periods of frenetic activity followed by periods of melancholia, withdrawal and inactivity. This is a bipolar personality."
I wonder if anyone here has figured out good ways of compensating for this personality type, who has managed to somehow turnout relatively well-adjusted in spite of it ;)
Before consulting with professionals, I'd never considered this might be my problem because I've never been hyperactive... But after doing some reading, it seems that this sort of disorder can present in a variety of ways, only one or two of which include hyperactivity.
If you are reading abstract algebra books because you want to, maybe this would encourage you as much as it did me - many people with various presentations of ADD are diagnosed in grade school because they "hit the wall" - they reach a significant level of dysfunction re: attention span, etc. and people around them are able to notice. However, the more a student is able to rely on their own natural intelligence to carry them (rather an ability to study), the longer it can take for a problem to appear. I was a junior in a CS degree at an excellent university when I finally hit my wall and realized I had to change something or everything would fall apart.
only you can ride your private racehorse. everyone else who tried got thrown. get on and ride.
basically, one has the tools to be a proper cyborg ninja, and the only thing stopping one are minor personal vanities that actually deliver minimal pleasure compared to the pain they create in blocking ones self-realization. ditch em :)
*i find yoga, stretching, exercise, etc. helps to gather the passion and focus to unleash it when sitting still again...
"Thanks for reading this book, but before we cover what you came for, let's do this other completely orthogonal thing first."
One of the design goals of Parinfer[1] is to help reduce the cognitive load of Lisp syntax for newcomers. Hopefully more introductory texts adopt it as part of their environment setup.
The reason? Lisp based and in spite of the fact it uses cough, Java (JVM), it runs on JavaScript. A better language to run/work with JavaScript. That is a good enough reason to learn and use.
You lose all the good parts of clojure when you go into the js runtime; stm, parallel processing, java interop, hot reloading, and it pulls in some really quite large js dependencies, and it's impossible to debug. Even console logging becomes a case of 'convert to readable object and log' using special helpers.
What's the benefit?
I don't see any meaningful reason to use clojure in this context; what's the draw? Why would you bother over any other compiles-to-js language?
You.. just like the syntax? That's the best answer I've gotten so far.
I'm biased, but I think ClojureScript is the best way to use the JavaScript platform today. Awesome core library, consistent build process, best of breed tooling, persistent data structures, flexible syntax (JSX is madness compared to hiccups); I could go on.
JavaScript the platform may have it's warts, but ClojureScript is all beauty :)
I've been slow to this, but yes this summarises why this particular language is good to use as a better JavaScript.
I've never seen breakpoints & source maps working properly; just a series of blog posts by various people who've tried and failed to get it working.
how do you do it then?
Easy, develop one language, ship using another to the largest user base.
"You.. just like the syntax?"
Code as data, macros, immutability, concurrency, access to libraries.
It really helped solidfy some concepts for me by presenting concepts one at a time with built in unit tests to provide fast feedback.
I think there is definitely a language that is the best "general" language, however general differs for everyone.
I'm not sure it's possible to get an average of everyone's definition of general and make a test to measure languages with though.
For me though, Haskell has been the best "general use" language.
https://www.manning.com/books/the-little-elixir-and-otp-guid...
I have the book, and I do not like it. I read it while learning, and returned to it only to realize what it did wrong, and why I learned nothing from it.
It saddens me to see this post.
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:
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.
As of the Jokes, it seems this is a matter of taste. I quite liked the jokes.
Concerning the book "Land of Lisp" I wished Conrad Barski had used Clojure instead of Common Lisp.
A sibling comment recommends "Joy of Clojure" but I feel that's better as a second or third book.
My personal recommendation, YMMV as always, is
Kyle Kingsbury's "Clojure from the Ground Up" series https://aphyr.com/tags/Clojure-from-the-ground-up, then "Clojure Applied", then "Joy of Clojure". Hard to say an ideal order for the last two -- "Clojure Applied" is more approachable IMO, but "Joy of Clojure" is more comprehensive and covers more "cool" applications that spark curiosity and creative thinking.
I consider Brave and True to be Clojure's version of _why's Poignant Guide to Ruby.
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.
I think it's a good introduction, and as someone who's programmed in a lot of languages over the years it was accessible without being too dumbed-down. The style certainly isn't to everyone's taste, of course.
still ^interesting^ though. news is such a low bar these days, I'll settle for interesting over news.