7 ms·

XML is not S-Expressions

35 points by yters 18y ago

11ren 18y ago
I have a corollary to Greenspun's Tenth Law, which is that: Lisp programmers see everything in terms of as an ad hoc, informally-specified, bug-ridden, slow implementation of half of Lisp, and don't see other benefits it might have. That is, Greenspun's Tenth Law is true - for Lisp programmers. I came to this conclusion because of a tragic pair of research papers, which had a fantastic usability idea. The second half of the first paper took the focus off the usability, and developed it into a very simple functional language. In their next paper, they dropped the fantastic usability idea completely, and made it into a lisp. :-( Some XML standards fell into a similar trap, by wanting languages that process XML to be themselves written in XML - such as XSLT. It's a nice abstract concept to be able to process yourself... but at the price of abominations like "i < 10". Adam Bosworth pointed out that XML's XPath resisted this - by making XPath itself an embedded non-XML mini-language. Imagine an XML representation of path components - now that would be verbose! In a politically expedient move, I'd like to point out that pg didn't fall into this trap: he made the DSL for users of Viaweb to customize their store to not be lisp (though an easily mapped subset, if I understand correctly.) It's a non-lisp mini-language. Great link from the article, about "principle of least power", for mini-languages: http://www.w3.org/DesignIssues/Principles.html#PLP http://www.w3.org/DesignIssues/Principles.html#PLP Constraints are very empowering, because you know what to expect. Regarding XML: I'd always thought it was just one of many possible syntaxes for representing hierarchical data; and it really didn't matter which syntax you used. As in a lingua franca (or any standard), provided that it is barely adequate, the key thing is that everyone agrees on it. XML became the Chosen, de facto standard, because everyone was already familiar with HTML, propelled by the mass adoption of the web. So the question becomes: why did we get HTML (based on SGML), instead of S-expressions? The article gives reasons, but I guess the short of it is that if a group of people work towards a specific purpose for years, and are successful at it (as SGML was), it is probably a good base to start from if you want to do something similar, i.e. describe documents. Also, more directly, if I imagine a large webpage described with S-expressions, I think HTML is a bit clearer. Nitpick: The article omits that quotes (or apostrophes) must be escaped in XML attributes. Very telling points about LaTeX - that like XML/HTML, it also uses named end-tags; and that Lisp documentation itself is used LaTeX instead of S-expressions - drinking their kool-aid; but not eating their dog-food.
- anamax 18y ago
  > Very telling points about LaTeX - that like XML/HTML No, it's a demonstration of ignorance. LaTeX wasn't written by Lispers, it is merely used by them. The fact that they find its design decisions acceptable must be weighed against the cost of their alternatives. That doesn't imply that they wouldn't have been happier with a more lispish syntax. At the time that those decisions were made, LaTeX was pretty much the best alternative. The fact that Lispers, like almost everyone else in related communities, made that decision merely says that Lispers don't cut off their noses to spite their face.
  - 11ren 18y ago
    The article suggests Lispers could have used sexp as a front-end to LaTeX, in the same way that XML was used as a front-end to LaTeX. Very easy to do. > If S-expressions were easier to edit, it would be most logical to edit the document in S-expressions and then write a small Scheme program to convert S-expressions into a formatting language like LaTeX. This is, what XML and SGML people have done for decades [...]
    - anamax 18y ago
      > The article suggests Lispers could have used sexp as a front-end to LaTeX (1) As another comment points out, they have when doing so provided benefits. (2) Lispers tend to be multi-lingual; they'll use other languages when appropriate. If XMLers can only work in XML.... >This is, what XML and SGML people have done for decades Decades? 20 years/two decades ago is 1988. The first draft of XML is roughly 1998/10 years later/one decade ago. GML, a predecessor to SGML, didn't become public until 73 but the "multiple use" stuff was still in the future. SGML rode the WWW wave, but that didn't happen for technical reasons.
    - gruseom 18y ago
      The article suggests Lispers could have used sexp as a front-end to LaTeX How does he know they didn't?
    - anamax 18y ago
