On Thursday, December 10, 2015 at 4:40:49 AM UTC-6, Dan Kersten wrote: > > I write such code like this: > > (defn sdescriptive-name [] <many lines>) > (def my-atom (atom (descriptive-name))) > > Where descriptive-name would describe the data shape or purpose. > This way the atom is not obscured behind many lines of code and the > data-generation is factored into a testable function with a hopefully > self-documenting name. > > On Thu, 10 Dec 2015 at 10:27 Colin Yates <colin...@gmail.com <javascript:>> > wrote: > >> I know it is dangerous to make sweeping statements, but any solution to >> “a lot of code obscures meaning therefore do X” is often solving the wrong >> thing - the real problem is "a lot of code that obscures meaning” :-). >> >> I hope that doesn’t come across as condescending as I fear... >> > How dare you. :-)
No, feedback is always good. As a rule of thumb, I tend to agree, but there are tradeoffs. In this case the long string of let bindings are all similar, and are used to create an initial data structure that plays a central role in a simulation. Different simulations vary only by what's in this data structure. It's clearest to keep the bindings together in one place, and there's no reason to pollute the top level. Daniel's solution is a good one. I had the code set up that way at one point, and may go back to it. (Normally I store the data structure directly in a top-level variable, which is referenced only once at the beginning of simulation runs, and update the structure in a purely functional way. Because of interaction with another program in my current project, I now have to maintain the structure in a state variable that changes, so I've added the atom wrapper. Same kind of data structure as in the purely functional versions, though.) -- 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.
