On Thursday, 5 February 2015 at 06:56:52 UTC, Dicebot wrote:
> You have clearly put a lot of effort in this. That makes me very uneasy to repeat the same critique as earlier but, sadly, it still all applies. This proposal tries to fix problems it doesn't prove exist, doing so with solutions that are not guranteed to help.

No need to be sorry. D needs quality guards.

> It also wrongly explains current process of inclusion into Phobos in general and specifically std.experimental - being probably one of more involved persons with Phobos review queue I feel like this needs to be explained.
>
> Considering all the discussion that happened during std.experimental.logger I understand that we have settled with pretty much this:
>
> 1) All Phobos proposals must go through std.experimental.logger

When you say I put the current process wrongly, you mean there is no way to submit a new module avoiding a std.experimental namespace? Or something else? Can you provide a link to the latest official description? I will update the pictures.

> 2) It must implement something generally desired in Phobos
Which is?

> 3) Implementation is supposed to be at least stable enough to not undergo a full rewrite after inclusion. Major API changes are acceptable.

This point is one of the main problems the DIP tries to avoid.
According to your statement the module should be almost complete before the pull request is accepted. I mean without any design flows. In many cases that is really hard to achieve for one developer (e.g gui).
OTOH if you don't see the full implementation and can't test it you may not see the fundamental flows in design.
Of course this may be doable for less complex modules. Then the current way of using  std.experimental alone may be applicable.

> 4) Before DMD/Phobos release is made existing packages that feel stable can undergo a formal review for inclusion in Phobos main package
>
> With that in mind initial public review is supposed to only determine if (2) and (3) is true which is mostly a formality as people rarely propose modules they are not serious about.

How could you be sure that after long lonely work the proposal is worth inclusion?

> As you may see requirements are very lax. Only real difference is that your poposal allows to accept modules that are not supposed to ever go to Phobos at all - which I am still convinced is a bad thing and belongs to code.dlang.org

How do you know what modules should not be in Phobos? Is there any widely accepted list? Even C++ is getting more "open minded".

> Speaking about objections vs code.dlang.org
>
>> community driven development as opposed to individually driven (ownership/control of the source code)
>
> see no reason to expect this is actually better of makes any notable difference in general
>> out of the box readiness
>
> dub is planned to be distributed with DMD
>
>> wide range of community members involved in the development to reduce controversy and fragmentation staring from the initial stage
>
> no idea where this even comes from

Maybe I'm wrong but there is a big controversy and fragmentation e.g. in database and gui domain.

> Pretty much all extra goodies from DIP73 can be implemented by creating special "officially endorsed" category in code.dlang.org and showing it as a default package list at code.dlang.org front page

This may lead to competing packages. How would we decide what are the "proper" packages. There can be impossible to fully control the development by the whole community (yes I know I repeat myself).

> In general, there needs to be a good analysis backing the proposal to change anything - good intention and good idea alone are not enough.

Fully agree. Of course I provided only ideas based on my personal experience and NG posts. Any hint what else I could do is welcome.

> It is better to do nothing than do something unless one is extremely sure that it will help.

I guess there is always risk there. But I agree that we should be convinced about the progress beforehand.

Piotrek

On Thursday, 5 February 2015 at 18:44:06 UTC, CraigDillabaugh wrote:
>>> 1) All Phobos proposals must go through std.experimental.logger
>>> 2) It must implement something generally desired in Phobos
>>> 3) Implementation is supposed to be at least stable enough to not undergo a full rewrite after inclusion. Major API changes are acceptable.
>>> 4) Before DMD/Phobos release is made existing packages that feel stable can undergo a formal review for inclusion in Phobos main package
>>
>> It seems to me that number 2 is wrong. It doesn't matter what is generally desired. The final say depends completely on the leadership. Yes or No has to come from above. Or am I wrong about this?
>
> Well there is a voting process for getting libraries accepted into Phobos, and Andrei and Walter are not the only ones who vote.  However, if you implement something that Andrei/Walter are strongly opposed to, I suppose the vote could be vetoed.

