www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Problem With DIPs

reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 7 June 2016 at 19:52:40 UTC, Walter Bright wrote:

 If you want to take charge of writing such a specification DIP, 
 please do so.


There's a reason why people resort to talking in the forms rather 
than write a DIP. It's quite obvious when you take a look at this 
page: https://wiki.dlang.org/DIP82

When it says "draft", what it actually means is "waiting for 
comments, approval, or rejection". 63 out of 88 DIPs are sitting 
in limbo because no one with authority ever made a decision on 
them. Which means a lousy 28% of DIPs are either definitively 
closed or accepted.

Take for example DIP 82: https://wiki.dlang.org/DIP82. Jonathan 
obviously spent some time on this, and it addresses an actual 
problem he's had with std.datetime. It's was written and proposed 
on the forum: 
http://forum.dlang.org/thread/ozvzscpmbixskarsgruw forum.dlang.org

Not a single person with the authority to make a decision even 
commented on the thread. Why would anyone invest the time it 
takes to write a DIP when it will be forgotten?

How to fix this:

You have several options,

* Make a rule that either auto rejects or auto approves a DIP if 
there's no activity/argumentation on it for a specific period of 
time. This is much better than leaving things in limbo and would 
force people to take action
* Move the DIPs to a more visible area like Github (a la Swift) 
and nominate someone to manage them
* If no one has time to review/manage these, than admit it, get 
rid of the DIP process, and move all big feature requests to the 
forums
Jun 07 2016
next sibling parent Seb <seb wilzba.ch> writes:
On Tuesday, 7 June 2016 at 20:32:54 UTC, Jack Stouffer wrote:

 On Tuesday, 7 June 2016 at 19:52:40 UTC, Walter Bright wrote:

 If you want to take charge of writing such a specification 
 DIP, please do so.


 There's a reason why people resort to talking in the forms 
 rather than write a DIP. It's quite obvious when you take a 
 look at this page: https://wiki.dlang.org/DIP82

 When it says "draft", what it actually means is "waiting for 
 comments, approval, or rejection". 63 out of 88 DIPs are 
 sitting in limbo because no one with authority ever made a 
 decision on them. Which means a lousy 28% of DIPs are either 
 definitively closed or accepted.

 Take for example DIP 82: https://wiki.dlang.org/DIP82. Jonathan 
 obviously spent some time on this, and it addresses an actual 
 problem he's had with std.datetime. It's was written and 
 proposed on the forum: 
 http://forum.dlang.org/thread/ozvzscpmbixskarsgruw forum.dlang.org

 Not a single person with the authority to make a decision even 
 commented on the thread. Why would anyone invest the time it 
 takes to write a DIP when it will be forgotten?


I absolutely agree with you!


 How to fix this:
 You have several options,

 * Make a rule that either auto rejects or auto approves a DIP 
 if there's no activity/argumentation on it for a specific 
 period of time. This is much better than leaving things in 
 limbo and would force people to take action
 * Move the DIPs to a more visible area like Github (a la Swift) 
 and nominate someone to manage them


and Rust, Python, ...

I already did the conversion, but not many noticed:

http://forum.dlang.org/post/iukxggyeisypmkgfhsoe forum.dlang.org

e.g. http://wilzbach.github.io/d-dip/DIP85
source: https://github.com/wilzbach/d-dip/tree/gh-pages/md

So the migration is already done (automatically), you just need 
to agree that we want to move to peer-reviewed DIPs ;-)


 * If no one has time to review/manage these, than admit it, get 
 rid of the DIP process, and move all big feature requests to 
 the forums


Please don't use forums - it's very hard to keep track of 
comments. Github gives us for the comments on the according line 
and allows incremental improvements!
Jun 07 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/7/2016 1:32 PM, Jack Stouffer wrote:

 a lousy 28% of DIPs are either definitively closed or accepted.


I understand that is frustrating. It happens to mine as well, though I am less 
bothered by it.

