On 11/26/2015 2:27 PM, CraigDillabaugh wrote:
>>> 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!


https://www.youtube.com/watch?v=Jdf5EXo6I68&feature=player_detailpage#t=50

On Friday, 27 November 2015 at 15:18:38 UTC, Chris wrote:
> 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.

It is terribly expensive to postpone the decision making to after the design process.

If you didn't participate in the design process... then you essentially delegated responsibility, and then it is your own responsibility to back whatever they did as long as it isn't completely unreasonable.

Or else your own ass are on fire because you failed to participate and lead (and you should be dismantled as a leader).

Right?

On Friday, 27 November 2015 at 15:29:38 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 27 November 2015 at 15:18:38 UTC, Chris wrote:
>> 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.
>
> It is terribly expensive to postpone the decision making to after the design process.

That's why I said that (timely) communication is of utmost importance. Post factum decisions are bound to cause trouble.

> If you didn't participate in the design process... then you essentially delegated responsibility, and then it is your own responsibility to back whatever they did as long as it isn't completely unreasonable.
>
> Or else your own ass are on fire because you failed to participate and lead (and you should be dismantled as a leader).
>
> Right?

On Friday, 27 November 2015 at 15:35:32 UTC, Chris wrote:
> That's why I said that (timely) communication is of utmost importance. Post factum decisions are bound to cause trouble.

Yes, I agree. So then one should just stand by whatever the maintainer has chosen, because he is more likely to have considered what is needed in terms of current and future needs.

What do people need to write their puny config files? A webpage with typical examples, commented and explained. Cut'n'paste.

Besides that, javascript is a horrible format for hand editing. In fact, any curly braced format is bad. Misplace one brace and things break in hard to figure out ways.

This is what is good about XML, the end markers are clear and makes automatic resolution possible even in loose grammars. I'll never really understand why people consistently fail to understand why SGML is designed the way it is.

On Friday, 27 November 2015 at 15:49:48 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 27 November 2015 at 15:35:32 UTC, Chris wrote:
>> That's why I said that (timely) communication is of utmost importance. Post factum decisions are bound to cause trouble.
>
> Yes, I agree. So then one should just stand by whatever the maintainer has chosen, because he is more likely to have considered what is needed in terms of current and future needs.

Basically yes. But if it concerns "offical D" things should be synchronized better.

> What do people need to write their puny config files? A webpage with typical examples, commented and explained. Cut'n'paste.
>
> Besides that, javascript is a horrible format for hand editing. In fact, any curly braced format is bad. Misplace one brace and things break in hard to figure out ways.
>
> This is what is good about XML, the end markers are clear and makes automatic resolution possible even in loose grammars. I'll never really understand why people consistently fail to understand why SGML is designed the way it is.

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:
>>>> On 2015-11-25 11:17, Suliman wrote:
>>>>> [...]
>>>>
>>>> BTW, why was not TOML [1] chosen? I know it was discussed but I
>>>> can't remember why SDL was preferred. I think TOML is more
>>>> widely used than SDL [2]. GitLib CI multi runner is also using
>>>> it.
>>>>
>>>> [1] https://github.com/toml-lang/toml
>>>> [2] https://github.com/toml-lang/toml#projects-using-toml
>>>
>>> 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)

Very well indeed. Sonke needs to respond to this.

By Sonkes own admission json does everything we need except comments. These configuration files are what 50 lines long? And there is an easy workaround. Seriously our problem we dont have nice comments for tiny files? So lets use a language nobody else wants to use? How dod we get to this point?

Andrei is an ass sometimes. But his point is valid. Now we have Sonke all offended but do not mix it the technical point. And of course Douchebot had to come out of the woodwork. Worst thing about D leadership is they didn't rid the community of persons like him. But that should not detract from the main point - SDL is a bad decision any way you look at it. It should be undone.

On Friday, 27 November 2015 at 15:58:40 UTC, Chris wrote:
>
> Basically yes. But if it concerns "offical D" things should be synchronized better.

Maybe defining what the inclusion process for "official D" is and set down policies for decision making processes and quality assurance for those projects that are included, then?

But what D really needs is to complete the language spec and clean up the core language.

No other activity will matter in the long run, IMO.

On Friday, 27 November 2015 at 16:27:07 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 27 November 2015 at 15:58:40 UTC, Chris wrote:
>>
>> Basically yes. But if it concerns "offical D" things should be synchronized better.
>
> Maybe defining what the inclusion process for "official D" is and set down policies for decision making processes and quality assurance for those projects that are included, then?

Yep. Something along these lines.

> But what D really needs is to complete the language spec and clean up the core language.
>
> No other activity will matter in the long run, IMO.

DUB does matter, because it's the official package manager and is used by developers and will likely be used by newcomers too. It should offer as good a user experience as possible.

On 2015-11-27 10:24, Ola Fosheim Grøstad wrote:

> Well, I usually don't use package managers for source code, but if I did
> I would not consider using one that can write to random directories.
>
> So if one uses Ruby, Python or D, the package manager has to make sure
> it executes in a "jail filesystem sandbox" that only can touch a
> specific subtree.

RubyGems works like this:

1. The author of a tool writes the package description in Ruby
2. The author then builds a gem (package) using the tool
3. The tool serializes/converts the Ruby code to YAML in the gem
4. The author uploads the gem using the tool

Then when a gem is installed the tool will only have access to the YAML file and reads that. The only one that have access to and need to run the Ruby code is the author.

-- 
/Jacob Carlborg

On Friday, 27 November 2015 at 16:32:57 UTC, Chris wrote:
> DUB does matter, because it's the official package manager and is used by developers and will likely be used by newcomers too. It should offer as good a user experience as possible.

Yes, it isn't irrelevant and end users should of course express where it cause them head aches it it does.

However, it does not affect adoption. I don't think high quality libraries will be held back from publication over a config format. Maybe some shitty ones with an uncertain lifespan (and good riddance for that).

A config format is not difficult to replace or convert into another format at a later stage, especially if it is hosted centrally (just have a different request protocol for the new format).

---

The real question is: how much money (time) can one afford to spend on fringe activities and mutation when the core issues that need attention are costly (time) to fix?

Priorities.

I've noticed that non-commercial Open Source projects often appear to not understand that they have a limited implicit budget (hours and goodwill).

C++, Go, Rust, Swift, TypeScript and Dart are all pretty commercially driven projects. They can waste volunteer resources without consequences.

The current D priorities seems to be:
- C++ exception handling
- More containers
- Config file format

Neither are likely to have a significant impact.