I hate new DUB config format

[Walter Bright via Digitalmars-d]

On 11/26/2015 11:08 PM, Sönke Ludwig wrote:
>> 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".

I would say to that: "famous last words". As Exhibit A, I submit 'static if', 
which has been getting increasing pressure to augment with loops.


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

You have to deal with that even if just plain json or sdl. After all, the 
implementation of those formats could be susceptible to buffer overflow or DoS 
as well. But this is less likely with json, because you'd be using a well-used 
json parser rather than your own sdl parser that is only used for Dub. (Yes I 
saw later that you use it in some other projects, but does it see use outside of 
your own things?)

Javascript can only interact with its environment using the DOM. If Dub 
presented its own DOM to the js engine, there isn't much the js code can do 
other than go into an infinite loop, recursive overflow, or exploit a buffer 
overflow.

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

I would think these problems have all been solved with Javascript, since it is 
used so extensively. Javascript is also a lightweight scripting language.


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

That goes back to restricting the DOM.


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

True, but consider this. JSON is a subset of Javascript. That means you could 
add a subset of Javascript to JSON, i.e. just the if statements. You'll have a 
clear design for it, and a clear path for how to do further enhancements.


>> "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,

The existence of the DEPs suggest otherwise, the number of posts in this thread 
suggest otherwise, the calls for a gui editor suggest otherwise, the customer 
"should I use json or sdl" makes for an ongoing support problem, no current 
means to convert between the two, etc.


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

The time for JSON was zero. You're a key developer here, and your time is very 
valuable. I can't tell you what to work on, but I can't be quiet about spending 
time on things with such marginal utility (and yes, I waste time, too). By using 
sdl, though, you're also spending other peoples' time, even if it's just "which 
format should I use for my project?" and then the D forum members have to advise 
them.


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

I'm not accepting the "ugly and highly inconvenient hack" argument in the light 
of the DEP4 proposal for conditional syntax that I already commented on. And, as 
mentioned before, I use $(COMMENT ...) in Ddoc and it works out quite nicely, 
even though Ddoc has no syntax for comments.

And if comments were the only reason to use sdl, and a solid case was made for 
them vs my suggestion, I'd vastly prefer adding /**/ to the json support rather 
than switching to an apparently dead format.


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

Sticking with json would enable you to simply ignore it. But you've been pretty 
much forced to engage in this one.