I see the same issues/feel the same pain, but I attribute it much more to dynamic typing than data. Changing the API is always going to be expensive but without typing we pretty much to do it without tool support.
Even in Java and the magic of IDEs there is still pain - changing the return type of a method from one type to another is still painful - sure, the IDE will help with the impact analysis but you still have to work it through. I think the problem is more exposed as there isn't any indirection between the thing you want and the getting of the thing you want but yeah, changing API is hard. Nothing to stop your API being (defn get-a [m]) if you want that indirection, but that isn't idiomatic. Performance I can't comment about other than to say for the scale of projects I am involved with I haven't seen the performance as the bottleneck. On 2 February 2016 at 10:05, Mikera <mike.r.anderson...@gmail.com> wrote: > I share the same unease. I haven't quite fully been able to articulate all > the reasons, but here are the things that concern me most: > > 1) Completing the API for data access with the representation > > This is my biggest issue. Good practice IMHO is to keep APIs abstracted from > underlying implementation details. There are many cases where you may want > to change the underlying data representation without changing the API > (adding indexing functionality, changing a "stored" value to a "calculated" > value, caching of repeated values etc.) It is *really* annoying when you > want to change the internal representation but have the problem of breaking > all the callers who have hard-coded assumptions about the structure. > > 2) Refactoring challenges > > It's pretty easy to refactor Java code with modern IDEs - changing method > names, updating all references etc. Doing this in Clojure when everything is > represented in nested data structures is a tricky task, because you > typically don't have the ability to catch all uses of a particular part of a > data structure. I've lost count of the number of times I have had > hard-to-track bugs because of changed keywords etc. > > This is less of an issue in small projects, but a much bigger issue once you > have a large project that passed complex values between subsystems. > > Furthermore, given that Clojure is a dynamically typed language, you > typically have more tests to compensate for the lack of type safety being > enforced by the compiler. Refactoring costs become even greater when you > need to refactor a large number of tests as well. > > 3) Performance > > If you express everything in nested data structures, you end up paying > significant performance overheads > a) Lack of fast type-based dispatch (you can use defrecord / protocols, but > then you are going the way of typed records anyway... so it isn't really > pure data) > b) Validation at runtime of deeply nested structures is expensive. You often > have to walk the entire tree to ensure compliance with a specific schema > c) Inherent overheads of boxing numbers. Less of a big deal for business > domain objects, but problematic for the data scientists among us. > d) If your data structure represents "operations" you effectively need to > write an "interpreter" to execute these. I'd rather have fast compiled code > :-) > e) The JVM is very good at optimising method calls / object access access > when it knows the types. With everything as "Object"... less so. You end up > with lots of casts and instance checks. > > Don't get me wrong, I think that immutable data as values are a great thing > overall. But I would urge caution about an ideological crusade to "data all > the things". > > > On Tuesday, 2 February 2016 06:02:23 UTC+8, Josh Tilles wrote: >> >> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: >> Distributed Computing for Clojure”, I'm distracted by a nagging worry that >> we —as a community— are somehow falling into the same trap as the those >> advocating XML in the early 2000s. That said, it's a very vague unease, >> because I don’t know much about why the industry seems to have rejected XML >> as “bad”; by the time I started programming professionally there was already >> a consensus that XML sucked, and that libraries/frameworks that relied >> heavily on XML configuration files were to be regarded with suspicion and/or >> distaste. >> >> So, am I incorrect in seeing a similarity between the “data > code” >> mentality and the rise of XML? Or, assuming there is a legitimate parallel, >> is it perhaps unnecessary to be alarmed? Does the tendency to use edn >> instead of XML sidestep everything that went wrong in the 2000s? Or is it >> the case that the widespread backlash against XML threw a baby out with the >> bathwater, forgetting the advantages of data over code? >> >> Cheers, >> Josh > > -- > 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. -- 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.
