Should we try to implement yet another language for writing building config? Maybe we should use any of existence language that may be very good for it, like Red. It have very small foot prints so it can be easy to embeded to build system.

On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:
> Should we try to implement yet another language for writing building config?

No, I wasn't really talking about a build system for D, more like a hypothetic generic distributed build system for all languages. But I've read that Google uses a distributed build system for their big C++ applications. So people are working on such solutions already.

> Maybe we should use any of existence language that may be very good for it, like Red. It have very small foot prints so it can be easy to embeded to build system.

I've never heard of Red, do you have a link?

On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:
> Should we try to implement yet another language for writing building config? Maybe we should use any of existence language that may be very good for it, like Red. It have very small foot prints so it can be easy to embeded to build system.

I really don't think so. There are plenty of perfectly good languages available, D being one of them. The other ones you can write reggae builds in are Python, Ruby, Javascript and Lua.

Atila

On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:
> Should we try to implement yet another language for writing building config? Maybe we should use any of existence language that may be very good for it, like Red. It have very small foot prints so it can be easy to embeded to build system.

-The only winning choice is not to choose.

I'm kinda spoiled by rdmd, I honestly don't see why I should go back to using config files again, pragma(lib) already exists and one could extend it with UDA:s for more advanced use-cases. Well, never mind. Most ppl seem happy with DUB:s approach though, so I guess it's just me.

On Monday, 30 November 2015 at 21:05:08 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:
>> Should we try to implement yet another language for writing building config?
>
> No, I wasn't really talking about a build system for D, more like a hypothetic generic distributed build system for all languages. But I've read that Google uses a distributed build system for their big C++ applications. So people are working on such solutions already.
>
>> Maybe we should use any of existence language that may be very good for it, like Red. It have very small foot prints so it can be easy to embeded to build system.
>
> I've never heard of Red, do you have a link?

Red started out as a Rebol 2 clone and last I checked (18 months ago) it was still is Rebol 2 compatible.

http://www.red-lang.org/

bye,
lobo

On Tuesday, 1 December 2015 at 02:46:46 UTC, lobo wrote:
> On Monday, 30 November 2015 at 21:05:08 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:
>>> [...]
>>
>> No, I wasn't really talking about a build system for D, more like a hypothetic generic distributed build system for all languages. But I've read that Google uses a distributed build system for their big C++ applications. So people are working on such solutions already.
>>
>>> [...]
>>
>> I've never heard of Red, do you have a link?
>
> Red started out as a Rebol 2 clone and last I checked (18 months ago) it was still is Rebol 2 compatible.
>
> http://www.red-lang.org/
>
> bye,
> lobo

I believe the main difference between Red and Rebol2 is that Red exposes more of the H/W driver and OS layers.

Although I admit to coming in late to a big bikeshed-fest, I have some opinions on configuration file formats from having seen younger, non-technical end users try to configure their own game servers. The support cost of misconfiguration due to syntax error is enormous. Gob-stoppingly huge. It is day after day of

Q: hey it's broke fix it
A: you forgot to add a double quote in your config file

And so when the file format is pressed into the role of primary UI, and is touched directly by hundreds or thousands of people, who want to write things that are more than a few trivial lines, relying only on JSON, which biases towards parser and programmer friendliness, not towards forgiving syntax, is not the right trade-off for total human effort and the stress levels of project maintainers. Those files are source code and need the additional care and forgiving structure of a source code language. If you want externally-generated configurations, then JSON is the right move, but it is not a complete design - it's passing the buck to users.

For similar reasons there are a lot of interfaces and formats for writing documents and nobody is entirely happy with any of them. It's easy to write simple things in Markdown variants, but complex material pushes against the feature boundaries. You can do pretty much everything with DocBook or TeX, but they're a chore. Word processing tools can smooth out the problem of discovering features, but again restrict your control and emit weird markup in the process. The happy medium workflow tends to involve writing in a "light" format and then transferring content to the "heavy" one to merge it and add finishing touches.

A year or two ago I spent a lot of time thinking about source-vs-serialization trade-offs. When you can get bi-directional serialization and ensure that pretty-printed output looks like the original input, you lose some freedom on the end of the user being allowed to make mistakes or change up their style partway through. Sometimes you want that, and sometimes you don't, and it really does depend on the context you're putting that format into.

If you look at Lisp family languages, for example, they take an extreme posture on bi-di behavior in that "code is data and data is code", but that also means that their ecosystem is defined around having s-expression-friendly editors and a coding style that biases a bit more towards using powerful language extension tools. And it's another valid way to go with configuration formats, of course. It would make sense to jump all the way over to a script interpreter if, as got mentioned earlier in this thread, SDL were to start being extended to do "programming-like" things.

FWIW, I'm tempted to take the side of "make JS the default, compile existing SDL and JSON to JS when run, add compilers for TOML or YAML if there's demand". If you make code your lowest common denominator, nothing else matters, and JS is the de-facto lowest common denominator of code, today. Someone presented with a config whose syntax they don't know can tell Dub to port it to JS and edit that instead, and so over time all configs end up being a blob of JS code, in the same way that the "light"/"heavy" markup situation is resolved by gradually converting everything into the heavy format even if it didn't start there. That is OK. Dub might run a bit slower, and there are some security issues raised from it, but the world is unlikely to blow up because someone wrote "clever" JS in their Dub config.

