Jump to page: 1 210  
Page
Thread overview
I close BIP27. I won't be pursuing BIPs anymore
Oct 16, 2016
deadalnix
Oct 17, 2016
Nick Sabalausky
Oct 17, 2016
Dicebot
Oct 17, 2016
deadalnix
Oct 20, 2016
Dicebot
Oct 17, 2016
Jacob Carlborg
Oct 17, 2016
Walter Bright
Oct 17, 2016
David Soria Parra
Re: I close DIP27. I won't be pursuing DIPs anymore
Oct 17, 2016
David Soria Parra
Oct 20, 2016
Dicebot
Oct 17, 2016
Walter Bright
Re: I close DIP27. I won't be pursuing DIPs anymore
Oct 17, 2016
Joakim
Oct 17, 2016
Walter Bright
Oct 17, 2016
Joakim
Oct 17, 2016
Joakim
Oct 17, 2016
Jonathan M Davis
Oct 17, 2016
ZombineDev
Oct 17, 2016
Walter Bright
Oct 18, 2016
Manu
Oct 18, 2016
Walter Bright
Oct 19, 2016
Manu
Oct 20, 2016
Shachar Shemesh
Oct 18, 2016
Namespace
Oct 18, 2016
ketmar
Oct 18, 2016
Namespace
Oct 18, 2016
Jonathan M Davis
Oct 18, 2016
Jonathan M Davis
Oct 19, 2016
Manu
Oct 18, 2016
ag0aep6g
Oct 18, 2016
Jonathan M Davis
Oct 18, 2016
Atila Neves
Oct 18, 2016
Jacob
Oct 19, 2016
Jacob
Oct 19, 2016
Manu
Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
Oct 19, 2016
Jonathan M Davis
Oct 19, 2016
Jonathan M Davis
Oct 19, 2016
Namespace
Oct 19, 2016
Jonathan M Davis
Oct 19, 2016
Namespace
Oct 20, 2016
Manu
Oct 20, 2016
Walter Bright
Oct 20, 2016
Manu
Oct 20, 2016
Manu
Oct 18, 2016
bachmeier
Oct 18, 2016
Walter Bright
Oct 18, 2016
Timon Gehr
Re: rvalue references
Oct 19, 2016
Marco Leise
Oct 19, 2016
Timon Gehr
Oct 19, 2016
Marco Leise
Oct 18, 2016
Walter Bright
Oct 18, 2016
Namespace
Oct 19, 2016
Manu
Oct 19, 2016
Ethan Watson
Oct 19, 2016
Manu
Oct 19, 2016
Ethan Watson
Oct 19, 2016
Walter Bright
Oct 19, 2016
Walter Bright
Oct 20, 2016
Ethan Watson
Oct 20, 2016
Namespace
Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
Oct 20, 2016
Walter Bright
Oct 20, 2016
Walter Bright
Oct 21, 2016
Manu
Oct 21, 2016
Ethan Watson
Oct 21, 2016
Walter Bright
Oct 21, 2016
Timon Gehr
Oct 22, 2016
Timon Gehr
Oct 22, 2016
Jonathan M Davis
Oct 23, 2016
bitwise
Oct 28, 2016
bitwise
Oct 30, 2016
bitwise
Oct 19, 2016
Guillaume Piolat
Oct 19, 2016
Namespace
Oct 19, 2016
Guillaume Piolat
Oct 17, 2016
bitwise
Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
Oct 20, 2016
Jonathan M Davis
Oct 20, 2016
Nicholas Wilson
Oct 21, 2016
ag0aep6g
Oct 21, 2016
Jonathan M Davis
October 16, 2016
Long story short, it si clearly a waste of time. Qualifying the process would be an understatement.

Some specifically DIP27 has been written in Feb 2913, following various discussion at that time. I pushed it at the time. I moved it to the new git DIP repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the loop time is measured in month.

I'm doing this on my free time. I have other things to do.

The DIP process is beyond broken. It essentially goes as :
 - If you are Andrei or Walter, then your DIP is just a formality. No matter how bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we clearly need that for lifetime).
 - If anybody else does it, you have no idea what you are getting into. You'll be still there in 5 years with no end in sight.

I've been a sucker for long enough. I'm not playing anymore and I'd suggest to anyone playing to stop. I've probably be playing longer than pretty much anyone here. Trust the bitter old man, he knows.
October 17, 2016
On Sunday, 16 October 2016 at 22:17:15 UTC, deadalnix wrote:
> Long story short, it si clearly a waste of time. Qualifying the process would be an understatement.
>
> Some specifically DIP27 has been written in Feb 2913, following various discussion at that time. I pushed it at the time. I moved it to the new git DIP repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the loop time is measured in month.
>
> I'm doing this on my free time. I have other things to do.
>
> The DIP process is beyond broken. It essentially goes as :
>  - If you are Andrei or Walter, then your DIP is just a formality. No matter how bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we clearly need that for lifetime).
>  - If anybody else does it, you have no idea what you are getting into. You'll be still there in 5 years with no end in sight.
>
> I've been a sucker for long enough. I'm not playing anymore and I'd suggest to anyone playing to stop. I've probably be playing longer than pretty much anyone here. Trust the bitter old man, he knows.

