I think the message is 'data doesn't have to be code' not 'code should
be expressed in data' which is significantly different. XML went wrong
because people tried to write code in XML.
Nobody (I think) is saying explicitly that we should write code, logic
etc. as data only that there is no need to wrap data in code.
Of course, Clojure's/Lisps homoiconicity means the _expression_ of
code is the same _expression_ as data so code can be treated as data.
In concrete terms, sure, XML (and YAML etc.) all tried to capture
logic which failed, that isn't what is being recommended in Clojure.
(if (some-pred? a) (do-this a) (do-that a))
is code that can be treated as data. Where it would go horribly wrong
is if you started trying to impose a DSL on top of this:
{:predicate #(some-pred? a) :predicate-match #(do-this a)
:predicate-fail #(do-that a)}
which is analogous (I think) to where XML etc. went down the rabbit hole.
On 2 February 2016 at 10:05, Mikera <[email protected]> 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 [email protected]
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> [email protected]
> 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 [email protected].
> 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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
