On Mon, Feb 1, 2016 at 4:02 PM, Josh Tilles <merelyapseudo...@gmail.com> 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. > XML was expressly designed for documents and it really has no competition for serious, professional documentation work. It's when people started using it to encode data and code that bad things started to happen. Classic example of using the wrong tool for the job. > 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? > It's unnecessary to be alarmed. Of course, you can misuse Clojure/edn just like you can misuse anything, but there's really no comparison with XML. Don't forget that maps, keywords, etc. may look like data but they're really functions - you can treat {} as a data constructor or a (finite) function constructor. Or maybe it would be more accurate to say that the distinction between code and data has always been a side effect of language designs and implementations, and Clojure goes a long way toward eliminating it. I'm not sure what you mean by "data > code mentality", but these days I often find myself going in the other direction - thinking of my data in terms of functions and protocols. With Clojure you can do the right thing, whatever works best for the problem at hand. -Gregg -- 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.
