Whoops, re-reading my post I realized that I simply linked to my own gist again when talking about separating out pure from side-effecting code. I meant to link here: https://github.com/philipschwarz/diamond-problem-in-clojure/blob/7efbc472632dced5e173084672ad76687e39dd1f/src/diamond_problem_in_clojure/core.clj#L68-L74
2014-12-06 22:36 GMT+09:00 David Della Costa <ddellaco...@gmail.com>: > 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.johann.schw...@googlemail.com>: > >> 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. >> > > -- 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.
