I started writing clojure full-time a year and a half ago. At first, it was a terrifying freedom that I could only write a few lines of code a day, and each line was so packed with meaning it makes your head spin. It took an incredibly long time to understand the terseness of code.
Maybe someone would notice how unproductive I was? Eventually, I started doing the mental math, comparing my code to what I think it would look like in Java, it was then I realized an anecdotal tradeoff something like this: 10x harder to write, 10x more concise, 5x harder to read. That means you'll see meaning twice as fast to write things this way, and it's worthwhile to minimize the space code takes, because you spend more time reading than writing. Less time scrolling around, clicking on lots of different files, weaving it bottom-up into a mental model of what the Java developer was thinking. More top-down, seeing it all at once kind of thinking. I say, write the simplest thing that could possibly work. Clojure does 'simple' really well. Use good abstractions that match what you're actually doing. Maybe a loop/recur is more explicit, but reifying an iterative computation as data (seq) is usually 'simpler' where applicable in terms of mental abstraction-jumping overhead. How scary something is at first glance has little bearing on how skillfully you can work with it in the long run. Multiply those costs and benefits by how often that feature is used and you can overtake the initial cost relatively easily. I feel this is the real killer feature of lisp, jumping levels of abstraction is so incredibly easy that technical problems in other languages become existential ones for the individual developer. Why? instead of how? It's like the 'Lisp Curse', but really, it's just being human. Familiarity feels safer, and that feeling is something we should identify and choose to comply with only when it objectively makes sense to do so. Instead of 'how clear is it to others', I wonder if it's interesting to ask, how clear 'should' this be to others. Maybe we can expect ourselves and each other to learn and do things at the edge of understanding once in a while. Frankly, I find it harder to understand code written by newcomers to the language, even though they use familiar concepts. That's the other side of the trade-off. But, I don't 'get' monads either. On Wednesday, April 10, 2013 1:27:58 PM UTC-4, edw...@kenworthy.info wrote: > > So, page 143 of Clojure Programming has an implementation of Conway's Life: > > (defn step > "Yields the next state of the world" > [cells] > (set (for [[loc n] (frequencies (mapcat neighbours cells)) > > :when (or (= n 3) (and (= n 2) (cells loc)))] > > loc))) > > The book claims this to be "an elegant implementation'. > > Now it's been a long while since I wrote code to put food on the table - > but back then if I saw C or C++ code written like this I would describe it > as obfuscated - the sort of thing I would expect to see in the (now > defunct?) annual obfuscated C competition. It's concise and rather clever, > certainly, but hardly self-documenting: it's not very clear what it's doing > at all- with a couple of magic numbers thrown in for good measure. Rather > arcane in fact. > > Is it just me? Is this considered to be good Clojure code and I'm just > hopelessly out of touch and need to get with the programme? > > > > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
