Hi Colin, 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.
yes, it seems to me that often (always maybe?) functional code speaks a lot about HOW, and not much about WHAT 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. Yes, that method was introduced by an application of the Explaining Message pattern. Here is how Kent Beck describes the pattern in Implementation Patterns <http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091>: > The first example I saw of this was in Smalltalk. Transliterated [into > Java], the method that caught my eye was this: > *Explaining Message*The distinction between intention and implementation > has always been important in software development. It is what allows you to > understand a computation first in essence and later, if necessary, in > detail. You can use messages to make this distinction by sending a message > named after the problem you are solving which in turn sends a message named > after how the problem is to be solved. > > highlight(Rectangle area) { > reverse(area); > } > I thought, “Why is this useful? Why not just call reverse() directly > instead of calling the intermediate highlight() method?” After some > thought, though, I realized that while highlight() didn’t have a > computational purpose, it did serve to communicate an intention. Calling > code could be written in terms of what problem they were trying to solve, > namely highlighting an area of the screen. > Consider introducing an explaining message when you are tempted to comment > a single line of code. When I see: > flags|= LOADED_BIT; // Set the loaded bit > I would rather read: > setLoadedFlag(); > Even though the implementation of setLoadedFlag() is trivial. The > one-line method is there to communicate. > void setLoadedFlag() { > flags|= LOADED_BIT; > } > Sometimes the helper methods invoked by explaining messages become > valuable points for further extension. It’s nice to get lucky when you can. > However, my main purpose in invoking an explaining message is to > communicate my intention more clearly. And here is a summary of how Beck originally described the pattern in Smalltalk Best Practice Patterns <http://www.amazon.co.uk/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X> : - How do you communicate your intent when the implementation is simple? - Probably the most frustrating part of learning Smalltalk - You see a message like highlight and think: this has to be something interesting ParagraphEditor>>highlight:aRectangle self reverse:aRectangle - What is going on? Communication. Most importantly, one line methods are there to communicate. - Explaining Messages are the most extreme case of writing for readers instead of the computer - How do you communicate your intent when the implementation is simple? - Send a message to “self”. Name the message so that it communicates what is to be done rather than how it is to be done. Code a simple method for the message. - Three examples: Collection>>isEmpty ^self size = 0 Number>>reciprocal ^1 / self Object>>=anObject ^self == anObject My program constructs the diamond by putting the top half of the diamond on top of the bottom half. The implementation is simple: the top and bottom parts are sequences that just need to be concatenated. But the implementation is a detail, and may even change one day, so I encapsulate it behind Explaining Message put-one-on-top-of-the-other. Explaining Message allows us to separate intention (the WHAT) from implementation (the HOW): the method name tells us WHAT, and the method body tell us HOW. Is the distinction between intention and implementation considered unimportant, or not so important in functional programming? 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.
