To understand the XML problem you have to understand Java in the 2000s.
Java was a very limited language, and it was extremely verbose. There were
type declarations and coersions everywhere. Almost all looping was managed
with for loops (there were no higher order functions, and recursion wasn't
tail cail optimized... also there was no loop-recur macro...).
So XML wasn't just there to be data, it was also code.
Everyone wrote little mini-languages into XML, because some things were so
damn painful to express in Java that it was easier to just implement a
small interpreter in Java for XML. The XML sections of Java projects become
massive often dwarfing the Java code on the project. I've worked on
projects that had more than 10x as much XML as Java code, and I don't think
my experience was an outlier.
So, when people started writing their code in XML, they essentially threw
out all the protections they had for their compilers, and wound up using
the most buggy, leaky little DSLs that ever were.
And even worse, they were damn near impossible to read, because it was XML.
XML is not easily readable. It has duplication baked in as you have to
declare the name of each node twice. It didn't just map simply to
S-expressions, because attributes were a thing.
As it became more and more ungainly and difficult to work with, people
started throwing clever little jQuery-like libraries at it to make it
simpler. Libraries like XPATH and others that were all quite complicated
and had a learning curve all their own. And of course lots of companies had
their own little DSLs that did the same thing as standardized libraries
like XPATH but were really buggy and screwed up but were so ingrained in
the project that removing them was seen as a non-option.
In short, the problem with XML was that XML was code as data as code
implemented in the worst possible way. It was there to fix a lack of
expressivity in the host langauge Java, and it was baked into a Markdown
Language with its own compexities and subtle rules. XML was not a first
class entity in Java either, so its manipulation was painful as hell. You
couldnt just embed a little XML in your class, you had to read a fucking
file in using the horrible decorator based input/output system in Java...
Things got a lot easier when people moved to JavaScript and JSON, both
because JavaScript is more expressive and JSON is far simpler than XML to
read and manipulate programatically. And they got easier again for me when
I moved to Clojure. 95% of the things I might have used XML for in the past
can be done in Clojure without dropping into a code as data approach, and
when I do try some kind of code as data approach, its usually just writing
a little literal edn that gets parsed by a function.
TLDR: The two really aren't comparable. Code as data is a way of getting
things done, and code as data in Java/XML was about being able to actually
get things done, no one did it because they liked it, they did it because
those horrible project abominations were the shortest path for that
tool-chain at the time, whereas code as data in Clojure is about accepting
that code as data is a core part of programming, and making it a front and
center piece of the language with excellent support such that when you need
to use it, its painless.
This question is a lot like asking why recursion makes sense as a language
feature when you've heard that projects that emulated recursion in some
really primitive language using pointer arithmetic had a really difficult
time with it, and you wanted to make sure that your project avoided the
"problems with recursion" that those projects faced in a language where
recursion is a primary language feature.
On Mon, Feb 1, 2016 at 7:37 PM, Sean Corfield <s...@corfield.org> wrote:
> Josh Tilles wrote on Monday, February 1, 2016 at 2:02 PM:
>
> So, am I incorrect in seeing a similarity between the “data > code”
> mentality and the rise of XML?
>
>
> I see it as the difference between:
>
> {:name "Sean" :age 52}
>
> And:
>
> public class Person {
> private String name;
> private Long age;
> public Person( String name, Long age ) {
> setName( name );
> setAge( age );
> }
> public String getName() { return this.name; }
> public Long getAge() { return this.age; }
> public void setName( String name ) { this.name = name; }
> public void setAge( Long age ) { this.age = age; }
> }
>
> Even if you made Person a value class by removing the setters, that’s a
> lot of code obscuring a simple data structure. And with the data structure,
> you can use any Clojure sequence function or hash map function, whereas
> with a Person type, you’re stuck with the API presented.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
> --
> 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.
