Am 26.11.2015 um 18:10 schrieb Walter Bright:
> On 11/26/2015 12:50 AM, Sönke Ludwig wrote:
>> Nobody has invented anything here. Please at least get your facts
>> straight
>> before ending discussions in this tone and manner.
>
> I told Andrei it was invented, so I take the blame for that. I was
> wrong. Jonathan has since corrected me.
>

Sorry, I had not read the whole thread at that time, so I missed that. But still this thread has overall been very irritating to me (that doesn't quite describe it). Maybe I should better have replied immediately and anticipate some of the statements that followed, but I have discussed this topic countless times and I'm getting seriously tired of it (because it is the _prototype of a bikeshedding topic_). Combine that with a hardly motivated and inflammatory initial post, I was hoping that this would just quickly die off - obviously a very naive thought.

Just to mention one additional reason for choosing SDLang over one of the more popular formats that shared some of the advantages, there is an idea to add limited support for (declarative) procedural statements: https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
The representation possible with SDLang is not as good as in an actual programming language, but far better than with any of the JSON-like languages.

Otherwise, the language syntax is also quite a natural fit for a curly-brace based language. And its simplicity basically renders the "learn" argument moot - what you really have to learn is the set of directives that DUB recognizes.

Overall, I don't think the popularity argument actually has much weight, but there are indeed a lot of arguments for a better format in general. BTW, around 20 of the packages registered on code.dlang.org since the release of the 0.9.24 version have SDLang based package descriptions (about 50%). I haven't checked the already existing packages.

On 2015-11-26 20:05, Sönke Ludwig wrote:

> Just to mention one additional reason for choosing SDLang over one of
> the more popular formats that shared some of the advantages, there is an
> idea to add limited support for (declarative) procedural statements:
> https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
> The representation possible with SDLang is not as good as in an actual
> programming language, but far better than with any of the JSON-like
> languages.

Everyone will hate me for saying this, but in that case, just go with Ruby (or some other similar language)

-- 
/Jacob Carlborg

On Thursday, 26 November 2015 at 19:57:19 UTC, Jacob Carlborg wrote:
> On 2015-11-26 20:05, Sönke Ludwig wrote:
>
>> Just to mention one additional reason for choosing SDLang over one of
>> the more popular formats that shared some of the advantages, there is an
>> idea to add limited support for (declarative) procedural statements:
>> https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
>> The representation possible with SDLang is not as good as in an actual
>> programming language, but far better than with any of the JSON-like
>> languages.
>
> Everyone will hate me for saying this, but in that case, just go with Ruby (or some other similar language)

Why?

On Thursday, 26 November 2015 at 18:56:20 UTC, Sebastiaan Koppe wrote:
> On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig wrote:
>> Thanks,
>>
>> Sönke
>
> Thank you (and others) for your time developing dub.
>
> I don't understand any feelings for or against the configuration's format. From a maintainability perspective JSON wins, from readability SDL wins. Pick _one_. Move on.
> ...

Yes man and like I said previously, this should be settled directly with developer, it is too much drama for such a small thing.

And thinking more about it, now I start to understand Linus Torvalds rants on code and I really think this community needs someone like him to shake up things, and stopping those nonsense complaints. :)

Matheus.

On 26/11/2015 16:10, Sönke Ludwig wrote:
>
> The only valid reason for an IDE to directly parse the package
> description is basically if it wants to provide a custom UI for editing
> it. If the IDE is written in D, it can easily use DUB as a library and
> not only get the package description in a common format, but also nicely
> statically typed. If not, the conversion feature that was planned for
> the next version would trivially solve that, too.

