On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei Alexandrescu wrote:
> On 11/25/2015 02:02 PM, Walter Bright wrote:
>> On 11/25/2015 7:25 AM, Jonathan M Davis wrote:
>>> The files are very short, and you don't have to deal with them much.
>>
>> That makes for an even less of a case for inventing a new file format. I
>> suppose it's water under the bridge, though.
>
> It's not. To DUB maintainers: this is a strategic error. Please throw SDL away and use a standardized file format. -- Andrei

You'll have to explain why you think it's a strategic error instead of decree it that it is.

On 11/25/2015 02:19 PM, Brad Anderson wrote:
> On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei Alexandrescu wrote:
>> On 11/25/2015 02:02 PM, Walter Bright wrote:
>>> On 11/25/2015 7:25 AM, Jonathan M Davis wrote:
>>>> The files are very short, and you don't have to deal with them much.
>>>
>>> That makes for an even less of a case for inventing a new file format. I
>>> suppose it's water under the bridge, though.
>>
>> It's not. To DUB maintainers: this is a strategic error. Please throw
>> SDL away and use a standardized file format. -- Andrei
>
> You'll have to explain why you think it's a strategic error instead of
> decree it that it is.

As Walter said a few times by now, inventing new languages is an endeavor of high fixed cost for everyone involved (including users) and shouldn't be done casually.

Please don't reply to this. Just throw SDL away and use JSON. Please don't waste time discussing it.


Thanks,

Andrei

On Wednesday, 25 November 2015 at 19:02:18 UTC, Walter Bright wrote:
> On 11/25/2015 7:25 AM, Jonathan M Davis wrote:
>> The files are very short, and you don't have to deal with them much.
>
> That makes for an even less of a case for inventing a new file format. I suppose it's water under the bridge, though.

I'm certainly not in favor of inventing a new file format, but since it _is_ used in a restricted context, even if it's a mistake, I don't expect that it'll cost us much. Honestly, if anything, I think that having multiple formats for dub config like we do is more confusing than using SDL.

> Note 1: json does support comments:
>
>     "comment" : "this is a comment",

Well, that's potentially a good workaround, but it still isn't really a comment, and it assumes both that that's valid that part of the json file and that there isn't an actual field called comment that an application reading the file would expect. It likely works in most cases, but it is a hack brought on by a major defect in the JSON spec.

- Jonathan M Davis

On Wednesday, 25 November 2015 at 19:18:25 UTC, Brad Anderson wrote:
> Tools should be querying dub directly instead of trying to read the package format.

Shouldn't this be true of writing it too? Like I said on irc earlier today, I actually kinda think we should have some kind of gui for it, or at least a command suite (like `dub add-dependency foo` maybe, idk) so the file itself never needs to be touched directly by users for common tasks.

On Wednesday, 25 November 2015 at 19:29:43 UTC, Adam D. Ruppe wrote:
> On Wednesday, 25 November 2015 at 19:18:25 UTC, Brad Anderson wrote:
>> Tools should be querying dub directly instead of trying to read the package format.
>
> Shouldn't this be true of writing it too? Like I said on irc earlier today, I actually kinda think we should have some kind of gui for it, or at least a command suite (like `dub add-dependency foo` maybe, idk) so the file itself never needs to be touched directly by users for common tasks.

While having a GUI might be nice, we're talking about a config file here. This is exactly the sort of thing that's normally edited by hand. It should be both writable and readable by both programmers and programs.

- Jonathan M Davis

On 11/25/2015 11:10 AM, Adam D. Ruppe wrote:
> On Wednesday, 25 November 2015 at 19:02:18 UTC, Walter Bright wrote:
>> Note 1: json does support comments:
>>
>>     "comment" : "this is a comment",
>
> That doesn't work in the majority of contexts (it is illegal in an array, for
> example) nor is it supported by standard tools.

The array thing is not a big problem. If it's a small array, just precede it with the comment. If it is a large array, the individual entries are hardly going to be commented.

It's not a problem with the standard tools, as the standard tools don't do semantic processing. The semantic part, which would be custom to DUB (or the app) can just ignore it.

JSON is not a perfect match for every application. But it is close enough, and certainly close enough for small files like DUB files.

On 11/25/2015 11:11 AM, David Nadlinger wrote:
> On Wednesday, 25 November 2015 at 19:04:19 UTC, Walter Bright wrote:
>> Sure it does:
>>
>>     "comment" : "This is a comment",
>
> That only works in contexts where a dictionary is used,

You can always add a dictionary anywhere in json.


> and also neither stands
> out visually by itself nor can be rendered differently by syntax highlighting.

Not a big problem. I still don't use a syntax highlighting code editor. I probably should, but I seem to somehow get by without it :-). Small files like DUB files hardly need syntax highlighting.

On Wednesday, 25 November 2015 at 19:25:18 UTC, Andrei Alexandrescu wrote:
> As Walter said a few times by now, inventing new languages is an endeavor of high fixed cost for everyone involved (including users) and shouldn't be done casually.
>
> Please don't reply to this. Just throw SDL away and use JSON. Please don't waste time discussing it.

While I agree with you, we shouldn't become the Go community either. Saying "let's not discuss this" seems very against the values of the D community.

On 11/25/2015 11:29 AM, Adam D. Ruppe wrote:
> On Wednesday, 25 November 2015 at 19:18:25 UTC, Brad Anderson wrote:
>> Tools should be querying dub directly instead of trying to read the package
>> format.
>
> Shouldn't this be true of writing it too? Like I said on irc earlier today, I
> actually kinda think we should have some kind of gui for it, or at least a
> command suite (like `dub add-dependency foo` maybe, idk) so the file itself
> never needs to be touched directly by users for common tasks.

And the cost of inventing a new file format just grew by another order of magnitude.

I should add "need a special gui editing tool" to my list of reasons not to invent another file format.

On Wednesday, 25 November 2015 at 20:08:13 UTC, Walter Bright wrote:
> And the cost of inventing a new file format just grew by another order of magnitude.
>
> I should add "need a special gui editing tool" to my list of reasons not to invent another file format.

The benefits of a gui are separate from the physical file format. It helps you get the semantics right primarily, secondarily it helps you navigate the ecosystem (the code.dlang.org website does this too). Only tertiary does it makes the file format irrelevant, but the main goal of them is to guide you through the process of creating a valid configuration that makes sense for you.