6 ms·

I'm trying so hard to love Clojure, but I keep running into examples of code like this in the world: http://imgur.com/79FlpTL http://imgur.com/79FlpTL. I don't

I'm trying so hard to love Clojure, but I keep running into examples of code like this in the world: http://imgur.com/79FlpTL http://imgur.com/79FlpTL. I don't write dense Lisp code like that, but unfortunately a lot of other people do. And I spend far more time reading code than writing it.

harperlee 12y ago
If you don't mind, what document is that?
- kaffeinecoma 12y ago
  It's a page from the O'Reilly Clojure Programming book. I hate to point fingers at the authors, because it's generally a really great book. Just that some of the examples are rather dense, and I get the feeling that this is not at all unusual in the community.
- raju 12y ago
  It's from Clojure Programming by Chas Emerick, Brian Carper, Christophe Grand - http://shop.oreilly.com/product/0636920013754.do http://shop.oreilly.com/product/0636920013754.do
swannodette 12y ago
Well that code seems pretty readable to me and appears to preserve some interesting properties of the original paper as mentioned below the source :) As far as spending more time reading Clojure than writing it I experience this myself - and I'm pretty sure this isn't a bad thing.
- kaffeinecoma 12y ago
  I meant that in general, we as programmers will spend more time reading (our, others') code than writing it. Nature of the business. Did not mean to imply this was a bad thing. When I consider adopting a language, part of that consideration is how well I can read others' idiomatic code. It's so important for understanding libraries. I'm still just having a hard time with Clojure. I know it clicks for a lot of people though.
- Flow 12y ago
  Perhaps readable if you read a lot of Clojure, but hardly anything that is easy to test piece by piece inspecting intermediate data, using a REPL for example.
gcv 12y ago
Think of this code as taking a built-in data structure and repeatedly refining it by transforming it into a different data structure. With only a little more practice, you'll find reading (and writing!) code like this becomes second nature. I find it much simpler to deal with this style than with the equivalent in other languages, which would scatter the details across a half-dozen files, a dozen classes, and two dozen methods.
smrtinsert 12y ago
These are fairly common functions in clojure. You might not be there yet as it is pretty readable. My personal preference would be to work in some let expressions for extra clarity.
- jgalt212 12y ago
  Amen to that. I try to write mostly functional Python, but I use a lot of temporary variables to make such things as f(g(args) more readable where each arg is in itself a non-trivial computation that must be passed along to another function. The problem with your let strategy is this can also impair readability if you use too many as the code becomes too far indented to the right (lets inside of lets inside of lets). But I guess in these situations you can just use transients that are first defined to nil. Some people will probably yell at you for this. http://clojure.org/transients http://clojure.org/transients

harperlee 12y ago

If you don't mind, what document is that?

kaffeinecoma 12y ago
It's a page from the O'Reilly Clojure Programming book. I hate to point fingers at the authors, because it's generally a really great book. Just that some of the examples are rather dense, and I get the feeling that this is not at all unusual in the community.
raju 12y ago
It's from Clojure Programming by Chas Emerick, Brian Carper, Christophe Grand - http://shop.oreilly.com/product/0636920013754.do http://shop.oreilly.com/product/0636920013754.do

swannodette 12y ago

Well that code seems pretty readable to me and appears to preserve some interesting properties of the original paper as mentioned below the source :) As far as spending more time reading Clojure than writing it I experience this myself - and I'm pretty sure this isn't a bad thing.

kaffeinecoma 12y ago
I meant that in general, we as programmers will spend more time reading (our, others') code than writing it. Nature of the business. Did not mean to imply this was a bad thing. When I consider adopting a language, part of that consideration is how well I can read others' idiomatic code. It's so important for understanding libraries. I'm still just having a hard time with Clojure. I know it clicks for a lot of people though.
Flow 12y ago
Perhaps readable if you read a lot of Clojure, but hardly anything that is easy to test piece by piece inspecting intermediate data, using a REPL for example.

gcv 12y ago

Think of this code as taking a built-in data structure and repeatedly refining it by transforming it into a different data structure. With only a little more practice, you'll find reading (and writing!) code like this becomes second nature. I find it much simpler to deal with this style than with the equivalent in other languages, which would scatter the details across a half-dozen files, a dozen classes, and two dozen methods.

smrtinsert 12y ago

These are fairly common functions in clojure. You might not be there yet as it is pretty readable. My personal preference would be to work in some let expressions for extra clarity.

jgalt212 12y ago
Amen to that. I try to write mostly functional Python, but I use a lot of temporary variables to make such things as f(g(args) more readable where each arg is in itself a non-trivial computation that must be passed along to another function. The problem with your let strategy is this can also impair readability if you use too many as the code becomes too far indented to the right (lets inside of lets inside of lets). But I guess in these situations you can just use transients that are first defined to nil. Some people will probably yell at you for this. http://clojure.org/transients http://clojure.org/transients