www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New DIP73: D Drafting Library

reply "Piotrek" <no_data no_data.pl> writes:
Hi,

Abstract:

D Drafting Library is an official library modeled by the D 
community and designed to support the development process of the 
D Standard Library. The drafting library is coupled with the 
standard library and doesn't introduce any duplicated 
functionality. It should be used during the drafting stage of the 
new functionality development.

Link to the DIP:
http://wiki.dlang.org/DIP73

and to the recent discussion for initial proposal:
http://forum.dlang.org/post/rwavdkzmkqxpldveueje forum.dlang.org

Please comment, share your view and doubts. Don't hesitate to ask 
any question.

I tried to define the proposal to be almost non-intrusive for not 
interested developers.

I can handle point 3 and 4 from "Proposal implementation steps" 
section as a pull requests when proposal is accepted. Step 1 and 
2 are trivial but can't be done by me as I'm not the person in 
charge.

Piotrek
Feb 04 2015
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Wednesday, 4 February 2015 at 22:10:51 UTC, Piotrek wrote:

 Hi,

 Abstract:

 D Drafting Library is an official library modeled by the D 
 community and designed to support the development process of 
 the D Standard Library. The drafting library is coupled with 
 the standard library and doesn't introduce any duplicated 
 functionality. It should be used during the drafting stage of 
 the new functionality development.

 Link to the DIP:
 http://wiki.dlang.org/DIP73

 and to the recent discussion for initial proposal:
 http://forum.dlang.org/post/rwavdkzmkqxpldveueje forum.dlang.org

 Please comment, share your view and doubts. Don't hesitate to 
 ask any question.

 I tried to define the proposal to be almost non-intrusive for 
 not interested developers.

 I can handle point 3 and 4 from "Proposal implementation steps" 
 section as a pull requests when proposal is accepted. Step 1 
 and 2 are trivial but can't be done by me as I'm not the person 
 in charge.

 Piotrek


This looks very similar to std.experimental.  I originally 
thought that the difference between std.experimental and this 
library was going to be how it was used.

std.experimental:
    module that may become part of the standard libary later

your proposed library "mars"?:
    modules that will probably not become a part of the standard 
library.  They are "addons" to the standard library.  i.e. Maybe 
you would like the SDL library, but it doesn't make sense to 
include in the standard library because it it not useful to 
everyone.  For these kinds of libraries it would be nice to have 
a set of community supported libraries that shouldn't be in the 
standard library but are still useful to a subset of the 
community.

However, it appears that this proposal is just another version of 
std.experimental.
Feb 04 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler 
wrote:

 This looks very similar to std.experimental.  I originally 
 thought that the difference between std.experimental and this 
 library was going to be how it was used.

 std.experimental:
    module that may become part of the standard libary later

 your proposed library "mars"?:
    modules that will probably not become a part of the standard 
 library.  They are "addons" to the standard library.  i.e. 
 Maybe you would like the SDL library, but it doesn't make sense 
 to include in the standard library because it it not useful to 
 everyone.  For these kinds of libraries it would be nice to 
 have a set of community supported libraries that shouldn't be 
 in the standard library but are still useful to a subset of the 
 community.

 However, it appears that this proposal is just another version 
 of std.experimental.


This is what I originally though as well. Personally I think what 
you just described would be much more useful. It really feels 
like this is just another std.experimental with only subtle 
distinctions. I don't think it adds much value.
Feb 04 2015
parent reply "tcak" <tcak gmail.com> writes:
On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:

 On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler 
 wrote:

 This looks very similar to std.experimental.  I originally 
 thought that the difference between std.experimental and this 
 library was going to be how it was used.

 std.experimental:
   module that may become part of the standard libary later

 your proposed library "mars"?:
   modules that will probably not become a part of the standard 
 library.  They are "addons" to the standard library.  i.e. 
 Maybe you would like the SDL library, but it doesn't make 
 sense to include in the standard library because it it not 
 useful to everyone.  For these kinds of libraries it would be 
 nice to have a set of community supported libraries that 
 shouldn't be in the standard library but are still useful to a 
 subset of the community.

 However, it appears that this proposal is just another version 
 of std.experimental.


 This is what I originally though as well. Personally I think 
 what you just described would be much more useful. It really 
 feels like this is just another std.experimental with only 
 subtle distinctions. I don't think it adds much value.



