Adrian's comments are spot on, and they can be a bit intimidating to a
newcomer. Let me offer a piece of encouragement.

There's an interesting result from the way Clojurians code as
described above.  Every once in a while, someone will do something so
radically brilliant with the built in constructs of the language that
it catches veterans off guard.  If you go through the archives of this
list, you'll see several threads where someone does something strange,
and fifty other people respond "WTF???... oh, I get it...  DAMN THAT'S
AWESOME".  In that order.

It's possible to learn the language quickly, and become proficient in
a year or two.  True expertise takes time, and I'd argue that even
Rich hasn't *mastered* Clojure yet.  This is not a reflection on
Rich's aptitude with his own language, rather it has to do with how
daunting a task mastering a LISP truly is.

So keep your chin up.  Write code, constantly practice.  Ask
questions.  We're all learning things all of the time here.  Who
knows, given enough time you might just write one of those radically
different forms yourself.

Happy Hacking,
Sean

On Dec 12, 11:44 pm, Adrian Cuthbertson <adrian.cuthbert...@gmail.com>
wrote:
> > (reduce (fn [model f] (assoc model f (inc (get model f 1))))
> >        {} features))
> > Do Clojurians usually arrange like that? Can it be rearrange for more
> > understandability?
>
> I would write it exactly like that. What happens as you become
> familiar with Clojure is that the patterns of the api become almost
> stamped on your brain, something like a set of nested boxes. When you
> see a piece of code that starts with "(reduce" your mind immediately
> forms a kind of template like;
> ... reduce [
>    a_function_with_2_args,
>    the_initial_thing_to_be_reduced_into,
>    the_coll_to_be_reduced
> ]
> and you just know that the 2 args of the function are;
> ... [the_thing_being_reduced_into_at_each_step,
>      the_element_of_the_coll_at_each_step
>    ]
> and that it should return;
> ... _the_coll_being_reduced_at_each_step
> which will be the final result of the "(reduce"
>
> Similarly your mind then "chunks" the function's contents and applies
> a similar pattern matching process to that.
>
> This ability just comes with practice and continual use of the
> language and the best (perhaps only) way of acquiring it is by
> experimenting with these main core api calls (reduce, map, assoc,
> update-in, loop, etc) at the repl.
>
> It's like driving a car, once you can drive you just use the api
> (clutch, accelerator, gears, etc) without having to think where the
> bits are and that you have to press the clutch before changing the
> gears. You would simply ignore, or be irritated with labels that said
> "Clutch Here", "Brake Here" and so on.
>
> This is not meant to be patronising, but I think it does speak to the
> problem of "disjoint" between experienced Clojure/Lisp'ers and noobs
> learning the language. They tend to code as above, but when trying to
> help people who are learning, they try to bridge the (imperative) gap
> by breaking down the code, adding let placeholders, etc. But they
> don't code like that.
>
> Not sure what the best way of bridging the gap is and it is
> patronising to just say "experiment at the repl", but for me
> personally, that was how the patterns started "clicking" in.
>
> Perhaps our learning resources should include examples like the above
> to help learners at least see what the patterns are?
>
> -Rgds, Adrian.

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

Reply via email to