It's a question of framing.

Consider the regression list:

https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=208862&query_format=advanced

There are currently 34 issues on it, where we implemented a feature and 
inadvertently broke something. There are constant complaints on the forum that 
we have not "fully" implemented things.

What should we be working on? We're doing well to have decisively dealt with
28% 
of the DIPs.

A DIP not being dealt with does not mean it is a bad idea. It pretty much means 
we just aren't ready to deal with it at the moment. It's time may not have come 
yet. But it's not going away, it'll still be there when needed. I've found 
mining DIPs to be quite useful in designing the 'return ref' feature. DIPs are
a 
gold mine of ideas that be built upon, and I know where to find them. They're 
great for pointing to when someone says on the n.g. "why don't we do X?"
Perhaps 
they can then build on X rather than reinventing the wheel.

DIPs tend to be much more thorough than other ways to propose enhancements, and 
are suitable for heavier topics. On the other hand, n.g. proposals are almost 
invariably something someone spent literally 5 minutes on, and then they scroll 
away and everyone forgets about them. There's no organization to them, and 
pretty much no useful way to mine a database of half a million posts. (I've
tried.)

Bugzilla enhancement requests are also lightweight, and as such they are good 
for small proposals. Bugzilla ERs also don't scroll away, and are easily 
searchable. But they are inappropriate if they take more than a few lines to 
describe. Bugzilla is not suitable for in-depth proposals because there is no 
markup and no way to edit previous comments.

Sometimes people initiate enhancement requests in github comments about other 
PRs. That's a sure way to have such forgotten and overlooked.

-----

Also, as with everything in life, a little promotion is usually necessary if
you 
really believe in something. As I endlessly repeat ad nauseum, "build it and 
they will come" is a hollywood myth, and it applies to the internal D community 
just as much as it applies everywhere else. If you've got a good DIP, and you 
believe in it, do some selling of it. Very, very few things sell themselves.
Jun 08 2016
next sibling parent reply Dicebot <public dicebot.lv> writes:
I believe it is big mistake to treat DIPs as a creative idea database.
Most importantly because it diminishes motivation to put real effort
into working on the DIP as opposed to just quickly throwing something on
the table and moving on. Sure, those are useful for that purpose too,
but focusing on it means greatly underusing potential of the concept.

As I have already mentioned in some other thread, I am willing to
volunteer to manage it in a more pedantic manner as I feel lack of
formal decision process for major changes is currently The Biggest D
Problem in my work (and not any of commonly called technical issues).

Ideally DIP system should be a way to make proposal to language authors
with good guarantees that it will get some resolution _eventually_ (not
matter how it is) - and I don't mean just language change proposals but
any major changes. Handling that process-wise is not that hard (and I
can contribute roughly 1 day a week for related matters) but it will
only work if you can arrange something like regular "2 hours of
reviewing" each month or so to slowly move through the queue. Slow but
perceived progress is still much better for morale than lack of visible
progress at all.
Jun 08 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2016 1:22 PM, Dicebot wrote:

 I believe it is big mistake to treat DIPs as a creative idea database.
 Most importantly because it diminishes motivation to put real effort
 into working on the DIP as opposed to just quickly throwing something on
 the table and moving on. Sure, those are useful for that purpose too,
 but focusing on it means greatly underusing potential of the concept.

 As I have already mentioned in some other thread, I am willing to
 volunteer to manage it in a more pedantic manner as I feel lack of
 formal decision process for major changes is currently The Biggest D
 Problem in my work (and not any of commonly called technical issues).

 Ideally DIP system should be a way to make proposal to language authors
 with good guarantees that it will get some resolution _eventually_ (not
 matter how it is) - and I don't mean just language change proposals but
 any major changes. Handling that process-wise is not that hard (and I
 can contribute roughly 1 day a week for related matters) but it will
 only work if you can arrange something like regular "2 hours of
 reviewing" each month or so to slowly move through the queue. Slow but
 perceived progress is still much better for morale than lack of visible
 progress at all.


