On Thursday, 26 November 2015 at 20:47:18 UTC, wobbles wrote:
> 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!

Andrei is a gentleman compared to Linus in this case. :)

Matheus.

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.


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

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.


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

V Thu, 26 Nov 2015 22:27:06 +0000
CraigDillabaugh via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

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

You can still maintain  selected version (0.4 in toml for example).

Maintaining parser for dead language where is not easy to find out specs is definitely not easier :).

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.

On 2015-11-26 23:38, BLM768 wrote:

> 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

I has worked fine for me.

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

This is (one of the reasons) why people complain. The problem with D is that it won't be pretty.

-- 
/Jacob Carlborg

On 2015-11-26 21:03, Suliman wrote:

> Why?

This is why [1]. Also, many developers here seem to have something against Ruby, in general. Or at least they don't want a single piece of Ruby code near D.

I contributed a build script for the OS X installer, written in Ruby. Eventually it was converted to shell script.

[1] http://forum.dlang.org/post/n38vv7$lnf$1@digitalmars.com

-- 
/Jacob Carlborg

On 2015-11-27 08:08, Sönke Ludwig wrote:

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

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

Personally I think Dub and code.dlang.org is designed completely wrong. Currently Dub works by the user pushing new code to the repository on GitHub and code.dlang.org watching for changes. If the user instead would use Dub to build a package locally which is then uploaded to code.dlang.org you would have less of these issues. The code would be executed on the client and serialized to a data format (JSON, XML, YAML, whatever) that no person will ever see. code.dlang.org would then read this data format, instead of executing the code, just like it's doing now.

-- 
/Jacob Carlborg

On Thursday, 26 November 2015 at 09:41:38 UTC, ponce wrote:
> On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko wrote:
>>
>> Single language, json based configuration engine is simpler for IDE development and configuration tools. For example, Sublime Text.This is very important to make language used by big amount of users.
>>
>> Ilya
>
> Sublime Text configuration has no comments and this kind of sucks compared to eg. a webserver key-value configuration file, or sc.ini, so I'm not sure you chose the best example.

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
// example, in Packages/Python/Python.sublime-settings for python files.
{
    // Sets the colors used within the text area
    "color_scheme": "Packages/Color Scheme - Default/Monokai.tmTheme",

    // Note that the font_face and font_size are overridden in the platform
    // specific settings file, for example, "Preferences (Linux).sublime-settings".
    // Because of this, setting them here will have no effect: you must set them
    // in your User File Preferences.
    "font_face": "",
    "font_size": 10,

    // Valid options are "no_bold", "no_italic", "no_antialias", "gray_antialias",
    // "subpixel_antialias", "no_round" (OS X only), "gdi" (Windows only) and
    // "directwrite" (Windows only)
    "font_options": [],

Am 27.11.2015 um 08:29 schrieb Jacob Carlborg:
> Personally I think Dub and code.dlang.org is designed completely wrong.
> Currently Dub works by the user pushing new code to the repository on
> GitHub and code.dlang.org watching for changes. If the user instead
> would use Dub to build a package locally which is then uploaded to
> code.dlang.org you would have less of these issues. The code would be
> executed on the client and serialized to a data format (JSON, XML, YAML,
> whatever) that no person will ever see. code.dlang.org would then read
> this data format, instead of executing the code, just like it's doing now.
>

That would mean more work for everyone and consequently less adoption. Seriously, I think it's the best approach possible and really couldn't imagine using a more manual system to the extend that I do now. But more importantly, it would mean that we have a problem with cross-platform packages. You can't expect everyone to be able to build for all platforms. But if they don't, you can't know the dependencies or whatever else for those other platforms, even if the code would in theory compile fine.

On Friday, 27 November 2015 at 07:08:40 UTC, Sönke Ludwig wrote:
> 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 think conditions in msbuild are neat:
<PropertyGroup Condition="'$(StyleCopEnabled)' == ''">
  <StyleCopEnabled>true</StyleCopEnabled>
</PropertyGroup>
You can make any tag conditional by adding a Condition attribute to it without creating an additional nesting level. Though it has condition grammar.
It has variables too:
<CreateItem
  Include="@(Compile)"
  Exclude="
  %(Project.RootDir)%(Project.Directory)**\*Test.cs;
  %(Project.RootDir)%(Project.Directory)**\*.Designer.cs">
  <Output TaskParameter="Include" ItemName="StyleCopFiles"/>
</CreateItem>
This takes compiled files, removes unneeded ones and subsequently the resulting files (StyleCopFiles) are fed to a style analyzer tool.

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

Also in the dependencies map keys are package names so {"comment": "..."} will be a dependency on a comment package.