mindslight 18y ago
XML definitely adds features over sexps, and is good for adding markup to primarily text-based documents, where the concept of bare text has an intuitive meaning, and elements denote a formally defined machine-readable layer on top. However, the fight occurs when XML is used as a generic serialization format, or even as syntax for a programming language. There, the features only add redundant complexity (what does unquoted text mean in an ant build file? why am I putting quotes around identifiers, and why am I including the redundant end tags when my editor indents for structure?). When your format already has specific semantics, the wiggle room between element/attribute/text only adds inflexible accidental complexity.
- 11ren 18y ago
  JSON is another contestant in the generic data serialization space, which is doing better than sexp - possibly due to the ubiquity of javascript (free-riding the web). Though, for this technology generation, the fight is over. I think there'll be another chance when SOA/web services are superseded; but there's still huge scope for improvement within their present architecture/ecosystem (e.g. REST vs. SOAP vs. ?). For programming languages, sexps are competing against all the other language syntaxes out there, not just XML. I agree that it seems odd that ant uses XML though... perhaps the extensibility of ant is easier with some kind of generic format (like XML/sexp/JSON)? yet other languages manage to be extensible via functions/classes/modules etc. Thank goodness no one uses JSON to encode a language (in the way that ant uses XML).
  - michaelneale 18y ago
    I am thinking ant did it to get the parser and some kind of tools for free. Certainly no one really likes it as XML.
    - mindslight 18y ago
      I don't know the ant specifics, but I'd surmise that one starts off thinking of a simple declarative format (we've got some targets, that depend on other targets, which is just a simple tree, and perhaps we can write various analysis tools later). Then of course as time goes on, it gets more general purpose language features (symbol bindings, conditionals, etc), and adopts an ever more procedural feel (especially in the case of a build system, which essentially all about mutating filesystem state). Since these features weren't designed from the start, you end up with rifts, such as between ant "attributes" and "properties", which don't really tax the ant gurus, just the casual users and newcomers. Seems that it would be easier to write a build system as an embedded DSL in a general purpose language to begin with, and when further analysis tools wanted to be written, make the necessary changes (meanwhile old build scripts run just fine using the old library). But then again, it's much easier to criticize with hindsight than to design a system that becomes popular.
Hexstream 18y ago
"The XML one does not use standard human-punctuation characters as markup. It doesn't require quoting of apostrophes, double quotes or parentheses." (:p "Lisp doesn't require quoting of apostrophes (') or parentheses (()) either...")
jodrellblank 18y ago
He makes some good points that I didn't consider when first I hated upon XML. I agree that XML is better for its problem domain than s-expressions, but in that case the whole article is an apples to oranges comparison. He claims that syntax is important, otherwise we'd still be using binary formats. If that's true then the only reason syntax is important is for humans, because machines can read binary formats just as well as anything else. So why compare it to s-expressions instead of to a human-friendly ideal? Is XML the best human-friendly markup language possible? Yes his paragraph is similarly readable in both forms, but would it be if wrapped in XML namespace clauses and an XML Schema? Would the s-expression version be if wrapped in a macro to parse text outside quotes as significant text? The purpose of XML shouldn't be to make everything more XML-y, but to make everything easier. Maybe it does, in big enterprisey systems and between large data silos. Look at the recent ODF v. Office XML file formats. Have any of you been tempted to process Microsoft Office documents directly because now they're XML they must be easier than the old binary formats? It's still not human friendly - you can't use the Jabber protocol by hand over telnet like you can use POP3, SMTP, IRC.
- 11ren 18y ago
  > you can't use the Jabber protocol by hand over telnet like you can use POP3, SMTP, IRC. There's an intriguing view that text can't be used by hand either - you have to use a "text shell". Wouldn't a fair comparison use an "XML shell"? If it knew the schema, it could even autocomplete/intellisense for you, showing you the available choices at that point... it's pretty cool how XML has factored out the grammar of a language, in a reusable way. I don't know the Jabber protocol, but the difficulty I've experienced with web-based XML protocols (web services) is that the http header needs the length of the message, which is hard to do by hand - it's not due to XML (and a "http shell" would fix that...)
  - hassy 18y ago
    http-twiddle mode for Emacs is handy for tinkering with web-based XML stuff: http://github.com/hassy/http-twiddle/ http://github.com/hassy/http-twiddle/
- 18y ago
gruseom 18y ago
The article is refuted by both reality -- the godawful messes that people have made out of XML, the complexity of the systems built on top of it, its failure to amount to more than a bloated machine format, and the exodus in favor of more lightweight notations like JSON -- as well as by itself: the author expects the reader to consider the proliferation of single-shot technologies built on XML as a good thing and not a Tower of Babel. He lists DTDs, RELAX, XML Schema, XPointer, XQuery, XPath (edit: whoops, I snuck that one in), XSLT, and CSS and cites the "decades of person-effort embodied in those specifications" as if it were an argument in their favor! I found this statement in the article interesting: "The central idea of the XML family of standards is to separate code from data." It explains why all the systems that express programming constructs in XML are such monstrosities (including XSLT, which he cites approvingly and yet which totally violates this separation). I wonder what the author would say to the people who do this kind of thing? They're not using it according to specification? Edit: some of the arguments are out of date, too. I don't know anything about Lisp documentation in LaTeX; the open-source Lisp world tends to generate HTML documentation from s-expressions, as for example here: http://www.weitz.de/cl-ppcre/ http://www.weitz.de/cl-ppcre/.
- 11ren 18y ago
  Do you have references for that exodus? By Google, XML is winning 50 to 1 - but declining, and JSON is growing: http://www.google.com/trends?q=xml%2C+json&ctab=0 http://www.google.com/trends?q=xml%2C+json&ctab=0 However, a factor is that people already know about XML and don't need to search for it. e.g. HTML is declining even faster: http://www.google.com/trends?q=xml%2C+json%2C+HTML&ctab=0&geo=all&date=all&sort=0 http://www.google.com/trends?q=xml%2C+json%2C+HTML&ctab=...
  - gruseom 18y ago
    Ooh, duelling URLs, can I play? :) http://www.google.com/trends?q=xml%2C+javascript http://www.google.com/trends?q=xml%2C+javascript Do you have references for that exodus? Not really. I'm talking about what I observe in the hacker world, which is a thoroughgoing trend away from XML. Do you really see it otherwise? It's not all going to JSON of course. Most of the XML stuff is in big enterprise projects and, for some value of "count", those just don't count. Last I checked the IT pundits were declaring SOA dead, after having milked it for a decade.