I agree we should do better, I certainly welcome any efforts you're willing to 
devote to this. Most of the huge improvements in process in D have come about 
precisely because someone selected himself to take charge of the matter and
make 
the required sustained effort. Saying others should do this or that has an 
abysmal track record.

I just didn't want to make promises I could not deliver.
Jun 08 2016
next sibling parent reply Dicebot <public dicebot.lv> writes:
On Wednesday, 8 June 2016 at 20:44:10 UTC, Walter Bright wrote:

 I agree we should do better, I certainly welcome any efforts 
 you're willing to devote to this. Most of the huge improvements 
 in process in D have come about precisely because someone 
 selected himself to take charge of the matter and make the 
 required sustained effort. Saying others should do this or that 
 has an abysmal track record.

 I just didn't want to make promises I could not deliver.


I will finish description for proposed process this weekend and 
send it to dmd-internal mail list.
Jun 08 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2016 1:47 PM, Dicebot wrote:

 I will finish description for proposed process this weekend and send it to
 dmd-internal mail list.


Cool!
Jun 08 2016
parent reply Dicebot <public dicebot.lv> writes:
On 06/09/2016 01:12 AM, Walter Bright wrote:

 On 6/8/2016 1:47 PM, Dicebot wrote:

 I will finish description for proposed process this weekend and send
 it to
 dmd-internal mail list.


 
 Cool!


http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9f90 dicebot.lv
Jun 12 2016
parent reply Guillaume Boucher <guillaume.boucher.d gmail.com> writes:
On Sunday, 12 June 2016 at 12:16:11 UTC, Dicebot wrote:

 On 06/09/2016 01:12 AM, Walter Bright wrote:

 On 6/8/2016 1:47 PM, Dicebot wrote:

 I will finish description for proposed process this weekend 
 and send
 it to
 dmd-internal mail list.


 
 Cool!


 http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9f90 dicebot.lv


