On Thursday, 28 August 2014 at 03:38:25 UTC, Andrei Alexandrescu wrote:
> On 8/27/14, 5:25 AM, Gary Willoughby wrote:
>> On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote:

> Then perfection in personal finance is easy to achieve :o). --

In corporate finance, too:

http://en.wikipedia.org/wiki/Accounting_scandals#List_of_reported_accounting_scandals

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;
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;

> - Nobody had to keep the opening/closing in sync

Huh? Never needed that. And it's the same with json and sdl: if you add new brace you need to go find the appropriate brace, after which to insert new brace, and there you see lisp-style stairway of indiscernible braces (with commas, yay).

> - The closing takes up zero bytes

I'd say, it's dwarfed by everything else especially indentation.

> - 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.

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.

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.
-----------------------------------

I would now like to invoke the Zero One Infinity Rule(http://en.wikipedia.org/wiki/Zero_one_infinity_rule).

Supporting one format makes sense - DUB can simply use the set of functions and data structures provided by Phobos or by external libraries for using this format.

Supporting two formats will require two sets of functions and data structures, and to decide a point where the two code-paths will be joined to a single representation of the build configuration. According to the ZOI rule, you might as well take the extra step and support infinity formats!


This is my idea - the point of entry will remain "dub.json". For a project to use SDL for build configuration, "dub.json" will look something like this:

    {
        "import" : [
            {
                "file": "dub.sdl",
                "parser": "dub-sdl"
            }
        ]
    }

When DUB sees this, it'll download the "dub-sdl" package from the DUB repository(unless it already downloaded it) and use it to parse "dub.sdl".

There can be a number of ways to do this - maybe DUB will load a dynamic library from "dub-sdl" and use the functions directly, or maybe "dub-sdl" will convert "dub.sdl" into JSON format that DUB can parse directly, or maybe it'll parse it into a binary format so it'll be more efficient to serialize and parse it.

It doesn't matter how it ends up done - the point is that DUB will decide the method for getting that data and the parser packages will have to conform to it. Once the framework is in place, we can have "dub-sdl", "dub-ason", "dub-yaml" etc.


This mechanism can also be used for splitting the build file - which can be useful if you want to have parts of it updated regularly by automatic tools, or to put only parts of the build configuration under source control. For this, different file names can be put in the "file" field even if they all use the same format, and "parser" can be omitted to read JSON files.

On Friday, 29 August 2014 at 20:54:49 UTC, Idan Arye wrote:
> I would now like to invoke the Zero One Infinity Rule(http://en.wikipedia.org/wiki/Zero_one_infinity_rule).
>
> Supporting one format makes sense - DUB can simply use the set of functions and data structures provided by Phobos or by external libraries for using this format.
>
> Supporting two formats will require two sets of functions and data structures, and to decide a point where the two code-paths will be joined to a single representation of the build configuration. According to the ZOI rule, you might as well take the extra step and support infinity formats!

This might make sense from a technical point of view, but do we want it? In the extreme case, we'd end up with a different format for each package, though more likely will be a distribution where most packages focus on one or two formats, but with a looooong tail...

> This mechanism can also be used for splitting the build file - which can be useful if you want to have parts of it updated regularly by automatic tools, or to put only parts of the build configuration under source control. For this, different file names can be put in the "file" field even if they all use the same format, and "parser" can be omitted to read JSON files.

This is useful in any case, no matter how many formats we're going to support.

On Saturday, 30 August 2014 at 09:37:55 UTC, Marc Schütz wrote:
> On Friday, 29 August 2014 at 20:54:49 UTC, Idan Arye wrote:
>> I would now like to invoke the Zero One Infinity Rule(http://en.wikipedia.org/wiki/Zero_one_infinity_rule).
>>
>> Supporting one format makes sense - DUB can simply use the set of functions and data structures provided by Phobos or by external libraries for using this format.
>>
>> Supporting two formats will require two sets of functions and data structures, and to decide a point where the two code-paths will be joined to a single representation of the build configuration. According to the ZOI rule, you might as well take the extra step and support infinity formats!
>
> This might make sense from a technical point of view, but do we want it? In the extreme case, we'd end up with a different format for each package, though more likely will be a distribution where most packages focus on one or two formats, but with a looooong tail...

Well, since we are already talking about implementing a second format in addition to JSON, I figured we don't give a rat's ass about diversion in packages...

On 8/25/2014 12:40 PM, Jonathan Marler wrote:
> Hello everyone,
>
> [endless discussion]

Anyone seen the mystery/comedy/detective show "Monk"?

I've been watching it lately. One interesting quirk about the main character Adrian Monk (a character who's humorously *loaded* with quirks) is that one must NEVER present him with a choice, especially a trivial or inconsequential one. He will contemplate and second-guess it endlessly. *Make* the choice instead, without providing him an opportunity to debate it with himself, and things work out fine (at least until another quirk is triggered).

If Dub had gone the "badly-managed-project" route and unilaterally made the call to rip out JSON entirely, replacing it with SDL, back when it was first considered...I doubt very much it would have generated anywhere near the level of back-and-forth objections and unrest that it's now generated over several discussions since. We're designing by committee.

We are Adrian Monk. We can't handle choice. ;)

On Saturday, 30 August 2014 at 11:40:01 UTC, Nick Sabalausky wrote:
> On 8/25/2014 12:40 PM, Jonathan Marler wrote:

> We are Adrian Monk. We can't handle choice. ;)

You may say anything you want, but I love Monk. And the actor impersonating him is just either a genius, either suffer from teh same illnes... He's just too perfect.

On 8/30/2014 8:37 AM, eles wrote:
> On Saturday, 30 August 2014 at 11:40:01 UTC, Nick Sabalausky wrote:
>> On 8/25/2014 12:40 PM, Jonathan Marler wrote:
>
>> We are Adrian Monk. We can't handle choice. ;)
>
> You may say anything you want, but I love Monk.

I do too! I've seen every episode at least twice. Brilliant show, and some of the secondary characters are every bit as good as Monk himself, like Disher and the captain.

The bikeshedding here just reminded me of Monk's (amusing and endearing) inability to handle simple choices. I had to point out the parallel. As a collective, we kind of are Monk in some ways. Something worth bearing in mind.

> And the actor
> impersonating him is just either a genius, either suffer from teh same
> illnes... He's just too perfect.

Yea, Tony Shalhoub is an incredible actor. You can tell he really did his research on the part (although I think his role on Wings helped a lot, too. His cab driver role was sort of like an earlier, less extreme version of Adrian Monk).

He also did a great job in "Pain & Gain" in a completely polar opposite type of role (although very similar to an alternate "Mobster" persona he adopted in one episode of Monk, near the end of the series IIRC).

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)