Hacker News new | comments | show | ask | jobs | submit login
Clojure for the Brave and True (2015) (braveclojure.com)
244 points by severine 13 days ago | hide | past | web | 99 comments | favorite





This is by far the best book around for learning Clojure from scratch (IMO).

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 :)


I can corroborate :) The book is well organized and pleasant to read. If you want to hear from the author about this book and other stuff, check out this episode http://blog.cognitect.com/cognicast/098?rq=brave%20and%20tru...

Plus: "cuddle zombies" :-)

Agree! My team all uses Clojure/ClojureScript for product development, and this has repeatedly been hailed as the most inviting book for getting started.

The best Clojure book in my personal experience (and fwiw) is O'Reilly's "Clojure Programming" by Chas Emerick, Brian Carper, and Christophe Grand. Extremely clear writing, and very knowledgeable authors. I really enjoyed working through the book.

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.


Just adding my 2 cents.

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.


you should try Programming Clojure then ;)

That's on my to-read list hahaha.

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!


This was a good book. It would have been better if he had a more critical perspective of the language. As much as I love Rich Hickey and Clojure, the language does have pitfalls and rough edges, and this book was a little too starry-eyed to tackle them head-on like Crockford's book on JavaScript.

I agree.

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.


is there any rhyme or reason to the order of the links on that page? the welcome post is bottom left.

They're in chronological order unfortunately, so you need to start with the bottom left and work backwards.

"The Joy Of Clojure" is more in line with Crockford's book. It goes into what Clojure does well and what you should avoid. I especially liked how it broke down it's different concurrency primitives and the pitfalls.

I consider Brave and True to be Clojure's version of _why's Poignant Guide to Ruby.


I agree.

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.


Clojure for the Brave and True is, in my opinion, more substantial than _why's Poignant Guide. It moves faster, guides you through some real (if small) projects, and the whimsical tone is really just some flavoring rather than the whole focus of the book. _why's guide really seems only to be incidentally about programming in Ruby because it's focus is being some kind of crazy postmodern deconstruction of programming tutorials, while Clojure for the Brave and True is the inverse, if that makes sense.

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.


This is a very good intro book. I skipped the emacs chapter and there was no dependency to emacs through the rest of the book. I used light table. I enjoyed the exercises, there is a good level of complexity and the author often suggests and helps to reimplement some core functions of clojure. It took me about two weeks to complete the book entirely (on the evenings and a bit more on the weekends) with no previous experience in functional programming. I was dragged into the book really quickly, more than 2 other books I started to read about Clojure (on which I gave up quickly). I also bought the paperback version to support the author but I was a bit disappointed on the quality. Overall I highly recommend this book as an intro to FP with clojure. Thanks a lot for writing this book.

I don't know what's wrong with me but I gave Clojure 3 tries in the past and every time I try to actually build something (aside from 4clojure and solving hackerrank problems with it) I get lost in the tooling and just give up then fallback to familiar frameworks\languages.

It just doesn't click with me and the whole leinengen\ring\compojure just seems weird and backhanded.


Clojure's community tend to shy away from larger frameworks in favor of small libraries. While this makes it flexible, it certainly is daunting to get into. We also know there is a struggle on the documentation front, and many of us are working to bring both the official documentation and the individual lib docs more friendly.

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.

[1] http://www.luminusweb.net/docs


I wanted to use Clojure for a long time, and finally I found a project that was "simple" enough to use it on (but which exercised some of the benefits of functional programming.

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).


Same here,

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).


It's not just you. I also find it very difficult to make anything useful with Clojure outside of practice problems.

What have you tried to make?

For me lisp in general was like that. But I just kept on until it clicked (mainly because I was getting sick of hearing all the hype and wanted to fully understand what all the fuss was about). A lot of people talk about when lisp clicks its an ahh-haa moment much like when your first programming language clicks and that is the best way to describe it. When it finally clicks it clicks but you have to put aside so much C rooted concepts and just keep beating Lisp concepts into your head until it clicks.

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.


> For me lisp in general was like that. But I just kept on until it clicked

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?


Some (me included) would argue the value is in learning a new notation for thought/program execution. Talking about the Lisp way kinda feels like converting someone to the dark side, especially with clojure. The mental model is what needs to click, not the language.

