Live data from Hacker News

Clojure from the ground-up: debugging

aphyr.com

21–22 of 22 posts

Re: Clojure from the ground-up: debugging

#21

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

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.

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.

Re: Clojure from the ground-up: debugging

#22

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

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.

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

Post reply on HN