3 ms·

I once explored the topic of "xml is just verbose s-exps" with someone who had no lisp experience. His first response was that it would be impossible to just u

I once explored the topic of "xml is just verbose s-exps" with someone who had no lisp experience. His first response was that it would be impossible to just use lisp in place of xml because you would then have to implement a minimal lisp parser into any language that wanted to make use of data stored in s-exps. I then pointed out that you have to do the same thing for xml or json, it's just that we've become used to standard tools existing to do this. That's actually where I find that XML is the most dangerous. People just take it as a fact of the universe that XML exists and make so many assumptions about how it solves a particular problem that they don't even stop to think "could there be a better way?"

Groxx 16y ago
Exactly. XML is a format, nothing more; it's the culture and everything around it that makes it a problem.
GFischer 16y ago
I'll admit my ignorance about the existence of S-expressions (had to look them up here: http://en.wikipedia.org/wiki/S-expression http://en.wikipedia.org/wiki/S-expression ) I've used XML because .NET has a parser, and I'll probably use JSON because parsers are widespread... are there good standard parsers for S-expressions for .NET or other popular platforms? A quick googling sends me here http://stackoverflow.com/questions/3051254/parsing-lisp-s-expressions-with-known-schema-in-c http://stackoverflow.com/questions/3051254/parsing-lisp-s-ex... which makes me believe.NET can't natively process s-expressions with ease, and that's a HUGE minus for me.
- dfox 16y ago
  Few lines of code in the last answer is actually everything you need to parse (reasonable subset of) S-expressions. So there probably isn't any general purpose programming language that cannot handle S-expressions with ease. That holds if you want to use S-expressions as data exchange format (or like network protocol as is done by Subversion). Parsing Common Lisp source is entirely different matter.
  - GFischer 16y ago
    It does seem you can handle them, but we .NET people are lazy (as in, Larry Wall lazy http://en.wikipedia.org/wiki/Larry_Wall http://en.wikipedia.org/wiki/Larry_Wall ). I agree with the poster's reply to that: "Yes I agree that this is simple and fast, but.. What I really want is a 1-D list of my own object types." I get that when using XML web services with .NET (though mostly when consumed with other .NET or similar languages !!! which goes against it being an universal data transfer language )
saurik 16y ago
> That's actually where I find that XML is the most dangerous. People just take it as a fact of the universe that XML exists and make so many assumptions about how it solves a particular problem that they don't even stop to think "could there be a better way?" Unfortunately, even when presented with numerous implementations of interesting algorithms like schema validators, tree transformation tools, etc. that /happen/ to use XML (for our purposes, a specific verbose dialect of s-expressions) as an interchange format, the entirely opposite problem occurs: people ask the question "could there be a better way?" needlessly, and then reinvent some subset of all of that tested and working code based on around something they made up, or even something people generally like (JSON), and throw away all of that existing ecosystem; and, in the end, the only way in which it is better is that it isn't XML.

Groxx 16y ago

Exactly. XML is a format, nothing more; it's the culture and everything around it that makes it a problem.

GFischer 16y ago

I'll admit my ignorance about the existence of S-expressions (had to look them up here: http://en.wikipedia.org/wiki/S-expression http://en.wikipedia.org/wiki/S-expression ) I've used XML because .NET has a parser, and I'll probably use JSON because parsers are widespread... are there good standard parsers for S-expressions for .NET or other popular platforms? A quick googling sends me here http://stackoverflow.com/questions/3051254/parsing-lisp-s-expressions-with-known-schema-in-c http://stackoverflow.com/questions/3051254/parsing-lisp-s-ex... which makes me believe.NET can't natively process s-expressions with ease, and that's a HUGE minus for me.

dfox 16y ago
Few lines of code in the last answer is actually everything you need to parse (reasonable subset of) S-expressions. So there probably isn't any general purpose programming language that cannot handle S-expressions with ease. That holds if you want to use S-expressions as data exchange format (or like network protocol as is done by Subversion). Parsing Common Lisp source is entirely different matter.
- GFischer 16y ago
  It does seem you can handle them, but we .NET people are lazy (as in, Larry Wall lazy http://en.wikipedia.org/wiki/Larry_Wall http://en.wikipedia.org/wiki/Larry_Wall ). I agree with the poster's reply to that: "Yes I agree that this is simple and fast, but.. What I really want is a 1-D list of my own object types." I get that when using XML web services with .NET (though mostly when consumed with other .NET or similar languages !!! which goes against it being an universal data transfer language )

saurik 16y ago

> That's actually where I find that XML is the most dangerous. People just take it as a fact of the universe that XML exists and make so many assumptions about how it solves a particular problem that they don't even stop to think "could there be a better way?" Unfortunately, even when presented with numerous implementations of interesting algorithms like schema validators, tree transformation tools, etc. that /happen/ to use XML (for our purposes, a specific verbose dialect of s-expressions) as an interchange format, the entirely opposite problem occurs: people ask the question "could there be a better way?" needlessly, and then reinvent some subset of all of that tested and working code based on around something they made up, or even something people generally like (JSON), and throw away all of that existing ecosystem; and, in the end, the only way in which it is better is that it isn't XML.