Would you recommend I start playing around with Lisp before I do clojure?

I've found http://www.ccs.neu.edu/home/matthias/HtDP2e/ to be the best resource to drill the "code as data" mindset necessary for Lisp programming. And I would recommend going through as many exercises in http://sarabander.github.io/sicp/ as possible using the Racket IDE: https://docs.racket-lang.org/sicp-manual/index.html

either or, Clojure has more of a focus on functional programming and immutability than some other lisp implementations but honestly they don't really get in the way and most lisp lean that way anyways. Personally I would say stick to Clojure or CL as there is a wealth of information and libs available for those two. Others will differ but once you know one it's a matter of style and conventions to adopt a different implementation (until you get under the hood)

There's really no need. Most of the Clojure material out there doesn't assume or require Lisp knowledge. Unless you're interested in specifically learning Lisp, of course.

I've found boot http://boot-clj.com/ to be a better than leiningen for tooling. There's no magic, just simple scripting.

Mind if I ask what isn't clicking? I've had the exact opposite experience, and have found it very easy to incorporate different libraries. Do you have experience with other lisps? There's certainly a learning curve with clojure and its frameworks.

I think there is too much cognitive load in the first stages of learning Clojure for people who haven't had experience with functional programming, Lisps, Java, and Emacs on top of that if you are following Clojure for the Brave and True. So to barely get started you are tackling a new programming paradigm (functional), a new syntax (Lisp), getting error messages in Java, using tools that are complicated to setup and use.

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.


I still teach in and prototype in Light Table, even though it is losing its "instarepl". Live evaluation visually matched up to an expression removes a lot of the cognitive load. Clojure stack traces are a big mental overhead.

Atom and the ProtoREPL package also make a great Clojure environment.

https://gist.github.com/jasongilman/d1f70507bed021b48625


I've tried just about Clojure IDE/editor, and this is probably my favorite. But still I think it is tough for a beginner. 9 packages to install, editing config files, the ProtoREPL tutorial doesn't include Mac keystrokes. The problem for a beginner is you follow all these steps and you don't if you are doing it right - there is no feedback. Once it is up and running, it is really nice.

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.


This. I wish the book would refer to lighttable instead of emacs so as to be considerably more portable and easier to get into. I recommended that combo to a non technical friend and he's happily scooting along after a short primer on (lein) repl vs (windows) command prompt vs lighttable inline evaluation

Ah, now it makes sense. I came to Clojure having experience with Java and Emacs. I can see that learning the ecosystem surrounding these things can't be an easy task if you're doing it all at once.

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.


Everything assumes you're a Java expert.

I came from Perl with zero Java when I learned Clojure and found it very easy. That was 3 years ago and apart from the occasional Integer/parseInt I've hardly ever needed to dip into Java. As Clojure is a dynamic language it's a much cleaner departure from Java than Scala or Groovy where OOP still plays a big part. Clojure can be a truly liberating experience if you've spent most of your programming life working within the OOP straightjacket.

Legacy Perl or Modern Perl with Moose, DBIx::Class, Catalyst...etc? Just curious.

Mostly modern Perl but I was happy without the OOP so Moose and friends were no big deal for me. Catalyst I always considered a lumbering beast with no chance of competing with Ruby on Rails. I'm saying Clojure was easy for me because I'd favoured the procedural Perl way for many years so wasn't so infected with the OOP mindset.

I think that's fine. I wouldn't recommend serious use of a language that targets the jvm without a decent knowledge of Java

Just like to use UNIX one needs to be comfortable with C, OS X comfortable with Objective-C, .NET confortable with C#, Web confortable with JavaScript and so forth.

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.


I have exactly different feeling about the language. When my boss wanted me to try Clojure to build a quite boring and normal REST api, it took about a day to get up to speed and I've never been more productive with any other language. Sure I miss static types, but when I see a working product with such a small amount of code it really feels nice.

I would suggest starting with compojure-api (via its leiningen template) on the backend and Reagent on the front-end. Super simple if you're familiar with building API driven SPAs and in particular React apps.

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 can tell us more about your pain points, i think we can help you give clojure another try but for this time going forward and not falling back to previous tools.

Apart from learning Clojure, Daniel's humor made it a really fun read for me.

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!

