+1. Two years ago we went all data driven here. We stripped the code size and complexity by a huge factor. All data encapsulation code was sent to the trash can.
Our processing is driven by data more than by code. We ended up with a significant increase in generic code not linked to the business domain and the rest is made up mostly of DSLs. What a relief.... Luc P. > 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. > -- Luc Préfontaine<lprefonta...@softaddicts.ca> sent by ibisMail! -- 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.