For me, this experimental thing is a problem due to the fact that 
release period of DMD is too long. Experimental means there will 
be lots of changes. A programmer shouldn't be waiting to get new 
versions of experimental codes.

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.
Feb 04 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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:

 On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler 
 wrote:

 This looks very similar to std.experimental.  I originally 
 thought that the difference between std.experimental and this 
 library was going to be how it was used.

 std.experimental:
  module that may become part of the standard libary later

 your proposed library "mars"?:
  modules that will probably not become a part of the standard 
 library.  They are "addons" to the standard library.  i.e. 
 Maybe you would like the SDL library, but it doesn't make 
 sense to include in the standard library because it it not 
 useful to everyone.  For these kinds of libraries it would be 
 nice to have a set of community supported libraries that 
 shouldn't be in the standard library but are still useful to 
 a subset of the community.

 However, it appears that this proposal is just another 
 version of std.experimental.


 This is what I originally though as well. Personally I think 
 what you just described would be much more useful. It really 
 feels like this is just another std.experimental with only 
 subtle distinctions. I don't think it adds much value.



 For me, this experimental thing is a problem due to the fact 
 that release period of DMD is too long. Experimental means 
 there will be lots of changes. A programmer shouldn't be 
 waiting to get new versions of experimental codes.

 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.


or std.experimental could just be separated into its own 
repository and put on dub?
Feb 04 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 05 Feb 2015 06:47:26 +0000, weaselcat wrote:


 or std.experimental could just be separated into its own repository and
 put on dub?


and make all rdmd users very unhappy, yeah. no, it's not about dub, it's=20
about "std." prefix.

happy rdmd user.=
Feb 05 2015
prev sibling parent reply "Israel" <tl12000 live.com> writes:
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.
Feb 05 2015
next sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
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.
Feb 05 2015
parent "Piotrek" <no_data no_data.pl> writes:
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
Feb 05 2015
prev sibling parent Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
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/
Feb 05 2015
prev sibling parent "Piotrek" <no_data no_data.pl> writes:
On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler 
wrote:

 This looks very similar to std.experimental.


In one way, yes, it is similar to std.experimental, but not that 
much as it seems.

More precisely:

1. Take the namespace designed for new module drafting out of the 
Phobos
2. Put it in a separate library
3. Allow community common development from the beginning of the 
drafting stage
4. Propose Phobos inclusion when module is ready


 I originally thought that the difference between 
 std.experimental and this library was going to be how it was 
 used.

 std.experimental:
    module that may become part of the standard libary later

 your proposed library "mars"?:
    modules that will probably not become a part of the standard 
 library.


Just small clarification.

Drafting library would include modules that are welcome to become 
a standard. The final decision about Phobos submission is made 
after standardization attempt failed, not before!


 They are "addons" to the standard library.  i.e. Maybe you 
 would like the SDL library, but it doesn't make sense to 
 include in the standard library because it it not useful to 
 everyone.  For these kinds of libraries it would be nice to 
 have a set of community supported libraries that shouldn't be 
 in the standard library but are still useful to a subset of the 
 community.


The DIP is defined in the spirit of what you originally thought.

1. If you want SDL (literaly) then use code.dlang.org package
2. If you want SDL like functionality then propose a new draft 
module (including gui functionality)

Piotrek
Feb 05 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.

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

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.

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

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

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

In general, there needs to be a good analysis backing the 
proposal to change anything - good intention and good idea alone 
are not enough. It is better to do nothing than do something 
unless one is extremely sure that it will help.
Feb 04 2015
next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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.

 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
 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?
Feb 05 2015
next sibling parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 5 February 2015 at 18:23:19 UTC, Zach the Mystic 
wrote:

 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.

 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
 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.
Feb 05 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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! :-)
Feb 05 2015
next sibling parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
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! :-)
Feb 05 2015
parent "Zach the Mystic" <reachzach gggmail.com> writes:
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!
Feb 05 2015
prev sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
 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).
Feb 05 2015
parent "Piotrek" <no_data no_data.pl> writes:
On Thursday, 5 February 2015 at 23:04:03 UTC, Laeeth Isharc wrote:

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.


Despite you mixed up many posts in the one answer I like most of 
you points.


 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?


+1


 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.



I mean I want to have a functionality in D like in Qt, i.e.  gui 
for:
-Windows
-Linux
-Android

This would need a huge amount of work.

I don't need it to be ready in the first release though. Also I 
don't mind to have it changing rapidly in the first stage of 
development.


 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.