You know, I don't even like the use of voting when it comes to important decisions which last forever. I have no mechanism for determining fairly who has the right to vote and who doesn't. Well, speaking more specifically, who is *competent* to vote and who isn't. D doesn't have a Board of Approved Members, and so putting something up for vote will let any shmoe (such as myself) actually have an equal share in the decision making process.

I believe in leadership. Leadership requires both confidence and humility - confidence to stick up for yourself when you know you're right, and humility to listen to others when you're not sure of yourself. Leadership is really hard... but I think it's necessary in all but the most trivial of cases.

Imagine all the people on the spectrum of competence on a given issue - the most people will be found in the zone of least competence, and the fewest people in the zone of highest competence. The only reason for leadership to put something to a vote is if they can reliably assume that the majority will have a more competent opinion the issue than they will. There are only two reasons to do this:

1. The leadership is able to admit that they know so little about the issue that they wouldn't be able to differentiate the quality of their own opinion from the majority's.

2. The issue is so trivial that the leadership is willing to sacrifice the best outcome for the social approval gained by giving all people the vote.

I don't see either of these happening very often in the case of D. The first case is lamentable indeed, but I don't think it is improved by just passing the issue to a majority vote. The best solution, IMO, is to be honest about one's level of ignorance, and brace oneself for the onslaught of opinions which follow. Maybe in the ensuing chaos one will obtain at least a modicum of competence on what to do.

Also, it's often best to use one's lack of confidence on an issue to win the favor of the higher ups in the community by deferring to one person's, then another's judgment, than to just try to win the favor of a bunch of strangers by letting them all vote.

Anyway, I guess that's just about 5 cents worth of almost completely unsolicited opinion! :-)

Snipped a bit, tl;dr is you should use dub.


How could you be sure that after long lonely work the proposal is worth
> inclusion?
>

No need to be lonely.  You can (and should) have community projects on dub.  The dub repository is a distribution mechanism, if you want community contribution to a library advertise as such and git er done.  With git. Until done.

If it's worth inclusion in phobos, it will rise to the top.

Maybe I'm wrong but there is a big controversy and fragmentation e.g. in
> database and gui domain.


Moving things towards phobos won't help with fragmentation, will just piss those off who disagree.  Better path is to put solutions in dub for people to use and abuse, see if one becomes dominant.  Only then look at moving to phobos.

This may lead to competing packages. How would we decide what are the
> "proper" packages.


Proper package is what works to get a particular job done.  Doesn't matter if it's in phobos or dub or what, as long as it does what is needed. Competing packages will either sort themselves out (given right community involvement) or show there are multiple useful ways of doing things.

See the java ecosystem for examples, there are plenty of things that are third-party but considered 'standard' more than what's in the standard library (joda time, slf4j, etc).  Personally I'd prefer a small standard library with lots of high-quality libraries to pull in as needed - it's suboptimal when the best solution is not what's in the standard lib.


I like the idea of having a 'recommended' section in dub, for those things considered by the community to be good.  I don't think anything should even think about phobos inclusion (even on-path-to-inclusion) until it has been used and abused enough.  We have this nice package system for non-phobos stuff, should leverage it.

On Thursday, 5 February 2015 at 21:21:22 UTC, Zach the Mystic wrote:
> On Thursday, 5 February 2015 at 18:44:06 UTC, CraigDillabaugh
clip
>
> You know, I don't even like the use of voting when it comes to important decisions which last forever. I have no mechanism for determining fairly who has the right to vote and who doesn't. Well, speaking more specifically, who is *competent* to vote and who isn't. D doesn't have a Board of Approved Members, and so putting something up for vote will let any shmoe (such as myself) actually have an equal share in the decision making process.
>
> I believe in leadership. Leadership requires both confidence and humility - confidence to stick up for yourself when you know you're right, and humility to listen to others when you're not sure of yourself. Leadership is really hard... but I think it's necessary in all but the most trivial of cases.
>
> Imagine all the people on the spectrum of competence on a given issue - the most people will be found in the zone of least competence, and the fewest people in the zone of highest competence. The only reason for leadership to put something to a vote is if they can reliably assume that the majority will have a more competent opinion the issue than they will. There are only two reasons to do this:

