Hi Colin, >Clojure code tends to be much more about the shape of transformations than the semantics of those transformations. Interesting, thanks
>I think most people would inline that. Extracting it however, give helpful information about the structure which isn't captured by the call to concat, namely the vertical nature (top/bottom). >Of course, if the variable names were retained then is also sufficient but they almost certainly wouldn't be. Yes >I am on the fence, and fall down frequently either side (you wouldn't believe the chaffing :)) - Yes, I may soon be in the same position >But I also *feel the loss of the info captured in variable names/function names* as well. Yes >the more Clojure you write the more you start to realise that the same "shapes" of functions come up time and time again - the structural shape of the code imparts knowledge sometimes. OK Philip On Saturday, 6 December 2014 18:40:16 UTC, Colin Yates wrote: > > Excellent question and I will be watching this thread with interest. > > Similar to David Della Costa, I find a bit difference between Clojure and > Java for example is that there is much less naming-of-concepts. Clojure > code tends to be much more about the shape of transformations than the > semantics of those transformations. > > A case in point, you wrote [code](defn put-one-on-top-of-the-other > [top-half-of-diamond bottom-half-of-diamond] (concat top-half-of-diamond > bottom-half-of-diamond))[/code]. I think most people would inline that. > Extracting it however, give helpful information about the structure which > isn't captured by the call to concat, namely the vertical nature > (top/bottom). Of course, if the variable names were retained then is also > sufficient but they almost certainly wouldn't be. > > I am on the fence, and fall down frequently either side (you wouldn't > believe the chaffing :)) - the more Clojure I write the more comfortable I > am with dense calls to core.clj functions. But I also feel the loss of the > info captured in variable names/function names as well. > > Another point worth mentioning is that the more Clojure you write the more > you start to realise that the same "shapes" of functions come up time and > time again - the structural shape of the code imparts knowledge sometimes. > > As David says, if you haven't looked at Prismatic Schema then have a look. > I find the definition of the schema is also an excellent place to capture > this extra layer of info in the names of those structures. > > Good question. > > On Saturday, 6 December 2014 10:48:02 UTC, Philip Schwarz wrote: >> >> Hello, >> >> can you please review my first solution to the diamond kata [1] and tear >> it to bits: let me know all the ways in which YOU would improve the code. >> >> I am not so interested in a better algorithm for solving the kata. I am >> learning Clojure and what I want to know is what YOU would do to make the >> code more readable/understandable/maintainable, or just to make it follow >> Clojure idioms and/or conventions that YOU find effective, or to follow a >> coding style that YOU find more effective. >> >> Thanks, >> >> Philip >> >> [1] https://github.com/philipschwarz/diamond-problem-in-clojure >> > -- 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/d/optout.