What are the reasons for putting the DIPs into several 
directories (Drafts, Approved, Implemented and Discarded)?  Rust 
also did that at first, but they merged them later into one 
folder (see https://github.com/rust-lang/rfcs/issues/360).  If 
you keep the structure as is, what is the preferred way to link 
to a certain DIP?
Jun 12 2016
parent reply Dicebot <public dicebot.lv> writes:
On 06/12/2016 08:19 PM, Guillaume Boucher wrote:

 On Sunday, 12 June 2016 at 12:16:11 UTC, Dicebot wrote:

 On 06/09/2016 01:12 AM, Walter Bright wrote:

 On 6/8/2016 1:47 PM, Dicebot wrote:

 I will finish description for proposed process this weekend and send
 it to
 dmd-internal mail list.


 Cool!


 http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9f90 dicebot.lv


 
 What are the reasons for putting the DIPs into several directories
 (Drafts, Approved, Implemented and Discarded)?  Rust also did that at
 first, but they merged them later into one folder (see
 https://github.com/rust-lang/rfcs/issues/360).  If you keep the
 structure as is, what is the preferred way to link to a certain DIP?


Rationale is to allow quickly navigate through existing DIPs (in absence
of actual database to query), filtering categories is probably most
common navigation task.

Your are very correct about importance of link stability though. What
comes to my mind immediately is to store all DIPs in same folder but
keep Approved/Implementec/etc as folders containing symlinks to the
merged one (git stores symlinks just fine).
Jun 12 2016
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 12 June 2016 at 18:50:06 UTC, Dicebot wrote:

 Your are very correct about importance of link stability 
 though. What comes to my mind immediately is to store all DIPs 
 in same folder but keep Approved/Implementec/etc as folders 
 containing symlinks to the merged one (git stores symlinks just 
 fine).


This might not be the case on Windows.

Does GitHub present symlinks in a nice way (i.e. as a redirect)?
Jun 12 2016
next sibling parent Dicebot <public dicebot.lv> writes:
On 06/12/2016 09:58 PM, Vladimir Panteleev wrote:

 On Sunday, 12 June 2016 at 18:50:06 UTC, Dicebot wrote:

 Your are very correct about importance of link stability though. What
 comes to my mind immediately is to store all DIPs in same folder but
 keep Approved/Implementec/etc as folders containing symlinks to the
 merged one (git stores symlinks just fine).


 
 This might not be the case on Windows.
 
 Does GitHub present symlinks in a nice way (i.e. as a redirect)?


AFAIK in Windows those are visible as text files containing linked path.
Github doesn't seem to be very helpful either :
https://github.com/Dicebot/DIPs/blob/master/Drafts/DIP20.md :(
Jun 12 2016
prev sibling parent Dicebot <public dicebot.lv> writes:
On 06/12/2016 09:58 PM, Vladimir Panteleev wrote:

 On Sunday, 12 June 2016 at 18:50:06 UTC, Dicebot wrote:

 Your are very correct about importance of link stability though. What
 comes to my mind immediately is to store all DIPs in same folder but
 keep Approved/Implementec/etc as folders containing symlinks to the
 merged one (git stores symlinks just fine).


 
 This might not be the case on Windows.
 
 Does GitHub present symlinks in a nice way (i.e. as a redirect)?


I will look into auto-generating overview table sorted by categories
instead.
Jun 13 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/12/2016 11:50 AM, Dicebot wrote:

 Your are very correct about importance of link stability though. What
 comes to my mind immediately is to store all DIPs in same folder but
 keep Approved/Implementec/etc as folders containing symlinks to the
 merged one (git stores symlinks just fine).


I like Bugzilla's method of tagging issues, which allows arbitrary crosscuts to 
be made.
Jun 12 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/12/16 3:48 PM, Walter Bright wrote:

 On 6/12/2016 11:50 AM, Dicebot wrote:

 Your are very correct about importance of link stability though. What
 comes to my mind immediately is to store all DIPs in same folder but
 keep Approved/Implementec/etc as folders containing symlinks to the
 merged one (git stores symlinks just fine).


 I like Bugzilla's method of tagging issues, which allows arbitrary
 crosscuts to be made.


Github has tags too:

https://github.com/dlang/druntime/pulls?q=is%3Aopen+is%3Apr+label%3AGC

But only on PRs and issues I would guess. Not sure how we could utilize 
this for files themselves.

-Steve
Jun 13 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-06-08 22:44, Walter Bright wrote:


 I agree we should do better, I certainly welcome any efforts you're
 willing to devote to this. Most of the huge improvements in process in D
 have come about precisely because someone selected himself to take
 charge of the matter and make the required sustained effort. Saying
 others should do this or that has an abysmal track record.

 I just didn't want to make promises I could not deliver.


The problem with the DIP's is that, by definition, it's something that 
needs your or Andrei's approval. Therefore it's not possible to leave it 
completely for someone else to deal with.

-- 
/Jacob Carlborg
Jun 09 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/9/2016 4:49 AM, Jacob Carlborg wrote:

 The problem with the DIP's is that, by definition, it's something that needs
 your or Andrei's approval. Therefore it's not possible to leave it completely
 for someone else to deal with.


That doesn't stop anyone from commenting on them, offering improvements, doing 
some promotion of them, organizing handling them, etc.
Jun 09 2016
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Thursday, 9 June 2016 at 21:34:00 UTC, Walter Bright wrote:

 On 6/9/2016 4:49 AM, Jacob Carlborg wrote:

 The problem with the DIP's is that, by definition, it's 
 something that needs
 your or Andrei's approval. Therefore it's not possible to 
 leave it completely
 for someone else to deal with.


 That doesn't stop anyone from commenting on them, offering 
 improvements, doing some promotion of them, organizing handling 
 them, etc.


It is not clear where to comment to begin with.
Jun 09 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/9/2016 5:10 PM, deadalnix wrote:

 It is not clear where to comment to begin with.


There's a space in the table for a link to n.g. discussion.
Jun 09 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-06-09 23:34, Walter Bright wrote:


 That doesn't stop anyone from commenting on them, offering improvements,
 doing some promotion of them, organizing handling them, etc.


If feel that's a bit pointless if no one with some form of authority 
will look at it.

-- 
/Jacob Carlborg
Jun 10 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/10/16 9:00 AM, Jacob Carlborg wrote:

 On 2016-06-09 23:34, Walter Bright wrote:


 That doesn't stop anyone from commenting on them, offering improvements,
 doing some promotion of them, organizing handling them, etc.


 If feel that's a bit pointless if no one with some form of authority
 will look at it.


It's much better than making informal remarks on the forum, which then 
scroll out of memory. I encourage people who have good ideas and are 
willing and able to take them to completion to formulate them as DIPs. 
Good quality DIPs will eventually get discussed more often and end up 
being implemented. -- Andrei
Jun 10 2016
next sibling parent Seb <seb wilzba.ch> writes:
On Friday, 10 June 2016 at 10:38:49 UTC, Andrei Alexandrescu 
wrote:

 On 6/10/16 9:00 AM, Jacob Carlborg wrote:

 On 2016-06-09 23:34, Walter Bright wrote:


 That doesn't stop anyone from commenting on them, offering 
 improvements,
 doing some promotion of them, organizing handling them, etc.


 If feel that's a bit pointless if no one with some form of 
 authority
 will look at it.


 It's much better than making informal remarks on the forum, 
 which then scroll out of memory. I encourage people who have 
 good ideas and are willing and able to take them to completion 
 to formulate them as DIPs. Good quality DIPs will eventually 
 get discussed more often and end up being implemented. -- Andrei


+1

It's all about working more collaboratively - I believe Dicebot 
will do an amazing job as review manager!

If you read his proposed procedure at the WIP-repo 
(https://github.com/Dicebot/DIPs), it's about collecting 
high-quality DIPs in "Drafts" that are then "brought to the 
language authors for review".
Jun 10 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 10 June 2016 at 10:38:49 UTC, Andrei Alexandrescu 
wrote:

 On 6/10/16 9:00 AM, Jacob Carlborg wrote:

 On 2016-06-09 23:34, Walter Bright wrote:


 That doesn't stop anyone from commenting on them, offering 
 improvements,
 doing some promotion of them, organizing handling them, etc.


 If feel that's a bit pointless if no one with some form of 
 authority
 will look at it.


 It's much better than making informal remarks on the forum, 
 which then scroll out of memory. I encourage people who have 
 good ideas and are willing and able to take them to completion 
 to formulate them as DIPs. Good quality DIPs will eventually 
 get discussed more often and end up being implemented. -- Andrei


What is the statistics for DIPs authored by outsiders vs being 
implemented?
Jun 10 2016
parent reply Seb <seb wilzba.ch> writes:
On Friday, 10 June 2016 at 14:38:35 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 10 June 2016 at 10:38:49 UTC, Andrei Alexandrescu 
 wrote:

 On 6/10/16 9:00 AM, Jacob Carlborg wrote:

 On 2016-06-09 23:34, Walter Bright wrote:


 That doesn't stop anyone from commenting on them, offering 
 improvements,
 doing some promotion of them, organizing handling them, etc.


 If feel that's a bit pointless if no one with some form of 
 authority
 will look at it.


 It's much better than making informal remarks on the forum, 
 which then scroll out of memory. I encourage people who have 
 good ideas and are willing and able to take them to completion 
 to formulate them as DIPs. Good quality DIPs will eventually 
 get discussed more often and end up being implemented. -- 
 Andrei


 What is the statistics for DIPs authored by outsiders vs being 
 implemented?


I don't think that any DIP was proposed by an outsider - the 
major problem is that the "Approval" process isn't formal at all, 
that's why so many DIPs are "Drafts".
Have a look yourself at the DIP wiki: http://wiki.dlang.org/DIP
Jun 10 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 10 June 2016 at 14:44:22 UTC, Seb wrote:

 I don't think that any DIP was proposed by an outsider - the 
 major problem is that the "Approval" process isn't formal at 
 all, that's why so many DIPs are "Drafts".
 Have a look yourself at the DIP wiki: http://wiki.dlang.org/DIP


Hm, were these done by outsiders maybe:

DIP 6 by Ary Borenszweig in 2009
DIP 20 by Alex Rønne Petersen in 2012

I can't find any later ones.
Jun 10 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/10/16 10:52 AM, Ola Fosheim Grøstad wrote:

 On Friday, 10 June 2016 at 14:44:22 UTC, Seb wrote:

 I don't think that any DIP was proposed by an outsider - the major
 problem is that the "Approval" process isn't formal at all, that's why
 so many DIPs are "Drafts".
 Have a look yourself at the DIP wiki: http://wiki.dlang.org/DIP


 Hm, were these done by outsiders maybe:

 DIP 6 by Ary Borenszweig in 2009


No, Ary was a regular at that time.


 DIP 20 by Alex Rønne Petersen in 2012


Alex is a member of Phobos, druntime, dlang.org, and tools team.

-Steve
Jun 10 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 10 June 2016 at 15:37:31 UTC, Steven Schveighoffer 
wrote:

 DIP 20 by Alex Rønne Petersen in 2012


 Alex is a member of Phobos, druntime, dlang.org, and tools team.


Aww, apologies to Alex :-)

Modifying the compiler might be more productive than writing a 
DIP, then.
Jun 10 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/10/2016 9:38 AM, Ola Fosheim Grøstad wrote:

 On Friday, 10 June 2016 at 15:37:31 UTC, Steven Schveighoffer wrote:

 DIP 20 by Alex Rønne Petersen in 2012


 Alex is a member of Phobos, druntime, dlang.org, and tools team.


 Aww, apologies to Alex :-)

 Modifying the compiler might be more productive than writing a DIP, then.



Consider: would you ever have noticed a n.g. posting written by Alex in 2012?
Jun 12 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 12 June 2016 at 19:51:02 UTC, Walter Bright wrote:

 Consider: would you ever have noticed a n.g. posting written by 
 Alex in 2012?


But would it really have an effect if I wrote a DIP on getting 
predictable floating point behaviour? If there is a chance that 
it would, then I might consider it :-).
Jun 13 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/13/2016 3:33 AM, Ola Fosheim Grøstad wrote:

 But would it really have an effect if I wrote a DIP on getting predictable
 floating point behaviour? If there is a chance that it would, then I might
 consider it :-).


