On Monday, 2 February 2015 at 03:58:44 UTC, Tofu Ninja wrote:
> One thing that would definitely help with the situation is a better code.dlang.org site with ratings, tags, categories, and comments. Also it would be great to advertise some of the better packages by putting them on a more prominent display in something like a "featured" section.

I think this is much better approach in the long-term. CI result integration fits the same purpose.

This is one task where getting some paid help from professinal web devs may be important.

On Sunday, 1 February 2015 at 22:54:51 UTC, Piotrek wrote:
> On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote:
>> 1) what would it give over std.experimental ?
>
> - draft modules will be more flexible for changes than in the ones in standard library
> - new drafting modules won't disturb usual users of the standard library
>
> IMO, std.experimental is not for the drafting stage of the SW development.

I don't see the return on investment for making a big distinction between a draft and a more polished, but still not guaranteed library. The big line that needs to be drawn is whether any given task is or is not an appropriate target for the standard library. Once something passes that stage, it needs to be decided whether the API is in flux (e.g. std.experimental) or stable (e.g. std proper). An additional distinction between "more in flux" (your idea) and "less in flux" (std.experimental) is both less useful and quite possibly dangerous:

The big temptation for software developers is to *promise* stability in order to attract the users they need in order to get the feedback they need in order to create the best possible design, and then break stability with the new design. By dividing libraries into the hazy "more in flux" and "less in flux" categories, one is simply deferring the hard choice between "stable" and "not stable", and likely to start making promises one cannot -- or worse, does not even intend to -- keep as a result.

Therefore, I think std.experimental is for all "in flux" APIs, from the drafting stage to the later "less in flux" stages. The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is.

On Sunday, 1 February 2015 at 23:21:36 UTC, Dicebot wrote:
> As per latest agreement everything in std.experimental is considered subject to any change so is perfectly flexible.
>



>> - new drafting modules won't disturb usual users of the standard library
>
> That statements needs some hard data that current situation is disturbing to be considered as a rationale.

If you put to many uncompleted modules in the std.experimental it can influence stable part of the Phobos.

- binary size
- pull request with more experimental stuff
etc.

>> IMO, std.experimental is not for the drafting stage of the SW development.
>
> Depends on your definition of "draft". Anything that is good enough to be actually used in real app is good enough for std.experimental - and anything less is of no use to end user anyway.

I agree that all is a matter of definition. I still doubt that fast evolving drafts would be possible in std namespace.

>>> 2) what would it give over code.dlang.org ?
>>
>> - community driven as opposed to individual driven
>> - out of the box readiness
>> - minimal fragmentation and controversy
>
> code.dlang.org is actually much more community driven because it is naturally decentralized. Controversy is inevitable anyway (hello std.json).

I used the "community driven" in contrast to "individually driven". The key property of the proposal is to minimize the controversy by community (common) drafting process.

> Fragmentation is a thing though - but I yet to be convinced that is a bad thing that needs to be fixed.

I consider fragmentation a major problem for standards.

>>> 3) what problems are you trying to solve and why do you think this is suitable solution?
>>
>> Adding new modules (replacing the deprecated ones) in more robust and quicker manner.
>
> It is as quick as it can be for standard library - and code.dlang.org takes care of everything else.

I have non-trivial modules in mind like gui, json, database, etc.

> Any library that risks quick removal of deprecated modules / API is not acceptable for "standard" stamp.


The drafting lib is a proposition of standard not a standard itself.
And I didn't said anything about removal. I was referring to:

"Warning: This module is considered out-dated and not up to Phobos' current standards. It will remain until we have a suitable replacement, but be aware that it will not remain long term."

> So far this does not seem a proposal that pulls own weight to me.

I can put the burden on my shoulders.

I'm in the middle of DIP creation. Unfortunately I have a regular job and other duties. Still, I hope to finish it as soon as promised.

Piotrek

On Sunday, 1 February 2015 at 23:22:55 UTC, Dicebot wrote:
>> Newbie confusion? In what way?
>
> What library to use between Phobos and Mars, why those are separate, why those have different stability guranatees, where to submit new contributions, why bother - it all would need to be written down and explained over and over again. And this alone is huge "-".

IMO, there is no more confusion than using std.experimental vs other modules. Drafting modules are for developing functionality not present in Phobos, but build upon Phobos foundation.

I admit I don't understand where confusion may come from. I will pay more attention to it as you described it as a huge problem.

Piotrek

On Monday, 2 February 2015 at 06:07:29 UTC, Zach the Mystic wrote:
> Therefore, I think std.experimental is for all "in flux" APIs, from the drafting stage to the later "less in flux" stages.

Definitely this is what I thought initially. But, IMO, it can be really hard or impossible to carry out, as you pointed one of the issues in the following part:

> The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is.