But what about?
http://en.wikipedia.org/wiki/The_Wisdom_of_Crowds

>
> 1. The leadership is able to admit that they know so little about the issue that they wouldn't be able to differentiate the quality of their own opinion from the majority's.
>
> 2. The issue is so trivial that the leadership is willing to sacrifice the best outcome for the social approval gained by giving all people the vote.
>
> I don't see either of these happening very often in the case of D. The first case is lamentable indeed, but I don't think it is improved by just passing the issue to a majority vote. The best solution, IMO, is to be honest about one's level of ignorance, and brace oneself for the onslaught of opinions which follow. Maybe in the ensuing chaos one will obtain at least a modicum of competence on what to do.
>
> Also, it's often best to use one's lack of confidence on an issue to win the favor of the higher ups in the community by deferring to one person's, then another's judgment, than to just try to win the favor of a bunch of strangers by letting them all vote.
>
> Anyway, I guess that's just about 5 cents worth of almost completely unsolicited opinion! :-)

On Thursday, 5 February 2015 at 05:51:18 UTC, tcak wrote:
> On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
> What could be great is if DMD supported something like JAR packages, and could look for modules inside of them. So, all experimental codes would be packed daily in a zip file, and any programmer, with only download of a single file and including it on command line while compiling, would have latest code very quickly.

This right here.

I like this Draft library but it should not be included with the release simply because they take WAY too long. Instead it should be a separate package that we can update and manage manually if the developer so chooses to use it then they can download and install it. DMD should be able to find it and use it automatically.

On Thursday, 5 February 2015 at 22:10:35 UTC, Israel wrote:
> On Thursday, 5 February 2015 at 05:51:18 UTC, tcak wrote:
>> On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
>> What could be great is if DMD supported something like JAR packages, and could look for modules inside of them. So, all experimental codes would be packed daily in a zip file, and any programmer, with only download of a single file and including it on command line while compiling, would have latest code very quickly.
>
> This right here.
>
> I like this Draft library but it should not be included with the release simply because they take WAY too long. Instead it should be a separate package that we can update and manage manually if the developer so chooses to use it then they can download and install it. DMD should be able to find it and use it automatically.

There is no contradiction between distributing the latest version of 'Mars' with DMD releases (including the library update tool) and having more frequent releases in between, if that is thought to be the right thing to do.

Small frictions have large effects when starting something new, so if you want something to succeed you ought to make it as easy as possible to get started.

On Thu, Feb 5, 2015 at 2:10 PM, Israel via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 5 February 2015 at 05:51:18 UTC, tcak wrote:
>
>> On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
>> What could be great is if DMD supported something like JAR packages, and
>> could look for modules inside of them. So, all experimental codes would be
>> packed daily in a zip file, and any programmer, with only download of a
>> single file and including it on command line while compiling, would have
>> latest code very quickly.
>>
>
> This right here.
>
> I like this Draft library but it should not be included with the release simply because they take WAY too long. Instead it should be a separate package that we can update and manage manually if the developer so chooses to use it then they can download and install it. DMD should be able to find it and use it automatically.
>

http://code.dlang.org/

On Thursday, 5 February 2015 at 22:08:42 UTC, CraigDillabaugh wrote:
> On Thursday, 5 February 2015 at 21:21:22 UTC, Zach the Mystic wrote:
>> On Thursday, 5 February 2015 at 18:44:06 UTC, CraigDillabaugh
> clip
>>
>> You know, I don't even like the use of voting when it comes to important decisions which last forever. I have no mechanism for determining fairly who has the right to vote and who doesn't. Well, speaking more specifically, who is *competent* to vote and who isn't. D doesn't have a Board of Approved Members, and so putting something up for vote will let any shmoe (such as myself) actually have an equal share in the decision making process.
>>
>> I believe in leadership. Leadership requires both confidence and humility - confidence to stick up for yourself when you know you're right, and humility to listen to others when you're not sure of yourself. Leadership is really hard... but I think it's necessary in all but the most trivial of cases.
>>
>> Imagine all the people on the spectrum of competence on a given issue - the most people will be found in the zone of least competence, and the fewest people in the zone of highest competence. The only reason for leadership to put something to a vote is if they can reliably assume that the majority will have a more competent opinion the issue than they will. There are only two reasons to do this:
>
> But what about?
> http://en.wikipedia.org/wiki/The_Wisdom_of_Crowds

