
Slashdot Book Reviews: Programming Clojure - apgwoz
http://books.slashdot.org/story/10/05/17/1351259/Programming-Clojure?from=twitter
======
pella
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>

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

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

~~~
AndrejM
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. :)

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

~~~
hello_moto
Good suggestion!

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

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

~~~
vyksyt
(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).

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

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

~~~
tzs
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?

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