The idea seems to be cheep in implementation (e.g. just creating 
the official project would be something) and can be reverted any 
time as it won't be any kind of dependency.


 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.


+1
For me, the issue is high entry barrier for Phobos. OTOH I can 
imagine myself making pull requests for the drafting library. Not 
mentioning testing the progress.



 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.


+1

http://wiki.dlang.org/DIP73#Comparison_to_code.dlang.org_packages

Piotrek
Feb 05 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 5 February 2015 at 18:23:19 UTC, Zach the Mystic 
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?


No, you get it wrong. This is decided exclusively community 
voting. Andrei or Walter can veto something that they don't want 
but their explicit approval is not required.
Feb 05 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Thursday, 5 February 2015 at 23:35:04 UTC, Dicebot wrote:

 On Thursday, 5 February 2015 at 18:23:19 UTC, Zach the Mystic 
 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?


 No, you get it wrong. This is decided exclusively community 
 voting. Andrei or Walter can veto something that they don't 
 want but their explicit approval is not required.


I'm surprised. From my point of view, yours is a bad strategy. 
What bothers me is how could a module just take Walter or Andrei 
completely by surprise and still end up in the standard library? 
I honestly wouldn't want that, and yet apparently it's possible. 
Now don't get me wrong. I do think listening to the community is 
critical, and allowing a new module because of overwhelming 
popular demand is also acceptable, provided there's no reason to 
veto it.

But to me, that veto means a whole lot. It means that people 
can't know what will be rejected or accepted unless told, and in 
the absence of being told, the motivation to work on something 
may dry up. That's what I'm trying to prevent by my strong 
insistence on the necessity of leadership.

The way I see it, the conversation about what is suitable for a 
standard library should come first. Someone should propose 
something, get a signal on prospects for inclusion, and then use 
that signal do determine whether to keep developing the library 
for phobos or not. Without the signal, how will they know whether 
to develop it for phobos or just for their own 3rd-party use? How 
do you get a clear signal when the module is only voted on at the 
*end* of the process?
Feb 05 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/15 4:08 PM, Zach the Mystic wrote:

 On Thursday, 5 February 2015 at 23:35:04 UTC, Dicebot wrote:

 No, you get it wrong. This is decided exclusively community voting.
 Andrei or Walter can veto something that they don't want but their
 explicit approval is not required.


 I'm surprised. From my point of view, yours is a bad strategy. What
 bothers me is how could a module just take Walter or Andrei completely
 by surprise and still end up in the standard library? I honestly
 wouldn't want that, and yet apparently it's possible. Now don't get me
 wrong. I do think listening to the community is critical, and allowing a
 new module because of overwhelming popular demand is also acceptable,
 provided there's no reason to veto it.


D is a collaborative project and it's obvious that at some point control 
and trust need to be distributed to foster faster growth and broader 
participation.

Walter and I have been occasionally appalled by stuff that made it in 
Phobos - as was this recent case with  trusted functions that can't be 
trusted nonsense - but by and large the good overwhelms the not-so-good. 
I trust close contributors who have historically done good work to 
continue doing so, and we can delegate certain tasks to folks. As a 
simple example I trust Martin and Rainer to do good work on the GC and 
review each other's work.


 But to me, that veto means a whole lot. It means that people can't know
 what will be rejected or accepted unless told, and in the absence of
 being told, the motivation to work on something may dry up. That's what
 I'm trying to prevent by my strong insistence on the necessity of
 leadership.


It is clear we have historically a less than stellar record of good 
leadership. We plan to improve dramatically on that starting January - 
of this year :o) - and there are a few good early signs that we hope 
will develop into successful patterns.

There's no need to fear rejection. There's always code.dlang.org and as 
I said: you can trust me to recognize great work when I see it. So 
there's definitely no need to ask for permission.

One thing we'll try more of is being more decisive instead of letting 
options linger forever. Sometimes we just say "we support this" or "we 
don't support that" and our quest for the community is to understand 
that "no" is sometimes necessary for focusing on the "yes".


 The way I see it, the conversation about what is suitable for a standard
 library should come first. Someone should propose something, get a
 signal on prospects for inclusion, and then use that signal do determine
 whether to keep developing the library for phobos or not. Without the
 signal, how will they know whether to develop it for phobos or just for
 their own 3rd-party use? How do you get a clear signal when the module
 is only voted on at the *end* of the process?


Just use code.dlang.org. It's perfect either as a place for good work 
and a stepping stone toward the standard library.


