Before we implement SDL package format for DUB

[Nick Sabalausky via Digitalmars-d]

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.