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