I encourage you to consider it.
Jun 13 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 13 June 2016 at 20:15:09 UTC, Walter Bright wrote:

 On 6/13/2016 3:33 AM, Ola Fosheim Grøstad wrote:

 But would it really have an effect if I wrote a DIP on getting 
 predictable
 floating point behaviour? If there is a chance that it would, 
 then I might
 consider it :-).


 I encourage you to consider it.


Ok, I am considering it. ;-)

I also don't think there is a problem in having DIPs that are in 
limbo. I prefer that over rejection, as most ideas often have 
something to them for others to build upon.

So it is better to just have some fields that lists how one DIP 
is related to another DIP (e.g. "replaced by", "related to", 
"depends on" etc).

Outright rejection probably just discourage people from 
contributing similar DIPs that would be good for the language.

Better with constructive qualitative comments which point out 
unresolved issues, which can lead to new improved DIPs.
Jun 15 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 15 June 2016 at 08:24:23 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 13 June 2016 at 20:15:09 UTC, Walter Bright wrote:

 On 6/13/2016 3:33 AM, Ola Fosheim Grøstad wrote:

 But would it really have an effect if I wrote a DIP on 
 getting predictable
 floating point behaviour? If there is a chance that it would, 
 then I might
 consider it :-).


 I encourage you to consider it.


 Ok, I am considering it. ;-)

 I also don't think there is a problem in having DIPs that are 
 in limbo. I prefer that over rejection, as most ideas often 
 have something to them for others to build upon.

 So it is better to just have some fields that lists how one DIP 
 is related to another DIP (e.g. "replaced by", "related to", 
 "depends on" etc).

 Outright rejection probably just discourage people from 
 contributing similar DIPs that would be good for the language.

 Better with constructive qualitative comments which point out 
 unresolved issues, which can lead to new improved DIPs.