It's not just DIPs, that pretty much fits my experience with dmd/phobos PRs, too. The only feedback is trivial nitpicking, and then you spend a year or so babysitting an endless stream of rebases just for it to keep getting ignored.
October 17, 2016
Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected.

But what you say here only shows that process is working as intended - and that it is not suitable for you. Quote from readme: "Be prepared for a lot of work. There are always many ideas proposed but far fewer developers commited to pursuing the idea to the final stages of evaluation. The DIP system is not for submitting undeveloped ideas, it is a process for formal approval of language changes".

There isn't any lack of ideas in D community. Those don't hold much value on its own. What is needed is commitment and stubbornness, and DIP system, among other things, helps to not pay attention to those who are unlikely to pursue their idea to an end.

On Sunday, 16 October 2016 at 22:17:15 UTC, deadalnix wrote:
> The DIP process is beyond broken. It essentially goes as :
>  - If you are Andrei or Walter, then your DIP is just a formality. No matter how bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we clearly need that for lifetime).

This is explicitly mentioned in README. Like it or not, but this is reality we have to live with and there is no point in pretending otherwise. Walter won't change and you can either try to make best of the status quo or move on to other things.

>  - If anybody else does it, you have no idea what you are getting into. You'll be still there in 5 years with no end in sight.
>
> I've been a sucker for long enough. I'm not playing anymore and I'd suggest to anyone playing to stop. I've probably be playing longer than pretty much anyone here. Trust the bitter old man, he knows.

.. and trying to convince others that your specific choice is "correct" is a shitty move.
October 17, 2016
On Monday, 17 October 2016 at 02:08:44 UTC, Dicebot wrote:
> Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected.
>

I spent fuck 4;5 years on that thing. Don't come at me saying I'm not interested in polishing it. I'm not interested in wasting my time. That's entirely different.

October 16, 2016
On 10/16/2016 3:17 PM, deadalnix wrote:
> Long story short, it si clearly a waste of time. Qualifying the process would be
> an understatement.
>
> Some specifically DIP27 has been written in Feb 2913, following various
> discussion at that time. I pushed it at the time. I moved it to the new git DIP
> repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the
> loop time is measured in month.

The wiki DIP27 is here:

  https://wiki.dlang.org/DIP27

listed as a draft, last change Sep 2014. I don't see it in the new DIP repository:

  https://github.com/dlang/DIPs

either submitted, approved, or in a PR.


> I'm doing this on my free time. I have other things to do.
>
> The DIP process is beyond broken. It essentially goes as :
>  - If you are Andrei or Walter, then your DIP is just a formality. No matter how
> bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we
> clearly need that for lifetime).
>  - If anybody else does it, you have no idea what you are getting into. You'll
> be still there in 5 years with no end in sight.

Here's the list of approved DIPs. (It's a short list.)

  https://github.com/dlang/DIPs/blob/master/DIPs/archive/README.md


> I've been a sucker for long enough. I'm not playing anymore and I'd suggest to
> anyone playing to stop. I've probably be playing longer than pretty much anyone
> here. Trust the bitter old man, he knows.

I know it's hard to get any language changes approved. Arguably, it should be hard. For better or worse, it also takes those who believe in it to promote it, convince others of its value, and get behind it an push, hard.

My proposals to C++ have seen 100% failure to gain any traction, so I have some basis for understanding how you feel. Ironically, after implementing them in D, they seem to have found fertile ground in C++, after being championed by others. My sole acknowledged contribution to C++ is the Named Return Value optimization, the rest are all unacknowledged via D :-)

P.S. DIP25 had several reported bugs in it, but they have all been fixed or have open PRs to fix. None were fatal to the idea, they were just bugs.

P.P.S. It may not be obvious, but you have been a positive and valued contributor to D for a long time. Thank you!
October 17, 2016
On 2016-10-17 04:08, Dicebot wrote:
> Listen, I understand you are not interested in spending loads of time on
> boring polishing of formalities. We all do this in our spare time so
> that is to be expected.
>
> But what you say here only shows that process is working as intended

Well, the designed of the DIP process if flawed. It's basically impossible to get something through the process unless you're Andrei or Walter. Yes, I know there's been approved DIP's but that was long time ago, when the process was very loosely defined.

If you're Walter or Andrei it's more of an FYI. Most likely Andrei already merged Walter's PR for DMD for this DIP, three weeks ago after being open for two hours.

-- 
/Jacob Carlborg
October 17, 2016
On 10/17/2016 01:02 AM, Walter Bright wrote:
> On 10/16/2016 3:17 PM, deadalnix wrote:
>> Long story short, it si clearly a waste of time. Qualifying the
>> process would be
>> an understatement.
>>
>> Some specifically DIP27 has been written in Feb 2913, following various
>> discussion at that time. I pushed it at the time. I moved it to the
>> new git DIP
>> repository. Got mostly irrelevant feedback (Hi Martin) and more
>> generaly the
>> loop time is measured in month.
>
> The wiki DIP27 is here:
>
>   https://wiki.dlang.org/DIP27
>
> listed as a draft, last change Sep 2014. I don't see it in the new DIP
> repository:
>
>   https://github.com/dlang/DIPs
>
> either submitted, approved, or in a PR.