Interesting article. There are a lot of opinions about the wisdom of crowds right there in the article, some in favor, some more skeptical. It seems like in order to get the benefit of crowd wisdom, you have to be able to formulate a question in a rather simplistic way - asking for a number, or choosing from a short list of possibilities. Maybe I'm in favor of leadership here because I don't know how such a subtle thing as a language or library design decision could be easily formulated into that type of simple question.

The leadership here can easily benefit from the wisdom of crowds, though - by utilizing the public nature of the internet. At least they can rely on whoever has enough motivation to invest time voicing his or her opinions here.

Maybe I just prefer leadership for my own personal reasons. The wisdom of crowds might be a valid way of making some decisions. But I think it would still take a bit of genius to even formulate an effective series of questions, for which the wisdom of crowds was to be relied upon for the answers. Even that would take quite a bit of leadership, since you'll probably agree with me that basing important decisions on the crowd's answers to a bad question would be a very fast road to software hell indeed!

>> How could you be sure that after long lonely work the proposal is worth
>> inclusion?

>No need to be lonely.  You can (and should) have community projects on
>dub.  The dub repository is a distribution mechanism, if you want community
>contribution to a library advertise as such and git er done.  With git.
>Until done.

>If it's worth inclusion in phobos, it will rise to the top.

I admire idealists, but in the past few years how many independent projects have been adopted by phobos?  Is it the case that none of those that were not are essentially at core unworthy of adoption, or is it that they need some polishing to be of more general use and doing so simply doesn't appeal to the library author, whilst others with the skills are less inclined to help on a private project?  I don't know the answer, but obviously have a tentative assessment.

Since there is so much hidden gold in dub, I wonder if it makes sense to ask notable library authors how they might feel about adoption of parts of their work into Mars.  What does Adam Ruppe think, for example?

> Maybe I'm wrong but there is a big controversy and fragmentation e.g. in
> database and gui domain.

So don't start with databases and guis.  And at least down the line consider the possibility that there might not be just one option when the needs of the problem domains may be very different in spite of apparent superficial technical similarity.

> Moving things towards phobos won't help with fragmentation, will just piss
> those off who disagree.  Better path is to put solutions in dub for people
> to use and abuse, see if one becomes dominant.  Only then look at moving to
> phobos.

If Mars doesn't accomplish its goals then people won't use it and all that will have happened is a little wasted effort - but one doesn't learn without experimentation, including in the social domain.   It just hasn't happened that people mystically converge on a solution just because it is in dub, polish the code and write documentation for somebody else's code base - possibly because someone needs to lead the effort.

> This may lead to competing packages. How would we decide what are the
> "proper" packages.

One might start with exploring what is already out there and seeing which authors are agreeable to having their work adopted.  Making decisions isn't easy in life, and people are going to criticize you because not everyone will be happy with the outcome - but that isn't a reason not to do something if it is worth doing.

> I like the idea of having a 'recommended' section in dub, for those things
> considered by the community to be good.

This is a start, but doesn't address the problem that to be useful to a broad audience one needs much more than raw code and that the library author may not want to or be good at doing these other things.

In response to Craig:

> http://en.wikipedia.org/wiki/The_Wisdom_of_Crowds

A democratic book for a democratic age.  But there is an extensive literature on the weaknesses of making decisions in this manner, and one certainly won't achieve excellence that way.  (See Peter Thiel, Linus, Gabriel Tarde, Gustave Le Bon, etc).

On Thursday, 5 February 2015 at 22:25:28 UTC, Laeeth Isharc wrote:
> There is no contradiction between distributing the latest version of 'Mars' with DMD releases (including the library update tool) and having more frequent releases in between, if that is thought to be the right thing to do.
>
> Small frictions have large effects when starting something new, so if you want something to succeed you ought to make it as easy as possible to get started.


I agree with both points. Even more with the letter.

Piotrek