Philip, one clarification--re: function with side-effects, I meant to link here, which I followed up with in a later post, but I think it got lost in the shuffle:
https://github.com/philipschwarz/diamond-problem-in-clojure/blob/7efbc472632dced5e173084672ad76687e39dd1f/src/diamond_problem_in_clojure/core.clj#L68-L74 The function "print-diamond" is both generating the diamond data structure (which is just a series of pure functions) but then at the end it prints out the diamond via display--this is a side effect. The function itself returns nil. So my point was that I would prefer a separate pure function to handle generating the entire diamond, which would return that data structure at the end. Then I could use this in conjunction with a side-effecting function to print, to save to a file, etc. Dave 2014-12-13 13:40 GMT+09:00 Philip Schwarz < philip.johann.schw...@googlemail.com>: > > HI David, > > >> - 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. > > > Makes perfect sense: "isolating your pure functions from your > side-effecting code as a sort of basic separation" > What do you mean by this: ", and avoid monolithic functions like the one I > linked to above. ". I ask because I think there are no side effects in my > code. Maybe I don't understand because it is 4.30 am and I am not fully > awake, or maybe you intend a different meaning for side effect. > > 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>: >> >>> 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 >>> 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 >>> 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. >>> 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. > -- 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.