I understand your frustration and please bear with us while we're arranging the DIP process to guarantee timely response.

Made a pass through https://wiki.dlang.org/DIP27. It needs serious work in order for it to be considered at the level of quality we want to foster. Here are a few suggestions that may improve its chances:

* The Rationale section should present evidence and examples, instead of argumentative prose, to explain how the complexity of the language creates problems for function definitions.

* Good evidence would include e.g. bugs or contorted code in existing D projects, repeated confusion in the learn forum, undue complications in the language definition, arcane compiler implementation - anything and everything that shows this is a significant problem.

* There should be more concrete motivation and explanation on how exactly the language is simplified, and what the beneficial consequences of such simplification are (e.g. no more puzzling behavior, smaller/more precise specification, fewer corner cases etc).

* The "Function definition and uses" section and the two following ones should explain where the proposed changes diverge from the current language. The constructive definition by means of an enum is useful, but does not offer sufficient insight to estimate the issues with the existing language definition and how the proposal addresses them.

* At best, some proposed text for the language definition would be good to have, e.g. "the following paragraph in the definition: [...] shall be replaced with: [...]".

* A careful editorial pass must be done to remove the numerous typos that make the document imprecise and difficult to read.

Overall, as things stand, it is difficult for the reader to figure (a) what the benefits of the DIP are; (b) what the cost is in terms of code breakage (e.g. which constructs will break and how). Conveying a good understanding of the relationship between costs and benefits would greatly improve the DIP.

Also, one thing to keep in mind: the way we intend DIPs going forward is ideally there would be scrutiny followed by some pick up in the community before a DIP gets submitted for formal review. The DIP has been posted in the forum on 2013-02-26 and has garnered 51 follow-ups through the next day. There were 6 more changes to the document also during those two days (https://wiki.dlang.org/?title=DIP27&action=history), most minor; most importantly the "is" expression section was added (https://wiki.dlang.org/?title=DIP27&diff=2216&oldid=2210). After that the document has been unchanged (save for one semicolon added by Rainer) for over three and a half years, during which there was no subsequent community discussion either. In an ideal world there would be some more interest and action leading up to a formal review.


Thanks,

Andrei

October 16, 2016
On 10/16/2016 11:39 PM, Jacob Carlborg wrote:
> Most likely Andrei already merged Walter's PR for DMD for this DIP,
> three weeks ago after being open for two hours.

What are you referring to?

October 17, 2016
On 10/17/2016 02:39 AM, Jacob Carlborg wrote:
> On 2016-10-17 04:08, Dicebot wrote:
>> Listen, I understand you are not interested in spending loads of time on
>> boring polishing of formalities. We all do this in our spare time so
>> that is to be expected.
>>
>> But what you say here only shows that process is working as intended
>
> Well, the designed of the DIP process if flawed.

What steps do you think we could take to improve it? Since Dicebot took the reins things are showing real promise. I'm sure he'd be interested in taking suggestions.

> It's basically
> impossible to get something through the process unless you're Andrei or
> Walter. Yes, I know there's been approved DIP's but that was long time
> ago, when the process was very loosely defined.

Sadly the process is still not super rigorous, but as I said we're working on it.

Could you please mention a few DIPs that have merit and have been unjustly rejected?

> If you're Walter or Andrei it's more of an FYI. Most likely Andrei
> already merged Walter's PR for DMD for this DIP, three weeks ago after
> being open for two hours.

Looking at https://wiki.dlang.org/?title=DIP27&action=history, I'm seeing 10 approved DIPs. Their respective authors are: Michel Fortin and Jacob Carlborg, Alex Rønne Petersen, Dicebot and Martin Nowak, Walter Bright and Andrei Alexandrescu, Jonathan M Davis, Walter Bright (4), and David Soria Parra and Martin Nowak.

Would you not expect that the creator of the language has a good presence in new work on the language?


Andrei

October 17, 2016
On Monday, 17 October 2016 at 05:02:52 UTC, Walter Bright wrote:
> On 10/16/2016 3:17 PM, deadalnix wrote:
>> Long story short, it si clearly a waste of time. Qualifying the process would be
>> an understatement.
>>
>> Some specifically DIP27 has been written in Feb 2913, following various
>> discussion at that time. I pushed it at the time. I moved it to the new git DIP
>> repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the
>> loop time is measured in month.
>
> The wiki DIP27 is here:
>
>   https://wiki.dlang.org/DIP27
>
> listed as a draft, last change Sep 2014. I don't see it in the new DIP repository:
>
>   https://github.com/dlang/DIPs
>
> either submitted, approved, or in a PR.
>
>

https://github.com/dlang/DIPs/pull/16


« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10