2016-02-02 20:41 GMT+01:00 kovas boguta <kovas.bog...@gmail.com>:
> XML is data, but its data that thwarts easy manipulation from a
> programming language. It doesn't cleanly map onto computational concepts.
>
How so? I mean, rolling key-value access and positional access into a
single data-structure, php-style, isn't the best idea in the world, but
it's not the worst either.
The real problem with XML starts where you can only store strings as
attribute values. This is even more constrained than JSON's
only-string-keys constraint, and leads to ambiguity in how to properly
encode maps.
Quick: how many ways can you represent key-value pairs in XML?
>
basically attributes, and child elements
but this is also the case in clojure:
{:key "value" ...} vs [:key "value" ...] vs [[:key "value"] ...]
Of course, its also a disaster from an efficiency point of view, since
> there is basically only 1 datastructure.
>
That's the same as saying: "Dynamic typing is an efficiency disaster,
because everything derives from the root class". True in a lot of cases,
but mostly irrelevant + mitigable by PICs and other
sufficiently-smart-compiler things.
To me the one-datastructure thing is just distasteful, because it reminds
me of PHP.
So to use XML, you often first need to convert it to something you can
> actually manipulate, and then back again (and there is no standard way to
> do this). With EDN these problems go away.
>
Well, show me an evaluator that directly operates on ascii-serialized EDN
(or even binary-serialized fressian) and I'll agree on this.
But I guess there isn't such thing. In most cases, the representation of
previously serialized data will be runtime-specific, even if it's just
PersistentVector vs ImmutableArrayList
Enough nitpicking. Ad. Topic:
To me, the real horror of XML is that it pretends to be
ascii-read/writable, but it's just horrible to eye-read and hand-write,
mainly because of the redundancy for start/end tags.
Ironically, this doesn't matter as much for data formats, because people
are happy to use tools to manipulate them. It does matter a lot for code,
because people hate generated source files.
Combine this with unclear mapping conventions, esoteric rules for quoting,
escaping and namespacing + the fact, that even the best XML editors (like
IntelliJ's, emacs' or chrome's devtools) feel quite clumsy
Then, there is also no unifying story for XML-based DSLs, each one has to
roll its own evaluator, and get all the details right, like lexical scope,
loops, performance, ... All while constantly fighting the urge to introduce
cute features just to go with the grain of the horrible base syntax.
Sure, EDN also has no builtin evaluator, but there is at least one
excellent REPL to work with first-class EDN values, then it also supports
arbitrary nesting of structures, there is paredit, .. the lack of those
things in XML adds up quickly.
--
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.
