I think all of James' points about the proven value of structuring an application primarily around data rather than a complex API are right on point. It is one of the things I love about the Clojure philosophy.
But there's nothing about the value of data-driven development that requires data lookups and data computations to be so different. There's plenty of room for Clojure to have continued evolution in this area and still preserve the essence of its approach. For example, consider that several years ago, Rich declared that Clojure would never have a simple mutable box. But lo and behold, now we have volatiles. Consider the rise of records, protocols, and components -- a lot of judiciously applied OOish concepts. I really enjoy introducing Java programmers to the Clojure way of thinking about data. But when I do, I like to explain the current thinking in the Clojure community, talk about some of the most triumphant success stories (e.g., Ring), acknowledge some of the pain points, talk about some of the ways that Clojure has grown to handle other data modeling pain points, and some of the ways that Clojure may continue to grow. -- 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.