anamax 18y ago
From the article: "Nor is it an accident of history that Lisp programmers never came up with these technologies for Lisp data. The central idea of the XML family of standards is to separate code from data. The cental idea of Lisp is that code and data are the same and should be represented the same." No, that's not the central idea of lisp. The closest "central idea of lisp" is that code should have a standard and convenient representation so it can be readily manipulated by programs. Lispers separate application code from application data. They do so even when the application data is a program.... It is true that Lisper's didn't engage in years of meta-whinging and defining transform languages, but the fact that the XML folk did was more of an accident of history. When the Semantic Web hype was in full-swing, the Lispers were still licking their wounds from the AI winter. And, how is that Semantic Web coming along? Pretty much where the Lisper's left it....
echair 18y ago
...but it would be better if it were.
jbert 18y ago
No love for the binary formats? Let's hear it for ASN.1 (http://en.wikipedia.org/wiki/ASN.1 http://en.wikipedia.org/wiki/ASN.1), so good that google can reinvent it as protocol buffers (http://code.google.com/apis/protocolbuffers http://code.google.com/apis/protocolbuffers) and get people interested. More seriously, yes, binary formats have their problems. And ASN.1 in particular suffered/suffers from being pre-unicode (and thus having a number of different + mostly useless character set types). But it seems to me that this nested tag-length-value structure (ASN.1 and protocol buffers) occupies a design sweet spot.
wingo 18y ago
I'm surprised no-one mentioned SXML, Kiselyov's representation of XML in Scheme. His paper, "A better XML parser through functional programming", can be found here: http://okmij.org/ftp/papers/XML-parsing.ps.gz http://okmij.org/ftp/papers/XML-parsing.ps.gz. The introduction covers the difficulty of parsing XML fairly well, which is another way of saying that XML does have a fairly complex "model" behind it that Lispers often ignore.
- anamax 18y ago
  Lisper's know that XML has a fairly complex model behind it. That's part of the argument against XML because the complexity doesn't seem to buy much.
