btw, my first impression when first looking at your solution is positive - 
the feeling I get is that I probably won't have problems understanding how 
it works

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.

Reply via email to