This is good advice, but I can't parse 1a after the phrase "or maybe", and I'm not sure about 1b. Can you reword them, making it clearer when you're using a Clojure keyword? I want to be sure I understand what you're saying--it sounds insightful! Thanks.
On May 11, 9:09 pm, Ken Wesson <kwess...@gmail.com> wrote: > 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-schoo..., > > 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
