On 8/29/2014 7:37 AM, Kagamin wrote:
On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky wrote:
The differences (off the top of my head, there may be more):
- Nobody has to actually write the closing
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.
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.
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.
- Nobody had to keep the opening/closing in sync
Huh? Never needed that.
(Just to be clear we're on the same page here, I'm not sure if I was
clear enough) You've never needed to change the name of a tag? Change
one, gotta change the other to match.
And it's the same with json and sdl: if you add
new brace you need to go find the appropriate brace,
Not what I'm talking about with "keep the opening/closing in sync"
after which to
insert new brace, and there you see lisp-style stairway of indiscernible
braces (with commas, yay).
Didn't I just suggest a simple editor feature to eliminate that problem?
Isn't that proposed feature exactly what we're currently debating?
- The closing takes up zero bytes
I'd say, it's dwarfed by everything else especially indentation.
Fine.
- 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.
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.
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.
(JSON-stye) Dedicated one-char end-tags:
Visually indistinct, can't see which is which at a glance even when
you want to.
Auto-inserted text (if you like that sort of thing), and a feature to
optionally hide/collapse end tags:
***Eliminates cons of XML-style matching end-tags.***
Feature to optionally show the tag name at the closing brace:
***Eliminates cons of JSON-stye dedicated one-char end-tags.***
Result:
***Feature parity and everyone's happy.*** Except...somehow they're
*not* and still complain and nitpick anyway...? I don't get it.
-----------------------------------