voidpointer 18y ago
I think when arguing about XML, many people forget its relationship to SGML. Many of the drawbacks in XML are design decisions made in order to maintain backwards compatibility with SGML tools that were in use when XML was devised. In order to simplify parsing (and in order to enable parsing a well formed document without knowing its DTD), XML threw out much of the syntactic sugar that SGML had to offer such as implicitly closed tags. I.e. Many people think that <tr><td>foo<td>bar... is invalid HTML because of missing </td>. In fact, it is perfectly valid because the HTML (SGML-)DTD specifies that a <td>-tag implicitly closes a preceding <td>. Most think it's a browser-hack. It is not. What both XML (and SGML) add over S-EXPR is support for expressing grammers, a well-defined validation mechanism and quite good support for coping with different character encoding.
asciilifeform 18y ago
Erik Naggum on XML vs. S-Expressions: "They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. Robbery is not just another way of making a living, rape is not just another way of satisfying basic human needs, torture is not just another way of interrogation. And XML is not just another way of writing S-exps. There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished." (http://www.schnada.de/grapt/eriknaggum-xmlrant.html http://www.schnada.de/grapt/eriknaggum-xmlrant.html)
- eru 18y ago
  Pretty strong words for such a trifle.
  - asciilifeform 18y ago
    Yet it is not a trifle. Wasting what might amount to thousands of man-years by forcing talented people (who might otherwise accomplish something meaningful) to build workarounds for an inferior technology is every bit as criminal as, say, embezzlement.
    - eru 18y ago
      By the same logic, QWERTY forcing talented people to develop RSI should get the same treatment..
      - asciilifeform 18y ago
        I can see no reason why not.

35 points by yters 18y ago

11ren 18y ago

I have a corollary to Greenspun's Tenth Law, which is that: Lisp programmers see everything in terms of as an ad hoc, informally-specified, bug-ridden, slow implementation of half of Lisp, and don't see other benefits it might have. That is, Greenspun's Tenth Law is true - for Lisp programmers. I came to this conclusion because of a tragic pair of research papers, which had a fantastic usability idea. The second half of the first paper took the focus off the usability, and developed it into a very simple functional language. In their next paper, they dropped the fantastic usability idea completely, and made it into a lisp. :-( Some XML standards fell into a similar trap, by wanting languages that process XML to be themselves written in XML - such as XSLT. It's a nice abstract concept to be able to process yourself... but at the price of abominations like "i < 10". Adam Bosworth pointed out that XML's XPath resisted this - by making XPath itself an embedded non-XML mini-language. Imagine an XML representation of path components - now that would be verbose! In a politically expedient move, I'd like to point out that pg didn't fall into this trap: he made the DSL for users of Viaweb to customize their store to not be lisp (though an easily mapped subset, if I understand correctly.) It's a non-lisp mini-language. Great link from the article, about "principle of least power", for mini-languages: http://www.w3.org/DesignIssues/Principles.html#PLP http://www.w3.org/DesignIssues/Principles.html#PLP Constraints are very empowering, because you know what to expect. Regarding XML: I'd always thought it was just one of many possible syntaxes for representing hierarchical data; and it really didn't matter which syntax you used. As in a lingua franca (or any standard), provided that it is barely adequate, the key thing is that everyone agrees on it. XML became the Chosen, de facto standard, because everyone was already familiar with HTML, propelled by the mass adoption of the web. So the question becomes: why did we get HTML (based on SGML), instead of S-expressions? The article gives reasons, but I guess the short of it is that if a group of people work towards a specific purpose for years, and are successful at it (as SGML was), it is probably a good base to start from if you want to do something similar, i.e. describe documents. Also, more directly, if I imagine a large webpage described with S-expressions, I think HTML is a bit clearer. Nitpick: The article omits that quotes (or apostrophes) must be escaped in XML attributes. Very telling points about LaTeX - that like XML/HTML, it also uses named end-tags; and that Lisp documentation itself is used LaTeX instead of S-expressions - drinking their kool-aid; but not eating their dog-food.

anamax 18y ago
> Very telling points about LaTeX - that like XML/HTML No, it's a demonstration of ignorance. LaTeX wasn't written by Lispers, it is merely used by them. The fact that they find its design decisions acceptable must be weighed against the cost of their alternatives. That doesn't imply that they wouldn't have been happier with a more lispish syntax. At the time that those decisions were made, LaTeX was pretty much the best alternative. The fact that Lispers, like almost everyone else in related communities, made that decision merely says that Lispers don't cut off their noses to spite their face.
- 11ren 18y ago
  The article suggests Lispers could have used sexp as a front-end to LaTeX, in the same way that XML was used as a front-end to LaTeX. Very easy to do. > If S-expressions were easier to edit, it would be most logical to edit the document in S-expressions and then write a small Scheme program to convert S-expressions into a formatting language like LaTeX. This is, what XML and SGML people have done for decades [...]
  - anamax 18y ago
    > The article suggests Lispers could have used sexp as a front-end to LaTeX (1) As another comment points out, they have when doing so provided benefits. (2) Lispers tend to be multi-lingual; they'll use other languages when appropriate. If XMLers can only work in XML.... >This is, what XML and SGML people have done for decades Decades? 20 years/two decades ago is 1988. The first draft of XML is roughly 1998/10 years later/one decade ago. GML, a predecessor to SGML, didn't become public until 73 but the "multiple use" stuff was still in the future. SGML rode the WWW wave, but that didn't happen for technical reasons.
  - gruseom 18y ago
    The article suggests Lispers could have used sexp as a front-end to LaTeX How does he know they didn't?
  - anamax 18y ago

mindslight 18y ago

XML definitely adds features over sexps, and is good for adding markup to primarily text-based documents, where the concept of bare text has an intuitive meaning, and elements denote a formally defined machine-readable layer on top. However, the fight occurs when XML is used as a generic serialization format, or even as syntax for a programming language. There, the features only add redundant complexity (what does unquoted text mean in an ant build file? why am I putting quotes around identifiers, and why am I including the redundant end tags when my editor indents for structure?). When your format already has specific semantics, the wiggle room between element/attribute/text only adds inflexible accidental complexity.

11ren 18y ago
JSON is another contestant in the generic data serialization space, which is doing better than sexp - possibly due to the ubiquity of javascript (free-riding the web). Though, for this technology generation, the fight is over. I think there'll be another chance when SOA/web services are superseded; but there's still huge scope for improvement within their present architecture/ecosystem (e.g. REST vs. SOAP vs. ?). For programming languages, sexps are competing against all the other language syntaxes out there, not just XML. I agree that it seems odd that ant uses XML though... perhaps the extensibility of ant is easier with some kind of generic format (like XML/sexp/JSON)? yet other languages manage to be extensible via functions/classes/modules etc. Thank goodness no one uses JSON to encode a language (in the way that ant uses XML).
- michaelneale 18y ago
  I am thinking ant did it to get the parser and some kind of tools for free. Certainly no one really likes it as XML.
  - mindslight 18y ago
    I don't know the ant specifics, but I'd surmise that one starts off thinking of a simple declarative format (we've got some targets, that depend on other targets, which is just a simple tree, and perhaps we can write various analysis tools later). Then of course as time goes on, it gets more general purpose language features (symbol bindings, conditionals, etc), and adopts an ever more procedural feel (especially in the case of a build system, which essentially all about mutating filesystem state). Since these features weren't designed from the start, you end up with rifts, such as between ant "attributes" and "properties", which don't really tax the ant gurus, just the casual users and newcomers. Seems that it would be easier to write a build system as an embedded DSL in a general purpose language to begin with, and when further analysis tools wanted to be written, make the necessary changes (meanwhile old build scripts run just fine using the old library). But then again, it's much easier to criticize with hindsight than to design a system that becomes popular.

Hexstream 18y ago

"The XML one does not use standard human-punctuation characters as markup. It doesn't require quoting of apostrophes, double quotes or parentheses." (:p "Lisp doesn't require quoting of apostrophes (') or parentheses (()) either...")

jodrellblank 18y ago

He makes some good points that I didn't consider when first I hated upon XML. I agree that XML is better for its problem domain than s-expressions, but in that case the whole article is an apples to oranges comparison. He claims that syntax is important, otherwise we'd still be using binary formats. If that's true then the only reason syntax is important is for humans, because machines can read binary formats just as well as anything else. So why compare it to s-expressions instead of to a human-friendly ideal? Is XML the best human-friendly markup language possible? Yes his paragraph is similarly readable in both forms, but would it be if wrapped in XML namespace clauses and an XML Schema? Would the s-expression version be if wrapped in a macro to parse text outside quotes as significant text? The purpose of XML shouldn't be to make everything more XML-y, but to make everything easier. Maybe it does, in big enterprisey systems and between large data silos. Look at the recent ODF v. Office XML file formats. Have any of you been tempted to process Microsoft Office documents directly because now they're XML they must be easier than the old binary formats? It's still not human friendly - you can't use the Jabber protocol by hand over telnet like you can use POP3, SMTP, IRC.

11ren 18y ago
> you can't use the Jabber protocol by hand over telnet like you can use POP3, SMTP, IRC. There's an intriguing view that text can't be used by hand either - you have to use a "text shell". Wouldn't a fair comparison use an "XML shell"? If it knew the schema, it could even autocomplete/intellisense for you, showing you the available choices at that point... it's pretty cool how XML has factored out the grammar of a language, in a reusable way. I don't know the Jabber protocol, but the difficulty I've experienced with web-based XML protocols (web services) is that the http header needs the length of the message, which is hard to do by hand - it's not due to XML (and a "http shell" would fix that...)
- hassy 18y ago
  http-twiddle mode for Emacs is handy for tinkering with web-based XML stuff: http://github.com/hassy/http-twiddle/ http://github.com/hassy/http-twiddle/
18y ago

gruseom 18y ago

The article is refuted by both reality -- the godawful messes that people have made out of XML, the complexity of the systems built on top of it, its failure to amount to more than a bloated machine format, and the exodus in favor of more lightweight notations like JSON -- as well as by itself: the author expects the reader to consider the proliferation of single-shot technologies built on XML as a good thing and not a Tower of Babel. He lists DTDs, RELAX, XML Schema, XPointer, XQuery, XPath (edit: whoops, I snuck that one in), XSLT, and CSS and cites the "decades of person-effort embodied in those specifications" as if it were an argument in their favor! I found this statement in the article interesting: "The central idea of the XML family of standards is to separate code from data." It explains why all the systems that express programming constructs in XML are such monstrosities (including XSLT, which he cites approvingly and yet which totally violates this separation). I wonder what the author would say to the people who do this kind of thing? They're not using it according to specification? Edit: some of the arguments are out of date, too. I don't know anything about Lisp documentation in LaTeX; the open-source Lisp world tends to generate HTML documentation from s-expressions, as for example here: http://www.weitz.de/cl-ppcre/ http://www.weitz.de/cl-ppcre/.

11ren 18y ago
Do you have references for that exodus? By Google, XML is winning 50 to 1 - but declining, and JSON is growing: http://www.google.com/trends?q=xml%2C+json&ctab=0 http://www.google.com/trends?q=xml%2C+json&ctab=0 However, a factor is that people already know about XML and don't need to search for it. e.g. HTML is declining even faster: http://www.google.com/trends?q=xml%2C+json%2C+HTML&ctab=0&geo=all&date=all&sort=0 http://www.google.com/trends?q=xml%2C+json%2C+HTML&ctab=...
- gruseom 18y ago
  Ooh, duelling URLs, can I play? :) http://www.google.com/trends?q=xml%2C+javascript http://www.google.com/trends?q=xml%2C+javascript Do you have references for that exodus? Not really. I'm talking about what I observe in the hacker world, which is a thoroughgoing trend away from XML. Do you really see it otherwise? It's not all going to JSON of course. Most of the XML stuff is in big enterprise projects and, for some value of "count", those just don't count. Last I checked the IT pundits were declaring SOA dead, after having milked it for a decade.

anamax 18y ago

From the article: "Nor is it an accident of history that Lisp programmers never came up with these technologies for Lisp data. The central idea of the XML family of standards is to separate code from data. The cental idea of Lisp is that code and data are the same and should be represented the same." No, that's not the central idea of lisp. The closest "central idea of lisp" is that code should have a standard and convenient representation so it can be readily manipulated by programs. Lispers separate application code from application data. They do so even when the application data is a program.... It is true that Lisper's didn't engage in years of meta-whinging and defining transform languages, but the fact that the XML folk did was more of an accident of history. When the Semantic Web hype was in full-swing, the Lispers were still licking their wounds from the AI winter. And, how is that Semantic Web coming along? Pretty much where the Lisper's left it....

echair 18y ago

...but it would be better if it were.

jbert 18y ago

No love for the binary formats? Let's hear it for ASN.1 (http://en.wikipedia.org/wiki/ASN.1 http://en.wikipedia.org/wiki/ASN.1), so good that google can reinvent it as protocol buffers (http://code.google.com/apis/protocolbuffers http://code.google.com/apis/protocolbuffers) and get people interested. More seriously, yes, binary formats have their problems. And ASN.1 in particular suffered/suffers from being pre-unicode (and thus having a number of different + mostly useless character set types). But it seems to me that this nested tag-length-value structure (ASN.1 and protocol buffers) occupies a design sweet spot.

wingo 18y ago

I'm surprised no-one mentioned SXML, Kiselyov's representation of XML in Scheme. His paper, "A better XML parser through functional programming", can be found here: http://okmij.org/ftp/papers/XML-parsing.ps.gz http://okmij.org/ftp/papers/XML-parsing.ps.gz. The introduction covers the difficulty of parsing XML fairly well, which is another way of saying that XML does have a fairly complex "model" behind it that Lispers often ignore.

anamax 18y ago
Lisper's know that XML has a fairly complex model behind it. That's part of the argument against XML because the complexity doesn't seem to buy much.

voidpointer 18y ago

I think when arguing about XML, many people forget its relationship to SGML. Many of the drawbacks in XML are design decisions made in order to maintain backwards compatibility with SGML tools that were in use when XML was devised. In order to simplify parsing (and in order to enable parsing a well formed document without knowing its DTD), XML threw out much of the syntactic sugar that SGML had to offer such as implicitly closed tags. I.e. Many people think that <tr><td>foo<td>bar... is invalid HTML because of missing </td>. In fact, it is perfectly valid because the HTML (SGML-)DTD specifies that a <td>-tag implicitly closes a preceding <td>. Most think it's a browser-hack. It is not. What both XML (and SGML) add over S-EXPR is support for expressing grammers, a well-defined validation mechanism and quite good support for coping with different character encoding.

asciilifeform 18y ago

Erik Naggum on XML vs. S-Expressions: "They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. Robbery is not just another way of making a living, rape is not just another way of satisfying basic human needs, torture is not just another way of interrogation. And XML is not just another way of writing S-exps. There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished." (http://www.schnada.de/grapt/eriknaggum-xmlrant.html http://www.schnada.de/grapt/eriknaggum-xmlrant.html)

eru 18y ago
Pretty strong words for such a trifle.
- asciilifeform 18y ago
  Yet it is not a trifle. Wasting what might amount to thousands of man-years by forcing talented people (who might otherwise accomplish something meaningful) to build workarounds for an inferior technology is every bit as criminal as, say, embezzlement.
  - eru 18y ago
    By the same logic, QWERTY forcing talented people to develop RSI should get the same treatment..
    - asciilifeform 18y ago
      I can see no reason why not.