Hi David,
- Stylistically, I found your naming conventions to be too verbose
Do you mean you find the method and variable names too long?
Here was my first attempt at the diamond kata in Clojure (written in 40
minutes during a commute)
(defn print-diamond [letter]
(let [alphabet "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
position-of (fn [letter] (inc (- (int letter) (int \A))))
number-of-letters (position-of letter)
dashes (fn [n] (repeat n \-))
fixed-text-for (fn [letter] (concat (dashes (dec (position-of
letter))) (list letter)))
template (map fixed-text-for (take number-of-letters alphabet))
pad-with-trailing-dashes (fn [index line] (concat line (dashes (dec
(- number-of-letters index)))))
top-right-quadrant (map-indexed pad-with-trailing-dashes template)
top-left-quadrant (map reverse (map rest (take number-of-letters
top-right-quadrant)))
top-half (map concat top-left-quadrant top-right-quadrant)
diamond (concat top-half (drop 1 (reverse top-half)))]
(doseq [line (map #(apply str %) diamond)]
(println line))))
Do you find that concise? Do you find it readable?
Ron Jeffries' reaction to that was: "can people read that and figure out
what it does? i can't but not a closure person"
I thought one reason why people might find it difficult to read it is that
they are confronted with a lot of detail about HOW the code is solving the
problem, rather than WHAT the code is doing.
So what I did is take the above code and have a go at making it more
understandable by rewriting it using the following implementation patterns:
Decomposing Message, Composed Method, Intention Revealing Method,
Explaining Message. With these patterns, we arrange the code so the the
reader is mostly confronted with the WHAT rather than the HOW.
Using the patterns in procedural and OO languages works well. I wanted to
see if they work in functional programming languages.
Philip
On Saturday, 6 December 2014 13:36:47 UTC, David Della Costa wrote:
>
> Hi Philip,
>
> I read your message and immediately wanted to try it myself--I intended to
> leave it at that but I realized I would be remiss if I did not give you a
> little bit of feedback based on my experience. I should add that I was
> kind of fast and loose with my solution (that is, I didn't really read the
> instructions), but it does print out the diamond shape according to what I
> saw in the blog post examples.
>
> First of all, here's what I came up with:
>
> https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9
>
> As you said, you weren't looking for alternative algorithms and I
> recognize that that's not the point. But there are a few things that I
> think are good and/or common Clojure practice that I think I've
> internalized, and writing out an alternative solution helped me to see them.
>
> - I'm assuming you used a TDD process to write this (correct me if
> wrong--basing that on the articles you linked to), but I think a
> repl-driven process may be more common for working through a problem like
> this--i.e. something you can wrap your head around as a whole and solve
> iteratively. That's not to say I and others don't use TDD in Clojure dev,
> but just that it's also quite common to do a lot of this kind of
> development in the repl.
>
> - you're grouping your side-effecting code w/the code that generates the
> diamond data structure here:
> https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9
>
> While of course the diamond kata is a bit contrived and the point is to
> print stuff out in the end, it also looks like you are trying to be
> thoughtful about how you structure your code. So I would suggest isolating
> your pure functions from your side-effecting code as a sort of basic
> separation, and avoid monolithic functions like the one I linked to above.
> This gives you the freedom to apply the data structure to other processes
> if need be, rather than having to refactor that code later on as soon as
> you need to do something other than printing to the final diamond data
> structure. That is a more compositional approach that is good to follow as
> part of functional programming practice in general. And otherwise it seems
> like you are following this approach--I think you can see this in the shape
> of your code overall.
>
> - Stylistically, I found your naming conventions to be too verbose, with
> not enough information about the actual input and output--I would prefer a
> style like I used in my solution which aims for readable conciseness, while
> documenting what is going in and coming out of my functions. I assume
> Clojure developers reading my code will have a good understanding of the
> core data structures and functions available to manipulate them, and so I
> want to leverage that as much as possible in how I write and document my
> code.
>
> In fact, at this point I prefer using Prismatic's schema (
> https://github.com/Prismatic/schema) to document as well as provide
> further safety for my functions, and am of the opinion that Clojure's one
> glaring weakness is its approach to typing--but that's another discussion
> and I recognize this is not necessarily a widely-held opinion.
>
> More generally, I think reasonable people could disagree on naming
> conventions and so I would hesitate to say you're doing something "wrong"
> here--I would rather say: the more Clojure code you read the more you'll
> get a sense of how people tend to write. You'll figure out what you want
> to adopt in your own style, and what Clojure devs are going to expect.
>
> - I don't want to get too deep into the algorithm itself but I think you
> would find it more natural to work line by line vs. the way you constructed
> blocks and flipped them right/left, and you'd have less code overall. I
> will boldly claim that my solution may be closer to how other developers
> familiar with Clojure (or functional programming in general) may approach
> it--not that I'm claiming it's the best approach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a main function, and you don't see
> them in libraries, certainly. But that is minor--there's no reason *not*
> to use it, just that I wouldn't expect to see it.
>
> I hope this is useful feedback--good luck in your journey and enjoy
> Clojure!
>
> Dave
>
>
> 2014-12-06 19:48 GMT+09:00 Philip Schwarz <philip.joh...@googlemail.com
> <javascript:>>:
>
>> 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 clo...@googlegroups.com
>> <javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> 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+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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.
