Hi Leif,
if I compare your suggestion
(let [top-right (create-top-right-quadrant-for letter)
> right (stack top-right
> (flip top-right))
> diamond (beside (map reverse (drop-first-col right)) right)]
> (display diamond))
with mine
(let [top-right-quadrant (create-top-right-quadrant-for letter)
top-left-quadrant (drop-first-column-and-reverse-every-row-of
top-right-quadrant)
top-half-of-diamond (join-together-side-by-side top-left-quadrant
top-right-quadrant)
bottom-half-of-diamond (flip-bottom-up-and-drop-first-row-of
top-half-of-diamond)
diamond (put-one-on-top-of-the-other top-half-of-diamond
bottom-half-of-diamond)]
yours is more inviting, and mine just looks like a barrage of verbiage.
But with some judicious spacing and syntax highlighting, I think mine
regains IMHO its effectiveness
(let [*top-right-quadrant **(**create-top-right-quadrant-for *
*letter**)*
*top-left-quadrant * *(*
*drop-first-column-and-reverse-every-row-of* *top-right-quadrant**)*
*top-half-of-diamond* *(**join-together-side-by-side*
*top-left-quadrant *
*
top-right-quadrant**)*
*bottom-half-of-diamond* *(**flip-bottom-up-and-drop-first-row-of*
*top-half-of-diamond)*
*diamond* *(*put-one-on-top-of-the-other
*top-half-of-diamond*
*bottom-half-of-diamond**)*]
even better if I adopt the 'beside' you suggested, and its 'above'
counterpart:
(let [*top-right-quadrant **(**create-top-right-quadrant-for *
*letter**)*
*top-left-quadrant * *(*
*drop-first-column-and-reverse-every-row-of* *top-right-quadrant**)*
*top-half-of-diamond* *(**beside* *top-left-quadrant *
* top-right-quadrant**)*
*bottom-half-of-diamond* *(**flip-bottom-up-and-drop-first-row-of*
*top-half-of-diamond)*
*diamond* *(*above *top-half-of-diamond*
*bottom-half-of-diamond**)*]
Do you see the value of hiding the HOW at all? Imagine if this was
something more complicated, e.g. a financial application: wouldn't you be
thankful for being spared the detail of HOW things are implemented until
that time when you consider it useful to understand it?
We talked elsewhere in this thread of separating intention from
implementation by using the Extract Method refactoring and implementation
patterns like Composed Method, Intention Revealing Method Name, Explaining
Message, etc. But the above code also highlights that other simple
technique we can use to separate WHAT from HOW: the Introduce Explaining
Variable refactoring (http://c2.com/cgi/wiki?IntroduceExplainingVariable -
AKA Extract Variable http://refactoring.com/catalog/extractVariable.html).
Instead of forcing the reader to deal with the whole of a non-trivial
expression which is all about the HOW, we can factor out one or more
sub-expressions and give them a name that says WHAT the expression(s) do.
In your 'let', you have two explaining variables, whereas I have four.
Do you see the value of hiding the HOW in this way?
Philip
On Tuesday, 9 December 2014 05:06:22 UTC, Leif wrote:
>
> Hi, Philip.
>
> I had the same urge as David--I tried it out, glossing over any formal
> rules. Here's what I came up with:
> https://gist.github.com/leifp/ae37c3b6f1b497f13f1e
>
> In truth, I think David's solution is more readable and maintainable. But
> I think "maintainability" is a pretty tricky concept:
>
> My code makes a seq of maps describing rows, and then turns them into
> strings at the end. This is probably more work to understand than David's
> solution. But is it less maintainable? Well, currently, the answer is
> "yes," but what if I need to output a diamond in several different
> formats? What if marketing wants each row to be a different color and
> font? I would start to favor my solution in that case. My point is that
> the difference between "maintainable" and "horrible" is evident, but the
> difference between "maintainable" and "easily maintainable" depends on
> predicting the future somewhat.
>
> I also favor a slightly less verbose style. A function is an abstraction,
> and you seem to be writing functions for very concrete steps. I think you
> have most of the correct abstractions for your solution method, you just
> need to consolidate the more concrete steps. Something like:
>
> flip-bottom-up -> flip (or vertical- and horizontal-flip)
> join-together-side-by-side -> beside
> put-one-on-top-of-the-other -> stack (or ontop, or ...)
> reverse-every-row -> (map reverse rows) ; very readable to clojure
> programmers
>
> (let [top-right (create-top-right-quadrant-for letter)
> right (stack top-right
> (flip top-right))
> diamond (beside (map reverse (drop-first-col right)) right)]
> (display diamond))
>
> The broad takeaway is: if I write a function I only use once, I usually
> just inline it. Unless of course I believe deep in my heart I'll have need
> of it somewhere else soon :).
> This is somewhat a matter of taste, and again, the requirements history
> usually determines what gets abstracted into functions, and history can be
> messy. :)
>
> Hope that helps,
> Leif
>
> On Saturday, December 6, 2014 5:48:02 AM UTC-5, 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.
