I hate new DUB config format

[Sönke Ludwig via Digitalmars-d]

Am 26.11.2015 um 23:47 schrieb Walter Bright:
> On 11/26/2015 11:05 AM, Sönke Ludwig wrote:
>> 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.
>
> I understand you being angry about this. It would be hard not to be. It
> would have been a lot better if Andrei and I had noticed this before
> much was invested in it.

It's not so much about the objective topic, but about how this was 
handled - on a methodical/factual level, but mostly on the personal level.

>> 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.
>
> This looks like it's creeping towards inventing a new script programming
> language. Adding loops, switch statements, functions, etc., can't be far
> off. Before you get too far down this path, consider:

Actually, no! Conditionals and loops are the only constructs - switch is 
a possibility, but basically nothing else. There will also never be 
variables, just constants. There is a definitive limit, namely when it 
becomes impossible to reason about the code in a generic way, without 
"executing" it, so in particular anything that would make it touring 
complete is a no-go - no recursion, no loop flow control statements, no 
goto. In fact, there are no "statements" at all, these are all purely 
declarative "directives".

>
> 1. JSON has a superset programming language - Javascript - which has
> conventional syntax rather than the DEP4 proposal for odd syntax like
>
>      if dub-version="<0.9.24"
>
> which I would strongly recommend against. And, we already have a
> Javascript engine written in D:
>
>      https://github.com/DigitalMars/DMDScript
>
> 2. D itself can be used as a scripting language (when # is the first
> character in the source code). Having DUB use this might be quite
> interesting.

On one hand that means that now you have to take care of security issues 
(holes in the scripting engine/compiler or DoS attacks of various sorts) 
when you want to use this on a server (code.dlang.org). Once there are 
big numbers of packages, this could also mean that the hardware 
eventually needs to be upgraded when it would have done fine for a long 
time with a tiny declarative parser.

On the other hand, it's not possible with a script to make general 
predictions of how a package would behave, for example the script could 
select a dependency based on some environment variable or a file that is 
only defined on the target system.

A personal example is a CI system that I have that collects the proper 
dependencies and schedules builds on worker machines. With a script 
based package recipe that would mean that I'd have to implement 
complicated roundtrips to the target machines, which don't have the 
necessary knowledge to select the dependencies themselves (they'd need 
the full git history of each project). Not only would that mean a lot 
more work and a lot more failure points, but it also means that the 
workers become much more complex and will probably have to be updated 
regularly, meaning also more work for those who maintain them.

Finally, it's always possible to switch from declarative to script 
without loosing expressive power, but not necessarily the other way around.

>> 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.
>
>  From my other post in this thread about all the problems with going
> with SDL:
>
> "With a standard json parser in Phobos, zip zap boom you're done. You
> don't have to design it, argue about it, build it, document it, debug
> it, test it, optimize it, explain it, deal with bug requests, deal with
> enhancement requests, deal with legacy compatibility, build a converter,
> build a gui tool for it, etc."

Let's say this isn't really an argument anymore now that it has already 
been done, but it wouldn't have been a strong argument anyway, because 
the SDLang parser is actually in use for other projects as well, so it 
has to be maintained anyway. There really is very little investment 
necessary development-wise, I think it took me maybe three to four hours 
total to implement it, including the support on code.dlang.org. Creating 
the sdlang-d library itself (by Nick Sabalausky) was of course a bigger 
task, as were the discussions and the design process.

But apart from that, finding a format that a) allows (real) comments and 
b) has less syntax noise was necessary in any case. Sure, JSON *works*, 
but it becomes really unpleasant with more complicated files, and the 
whole {"comment": "..."} approach is nothing but an ugly and highly 
inconvenient hack, both when writing and when reading it. And the fact 
is that no matter which other format we would have chosen (JSON with 
comments is also another language) we'd have these bikeshedding discussions.