On Wed, May 11, 2011 at 10:10 PM, J.R. Garcia <mrjohngar...@gmail.com> wrote: > I'm wondering what resources would be best to learn how Clojurians > write their code. > > I've been developing for about 4 years in several object-oriented > languages (mostly C# and Ruby). I understand Clojure's syntax well and > I'm familiar with a lot of the features of Clojure (although I'm sure > several of you would prove me wrong). One problem I keep running into > is how to attack a problem "the Clojure way". I often find myself > writing Clojure like I would write C# code with LINQ, only in > Clojure's syntax. > > I'm not interested in Java interop or Clojure on the web or Clojure's > syntax. I've had no problem finding answers for those things on the > Internet. I'm really more interested in stuff like > http://www.bestinclass.dk/index.clj/2010/10/taking-uncle-bob-to-school.html, > but covering a wider range of things rather than a small example. I'm > interested in any resource whether it's a book, a video, a blog, a > person, etc. > > Any suggestions?
I don't know about any books or other resources, but a few general pointers: 1. Think functional. Try to express as much as possible as "data plumbing": here is an input, here is the desired result, how to get there from here? Think in terms of calculating a new value in terms of an existing one, rather than changing things in place. Familiarize yourself with map, filter, remove, reduce, iterate, and friends, and the data structures (maps, sets, vectors, seqs) and use those to represent as much as possible and to do as much as possible. In particular, when a processing step has to be repeated: 1a. If it's for each element of a sequence, consider map, reduce, and for. If it has to walk several sequences in tandem, use map, or maybe reduce or for with (map vector s1 s2 ...). If it's for each combination in some sequences, so for all in the first sequence, and for each of those for all in the second, etc., use for. 1b. If it's accumulating a result, consider reduce, even if the input isn't (obviously) a sequence, or iterate, before resorting to loop/recur. 2. When the time comes to abstract things, abstract as much as you can using function arguments and, perhaps, returns and using maps before resorting to defmulti/defrecord/etc. 3. Look at other Clojure code, including what shows up here from time to time, and ask here about making specific code more idiomatic. Many people here will likely answer fairly quickly, and even when they disagree, the disagreement and their stated reasons for disagreeing may themselves be illuminating -- and then anything *everyone* agrees is ugly or poor practice almost certainly is. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
