On 8/28/2014 5:29 AM, Kagamin wrote:
On Wednesday, 27 August 2014 at 19:30:35 UTC, Nick Sabalausky wrote:
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.)
You just acknowledged succinct languages don't scale,
No, I've only acknowledged that they don't exhibit *perfect* scaling.
They certainly still scale. And they can scale even better with a little
editor help.
and the only way
to make them scale is to turn them into syntactical equivalent of XML
with closing tags. And even then more verbose than XML itself. So what's
a difference from XML if good config language still must have XML syntax?
The differences (off the top of my head, there may be more):
- Nobody has to actually write the closing
- Nobody had to keep the opening/closing in sync
- The closing takes up zero bytes
- Nobody has to actually look at the closing if they want to reduce the
visual clutter: Ie, viewing it is an optional thing.
I don't know why no editors ever do that.
The editors show only what's written and written is JSON, not JSON++.
My editor shows all sorts of stuff that ain't written. Line numbers,
80-col mark, visible whitespace/EOLs, indent guides, a horizontal line
to denote folded code sections, etc. You're not going to split hairs and
claim those are fundamentally/meaningfully different from what I'm
suggesting are you?
