Things are never quite the same, but it is still interesting to remind oneself of experience in other languages.  History of numpy /scipy here:

http://wiki.scipy.org/History_of_SciPy

Would it have made the cut if it had had to meet an std.experimental level of quality in its earlier days ?  And the fact that it didn't allowed also for greater flexibility of development and for exploring multiple approaches (eventually recombined).

New growth often comes from the fringes and so won't be recognised until so many people are using it it can no longer be ignored.  It is important then to have less regulated interstices where such things can prove themselves.  So it might be worth asking directly the leading library authors what they think, since if people have no interest in filling out DIPs then it is good to know what the trade off might be (rigour versus creative work).

Just few quick questions:

1) what would it give over std.experimental ?
2) what would it give over code.dlang.org ?
3) what problems are you trying to solve and why do you think this is suitable solution?

On Sunday, 1 February 2015 at 09:28:42 UTC, HaraldZealot wrote:
> Approximately a half year ago I have similar idea and suggestion.

Thanks for your input. Yes, there are similarities, but there are also some differences. See some of my comments below:

> This is my idea:
> * make new feature in dub, that it can place some libraries in common namespace.
>
> For example CyberShadow's ae will be placed in something like advancex.image, or logger (lucky it is in std.experimental already, but as alternative history) is placed in stdx.logger. But they are not part of phobos in that time but usual dub package on dub registry.
>
> * create namespaces "advance" (or any other) for useful but not so common components (e.g. proposal windowing, image processing an so on), "bind" for Deimos. Phobos is "std" already :). And also create their experimental counterpart like "advancex", "bindx" and "stdx". (It can be other name but I prefer one worded "stdx" than two worded "std.experimental" in other level of hierarchy").

This differ from the "Drafting Library" proposal in the following points:
- modules/packages are owned/driven by one developer
- dub packages are not inclined to work out of the box with dmd release package


> * make new feature in dub and dub register that counts download, likes and bugs. When some package receives essential feedback it can be started pull request process.

By the "pull request process" you mean inclusion in Phobos? Then, in result, wouldn't it just mean: make the most popular dub package in some category a standard?


> For now I drive two interesting project, but I also try to find forces for this one.

The important thing about the proposal is to provide a process so one can be a part in creating the standard. You could contribute to drafts for the modules related to areas of your expertise.

Piotrek

On Sunday, 1 February 2015 at 14:40:17 UTC, Zach the Mystic wrote:
>> The intention of creating draft modules would be the inclusion in Phobos.
>> In simplistic way, the following stages of development will be applied:
>>
>> 1. Proposal (DIP, NG discussion, DUB package showcase, local meet-up events etc)
>> 2. Draft module creation and development
>> 3  Approval for Phobos merge, i.e. "draft" -> "std"
>
> I really can't see the difference between `std.experimental` and this. If `std.experimental` doesn't get used for this, `std.experimental` will end up a marginalized "experiment" itself. I think `std.experimental` runs the huge risk of not being recognized as what it is - i.e. a shop for building things (from scratch if necessary, IMO). If you're not worried about the name "Mars", why are you worried about `std.experimental`?

I initially thought about the "std.experimental", but came up to the conclusion that when modules are in drafting stage they shouldn't pollute the Phobos. Basically because the final standard is not defined.

A simple distinction can be seen as follows:
 draft - drafting
 std.experimental - piloting

The Drafting library can be omitted during DMD installation without any harm for Druntime and Phobos.

>> I briefly read the article and some parts are similar. However the difference is that Curiosity/Mars would form some kind of trinity with Druntime and Phobos. See also my answer to weaselcat's post (http://forum.dlang.org/post/mtqjtavxzjucixuycnlf@forum.dlang.org).
>>
>> Piotrek
>
> Yes, we're basically talking about the two categories I mentioned to begin with. You're focusing on those libraries which can be pre-approved as worthy of phobos. The way I figure it, only Andrei and Walter can ultimately give pre-approval for such libraries.

I don't treat Walter and Andrei as a blocking point. I think they will do anything is good for the language. Many time the D community initiated successful campaigns seconded by the key designers.


> But I think the second kind I mentioned -- high-quality libraries which aren't suited for phobos -- also need official, or at least prominent, recognition. It's really important for people not to have to investigate every program listed on code.lang.org in order to find high-quality existing code. I would even argue that such recognition is more important than the library you're proposing here (which already seems to exist with `std.experimental`).

I truly agree that there are many valuable DUB packages needing the advertisement.
However this is out of the scope of the proposal.

Piotrek

> came up to the conclusion that when modules are in drafting stage they
shouldn't pollute the Phobos

This is does not seem a strong enough point to warrant extra maintenance effort and extra newbie confusion.

On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote:
> Just few quick questions:

Hi

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

> 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

> 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.
IMO, this is a change in the direction how standards are made.

Piotrek

On Sunday, 1 February 2015 at 22:45:32 UTC, Dicebot wrote:
>> came up to the conclusion that when modules are in drafting stage they
> shouldn't pollute the Phobos
>
> This is does not seem a strong enough point to warrant extra maintenance effort and extra newbie confusion.

Newbie confusion? In what way?

Piotrek

On Sunday, 1 February 2015 at 22:54:51 UTC, Piotrek wrote:
> On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote:
>> Just few quick questions:
>
> Hi
>
>> 1) what would it give over std.experimental ?
>
> - draft modules will be more flexible for changes than in the ones in standard library

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.

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

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

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

>> 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. Any library that risks quick removal of deprecated modules / API is not acceptable for "standard" stamp.

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

On Sunday, 1 February 2015 at 22:57:07 UTC, Piotrek wrote:
> On Sunday, 1 February 2015 at 22:45:32 UTC, Dicebot wrote:
>>> came up to the conclusion that when modules are in drafting stage they
>> shouldn't pollute the Phobos
>>
>> This is does not seem a strong enough point to warrant extra maintenance effort and extra newbie confusion.
>
> 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 "-".

On Sunday, 1 February 2015 at 14:40:17 UTC, Zach the Mystic wrote:
> Yes, we're basically talking about the two categories I mentioned to begin with. You're focusing on those libraries which can be pre-approved as worthy of phobos. The way I figure it, only Andrei and Walter can ultimately give pre-approval for such libraries. But I think the second kind I mentioned -- high-quality libraries which aren't suited for phobos -- also need official, or at least prominent, recognition. It's really important for people not to have to investigate every program listed on code.lang.org in order to find high-quality existing code. I would even argue that such recognition is more important than the library you're proposing here (which already seems to exist with `std.experimental`). Meeting the pre-approval standards for phobos is a very high bar, and it certainly won't be the majority of high-quality libraries.

I tend to agree with this. I am not sure how another library with phobos level requirements would actually help. To me is seems like std.experimental, just with a different name.

The problems with code.dlang.org seem to be a more important thing to focus on. One thing that is a downside of code.dlang.org is that it is hard to tell which libraries are good, which are bad, and it is hard to find what does what.

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 really wish I knew website design, then I could help with some of this stuff rather than just talking about it.