Also, people will see the option of coding JS and go, "Now I can write a build system on top of Dub, and it can use my own config format, way better than SDL or YAML or TOML! Everyone's gonna love this!" The D and Dub maintainers smile innocently and say nothing...

On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann wrote:
>
> FWIW, I'm tempted to take the side of "make JS the default, compile existing SDL and JSON to JS when run, add compilers for TOML or YAML if there's demand". If you make code your lowest common denominator, nothing else matters, and JS is the de-facto lowest common denominator of code, today. Someone presented with a config whose syntax they don't know can tell Dub to port it to JS and edit that instead, and so over time all configs end up being a blob of JS code, in the same way that the "light"/"heavy" markup situation is resolved by gradually converting everything into the heavy format even if it didn't start there. That is OK. Dub might run a bit slower, and there are some security issues raised from it, but the world is unlikely to blow up because someone wrote "clever" JS in their Dub config.
>
> Also, people will see the option of coding JS and go, "Now I can write a build system on top of Dub, and it can use my own config format, way better than SDL or YAML or TOML! Everyone's gonna love this!" The D and Dub maintainers smile innocently and say nothing...

Sorry, I think that most of what you said made good sense, but I am a bit confused by the quoted bit.  So you want the DUB config files written in full-blown JavaScript? Then DUB and the other tools would need a JavaScript compiler built-in.

On Tuesday, 1 December 2015 at 02:46:46 UTC, lobo wrote:
> On Monday, 30 November 2015 at 21:05:08 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:
>>> Should we try to implement yet another language for writing building config?
>>
>> No, I wasn't really talking about a build system for D, more like a hypothetic generic distributed build system for all languages. But I've read that Google uses a distributed build system for their big C++ applications. So people are working on such solutions already.
>>
>>> Maybe we should use any of existence language that may be very good for it, like Red. It have very small foot prints so it can be easy to embeded to build system.
>>
>> I've never heard of Red, do you have a link?
>
> Red started out as a Rebol 2 clone and last I checked (18 months ago) it was still is Rebol 2 compatible.
>
> http://www.red-lang.org/
>
> bye,
> lobo

Red is not Rebol2 compatible - it's outright impossible to have a single script file that'll run without errors on both Rebol2 and Red. The reason is that Rebol2 requires the first thing in the file to be a `REBOL` preamble, while Red requires it to be a `Red` preamble(though it's generous enough to allow a shebang before it). Since you can only have one preamble, and it can't be both `REBOL` and `Red`, I refuse to call them compatible even if every Rebol2 command can be copied to a Red script and run in there!

At any rate, please don't use any Rebol dialect in DUB(or for anything else, in that matter. Just - don't use it). Many languages have awkward quirks, but Rebol seems to be a collection of awkward quirks with a programming language somtimes accidentally hiding in between, created by someone who thought Perl is too readable and shell scripts have too strict type systems.

On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann wrote:
> Although I admit to coming in late to a big bikeshed-fest, I have some opinions on configuration file formats from having seen younger, non-technical end users try to configure their own game servers. The support cost of misconfiguration due to syntax error is enormous. Gob-stoppingly huge. It is day after day of
>
> Q: hey it's broke fix it
> A: you forgot to add a double quote in your config file
>
> And so when the file format is pressed into the role of primary UI, and is touched directly by hundreds or thousands of people, who want to write things that are more than a few trivial lines, relying only on JSON, which biases towards parser and programmer friendliness, not towards forgiving syntax, is not the right trade-off for total human effort and the stress levels of project maintainers. Those files are source code and need the additional care and forgiving structure of a source code language. If you want externally-generated configurations, then JSON is the right move, but it is not a complete design - it's passing the buck to users.

Yes, _all_ configuration file formats become a mess once you do non-trivial stuff. However, for what you describe above, you shouldn't have users edit JSON directly. If you deal with UI stuff, have hundreds and thousands of people working on it, people who are non-technical, you should use automated WYSIWYG tools like Glade. Even a technical person might have difficulties making non-trivial changes to huge configuration files manually.

[snip]

>
> FWIW, I'm tempted to take the side of "make JS the default, compile existing SDL and JSON to JS when run, add compilers for TOML or YAML if there's demand". If you make code your lowest common denominator, nothing else matters, and JS is the de-facto lowest common denominator of code, today. Someone presented with a config whose syntax they don't know can tell Dub to port it to JS and edit that instead, and so over time all configs end up being a blob of JS code, in the same way that the "light"/"heavy" markup situation is resolved by gradually converting everything into the heavy format even if it didn't start there. That is OK. Dub might run a bit slower, and there are some security issues raised from it, but the world is unlikely to blow up because someone wrote "clever" JS in their Dub config.
>
> Also, people will see the option of coding JS and go, "Now I can write a build system on top of Dub, and it can use my own config format, way better than SDL or YAML or TOML! Everyone's gonna love this!" The D and Dub maintainers smile innocently and say nothing...

Ain't gonna happen. I don't think anyone is interested in making DUB dependent on JS or any other 3rd party scripting language, e.g. Lua (which I like) or Ruby. I suppose DUB will always rely on home made D solutions, and it should.