Consider that there are many optimizations that rely on fp not 
being predictable. For instance, fabs(x) can be transformed into 
x | 0x80000000 if you don't care about NaN's sign (yes, NaN are 
signed).
Jun 15 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 June 2016 at 20:50:25 UTC, deadalnix wrote:

 Consider that there are many optimizations that rely on fp not 
 being predictable. For instance, fabs(x) can be transformed 
 into x | 0x80000000 if you don't care about NaN's sign (yes, 
 NaN are signed).


I guess that would be "-fabs(x)"? NaNs are signed, 
quiet/signalling and may carry an id. Floating point would truly 
benefit from a more constraint based typing system, but not sure 
how that would work out with D. (E.g. constraining a type to be 
non-Nan, non-Infinity, non-Zero etc subtype)

I am thinking that one should keep strict semantics and sloppy 
semantics separate in the type system. I am not a big fan of 
letting the compiler switches control it, so maybe float/double 
should work more like C/C++ or current D.

Then have other types for the strict semantics and allow direct 
bitmasking operations/simd. The overall solution could be 
restricted to a useful, but reproducible subset of 754-2008 
(avoiding trancendentals). Meaning, you would have to cast to 
double/float to get non-reproducible behaviour.

Then you can have implicit transition from strict->sloppy, but 
require explicit casting the other way.

