I have suffered the exact same problem in large projects. Clojure's associative style is extremely powerful and simple, together with powerful sequence handling functions you could hurt yourself. The fact that it's really easy to put together nested maps to represent your models, shouldn't be an excuse for lack of abstraction. In particular I have found that the Law of Demeter can be applied to a certain degree to nested clojure maps:
(-> car :wheels first :tire :pressure) This probably lacks abstraction, calling code needs to know every details about how to get the pressure starting from a car model. If at some point you decide to change your implementation and turn :wheels into a map instead of a list/vector, your code is broken. As always, it's a compromise between easy of use and resilience to change. One of the most important things you loose when you use accessor functions is map destructuring. I'm still learning in my large clojure projects the art of deciding when some code is "too short to be true". I'd love to hear other opinions on the subject. -- 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