On Friday, 29 August 2014 at 19:53:26 UTC, Nick Sabalausky wrote:
True for XML too:
1. many editors already autocomplete it, no need to wonder,
why nobody
implemented it;
Personally, I don't like that auto-insert stuff, it just trips
me up.
Didn't you argue for autoinserting? If you don't want it, you can
turn it off (it's implemented).
2. if you need a new document fragment, you just copy existing
one and
tweak it to new needs; and it's easier and faster this way
with succinct
languages too;
Yea, I do that to. But stuff, would you be ok with this (not
rhetorical)?:
while(cond)
if cond
...
end if
end while
etc.
Yea, obviously I *can* use a language like that. I prefer not
to.
General-purpose programming languages usually allow arbitrary
code organization, documents don't. And nested blocks are usually
nested ifs (or #ifs), so #endifs don't add lots of information,
while in a document almost every element is unique.
- Nobody has to actually look at the closing if they want to
reduce
the visual clutter: Ie, viewing it is an optional thing.
And get lost, when it doesn't cut it.
If that doesn't always cut it, then neither do XML-style
matching end tags.
When they are invisible when you decided it's clutter.
Oh and it makes no sense to add a non-trivial editor support
for json,
because it's a format buried in a dark corner of javascript
ecosystem,
and even there it's used as a serialization format for data
exchange
(that's because it doesn't have comments) instead of
long-living
manually written documents.
JSON's extremely common, and I never intended the idea as being
exclusively for JSON alone.
Serialization format for web services is the only application I
know.
This is the part that I don't understand why people seem to be
either missing or disagreeing with:
-----------------------------------
(XML-style) Matching end-tags:
Have to type, always visible even when it's clutter.
If you don't want to type or copy them, there's autocomplete.
Small documents have no clutter because of their sheer size and
simplicity, big documents need xml-style visualization anyway.
(JSON-stye) Dedicated one-char end-tags:
Visually indistinct, can't see which is which at a glance
even when you want to.
Feature to optionally show the tag name at the closing brace:
***Eliminates cons of JSON-stye dedicated one-char
end-tags.***
BTW, json can simply reuse javascript lexer, which doesn't do
anything json-specific. Maybe, json is just meant to be succinct
and doing otherwise goes against its design?
In any case, I don't see how that feature provides much benefit
over my suggestion. If you don't mind the auto-inserted text,
then it's pretty much on par with my suggestion.
Result:
***Feature parity and everyone's happy.*** Except...somehow
they're *not* and still complain and nitpick anyway...? I don't
get it.
-----------------------------------
Your suggestion is a hack and less popular than XML. Though, I
don't see why create the problem with succinct language and then
heroically solve it? (oh, wait, not yet)