For the strict type the rounding mode probably should be part of 
the type, enabling interval arithmetics and avoiding the "dynamic 
typing issues" of run-time rounding mode. Interval arithmetics is 
something that is hard to get right with the main C/C++ compilers.
Jun 15 2016
prev sibling next sibling parent reply Pie? <AmericanPie gmail.com> writes:
On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote:

 On 6/7/2016 1:32 PM, Jack Stouffer wrote:

 a lousy 28% of DIPs are either definitively closed or accepted.


 There are currently 34 issues on it, where we implemented a 
 feature and inadvertently broke something. There are constant 
 complaints on the forum that we have not "fully" implemented 
 things.



How about everyone stop working on "new features" and try to make 
D solid? Surely you realize the downside to starting a new 
project in the midst of a current one?  It's very easy to start 
something new, it's enticing in fact... But the the previous 
project(s) always suffer.

D doesn't need any more fancy new features. It needs to be made 
rock solid and made to be used. My biggest frustration with D is 
not the language or the compiler but the tools and 
regressions(that come from starting new "projects").

If one keeps piling stuff on top of stuff eventually the weight 
of it all creates such a pressure that it turns it into crap(or 
diamonds, but that usually takes millions of years ;)

I use Visual D, for example, and it's the most barbaric way to 
debug(ok, better than gbd and the other stuff you guys tend to 
use because you won't get out of the dark ages). I have to wade 
through useless information to find what I want. OTH, .NET 
debugging is a walk in the park... I can even write my own 
visualizers if I want too. I'm spoiled, I've seen the light. 
Forgive me! What's happening is that the "rest of the world" has 
great tool sets. D has great language capabilities.  D is ahead 
in that respect but is behind in the other.

Remember, most of the programmers out there are not you and they 
just want things to work so they can do their hello world apps or 
make a virus or fart app.  They need things to work, work well, 
and look nice and inviting. If you can't get these people you are 
catering only to the upper echelon of the programmers in the 
world, most of which are too hard headed and old to switch to 
something new.

Target the kids and D will live long and prosper, target the old 
fogies and it will die a quick death.
Jun 08 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2016 1:37 PM, Pie? wrote:

 How about everyone stop working on "new features" and try to make D solid?


This does get repeatedly proposed, usually along with "just add this one more 
feature" :-(

There aren't any easy answers.
Jun 08 2016
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote:

 On 6/7/2016 1:32 PM, Jack Stouffer wrote:

 a lousy 28% of DIPs are either definitively closed or accepted.


 I understand that is frustrating. It happens to mine as well, 
 though I am less bothered by it.

 It's a question of framing.

 Consider the regression list:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=208862&query_format=advanced

 There are currently 34 issues on it, where we implemented a 
 feature and inadvertently broke something. There are constant 
 complaints on the forum that we have not "fully" implemented 
 things.


I agree 100% with the sentiment. We have way too many 95% things. 
On the other hand, many DIPs are not about implement this new 
groundbreaking thing, but about tightening loose screws.

A good chunk of the problem is that development is made using the 
wack a mole methodology rather than a more principled approach. 
Having a DIP specifying at least the intended end goal would be 
beneficial. Such DIPs would for instance include DIP27/28/30 that 
change very little of the behavior, but fix a typesystem hole and 
provide a principled approach to what we already do.
Jun 08 2016
parent Pie? <AmericanPie gmail.com> writes:
On Wednesday, 8 June 2016 at 21:15:20 UTC, deadalnix wrote:

 On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote:

 On 6/7/2016 1:32 PM, Jack Stouffer wrote:

 a lousy 28% of DIPs are either definitively closed or 
 accepted.


 I understand that is frustrating. It happens to mine as well, 
 though I am less bothered by it.

 It's a question of framing.

 Consider the regression list:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=208862&query_format=advanced

 There are currently 34 issues on it, where we implemented a 
 feature and inadvertently broke something. There are constant 
 complaints on the forum that we have not "fully" implemented 
 things.


 I agree 100% with the sentiment. We have way too many 95% 
 things. On the other hand, many DIPs are not about implement 
 this new groundbreaking thing, but about tightening loose 
 screws.

 A good chunk of the problem is that development is made using 
 the wack a mole methodology rather than a more principled 
 approach. Having a DIP specifying at least the intended end 
 goal would be beneficial. Such DIPs would for instance include 
 DIP27/28/30 that change very little of the behavior, but fix a 
 typesystem hole and provide a principled approach to what we 
 already do.


Maybe you should make a DIP for that? ;)
Jun 08 2016
prev sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote:

 A DIP not being dealt with does not mean it is a bad idea. It 
 pretty much means we just aren't ready to deal with it at the 
 moment. It's time may not have come yet. But it's not going 
 away, it'll still be there when needed. I've found mining DIPs 
 to be quite useful in designing the 'return ref' feature. DIPs 
 are a gold mine of ideas that be built upon, and I know where 
 to find them.


So DIPs are more like idea pool and what wasn't outright rejected 
so far can still be of some interest?
Jun 09 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/9/2016 6:54 AM, Kagamin wrote:

 On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote:

 A DIP not being dealt with does not mean it is a bad idea. It pretty much
 means we just aren't ready to deal with it at the moment. It's time may not
 have come yet. But it's not going away, it'll still be there when needed. I've
 found mining DIPs to be quite useful in designing the 'return ref' feature.
 DIPs are a gold mine of ideas that be built upon, and I know where to find
them.


 So DIPs are more like idea pool and what wasn't outright rejected so far can
 still be of some interest?


Of course.

For example, there have been many ref counting proposals for D (not remotely
all 
of them are DIPs). They've all had problems of one sort or another, but by 
reviewing existing work one has a hope of coming up with a better proposal than 
repeating a flawed one. Or one can take the "best of" the various proposals to 
produce a better one. It becomes part of the collective knowledge around D.
Jun 09 2016