Before we implement SDL package format for DUB

[Kagamin via Digitalmars-d]

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)