Re: The Problem With DIPs
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 | 0x8000 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.
Re: The Problem With DIPs
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 | 0x8000 if you don't care about NaN's sign (yes, NaN are signed).
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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 :-).
Re: The Problem With DIPs
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?
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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 :(
Re: The Problem With DIPs
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)?
Re: The Problem With DIPs
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-177c121a9...@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).
Re: The Problem With DIPs
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-177c121a9...@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?
Re: The Problem With DIPs
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-177c121a9...@dicebot.lv
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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
Re: The Problem With DIPs
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?
Re: The Problem With DIPs
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".
Re: The Problem With DIPs
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
Re: The Problem With DIPs
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
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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?
Re: The Problem With DIPs
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
Re: The Problem With DIPs
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!
Re: The Problem With DIPs
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_status=NEW_status=ASSIGNED_status=REOPENED_id=208862_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? ;)
Re: The Problem With DIPs
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_status=NEW_status=ASSIGNED_status=REOPENED_id=208862_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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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.
Re: The Problem With DIPs
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_status=NEW_status=ASSIGNED_status=REOPENED_id=208862_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.
Re: The Problem With DIPs
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/ozvzscpmbixskarsg...@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/iukxggyeisypmkgfh...@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!
The Problem With DIPs
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/ozvzscpmbixskarsg...@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