Hence the *proposal* of the drafting library.

Piotrek

On Monday, 2 February 2015 at 20:09:42 UTC, Piotrek wrote:
> On Monday, 2 February 2015 at 06:07:29 UTC, Zach the Mystic wrote:
>> Therefore, I think std.experimental is for all "in flux" APIs, from the drafting stage to the later "less in flux" stages.
>
> Definitely this is what I thought initially. But, IMO, it can be really hard or impossible to carry out, as you pointed one of the issues in the following part:
>
>> The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is.
>
> Hence the *proposal* of the drafting library.
>
> Piotrek

I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be "sort of" experimental, but really not, whereas mars is "really actually" experimental? Where is the cutoff line? How would anyone know whether they reached it or not?

My attitude is that any given module in std.experimental should simply indicate its current level stability at the top of its documentation - full disclosure about where it is from, say, 0 to 95%, (with anything above that already assumed qualified for std proper).

I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, "This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module."

On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic wrote:

> I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be "sort of" experimental, but really not, whereas mars is "really actually" experimental? Where is the cutoff line? How would anyone know whether they reached it or not?

Hard to admit but I thought about removal of std.experimental ;), then I tried to find a better solution (not sure I did). After all I don't want to make more enemies than I have.

So I got an idea that std.experimental can be adopted for the piloting new modules into Phobos when approved to be a standard.

After Wikipedia:
"A pilot project refers to an initial roll-out of a system into production"

> My attitude is that any given module in std.experimental should simply indicate its current level stability at the top of its documentation - full disclosure about where it is from, say, 0 to 95%, (with anything above that already assumed qualified for std proper).

Yes, the drafting stage can have many sub-stages, but I didn't want to complicate the initial proposal too much and risk both low chance of the approval and later, inability of proper implementation. I learned that there can be taken only limited steps at once.

> I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, "This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module."

Haha, let's not lose our nerves :) It's not that bad. Moreover. I can barely find  the equivalent level of code awesomeness as it is in D libraries. We just need to speed up the progress and reduce work fragmentation.

Piotrek

On Monday, 2 February 2015 at 22:18:59 UTC, Piotrek wrote:
> On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic wrote:
>
>> I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be "sort of" experimental, but really not, whereas mars is "really actually" experimental? Where is the cutoff line? How would anyone know whether they reached it or not?
>
> Hard to admit but I thought about removal of std.experimental ;), then I tried to find a better solution (not sure I did). After all I don't want to make more enemies than I have.
>
> So I got an idea that std.experimental can be adopted for the piloting new modules into Phobos when approved to be a standard.

I'm arguing from the perspective that the approval must come first, and the piloting second. Who would want to develop a module in the "pre-pilot" phase, without having any idea of whether they were developing it finally for phobos or just 3rd-party use, then wait months or years to find out if the leadership is even *interested* in what they're doing? Why would people try to meet high standards without knowing if those standards are actually going to be required or not? It's like an unpaid internship: "Work for us for free, and we'll let you know at the end whether we want your work or not."

>> I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, "This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module."
>
> Haha, let's not lose our nerves :) It's not that bad. Moreover. I can barely find  the equivalent level of code awesomeness as it is in D libraries. We just need to speed up the progress and reduce work fragmentation.

It occurred to me that when copying a module to std.experimental, the documentation at the top of the original std module should say, "This module has been feature frozen while work on the new one continues at std.experimental.xxxx. The API for this module will not break, nor will it be improved. Please consider using std.experimental.xxxx and giving feedback for its design, since eventually this module will be replaced with that one."

I do realize that this is kind of what happened with D1 and D2, of course. Now you're going to have competing modules, and some people won't want to give up on the old one. So you will have to deprecate every change that breaks the old API first before finally replacing it with the new one. Well, it's a hard problem, and yet, "Most D code has yet to be written." But then again, I'm not the one who has to take fire for breaking people's old code, and I don't know if my attitude would change if I were.

On Tuesday, 3 February 2015 at 02:38:57 UTC, Zach the Mystic wrote:
> I'm arguing from the perspective that the approval must come first, and the piloting second. Who would want to develop a module in the "pre-pilot" phase, without having any idea of whether they were developing it finally for phobos or just 3rd-party use, then wait months or years to find out if the leadership is even *interested* in what they're doing? Why would people try to meet high standards without knowing if those standards are actually going to be required or not? It's like an unpaid internship: "Work for us for free, and we'll let you know at the end whether we want your work or not."

Al least the module will be available in draft namespace until controversy is resolved. I don't think there would be any blocking campaign without providing sane requirements to move on.

BTW. I tried to publish the DIP but got into the following issue:
http://forum.dlang.org/post/yoqwuqhtlpifgwudeevm@forum.dlang.org
It looks the DIP will be delayed at least by day.

Piotrek