This is isn't true. There are things that an IDE might want to do, that "dub describe" doesn't currently account for. The DDT IDE is an example of that, and I've raised these issues before with DUB. For example:

 * dub describe fails if dependency resolution fails, yet there is still partial information about the DUB package that would be of use.
 * dub describe does not provide information for all build configurations, only the default one. As such the IDE has to parse the json to find out all available configurations itself. (This is used in the DDT IDE to show a list of "Build Targets" in the UI)


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Thursday, 26 November 2015 at 20:35:28 UTC, mattcoder wrote:
> On Thursday, 26 November 2015 at 18:56:20 UTC, Sebastiaan Koppe wrote:
>> On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig wrote:
>>> Thanks,
>>>
>>> Sönke
>>
>> Thank you (and others) for your time developing dub.
>>
>> I don't understand any feelings for or against the configuration's format. From a maintainability perspective JSON wins, from readability SDL wins. Pick _one_. Move on.
>> ...
>
> Yes man and like I said previously, this should be settled directly with developer, it is too much drama for such a small thing.
>
> And thinking more about it, now I start to understand Linus Torvalds rants on code and I really think this community needs someone like him to shake up things, and stopping those nonsense complaints. :)
>
> Matheus.

We do, he's called Andrei!

On 26/11/2015 12:29, Jacob Carlborg wrote:
> BTW, why was not TOML [1] chosen? I know it was discussed but I can't
> remember why SDL was preferred. I think TOML is more widely used than
> SDL [2]. GitLib CI multi runner is also using it.
>
> [1] https://github.com/toml-lang/toml
> [2] https://github.com/toml-lang/toml#projects-using-toml

I was wondering the same. I actually think JSON would be just fine since the dub.json manifest is usually quite small, and edited very seldomly, so no worries to have the slightly verbose JSON as a format.

But if we really wanted a more succinct format, why not go with TOML instead of SDL?!? TOML actually has some widespread support (even if not as much as JSON), and has parsers written in several languages already! SDL on the other hand always looked like a out-of-nowhere, no-one-ever-heard-of-it-project.
Like the Lincoln Chafee of US Democratic presidental candidates... I mean, there are probably ultra weird, obscure japanese fetishes that are more well-known than SDL!

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:
> V Thu, 26 Nov 2015 12:43:52 +0000
> Chris via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:
>
>> On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
>> wrote:
>>> On 2015-11-25 11:17, Suliman wrote:
>>>> [...]
>>>
>>> BTW, why was not TOML [1] chosen? I know it was discussed but I
>>> can't remember why SDL was preferred. I think TOML is more
>>> widely used than SDL [2]. GitLib CI multi runner is also using
>>> it.
>>>
>>> [1] https://github.com/toml-lang/toml
>>> [2] https://github.com/toml-lang/toml#projects-using-toml
>>
>> TOML looks nice, _but_ it's version 0.4.0. We cannot afford to
>> maintain a parser for a format that hasn't "settled down" yet.
>
> Ok, but we can afford to mantain a parser for a dead format?
> https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language
>

BAM!! *Daniel drops mike, walks way*


(well said)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros wrote:
> On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:
>> V Thu, 26 Nov 2015 12:43:52 +0000
>> Chris via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:
>>
>>> On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
>>> wrote:
>>>> [...]
>>>
>>> TOML looks nice, _but_ it's version 0.4.0. We cannot afford to
>>> maintain a parser for a format that hasn't "settled down" yet.
>>
>> Ok, but we can afford to mantain a parser for a dead format?
>> https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language
>>
>
> BAM!! *Daniel drops mike, walks way*
>
>
> (well said)

Isn't it easier to maintain a parser for a dead format than a living one? You know it won't change ... after all, its dead!

On Thursday, 26 November 2015 at 19:57:19 UTC, Jacob Carlborg wrote:
> Everyone will hate me for saying this, but in that case, just go with Ruby (or some other similar language)

That was actually one of my first thoughts. It would be pretty, but we'd have another dependency then. Also, Ruby doesn't embed well into other applications, and if we're using another general-purpose programming language for our config format, what kind of impression does that give others about our confidence in D?

That said, I found a neat language today, and it might be usable for config files. See nim-lang.org.