[1] https://youtube.com/watch?v=eRq5UBx6cbA


Try spacemacs everyone, it's incredible, and the cider repl for clojure is the real deal. I was a long time vim user who tried to switch to emacs for a month but abandoned it for intelli j, and then atom for while. The spacebar mechanism to trigger the top level navigation that you drill into is an amazing mechanism for memorizing key short cuts (or not remembering and being able to use the menu to get what you need). spc p f inside a project has changed my life, I can't go back to a tree directory for navigation. Frees a lot of my working memory up.

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 use Spacemacs for Clojure at the moment and I quite enjoy it. My only problem is there doesn't seem to be a way to insert a newline in the repl without submitting the line for evaluation (I want to be able to structure a function definition for readability, for example, rather than having to have a single huge line).

I did also have to stop smart-parens from auto-closing backticks, but that was a simple fix.


Use C-j to insert a newline in the repl.

Thanks!

I didn't enjoy this book; the examples used clojure constructs before introducing what they did making them arcane and difficult to understand, and it focused on the language without showing why you would use it or how to use it for real world projects.

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 agree with you about the book, it's not for everyone.

> 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.


This is why I find Apple's decision to go Swift, despite all the hurdles, is very positive.

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.


After learning syntax, the most valuable Clojure book to me was "Clojure Applied". Most books seem to cover the what of a language, Clojure Applied focused more on when and why. Which is extremely important, because I found that there tended to be lots of similar ways to tackle something in Clojure, which created mental gridlock whenever I tried to code a larger project.

I love Clojure, and have spent most of the last seven years in a Clojure REPL inside Emacs. But it still doesn't feel like critical mass has been reached. If anything, large efforts like Incanter have mostly died off, because most Clojure people are smart and resourceful enough to build their own stuff. There's an aversion to frameworks and a reliance on gluing together smaller libraries, which is totally valid as a philosophy.

Me, I'm fairly dumb and lazy, and basically at the point where I wish I'd stuck with something like Python all along.


Kind of reminds me of this: http://web.archive.org/web/20160304105922/http://www.lambdas...

"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."


That's a very nice essay—and unfortunately, I found myself described very accurately in it. I'm currently unemployed, sitting adjacent to a large pile of empty Indian food takeout bags, skimming a book on Abstract Algebra to better understand a paper on theory of deep neural networks—all of which has no connection to any lasting thing I'm doing aside from not working on a side project which happens to be at a local minimum of interest at the moment.

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 ;)


An ADD diagnosis in my twenties and an Adderall prescription have done wonders for my depression (gone), unemployment (working), self esteem (good), ability to maintain interest in projects (more fun than video games), sleep schedule (regularish) and social life (I now actually initiate plans to do things with humans now and then).

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.


I've wondered about this. I think I'm gonna see a psychiatrist soon and just present the anomalies in my background and see if they come to the same conclusion...

smell the whiff of death a few times, realize that your time on earth is limited, stop messing around, and make each stroke of your blade count (and follow through)

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...


I think that's probably pretty on point. Thanks.

I .. am reading this in my bed. I need to reflect.

The entire second chapter is devoted to learning emacs. I find this to be a baffling editing decision.

"Thanks for reading this book, but before we cover what you came for, let's do this other completely orthogonal thing first."


I totally agree the overhead of learning Emacs is orthogonal from learning Lisp. IMO, it's a shame that there is such a strong association between that tooling ecosystem and Lisp languages. I think it pushes a lot of newcomers away from the learning process.

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.

[1]:https://shaunlebron.github.io/parinfer/


Wow, those docs are pretty good!

You are free to skip the chapter and there is not a single reference to emacs in the rest of the book. I did it with another editor, I think the emacs chapter could be an annexe. It's only bonus and I can only be grateful as the book is free

I think Clojure is so much better with emacs, and teaching working tooling is the key to teaching a language. That's because actually doing the coding is the key to understanding the language. Emacs is by far the best editor out there for this language. One of the trickiest aspects to picking up emacs is the emacs init files, which the author provided. I just think it's awesome that he takes you from zero to a working development environment and doesn't leave getting code running as an exercise for the reader (which would mean many wouldn't get it running).

Really appreciate the access to the book online http://www.braveclojure.com/clojure-for-the-brave-and-true/ more likely to buy products that you can see. This years challenge, learn two new languages. Clojure might be one of them.

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.


