Am 26.11.2015 um 21:41 schrieb Bruno Medeiros:
> 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.

Good point. I'd say "dub describe" should simply fail gracefully and just skip the "targets" and "dependencies" fields.

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

You can do "dub --print-builds --print-configs --annotate"

But it's currently uselessly bound to the build/run commands. Should definitely be part of "dub describe"'s output.

On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:
> Our house doesn't stand properly yet and we're discussing effin bikesheds.

+10

Everyones opinion is different, no one is right, no one is wrong - It's all just opinion.

The only thing it's served to do is piss off a very important contributor to the D ecosystem.

None of this thread matters - can we move on?

On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:
> On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:
>> Our house doesn't stand properly yet and we're discussing effin bikesheds.
>
> +10
>
> Everyones opinion is different, no one is right, no one is wrong - It's all just opinion.
>
> The only thing it's served to do is piss off a very important contributor to the D ecosystem.
>
> None of this thread matters - can we move on?

"It" being this thread.

On Friday, 27 November 2015 at 13:52:58 UTC, wobbles wrote:
> On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:
>> On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:
>>> Our house doesn't stand properly yet and we're discussing effin bikesheds.
>>
>> +10
>>
>> Everyones opinion is different, no one is right, no one is wrong - It's all just opinion.
>>
>> The only thing it's served to do is piss off a very important contributor to the D ecosystem.
>>
>> None of this thread matters - can we move on?
>
> "It" being this thread.

It also unleashes some critism people wouldn't have formulate otherwise.

And contrary to what people say, I think such topics give a dynamic aspect to the NG. Such topics are in a sense recreative and pleasant (fun) to read. The only thing to get is that this is not so serious.

On Friday, 27 November 2015 at 07:31:35 UTC, Jack Applegame wrote:
>
> Sublime Text configuration has a lot of comments:
>
> // Place your settings in the file "User/Preferences.sublime-settings", which
> // overrides the settings in here.
> //
> // Settings may also be placed in file type specific options files, for

Didn't know that.
Well it's not JSON then. It's a niche JSON-derivative.

On Friday, 27 November 2015 at 14:04:26 UTC, B.Basile wrote:
> On Friday, 27 November 2015 at 13:52:58 UTC, wobbles wrote:
>> On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:
>>> On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:
>>>> Our house doesn't stand properly yet and we're discussing effin bikesheds.
>>>
>>> +10
>>>
>>> Everyones opinion is different, no one is right, no one is wrong - It's all just opinion.
>>>
>>> The only thing it's served to do is piss off a very important contributor to the D ecosystem.
>>>
>>> None of this thread matters - can we move on?
>>
>> "It" being this thread.
>
> It also unleashes some critism people wouldn't have formulate otherwise.
>
> And contrary to what people say, I think such topics give a dynamic aspect to the NG. Such topics are in a sense recreative and pleasant (fun) to read. The only thing to get is that this is not so serious.

If anything, this thread shows that there has to be more communication between the developers. It's detrimental, when discontent builds up behind the scenes only to erupt suddenly over a minor issue.

There are two things at loggerheads here: a) the call for strong leadership and b) the desire to make decisions based on open discussions within the community.

It's certainly not easy to find the right balance, which is why better communication is of utmost importance. The odd email might help to get people out of their bikesheds to discuss the color of the door.

On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:
> There are two things at loggerheads here: a) the call for strong leadership and b) the desire to make decisions based on open discussions within the community.
>
> It's certainly not easy to find the right balance, which is why better communication is of utmost importance.

What balance? Discussion is the way to communicate leadership, i.e. to make things work without micromanagement.

On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:

>
> If anything, this thread shows that there has to be more communication between the developers. It's detrimental, when discontent builds up behind the scenes only to erupt suddenly over a minor issue.
>
> There are two things at loggerheads here: a) the call for strong leadership and b) the desire to make decisions based on open discussions within the community.
>
> It's certainly not easy to find the right balance, which is why better communication is of utmost importance. The odd email might help to get people out of their bikesheds to discuss the color of the door.

My _personal_ impression is that projects like DUB that are not part of DLang, but are part of "offical D", are not tied fast enough to official D. If we find a strategy to tie anything that is part of "official D", but may live in a separate repos, faster to D, threads like this can be avoided.

Peace pipe?

On Friday, 27 November 2015 at 15:04:15 UTC, Kagamin wrote:
> On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:
>> There are two things at loggerheads here: a) the call for strong leadership and b) the desire to make decisions based on open discussions within the community.
>>
>> It's certainly not easy to find the right balance, which is why better communication is of utmost importance.
>
> What balance? Discussion is the way to communicate leadership, i.e. to make things work without micromanagement.

Yes. But a (well-informed) decision has to be made at some point. And it's the leaders who have to make them. I often find myself agreeing with both sides, I'd be terrible at making decisions.

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.