On 20 October 2014 17:08, Phillip Lord <phillip.l...@newcastle.ac.uk> wrote:
> James Reeves <ja...@booleanknot.com> writes: > > > Clojure prefers "simple" solutions over "easy" solutions. > > A nice aphorism sometimes, but content free in this case, I think. Well, no... The whole point is that "simple" and "easy" in this context have objective definitions. If you go by Rich's definition of "simple", then a value is *objectively* simpler than a function. So, there is this tourist, and he asks a local, "how do I get into > town". "Hmmm," says the local, "if I want to get into town, I wouldn't > start from here". > That makes perfect sense, *if* the tourist is making the trip *only once*. But that hardly applies in this case, because a documentation system will be used many times. So there's this business owner, and he asks a local, "What's the quickest route for my vehicles to get to town?" The local considers, and replies, "You'd be able to get into town much faster if your vehicles were stationed on the other side of town." A small context shift, and suddenly the local's advice is extremely useful. > Which is nice and simple, yes. And has negative consequences in terms of > extensibility. I understand if you are happy with this compromise. But > it is a compromise. > I don't disagree, but I do consider the compromise to be a minor one. UAP has huge disadvantages in terms of complexity, repetition, scalability, reliability, isolation, and a whole bunch of other things that Clojure is explicitly trying to avoid. On the other hand, I can't personally recall a situation where it would have actually been useful to me. Well, the question is, where does this additional complexity come from. > In Java, it results in enormous quantities of boilerplate get/set > methods. In Scala, these are autocoded away. > By "complexity" I'm again referring to Rich's more objective definition of the term. Complexity in this sense is a measurement of how many things can affect part of your program. An immutable value is the simple, because nothing can affect it. A pure function is more complex, because it's affected by its arguments, and a side-effectful function has even an greater complexity, because it can be affected by pretty much anything. The simple vs. easy idea is a short way of saying we should prioritise reducing coupling between components (simplicity), even at the cost of short term gains (easiness). - James -- 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.