Andrei
Feb 05 2015
parent "Israel" <tl12000 live.com> writes:
On Friday, 6 February 2015 at 00:45:16 UTC, Andrei Alexandrescu
wrote:

 On 2/5/15 4:08 PM, Zach the Mystic wrote:

 Just use code.dlang.org. It's perfect either as a place for 
 good work and a stepping stone toward the standard library.

 Andrei


I get the feeling you guys will eventually look back at this idea
to revive it in some way. Im no oracle though, just saying...
Feb 05 2015
prev sibling next sibling parent reply "Piotrek" <no_data no_data.pl> writes:
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
Feb 05 2015
next sibling parent reply Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Feb 05 2015
parent reply "Piotrek" <no_data no_data.pl> writes:
On Thursday, 5 February 2015 at 22:04:04 UTC, Jeremy Powers wrote:

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


I use it but with no success in the matter of the proposal.


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

 inclusion?




..

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


I actually don't know how to comment that in regards to the DIP. 
I don't recall dedicated protects for particular modules.



 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.


Any example of existing Phobos modules (added recently)?


 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.


I don't have nothing against. But IMO this won't solve the 
problem with standardization of functionality. From the 
perspective of usual user.


 We have this nice package system for non-phobos stuff, should 
 leverage it.


The functionality of dub is not related to the DIP. I tried to 
keep it as a separate topic.

Piotrek
Feb 05 2015
parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
Perhaps it is over ambitious to start with the goal of producing 
only code destined to end up in Phobos.  The domain is so broadly 
defined, and the standard to aspire to so high that one ends up 
setting the goalpost so high that given likely contributors one 
risks ending up running out of steam before getting very far.  
Also, the domain of things that maybe should never be in Phobos 
but are nonetheless important and lack a well documented, 
industrial strength solution - this domain is not tiny.

Maybe biting off a small chunk so you can show what you mean, and 
understand in practical terms what is involved might be the first 
step on a longer journey.  That's actually realistically how one 
would have to approach it anyway even were you to get universal 
buy-in, which doesn't seem to be on the cards.  It is easier to 
convince people as momentum picks up than with just an idea.

Pick something not too large but useful and start working on it ?
Feb 05 2015
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 5 February 2015 at 19:05:10 UTC, Piotrek wrote:

 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?


Yes, right now this is the idea. All new modules must stay some 
time in std.experimental to stabilize (unless they are simply 
renaming or split of existing modules).


 Can you provide a link to the latest official description? I 
 will update the pictures.


Sadly, no, and this is largely my fault. Existing description 
(http://wiki.dlang.org/Review/Process) was written by previous 
review queue manager. During last few reviews I have managed 
plenty of things has changed (including addition of 
std.experimental) but wiki description wasn't updated.

I will need to update that. Main problem is that it is still a 
rapidly changing target and I am not sure current scheme is final.


 2) It must implement something generally desired in Phobos


 Which is?


Decided by community voting as part of formal reviews process. 
One of questions for voting is "Do you want to see this 
functionality 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.


 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.


I disagree that those are "many cases". In fact, it applies to 
only few really big libraries like ones that deal with GUI or 
databases - all kind of stuff that is inherently controversial 
and can't be officially endorsed anyway.


 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?


Because it gets destroyed by many reviewers - in great detail. 
And if formal review thread does not get enough contribution from 
to-be-users, it is likely to be rejected. AFAIR I had to halt 
review of std.signal replacement because of that, until it gets 
more interest from community.


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


You decide that, among all other voters. Opinion of existing 
Phobos developers naturally is considered of more importance 
during the voting though (I publish separate stats).


 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.


Yes, and it will always stay so because of inherent nature of 
such domains. People won't start using libraries they don't like 
simply because those are marked as "official". Clearly not in D 
community, we like our reinvented wheels :)


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


No different from deciding what goes to Phobos or deciding what 
goes to your proposed library.
Feb 05 2015
prev sibling parent "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
Hi Dicebot.

You are a clear thinker - close reasoning - and I admire that.


 As you may see requirements are very lax. Only real difference 
 is that your proposal 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

 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


Isn't there a psychological barrier to submitting pulls for 
someone else's source code when it is not clear it will be 
welcome?  Plus encouraging others to write docs etc. A community 
project will still be de facto owned by the author, but 
perception of its status is clearer.

Any benefit from Mars would come from purely human factors, but 
sometimes these are important.


Laeeth.
Feb 05 2015