>>8
Still stupid. Why repeating the name of the crap you're closing? (Before you say it, it's not like it's any clearer if you can recursively include tags of the same name.)
Of those alternatives, I'd consider most inferior to XML, as they don't even nest!
Java fag
{fuck: {java: 'fag'}}
(fuck (java fag))
fuck{java{fag}}
[really/really/fuck]
java=fag
>>9
S-expressions are... okay, I suppose, but they do not clearly separate the tags from the content
Tags are, in a way, content. They are of type symbol. If you want, you can use symbols for what you call tags, and strings (stuff in "") for what you call content. For example:
(people (java-fag (name ">>9")) (traitor (name "Guy Steele")))
malformed content like mismatched parenthesis can fuck up the parser
lern2cod
It's MUCH simpler to write an S-expression parser.
with no clear indication where the fuckup started.
What's the difference between...
(lol (lol (lol )))))) ;oops
and
<lol><lol><lol> </lol></lol></lol></lol></lol></lol> <!-- oops -->
Besides the ugly fuck piece of a shit of a syntax and possible waste of Internet bandwidth in the second case?
XML won and is now pretty much the standard.
The standard of what? XML is just today's enterprise best-practice object-oriented business synergy solution.
Being directly executable by JavaScript and Python means shit if you're not programming in either
Python is a good language for web applications development, and JavaScript is present in most web browsers (even elinks), so at least for the web, it's relevant to my interests.
or if you do not trust the content.
You can safely eval in the client side, not much harm to do with JavaScript and he's the luser anyways. As for Python, yeah, you better parse it yourself (even eval(input, {}, {}) is vulnerable to crap like __import__('os').system('echo lol>hax')), but for quick nigger scripting jobs where you trust the input (like a config file), you can afford to eval.