On 8/27/2014 5:27 AM, Sönke Ludwig wrote:
Am 27.08.2014 10:02, schrieb Kagamin:
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:
That's somewhat misleading.
More accurately, SDL is newline-delimited (with backslash line
continuation). That's pretty darn simple and has an age-old history.
It's not like we're talking weird Python/JavaScript rules or anything
here.
The only thing that does trip people up is that the existence of { and
} in the syntax makes people think "C-family and therefore freeform".
And then it isn't, so that makes them angry. "Yeeargh! Hulk Not Want!"
Well...or something vaguely sorta kinda like that ;)
That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line
continuations.
Yea, I'll grant it *is* somewhat of a blemish in SDL's design. But I
don't think it's a critical one.
Besides, this thread's (dare I say "bikeshedded"?) quest for an ideal
data language seems doomed from the start: If we try to avoid the less
common ones, and avoid inventing our own (which I think we have good
reason to avoid), then everything left *does* have imperfections.
Therefore, I think the main critera we should be looking at here, for
any of the possibilities, isn't "Does this language have flaws?" but
rather "Is this language *good enough* to be supported by DUB as a JSON
alternative?"
Like JavaScript for example?
Heh, there is that.
What's wrong with XML? I work with it daily and see no problem. The less
syntax a language has, the worse it scales, and if it doesn't scale, its
adoption creates a technical debt. 100 lines with 3 levels of nesting
and JSON becomes hard to follow and TOML becomes simply unmanageable.
The reason to search for an additional format is to make it more
convenient and readable for human interaction. XML wouldn't structurally
a bad choice, but is awful because of it's syntactical overhead.
That's a big one. *The* big one in my mind.
Additionally, despite XML's simplistic appearance, some of the details
about it get disturbingly over-engineered. Heck, take a look at W3C's
docs on it: for something that's *supposed* to be as simple as:
<tag1>
<tag2 attr="value">blah</tag2>
<tag3 />
</tag1>
For something that *appears* to be that simple, it's formal reality is
horrifically complicated.
Besides, there's nothing stopping a good editor from taking this:
{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
}
}
And adding helper visuals (not part of the actual document) to display
it as this:
{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
} <i>"tag1"</i>
} <i>{root}</i>
(The <i></i> wouldn't be displayed, I just put them there to indicate
the text inside would be visually distinguished so that the user finds
it obvious it's not actually part of the document. Can't really emulate
that in a NG post.)
I don't know why no editors ever do that.
