Identifying the requirements for "maintainable" is the key and as far as I know we as a software industry aren't close to solving it. Whilst programs are written by those bags opinionated, subjective and finicky bags of water known as people it will also be elusive as maintenance has to be at least "easy" to the current skill set. And that is the crux of the problem - "easy" changes over time based on resource, market trends, flavour of the month, corporate policy etc. I think there are some excellent resources to help; Rich Hickey's "Simple made easy", SOLID, DDD and so on, but in the large, nope. The closest solution I have seen is in those large corporate enterprises where everything is nailed down. In other words, "maintainability" and "creativity" are in a very unhelpful inverse relationship.
Oh, and as you say the fact nobody knows exactly what they meant until they have seen what you have built :). In terms of REPL and TDD, I find a really interesting property in my code, which may just be because I have been missing the point for the last decade of TDD (I know some people will claim that ;)), but I find that TDD can produce code that is very normalised to the problem at hand, where-as REPL driven code may be more generic and expressive of the problem domain. I find that sometimes REPL driven code contains more helpful context where-as TDD code can produce almost the minimal amount of code to solve a given problem. As I say, this is more to do with my particular style, but I would be interested if others found that. On 9 Dec 2014 05:06, "Leif" <leif.poor...@gmail.com> 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/zR5Ny7aoBM0/unsubscribe. > To unsubscribe from this group and all its topics, 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.
