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 construc
> 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 breakin
> (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 b
On Dec 11, 10:33 pm, Richard Newman 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 can't speak for everyone, but I don't think it's common to
> (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 can't speak for everyone, but I don't think it's common to jam
*everything* on one line. I imagine Rich was layi
Below is a snippet from Rich's presentation at QCon 2009 (http://
qconlondon.com/london-2009/file?path=/qcon-london-2009/slides/
RichHickey_Clojure.pdf):
(reduce (fn [model f] (assoc model f (inc (get model f 1
{} features))
Do Clojurians usually arrange like that? Can it be rearrange
On Dec 11, 1:14 am, ngocdaothanh wrote:
> > Do you come from a Python background?
>
> For the sake of this discussion, I would say I come from Erlang.
>
> > Judging by you examples, I looks like you're still getting used to the lisp
> > style of coding. Everything is a chained function call.
>
>
> This makes Clojure code hard to understand
I'd phrase this "This makes it hard for me to understand Clojure
code". Lots of us do just fine most of the time.
Try spending some time reading point-free Haskell: there are *no*
local names. You can do that in Clojure, too.
> Is this style of "l
> ((comp negate inc) 6) -> -7
Hm, I was sure negate existed... But seems like it doesn't.
Oh well. (comp - inc) works. :)
--
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
On Dec 11, 11:14 am, ngocdaothanh wrote:
> Because of indents, my previous Clojure code lied to my eyes that x,
> y, f, g are not at the same block level. This is my difficulty with
> Clojure. In short, I can't see a rough algorithm from any Clojure code
> any more just by seeing the shape (leve
> Do you come from a Python background?
For the sake of this discussion, I would say I come from Erlang.
> Judging by you examples, I looks like you're still getting used to the lisp
> style of coding. Everything is a chained function call.
You're correct. Comming from Erlang:
* I tend to see
On Thu, Dec 10, 2009 at 09:13:33AM -0800, samppi wrote:
>notation before, and it is fine. For my tastes, however, I think that
>it repeats the symbol (in this case, 'x) too much. Sometimes it may be
>the best way, but usually I would instead use ->, ->>, and/or letfn.
The problem I have using ->
> The spy macro from c.c.logging does that. ;)
I knew it was there somewhere; I just couldn't remember where, or what
it was called! :)
--
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
N
On Dec 10, 11:02 am, Richard Newman wrote:
> > They're especially useful for inserting println calls for seeing the
> > value of something when I'm debugging; in fact, this is the primary
> > way I do debugging.
>
> (defn tee (x)
> (println "Debug: " (prn-str x))
> x)
>
> (let [x (tee (foo
> They're especially useful for inserting println calls for seeing the
> value of something when I'm debugging; in fact, this is the primary
> way I do debugging.
(defn tee (x)
(println "Debug: " (prn-str x))
x)
(let [x (tee (foo 1))]
...)
--
You received this message because you are s
> How to rearrange the Clojure code for understandability?
One approach I've used in Common Lisp to avoid multiple lets is to do
(let* ((x (let ((v 1))
(f v) ; for side-effects
v))
(y (+ x 2)))
(g y))
This calls to mind Clojure's doto, which instantiates a
If it's for side-effects, then using _ is fine, in my opinion—they're
nicely identifiable.
They're especially useful for inserting println calls for seeing the
value of something when I'm debugging; in fact, this is the primary
way I do debugging. I would say, though, that usually if you're going
On Thu, Dec 10, 2009 at 09:26:07AM -0500, Graham Fawcett wrote:
>(let [x 1
> _ (f x)
> y (+ x 2)
> _ (g y)]
> ...)
What do people in general think of this style? I remember using this
trick a lot with O'Caml, and I've certainly used it a few times in
Clojure, but something feels
A few things might help:
* Judging by you examples, I looks like you're still getting used to
the lisp style of coding. Everything is a chained function call.
Write your code to support with that in mind.
* Practice using comp & partial. Write a few small apps where you
NEVER use a let form.
* P
On Thu, Dec 10, 2009 at 9:15 AM, ngocdaothanh wrote:
>
> My Clojure code:
> (let [x 1]
> ...
> (f x)
> ...
> (let [y (+ x 2)]
> ...
> (g y)))
>
> It is very difficult to capture the "algorithm" behind the Clojure
> code because things of the same "abstractness" level do not have the
> sa
I'm not sure either what you mean by "abstraction level", but I would say
that I tend more to think about abstraction level to be at function
definition level.
2009/12/10 ngocdaothanh
> Hi,
>
> I want to ask about code arrangement and understandability
> (readability).
>
> Consider this "normal"
On Thu, Dec 10, 2009 at 9:15 AM, ngocdaothanh wrote:
> Hi,
>
> I want to ask about code arrangement and understandability
> (readability).
>
> Consider this "normal" code:
> x = 1
> ...
> f(x)
> ...
> y = x + 2
> ...
> g(y)
>
> x, f, y, g have the same "abstractness" level, so they are indented to
Hi,
I want to ask about code arrangement and understandability
(readability).
Consider this "normal" code:
x = 1
...
f(x)
...
y = x + 2
...
g(y)
x, f, y, g have the same "abstractness" level, so they are indented to
the same level.
My Clojure code:
(let [x 1]
...
(f x)
...
(let [y (+ x
23 matches
Mail list logo
