On 18 October 2014 08:28, Mark Engelberg <mark.engelb...@gmail.com> wrote:
> Yeah, it's hard to deny the convenience of Clojure's keyword lookups and > standard assoc mechanism for getting and setting stored values, but I think > Bertrand Meyer's Uniform Access Principle reflects some pretty deep > thinking about the kinds of complications that arise in maintaining large > programs. Although the Clojure community mostly rejects the Uniform Access > Principle right now, as people start writing larger programs in Clojure, > and need to maintain them for longer periods of time, it will be > interesting to see if the pendulum swings back in favor of uniform access. > You make it sound as if structuring an application around data, rather than APIs, is untested at scale. I'd argue the opposite: the only architecture we know works at scale is data driven. The largest systems we've developed, including the web itself, are data driven. Above a certain size, they have to be, due to latency and consistency concerns. Structuring a large system into isolated services that communicate with data is a tried and tested architecture. There may be a place for the Uniform Access Principle at the medium scale, where an application is large, but not so large it can't be hosted on one machine. I don't think the relative merits of data-driven vs. api-driven approaches has been proven at this scale. That said, I think there are reasons for betting on Clojure's approach. Ultimately it comes down to whether we try to *manage* complexity or *remove* complexity. The Uniform Access Principle falls in the former camp, along with OOP and encapsulation. They're tools to manage connections between components of a codebase. Clojure takes the more aggressive stance, and suggests that rather than managing complexity, we should be focused on getting rid of it wherever possible. For instance, where OOP languages try to manage state change though encapsulation, Clojure just removes mutable state entirely, or at least places it in confinement. Where complexity *can't* be removed, then we start to get Clojure code that begins to look similar to OO designs. Stuart Sierra's components, for instance, look somewhat similar to stripped-down objects. The difference in Clojure's approach is that these constructs are a last resort, rather than the norm. - 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.
