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” > <https://youtube.com/watch?v=YlfA8hFs2HY&t=734>, 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.