I hear this a lot, but it totally mystifies me.

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 not sure when your last exposure to the ClojureScript ecosystem was, but almost nothing you mention is a problem as of 2016: debugging, hot reloading, large JS deps, etc.

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'm biased, but I think ClojureScript is the best way to use the JavaScript platform today. ... 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.


Got a link with specifics?

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.


That's like 2 years ago. Source maps work fairly well today.

come on, dont just wave your hands in the air and say its all good.

how do you do it then?


What do you mean how? Clojurescript compiler today has four different, well documented options related to source maps: https://github.com/clojure/clojurescript/wiki/Compiler-Optio... Just yesterday I placed `(js* "debugger;")` in my .cljs code and it stopped exactly where I wanted it. And showed exact piece of Clojurescript (not compiled JS)

"You lose all the good parts of clojure when you go into the js runtime;"

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.


You don't lose hot reloading. Use figwheel.

If you're developing a web app, you can share code between the frontend and backend and still use the JVM on the backend.

i am building a browser plugin with clojurescript and reagent. i could not be happier. i have easy js interop, i have hot reloading, i have easy state management, i have code optimizations thanks to direct integration to google closure compiler.

also, here's a really good introduction to clojurescript with reagent: https://www.youtube.com/watch?v=wq6ctyZBb0A

I found the jokes and humor in Clojure for the Brave and True actually hilarious, to where I just read it now occasionally just to laugh a bit. I don't know why I like his humor and writing so much, but I suspect that it's the same way some people at a party will laugh at my jokes and some will not. It's all about finding your audience. The book (I did the online version) actually 'unstuck' me from where I had bogged down in learning Clojure. It's the humor that made it less intimidating a subject. I am deeply grateful to this book and it actually made a big difference in my life. My brain is wired for a book like this, and so I'm very, very glad he took the time to put it all together.

After reading that book, I also suggest trying this free MOOC, http://iloveponies.github.io/120-hour-epic-sax-marathon/

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 can confirm that. I did the same route. Afterwards I read the "Living Clojure" book and solved the Wonderland Katas (https://github.com/gigasquid/wonderland-clojure-katas)

It's funny how most programming languages have die hard fans that truly believe (and will tell any stranger they meet in the street) that language X is "the best". There is no such thing as "the best" programming language for any given task. I like Clojure and Haskell and Javascript and Erlang and C++ for different reasons. They all have strengths and weaknesses, depending on the context and task at hand. And given the choice, I pick the language I use depending on the context and task that I need to solve.

> There is no such thing as "the best" programming language for any given task.

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.


I love this book. Can someone recommend something similar for Go or Elixir?

For Elixir try The Little Elixir OTP Guidebook

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


thanks!

Also on the search for something like this book for Go or Rust. I liked the book. An easy first step into the language. Sadly i don't want to write everything in jvm and somehow i got hooked on safety concepts like type-safety or even more like ownership in Rust (also when i dont really understand Rust till now).

One of the most practical yet detailed clojure "book". Thanks again.

brave clojure is really straight forward and well written

This book is painfully unfunny, filled with corny drawings and poorly structured with weak examples.

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.


I would agree with you on unfunny and corny points, but I guess it is very much a personal taste issue. On the matter of substance I have found the book to be quite OK. Could you point to any specific examples of what it does "wrong"?

Coming at clojure as a java developer with a firm grasp of programing necessities, trying to bootstrap my awareness of the language, and re-apply existing experience and establish a frame of reference by reading this book alone was not possible. The book was not written for consumption by java developers.

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.


I think you're right, the book is not suitable for first time learners without any or much background in programming. This as lots of concepts are explained in passing. It quite frustrated me and I think Carin Meyers "Living Clojure" or Aphyr's "Clojure from the ground up" are in this respect a much better job. However, after having gained some experience with Clojure I thought the book was quite rewarding.

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.


This is a fantastic book-- but it's hardly news. It was released in 2015.

"hardly news"

still ^interesting^ though. news is such a low bar these days, I'll settle for interesting over news.


That's what I thought... Now I see there was an interesting discussion (https://news.ycombinator.com/item?id=10426106) when it went free online and so actual news.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: