Slashdot Book Reviews: Programming Clojure | Hacker News Reader

Slashdot Book Reviews: Programming Clojure

books.slashdot.org

29 pointsapgwoz19 comments

original website: http://www.pragprog.com/titles/shcloj/programming-clojure

excerpt: http://media.pragprog.com/titles/shcloj/concurrency.pdf http://media.pragprog.com/titles/shcloj/flow.pdf

source code: http://www.pragprog.com/titles/shcloj/source_code

Gah! I wish I could have the mental capacity to learn all of this stuff at once. I'm busy with Python, C, tons of code that I want to explore, plus I'm interested in D (waiting anxiously for the DPL book). And then there's all that talk about Haskell and Clojure which really sparks my interest. I fear if I try to read too much, my head will explode (or worse, I'll simply forget what I've learnt).

I fear if I try to read too much, my head will explode

That's how you know you're learning - your brain rebuilds itself around new concepts. If you push it hard enough you will start hearing a hum in your ears after few hours of continuous learning.

Life is about making choices and perhaps knowing your limitations as a human being.

You can either be someone who knew various programming languages and wrote a few small single-purposed libraries (and jump the wagon to another new languages) or knew two or three programming languages and build something big.

It's a choice. Ask yourself if you are truly interested at these languages or is it because of the HN side-effect (hang out with a crowd with certain belief, you'll become them or want to become them).

Well popularity is not really the reason I'm interested in these languages. The practical guy in me tells me to stick with the languages that I know, and expand my knowledge in that domain. But then there's that other side of me that's really interested in everything. These days I'm leaning towards being more practical, but I was always interested in just about everything (be it programming, music, 3D/art, or even various sports).

And you're absolutely right about making decisions, they have to be made. Anyway, I don't want to steal the topic, but thanks for the handy reminder. :)

I'm in the same boat. A few months ago, I decided I'm not going to learn a new programming language unless I need to.

These days, learning a new programming language every year is the fashionable thing to do. This trend, IMO, is stupid. I'd say build something new every year with what you already know. If what you know isn't enough to build that something, then go ahead and learn a new technology. (For example, I mostly program Cocoa but now I want to build a webapp. I can't write a webapp in Cocoa, which is why I'm learning Django.)

Good suggestion!

Pick one for the specific domain if your current one can't handle it.

Does anyone know how it compares to The Joy of Clojure (I realize it's not done yet)?

They aim to fill two entirely different purposes.

JoC is for deeper understanding, Programming Clojure is for breadth and basic understanding to get you going in the first place. They, or maybe (depending on how it turns out) Clojure in Action are companion pieces to each other. On it's own JoC would be a decent book, but it really feels like one to take you the next steps AFTER you already have a foundation in the language from which to build.

(I'm on the Manning Early Access programs for the new Clj books, so been reading through the chapters as they come up)

Programming Clojure is an introductory book that provides an overview of the language and its functional heritage/constructs. I'd say its the "First" Clojure book.

JoC is the next step - it does offer a good look into Clojure, but from Ch 7, aims to go deeper into higher level constructs - macros, protocols, reify et al as well as concurrency. There's a lot of new 1.2 stuff that wasn't developen when PC came out.

The third book, Clojure in Action, is going to be excellent insight into the very practical, deployment, editing and interfacing aspects of the language. (Things like DSLs, web services, et al).

Anyone else dislike the use of 'recur' to indicate iteration?

Anyone else dislike the color #ff0f93 more than #ff0e95?

How is that comparable? The word 'recur' suggests recursion, so using it to mean you do NOT want recursion seems to be kind of odd. Does it make sense to you?

The 'recur' operator was meant as a replacement for the lack of tail-recursive optimization in the JVM, and is often seen as a recursion operator, not an iteration operator, especially by people coming from a functional background. People from an imperative background seem to understand it as a type of limited GOTO, with only a single place it can go to; people from a functional background see it as similar to calling the function you're in by name, but mentioning the recursion explicitly for compiler optimizations.

Recur seems to be maligned by people on both sides of the recursion/iteration divide. I rather like it, in no small part because I think the divide is silly. Iteration is the same as recursion, both semantically (especially if you have tail-call optimization) and syntactically (especially if you can have multiple loop variables). Recur blurs the distinction. If you think the distinction is important, it's confounding; if you think the distinction is silly, it's unifying.

recursion is the same as iteration in a tail-call optimized environment. Granted, the JVM isn't tail-call optimized, but whatever.

That seems like common usage. It's used prominently in either SICP or The Little Schemer (I think the latter).

It bothered me at first but after not too much time began to feel pretty reasonable. I have a few issues with the language but they're really just trivial ones. Clojure has become my favorite language, so I can't complain too much.

Reply on news.ycombinator.com