www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Walter and Andrei and community relationship management

reply Nick B <nick.barbalich gmail.com> writes:
I'm going to address this post to Walter and Andrei, as the joint 
captains of the D ship, so to speak.


As an outsider I can see there are two major issues, at play, at 
present, in this series of threads.

1. The technical proposals and arguments for x & y, or against x 
& y. On one side is Walter & Andrei with Walters proposal, and 
the other is Deadalnix.

2. The relationship management, between the co-captains and the 
community. And the perception of the different rules for the 
captains verses the community, which causes
resentment, and friction, to members of this community.

I'm not going to discuss item 1 in-depth, because item 2 is far 
more important.

So let's go back to the beginning.

------------------------

Andrei starts a thread, 4 days ago, titled 'Exceptions in  nogc 
code'.

     "Walter and I discussed the following promising setup:

     Use "throw new scope Exception" from  nogc code. That will 
cause the exception to be allocated in a special stack-like 
region.

     If the catching code uses "catch (scope Exception obj)", then 
a reference to the exception thus created will be passed to 
catch. At the end of the catch block there's
no outstanding reference to "obj" so it will be freed. All  nogc 
code must use this form of catch.

     If the catching code uses "catch (Exception obj)", the 
exception is cloned on the gc heap and then freed.

     Finally, if an exception is thrown with "throw new Exception" 
it can be caught with "catch (scope Exception obj)" by copying 
the exception from the heap into the special region, and then 
freeing the exception on the heap.

     Such a scheme preserves backward compatibility and leverages 
the work done on "scope".


----------------------------

Deadalnix enters the discussion in Andrei's thread, with:

     "It doesn't need any kind of throw new scope Exception, and 
was proposed, literally, years ago during discussion around DIP25 
and alike.

     I urge you to reconsider the proposal that were made at the 
time. They solve all the problems you are discovering now, and 
more. And, while more complex that DIP25
alone, considering DIP25+DIP1000+this thing+the RC object thing, 
you are already in the zone where the "simple" approach is not so 
simple already.

     Things are unfolding exactly as predicted at the time. Ad hoc 
solutions to various problems are proposed one by one and the 
overall complexity is growing much larger
than initially proposed solutions."

Others (Eugene Wissner & Dmitry Olshansky) also comment on the 
proposed syntax.

Walters responds to Deadalnix by asking for more details:

     > It doesn't need any kind of throw new scope Exception, and 
was proposed,
     > literally, years ago during discussion around DIP25 and 
alike.

     "A link to that proposal would be appreciated."

Walter adds an additional requirement in response to Deadalnix

     "This does not address the stated need (by many programmers) 
to not even have to link in the GC code. A solution that falls 
short of this will be rejected. The
rejections may not be technically well founded, but we're not in 
a good position to try to educate the masses on this. A solution 
that does not require linking to the GC
sidesteps that problem."

Walter then adds the following:

     >  I urge you to reconsider the proposal that were made at 
the time. They solve all
     > the problems you are discovering now, and more. And, while 
more complex that
     > DIP25 alone, considering DIP25+DIP1000+this thing+the RC 
object thing, you are
     > already in the zone where the "simple" approach is not so 
simple already.

     "I did some searching for this previous proposal discussion, 
but could not find it. Instead, I'll go by your description of it 
here.

     I've written a more fleshed out proposal and started a new 
thread with it. Feel free to rip it to shreds! "
------------------------

Walter then starts a new thread, 3 days ago, titled: Proposal: 
"Exceptions and  nogc". Within the post he lays sub-headings out: 
Problem; Solution; throw Expression; catch

(Exception e); Chained Exceptions; Copying Exceptions; Legacy 
Code Breakage; Conclusion; and References. It's like a DIP in 
structure, but its NOT a formal DIP.

Walters replies to a request by Rikki Cattermole for a DIP.

     >And as probably expected, DIP please. Its a big set of 
changes and warrants
     > documenting in that form.

     "If it survives the n.g. discussion I will. Though the DIP 
process is in limbo at the moment since Dicebot is no longer 
running it."

Here Walter is saying, lets discuss it thoroughly on the n.g. and 
then LATER, if it's any good, he will formal put it into a DIP.
Fair enough.
----------------------------

Discussions continue.

Deadalix then composes a long reply, in Andreis thread, to 
Walters request. He is hopeful he will be heard:

     "The forum search isn't returning anything useful so I'm not 
sure how to get that link. However, it goes roughly as follow. 
Note that it's a solution to solve
DIP25+DIP1000+RC+nogc exception and a sludge of other issues, and 
that comparing it to any of these independently will yield the 
obvious it is more complex. "

[snip]

He posts a link to a Microsoft Research paper.

      "Going into the details here would take too long, so i'll 
just reference this paper ( 
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/0

applicable to D."

The PDF is 26 pages long, and very technical.  There is also a 
link to a Youtube talk that runs for over one hour.

Discussions continue, but Deadalix proposal is not replied to.

I (Nick) after 24 hours, of no response, then ask for a comment 
from Walter to Deadalix's proposal:

     "Can one assume that Walter is thinking about Deadalnix's 
detailed proposal above, and that he will give a formal response, 
once he has given it serious thought, and
discussed it with Andrei ?"

Walter then responds, and gives six counter-arguments to Deadalix 
proposal, and ends with:

    "This proposal looks promising for making a better garbage 
collected language, but people want a language with an optional 
GC."

Deadalix gives counter-arguements.

Walter gives more arguements,and Deadalix replies.

Then Andrei replies, to my post. I will quote in full:

     "As a matter of procedure no, a forum post will not be 
followed by a formal response. The DIP process ensures a formal 
response.

     The post is far from what one would call a proposal, let 
alone a detailed one. It is a sketch of an idea that addresses a 
complex matter without minding a large number
of details. That's totally fine; the whole discussion opener was 
also informal and lacking details. It's just that we can't work 
on someone else's vague idea.

     I encourage anyone interested in pursuing this idea to work 
on a DIP."

Deadalix, becomes angry at this request for a DIP, again I will 
quote in full:


     "To be blunt I played the DIP game in the past, never again.

     This is very time consuming and nobody gives a shit. You two 
just do whatever the heck you want at the end of the day. I'm 
just pointing I predicted the problem you are
running into with your brilliant approach years before you 
realized it is a problem. You can decide to not listen, not 
really my problem.

    I wrote fairly comprehensive specs of the idea in various 
places, including in the ML you created for this very topic. I 
just can't be writing specs again and again for
them to be ignored, that's just not a productive use of my time, 
and at this point I'd even say it's not very respectful to ask 
people to waste more time.

    I'm happy to work with you guy to come up with something, but 
I surely won't spend several days working a spec for nothing. "


Walter, gives a  18 lines of reply why he thinks the Deadalix 
proposal is unworkable.

Walters core objection can be summed up here:

     "For example, adding an `owned` type constructor is a major, 
major language change. Issues of implicit conversion, 
overloading, covariance, partial ordering, type deduction, 
mangling, construction, postblit, TypeInfo, inout, etc., all have 
to be addressed and worked out. Then there's legacy 
compatibility, deprecation issues,
interaction with other languages, interaction with multiple 
storage allocators, etc. "

I will quote the last two lines of Walters reply:

     "Making this work for D involves a great deal of careful 
design work, and even more implementation work. It also includes 
some significant risk that it will prove unworkable.

     I don't believe that a back-and-forth disjointed email chain 
here is going to resolve the major issues with it. Until a far 
more thorough design proposal is made, I'm going to bow out."

Walter can see what would need to be changed, and the risks 
involved, but he does not address, in his reply, the proposed 
benefits raised by Deadalnix, nor the claim it
will solve a number of problems.

As an alternative, Walter could of said, to Deadalnix, give me 
more detail here, and here, and here. But no, he asks Deadalnix 
to submit a formal DIP, for he believes the
proposal to be too large and risky.

Finally, Andrei,  replies to Deadalnix, commenting that his 
previous DIP was of poor quality; on his use of 'crude' language; 
and stating that he is framing the issue as
part of a larger problem.

Commentary.

I have tried very hard to be objective in this review of these 
discussions.

But, it seems that while Walter and Andrei are prepared to put a 
proposal out on the newsgroup, and then discuss it with the 
community, and then LATER, if its any good,
state they will formally document it into a DIP.

For the community, it seems different rules apply. In-depth 
news-groups discussions for new proposals are firstly encouraged 
and then later discouraged, with the ultimate
response that the proposal MUST be in the form of a 
time-consuming DIP, to be considered, even if it will ultimately 
wastes everyone time, and cause resentment in the community.
Apr 06 2017
next sibling parent reply Olivier FAURE <olivier.faure epitech.eu> writes:
On Thursday, 6 April 2017 at 07:24:28 UTC, Nick B wrote:

 I'm going to address this post to Walter and Andrei, as the 
 joint captains of the D ship, so to speak.

 [...]

 For the community, it seems different rules apply. In-depth 
 news-groups discussions for new proposals are firstly 
 encouraged and then later discouraged, with the ultimate
 response that the proposal MUST be in the form of a 
 time-consuming DIP, to be considered, even if it will 
 ultimately wastes everyone time, and cause resentment in the 
 community.


Agreed.

I don't want to make any assumptions, and I do respect Walter for 
consistently taking on a role that means that people keep 
criticizing his choices whatever he does, but his approach to 
dealing with the community is undeniably flawed, and seems to be 
breeding a lot of frustration and resentment.

My personal example is from a discussion we had in February about 
'return scope', where Walter Bright asked deadalnix to explain 
his case, and explain the problems he saw. At the time, deadalnix 
(and other users) replied that they didn't want to make their 
cases, because they had already done so in the past, and they 
expected Walter to ignore whatever they would tell him.

http://forum.dlang.org/post/o6h3re$26lo$1 digitalmars.com

I outlined several problems I saw with return scope, and Walter 
replied to my post, answering each point I made. And while it's 
commendable that Walter took the time to do it, those answers 
felt extremely frustrating to me; Walter did *not* address my 
points, and did not take what I was saying seriously. As an 
example, one of the problems I pointed out was:


 It only addresses cases where a reference might be escaped 
 through a single return value; it doesn't address escaping 
 through 'out' parameters,


The following conversation ensued:

Walter:

 Yes it does (the general case is storing a value into any data 
 structure pointed to by an argument).


Me:

 I don't understand. Let's say I have an arbitrary class 
 'Container', and I want a function that stores a pointer to an 
 int in this container, in a way that lets the function's caller 
 know that the int* given to it will last only as long as the 
 container, and I want to do it without return values. The 
 prototype would be akin to

     void store(ref <scope-info> Container cont, <scope-info> 
 int* ptr);

 And the code it would be used in would look like:

     {
         scope Container c;
         scope int*      ptr = ...;

         store(c, ptr);
     }

 What would the syntax be?


Walter:

     c.ptr = ptr;

 You can also do:

     ref Container store(ref return scope c, return scope int* 
 ptr);


The rest of the conversation basically went like this:
Me: This isn't possible, or if it is, it shouldn't be.
Walter: Yes it is. It compiles.
Me: Okay, but it shouldn't compile, because it make [invalid 
write error] possible.
Walter: Well, it doesn't compile with  safe.
Me: Yes, it does compile with  safe, and no, it shouldn't, and my 
point from the beginning was that your model made that kind of 
function impossible. Why do you think we're even talking about 
this?

In short, Walter asked for people to give their opinions on the 
subject; but when I did give my opinion, Walter did not take my 
points seriously, and basically assumed that the only reason I 
disagreed with him was that I didn't understand the subject as 
well as he did. Other people (including Dicebot) have complained 
about that.

This was a very frustrating experience, and I did not want to 
participate in the discussions about Dlang any further after that.

Look, again, I feel bad trash-talking Walter. He's putting a lot 
of effort into this. But he's clearly really, really bad at 
listening to other people. This has to be addressed at some point.
Apr 06 2017
parent reply bachmeier <no spam.net> writes:
On Thursday, 6 April 2017 at 13:55:43 UTC, Olivier FAURE wrote:


 I don't want to make any assumptions, and I do respect Walter 
 for consistently taking on a role that means that people keep 
 criticizing his choices whatever he does, but his approach to 
 dealing with the community is undeniably flawed, and seems to 
 be breeding a lot of frustration and resentment.


IMO the source of the problem is that Walter and Andrei have 
freedom to make any language changes they want, without even 
consulting the community, while everyone else has to put a lot of 
time into a formal proposal with nearly a 100% chance that it 
will be denied because of [insert your favorite reason]. The 
design of the language is done in something of a corporate 
fashion, and that leads to frustrated posts.*

* But not from me.
Apr 06 2017
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/6/17 1:56 PM, bachmeier wrote:

 On Thursday, 6 April 2017 at 13:55:43 UTC, Olivier FAURE wrote:
 

 I don't want to make any assumptions, and I do respect Walter for 
 consistently taking on a role that means that people keep criticizing 
 his choices whatever he does, but his approach to dealing with the 
 community is undeniably flawed, and seems to be breeding a lot of 
 frustration and resentment.


 
 IMO the source of the problem is that Walter and Andrei have freedom to 
 make any language changes they want, without even consulting the 
 community, while everyone else has to put a lot of time into a formal 
 proposal with nearly a 100% chance that it will be denied because of 
 [insert your favorite reason].


We commit to be more formal about the process, but overall it is correct 
that we have more say in what gets in the language. Allow me to add a 
couple of things.

First, this is the way things are commonly done in language design - a 
small committee defines a formal process and ultimately decides on 
features. In fact it is unusual that we put up unfinished ideas up for 
discussion, which we hope has the raises the level of responsibility in 
the community. I understand how what we did has been misunderstood as us 
just considering ourselves exempt from the due process. We have a very 
strong interest to follow a formal process and have the trail serve as a 
template to follow. (That intent is visible in 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md as well, with 
the unexpected twist of an interesting idea that obsoleted it. The idea 
has come from Daniel Nielsen in this forum and has been adapted with 
credit in https://github.com/dlang/druntime/pull/1756.)

Second, we are very much open to increasing the size of our committee. 
This is already happening - it is obvious that known strong contributors 
with a good track record and who make consistently valuable have a huge 
impact on the language and library definition. Fortunately we have quite 
a few of those. In contrast, our attention is more difficult to be 
commanded by commentators who have little history of pull requests, 
good-quality DIPs, articles etc. and attempt to strong-arm us into 
pursuing underspecified ideas.

Third, all of this is a process not an immutable status. We are learning 
leadership on the job, and although I think we have made large strides 
since only e.g. one year ago, there is much more to improve. Expect more 
changes in the future and please bear with us and grant us your 
understanding as we are getting the hang of it.


Andrei
Apr 06 2017
next sibling parent Nick B <nick.barbalich gmail.com> writes:
On Thursday, 6 April 2017 at 19:27:50 UTC, Andrei Alexandrescu 
wrote:


 We commit to be more formal about the process, but overall it 
 is correct that we have more say in what gets in the language. 
 Allow me to add a couple of things.

 First, this is the way things are commonly done in language 
 design - a small committee defines a formal process and 
 ultimately decides on features. In fact it is unusual that we 
 put up unfinished ideas up for discussion, which we hope has 
 the raises the level of responsibility in the community. I 
 understand how what we did has been misunderstood as us just 
 considering ourselves exempt from the due process. We have a 
 very strong interest to follow a formal process and have the 
 trail serve as a template to follow. (That intent is visible in 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md as 
 well, with the unexpected twist of an interesting idea that 
 obsoleted it. The idea has come from Daniel Nielsen in this 
 forum and has been adapted with credit in 
 https://github.com/dlang/druntime/pull/1756.)

 Second, we are very much open to increasing the size of our 
 committee. This is already happening - it is obvious that known 
 strong contributors with a good track record and who make 
 consistently valuable have a huge impact on the language and 
 library definition. Fortunately we have quite a few of those. 
 In contrast, our attention is more difficult to be commanded by 
 commentators who have little history of pull requests, 
 good-quality DIPs, articles etc. and attempt to strong-arm us 
 into pursuing underspecified ideas.

 Third, all of this is a process not an immutable status. We are 
 learning leadership on the job, and although I think we have 
 made large strides since only e.g. one year ago, there is much 
 more to improve. Expect more changes in the future and please 
 bear with us and grant us your understanding as we are getting 
 the hang of it.


Thank you for the detailed reply.  It helps the understanding by 
the community.
Apr 10 2017
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 6 April 2017 at 19:27:50 UTC, Andrei Alexandrescu 
wrote:

 We commit to be more formal about the process, but overall it 
 is correct that we have more say in what gets in the language. 
 Allow me to add a couple of things.

 First, this is the way things are commonly done in language 
 design - a small committee defines a formal process and 
 ultimately decides on features. In fact it is unusual that we 
 put up unfinished ideas up for discussion, which we hope has 
 the raises the level of responsibility in the community. I 
 understand how what we did has been misunderstood as us just 
 considering ourselves exempt from the due process.


I'm glad to hear your intentions regarding process, but on this 
note I think there's a point that's worth considering.

One of the challenges we have is that a number of talented people 
have in the last years become disillusioned with the ability to 
get results through the processes on the table, or to have their 
feedback taken into account.  That means that there's not just a 
question of process moving forward; there's a question of how to 
undo the credibility gap that's been created by these past events.

So, while I think it's good that you lead by example in putting 
complete ideas up for discussion, it's also necessary to lead by 
example in actively seeking and taking on board feedback on these 
ideas, wherever it comes from (whether through a formal DIP 
review, or in discussion on the message boards, or whatever).  
This matters because if people can see that their smaller-scale 
feedback is being clearly taken into account, it gives greater 
encouragement to actually put in the work on larger-scale, more 
complete ideas of their own.

To take an example, Deadalnix' feedback on the  nogc Exceptions 
thread may not have been actionable, but there was detailed 
information there that could have been the subject of future 
investigation.  It comes across as putting process before 
community to insist that this feedback be provided via a DIP or 
in the formal review of a DIP 
<https://forum.dlang.org/post/oc2n3d$ijg$1 digitalmars.com> 
before it will be taken on board.  You have the information; why 
wouldn't you engage with it, if nothing else just to show 
willingness to break with the way things turned out in the past?

Put it this way: if the complaint is that you and Walter bypass 
process when you feel like it to get your own ideas through, a 
good way back from that might be to switch the equation round -- 
to _strictly_ apply process to your own ideas and contributions, 
but to actively engage with community feedback and ideas even 
when it doesn't go through the expected channels.

Then, if you get some level of progress and increased engagement 
with that, you might slowly make the process for everyone 
stricter over time -- once confidence in the process has been 
re-established.

That general principle -- of applying a higher bar to oneself 
than to anyone else -- is one that can serve well in increasing 
confidence in leadership.
Apr 14 2017
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Points well taken, thanks. One clarification - there is no need to 
formalize feedback to a DIP as another DIP, unless of course it is an 
alternative approach of its own.

A better process will indeed help all of us and raise the level of 
responsibility across the board. Acting on feedback entails good 
feedback is being passed around, thus creating a virtuous circle. So far 
the best example of that we have around is DIP1005, wherein successive 
rounds of meaningful feedback led to rigorous experiments and reviews, 
which in turn revealed new and surprising insights.


Thanks,

Andrei

On 04/14/2017 11:12 AM, Joseph Rushton Wakeling wrote:

 On Thursday, 6 April 2017 at 19:27:50 UTC, Andrei Alexandrescu wrote:

 We commit to be more formal about the process, but overall it is
 correct that we have more say in what gets in the language. Allow me
 to add a couple of things.

 First, this is the way things are commonly done in language design - a
 small committee defines a formal process and ultimately decides on
 features. In fact it is unusual that we put up unfinished ideas up for
 discussion, which we hope has the raises the level of responsibility
 in the community. I understand how what we did has been misunderstood
 as us just considering ourselves exempt from the due process.


 I'm glad to hear your intentions regarding process, but on this note I
 think there's a point that's worth considering.

 One of the challenges we have is that a number of talented people have
 in the last years become disillusioned with the ability to get results
 through the processes on the table, or to have their feedback taken into
 account.  That means that there's not just a question of process moving
 forward; there's a question of how to undo the credibility gap that's
 been created by these past events.

 So, while I think it's good that you lead by example in putting complete
 ideas up for discussion, it's also necessary to lead by example in
 actively seeking and taking on board feedback on these ideas, wherever
 it comes from (whether through a formal DIP review, or in discussion on
 the message boards, or whatever).  This matters because if people can
 see that their smaller-scale feedback is being clearly taken into
 account, it gives greater encouragement to actually put in the work on
 larger-scale, more complete ideas of their own.

 To take an example, Deadalnix' feedback on the  nogc Exceptions thread
 may not have been actionable, but there was detailed information there
 that could have been the subject of future investigation.  It comes
 across as putting process before community to insist that this feedback
 be provided via a DIP or in the formal review of a DIP
 <https://forum.dlang.org/post/oc2n3d$ijg$1 digitalmars.com> before it
 will be taken on board.  You have the information; why wouldn't you
 engage with it, if nothing else just to show willingness to break with
 the way things turned out in the past?

 Put it this way: if the complaint is that you and Walter bypass process
 when you feel like it to get your own ideas through, a good way back
 from that might be to switch the equation round -- to _strictly_ apply
 process to your own ideas and contributions, but to actively engage with
 community feedback and ideas even when it doesn't go through the
 expected channels.

 Then, if you get some level of progress and increased engagement with
 that, you might slowly make the process for everyone stricter over time
 -- once confidence in the process has been re-established.

 That general principle -- of applying a higher bar to oneself than to
 anyone else -- is one that can serve well in increasing confidence in
 leadership.
Apr 14 2017
prev sibling parent reply HaraldZealot <harald_zealot tut.by> writes:
On Thursday, 6 April 2017 at 17:56:03 UTC, bachmeier wrote:

 On Thursday, 6 April 2017 at 13:55:43 UTC, Olivier FAURE wrote:


 I don't want to make any assumptions, and I do respect Walter 
 for consistently taking on a role that means that people keep 
 criticizing his choices whatever he does, but his approach to 
 dealing with the community is undeniably flawed, and seems to 
 be breeding a lot of frustration and resentment.


 IMO the source of the problem is that Walter and Andrei have 
 freedom to make any language changes they want, without even 
 consulting the community, while everyone else has to put a lot 
 of time into a formal proposal with nearly a 100% chance that 
 it will be denied because of [insert your favorite reason]. The 
 design of the language is done in something of a corporate 
 fashion, and that leads to frustrated posts.*


I agree.

I was never personally affected by this (because I haven't 
contributed to the language or library), but I have heard enough 
rumours and read enough posts, that see this as problematic (and 
even frustrated although me not personally touched).

The problem exists probably because D community some years ago 
reached the scale when only interpersonal non-formal 
communication doesn't work for managing the development process. 
I know that Walter is oppose  to any code of conduct, but it is 
really time for this. The formalization of processes gives 
transparency and objectivity, very high needed values especially 
for volunteer community. A depersonification could also go by 
hand (but not necessary, having a written rule where e.g. Walter 
personally designated to specific role and exceptions, better 
that not have rule at all).

The DIP process is very good step in this way, but much more 
required. E.g. I have heard so much about miserable commit 
messages of one of pillar developers, that it would be funny if 
it wouldn't be so sad.

I hope that D community find its good way to interoperate and 
hence survive.

Alaksiej Stankievič
Apr 11 2017
parent reply bachmeier <no spam.net> writes:
On Tuesday, 11 April 2017 at 13:20:58 UTC, HaraldZealot wrote:

 I hope that D community find its good way to interoperate and 
 hence survive.


Just to clarify, I'm not sure that the current process is broken. 
As Ken Thompson has said of C++: "It certainly has its good 
points. But by and large I think it’s a bad language. It does a 
lot of things half well and it’s just a garbage heap of ideas 
that are mutually exclusive." The current process does protect D 
from going down that road, AFAICT. This might upset some 
individuals, but the alternative, where the community designs the 
language, could very well be worse.
Apr 11 2017
parent Shachar Shemesh <shachar weka.io> writes:
On 11/04/17 21:04, bachmeier wrote:

 On Tuesday, 11 April 2017 at 13:20:58 UTC, HaraldZealot wrote:

 I hope that D community find its good way to interoperate and hence
 survive.


 Just to clarify, I'm not sure that the current process is broken. As Ken
 Thompson has said of C++: "It certainly has its good points. But by and
 large I think it’s a bad language. It does a lot of things half well and
 it’s just a garbage heap of ideas that are mutually exclusive." The
 current process does protect D from going down that road, AFAICT.


You do realize that the thread we're discussing is about how to 
reconcile exceptions and nogc, right? It seems that they are, at least 
so far, mutually exclusive.

Shachar
Apr 12 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2017 12:24 AM, Nick B wrote:

 For the community, it seems different rules apply. In-depth news-groups
 discussions for new proposals are firstly encouraged and then later
discouraged,
 with the ultimate
 response that the proposal MUST be in the form of a time-consuming DIP, to be
 considered, even if it will ultimately wastes everyone time, and cause
 resentment in the community.


There's one big difference. The proposal I put forth is fairly complete, and I 
am well along implementing it. deadalnix's requires a great deal of further
work 
just to figure out what it means - as presented, it is not much more than an
idea.

Nor is it a simple idea. It will upend D's type system. It'll likely affect
much 
of the semantic code in the compiler, and will require a lot of retrofitting in 
Phobos. Who knows how extensive that will be.

I don't know any language process that would accept it as it stands - it would 
get bounced back with "needs more work". Somebody has to work on it to move it 
forward - who do you propose should do it? We don't have a team anywhere whose 
job it is to create detailed proposals based on other peoples' ideas (which 
appear in the forum every day). Things rarely move forward unless a champion
for 
it self-selects with the will and motivation to push it relentlessly.

(The general attitude of the C++ committee is if no champion emerges for a 
proposal that is willing to fix it and address all concerns about it and fight 
for it, then the proposal is not worth considering. It works for them.)

If you or anyone else wants to be the champion for deadalnix's idea, I
encourage 
you to do so. Collaborate here or in any way that works for you. I'm not going 
to shut you or anyone down on such discussions. I have already done a review of 
it and identified where it needs more work, so the next step is up to you.

(I also did not submit it as a DIP because the DIP process at the time was in 
limbo due to Dicebot exiting it. Now that Mike Parker is the new DIP czar, 
things should be moving again.)
Apr 06 2017
parent reply Nick B <nick.barbalich gmail.com> writes:
On Thursday, 6 April 2017 at 19:17:53 UTC, Walter Bright wrote:


 There's one big difference. The proposal I put forth is fairly 
 complete, and I am well along implementing it. deadalnix's 
 requires a great deal of further work just to figure out what 
 it means - as presented, it is not much more than an idea.

 Nor is it a simple idea. It will upend D's type system. It'll 
 likely affect much of the semantic code in the compiler, and 
 will require a lot of retrofitting in Phobos. Who knows how 
 extensive that will be.


I understand. It was a major change, and you likely felt the 
risks were not worth it.

 I don't know any language process that would accept it as it 
 stands - it would get bounced back with "needs more work".


Yes, but if you had detailed which areas, he might of been more 
receptive.


 Somebody has to work on it to move it forward - who do you 
 propose should do it? We don't have a team anywhere whose job 
 it is to create detailed proposals based on other peoples' 
 ideas (which appear in the forum every day). Things rarely move 
 forward unless a champion for it self-selects with the will and 
 motivation to push it relentlessly.


That sets a high bar. Can you give an example when this has 
worked well, or have they been mostly minor changes?

 (The general attitude of the C++ committee is if no champion 
 emerges for a proposal that is willing to fix it and address 
 all concerns about it and fight for it, then the proposal is 
 not worth considering. It works for them.)


So this is your and Andreis approach? If so, perhaps you want to 
document it, so everyone understands.


 If you or anyone else wants to be the champion for deadalnix's 
 idea, I encourage you to do so. Collaborate here or in any way 
 that works for you. I'm not going to shut you or anyone down on 
 such discussions. I have already done a review of it and 
 identified where it needs more work, so the next step is up to 
 you.


No, its his big idea, and I don't understand it well enough to 
push it.
But I also think that your vision of the language, seems to be 
fluid at present, with the requirements to support a GC, ARC, and 
the ability to remove the run-time. Again perhaps you and Andrei 
want to confirm this direction.

My intent for this post, was to bring to both your attentions, 
how this was perceived by the outsiders/community, and a 
perceived (if incorrect) double standard. That was all.


 (I also did not submit it as a DIP because the DIP process at 
 the time was in limbo due to Dicebot exiting it. Now that Mike 
 Parker is the new DIP czar, things should be moving again.)


Good to hear.
Apr 10 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/10/2017 3:58 AM, Nick B wrote:

 Somebody has to work on it to move it forward - who do you propose should do
 it? We don't have a team anywhere whose job it is to create detailed proposals
 based on other peoples' ideas (which appear in the forum every day). Things
 rarely move forward unless a champion for it self-selects with the will and
 motivation to push it relentlessly.


 That sets a high bar. Can you give an example when this has worked well, or
have
 they been mostly minor changes?


There are many. A random sampling:

Daniel Murphy - moving front end to D
Jacob Carlborg - Objective C support
Stephan Koch - newCTFE
Brad Roberts - autotester, bugzilla
the gdc and ldc teams
Rainer Schutze - GC work, Visual Studio support
Martin Nowak - the releases
Ali Cehreli - book on D
Adam Ruppe - book on D
Jan Knepper - the dlang site server

And a LOT more.

None of them are doing what I told them to do. I didn't pick any of them. They 
are all self-selected champions. They are what moves D forward.

Pragmatically speaking, the champions are the ones with the most say, because 
they do the work.

(Even doing the work doesn't guarantee acceptance, but it improves the odds 
greatly over just posting ideas.)
Apr 10 2017
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 10, 2017 15:07:11 Walter Bright via Digitalmars-d wrote:

 On 4/10/2017 3:58 AM, Nick B wrote:

 Somebody has to work on it to move it forward - who do you propose
 should do it? We don't have a team anywhere whose job it is to create
 detailed proposals based on other peoples' ideas (which appear in the
 forum every day). Things rarely move forward unless a champion for it
 self-selects with the will and motivation to push it relentlessly.


 That sets a high bar. Can you give an example when this has worked well,
 or have they been mostly minor changes?


 There are many. A random sampling:

 Daniel Murphy - moving front end to D
 Jacob Carlborg - Objective C support
 Stephan Koch - newCTFE
 Brad Roberts - autotester, bugzilla
 the gdc and ldc teams
 Rainer Schutze - GC work, Visual Studio support
 Martin Nowak - the releases
 Ali Cehreli - book on D
 Adam Ruppe - book on D
 Jan Knepper - the dlang site server

 And a LOT more.

 None of them are doing what I told them to do. I didn't pick any of them.
 They are all self-selected champions. They are what moves D forward.

 Pragmatically speaking, the champions are the ones with the most say,
 because they do the work.

 (Even doing the work doesn't guarantee acceptance, but it improves the
 odds greatly over just posting ideas.)


LOL. IIRC, there have been cases where you and/or Andrei have actually tried
to get folks to do specific stuff, and it generally hasn't worked. Pretty
much everything that gets done around here is because someone steps and does
it.

Regardless, because we're all doing this in our free time, what everyone
does is going to be highly influenced by what they're interested in or what
they need. This does unfortunately tend to result in a number of things not
getting done that really should get done (in addition to the issues with
everyone finding enough time to do what they're trying to do or whether
there are enough people to do what needs doing), but we've gotten a lot of
good stuff done around here, because someone decided to step up and champion
something, and for better or worse, if no one steps up to champion
something, odds are, it doesn't get done.

- Jonathan M Davis
Apr 10 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/10/2017 6:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 LOL. IIRC, there have been cases where you and/or Andrei have actually tried
 to get folks to do specific stuff, and it generally hasn't worked. Pretty
 much everything that gets done around here is because someone steps and does
 it.


It pretty much totally doesn't work, even when the person asks "what can I work
on?"

It's an interesting management problem, one I've never seen covered in 
management books, which never seem to cover volunteer organizations.
Apr 10 2017
parent reply qznc <qznc web.de> writes:
On Tuesday, 11 April 2017 at 02:20:07 UTC, Walter Bright wrote:

 On 4/10/2017 6:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 LOL. IIRC, there have been cases where you and/or Andrei have 
 actually tried
 to get folks to do specific stuff, and it generally hasn't 
 worked. Pretty
 much everything that gets done around here is because someone 
 steps and does
 it.


 It pretty much totally doesn't work, even when the person asks 
 "what can I work on?"

 It's an interesting management problem, one I've never seen 
 covered in management books, which never seem to cover 
 volunteer organizations.


I'd say it is more about politics than management theory. At 
least in the lower ranks of politics. Local affairs are driven by 
volunteer work as well.

It usually comes down to charismatic and visionary leaders. 
Walter and Andrei are good with that, otherwise D would have 
faltered long ago.
Apr 11 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2017 2:18 AM, qznc wrote:

 It usually comes down to charismatic and visionary leaders. Walter and Andrei
 are good with that, otherwise D would have faltered long ago.


For a socially inept nerd such as myself, with all the charisma of a lamppost,
I 
think D has done very well.
Apr 11 2017
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Apr 11, 2017 at 10:24:01AM -0700, Walter Bright via Digitalmars-d wrote:

 On 4/11/2017 2:18 AM, qznc wrote:

 It usually comes down to charismatic and visionary leaders. Walter
 and Andrei are good with that, otherwise D would have faltered long
 ago.


 
 For a socially inept nerd such as myself, with all the charisma of a
 lamppost, I think D has done very well.


You underestimate yourself. While you're no charismatic hero by any
stretch of imagination, you do carry quite some weight in what you say
simply by your history of achievements, as well as your technical
expertise and wealth of experience in computer-related issues. It's no
surprise that in this crowd full of like-minded nerds who respect
technical expertise, you're doing none too badly.  It might be a
completely different story if you were in a more "typical" social
setting, though. :-P


T

-- 
This is a tpyo.
Apr 11 2017
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 11 April 2017 at 19:18:32 UTC, H. S. Teoh wrote:

 On Tue, Apr 11, 2017 at 10:24:01AM -0700, Walter Bright via 
 Digitalmars-d wrote:

 On 4/11/2017 2:18 AM, qznc wrote:

 It usually comes down to charismatic and visionary leaders. 
 Walter and Andrei are good with that, otherwise D would have 
 faltered long ago.


 
 For a socially inept nerd such as myself, with all the 
 charisma of a lamppost, I think D has done very well.


 You underestimate yourself. While you're no charismatic hero by 
 any stretch of imagination, you do carry quite some weight in 
 what you say simply by your history of achievements, as well as 
 your technical expertise and wealth of experience in 
 computer-related issues. It's no surprise that in this crowd 
 full of like-minded nerds who respect technical expertise, 
 you're doing none too badly.  It might be a completely 
 different story if you were in a more "typical" social setting, 
 though. :-P


I was going to say something similar.  I have seen responses in 
reddit/HN threads where devs were in awe that Walter Bright 
responded to them.  In the tech community, which has _completely_ 
different ideas of what constitutes charisma and vision, Walter 
and Andrei, with his distinguished history and very entertaining 
talks, are pretty much the definition.  That is not the issue, D 
has those in spades.

The issues I see are communication and delegation, both of which 
probably come down to the same problem: bus factor 
(https://en.wikipedia.org/wiki/Bus_factor).  I get the sense that 
the communication problems come down to reading and responding to 
a ton of threads, in addition to organizing DConf and doing a 
bunch of other D scut work, so that you don't have time to fully 
context switch for each discussion.

Taking a page from Linus, another charismatic visionary (remember 
we're talking charisma _within tech_ here) who heads the most 
successful open source project of them all, is probably in order 
here: choose people to delegate specific roles to and get that 
stuff off your plate.

Andrei has talked about doing this before, and roles like release 
manager, now manned by Martin Nowak, and DIP manager, Mike 
Parker, have been spun off.  I'm guessing Sociomantic has picked 
up a lot of the DConf management.  But I figure there's more to 
be done.

I suggest that Walter and Andrei get together and figure out what 
else they _shouldn't_ be doing and spin those out as specific 
roles, advertising that they want someone to fill them.  Think of 
it like putting up a job ad: you must figure out what work needs 
to be done, specify detailed job roles to do it, then advertise 
the openings.

I've seen vague calls for help so far, but not anything specific 
like this.  You may not get anyone to fill these new volunteer 
roles, but you're more likely to get someone than with the 
current approach.

Of course, I could be wrong and you've already delegated 
everything that you want, but I get the sense that isn't so.  As 
D scales, getting this delegation right is going to be critical.

On Tuesday, 11 April 2017 at 17:28:51 UTC, Walter Bright wrote:

 On 4/11/2017 4:57 AM, Jacob Carlborg wrote:

 On 2017-04-11 00:07, Walter Bright wrote:


 There are many. A random sampling:

 Jacob Carlborg - Objective C support


 Actually, this one wasn't my idea originally. It was Michel 
 Fortin that started
 this work and did most of it. I just did the necessary work to 
 get it merged
 (the initial version).


 I.e. you self-selected and emerged as the champion of it, and 
 got it done. You're exactly what I'm talking about.

 It's not really about ideas, it's about getting **** done, and 
 the people in the D community that get **** done are inevitably 
 the people who decide what gets done.

 Something could be the bestest idea evar, but without a 
 champion it is going nowhere.


While this is undoubtedly how open source usually works, I'm not 
sure it's exactly right for D.  For example, there was the 
checkedint PR that was submitted to Phobos and then rejected by 
Andrei, only for him to write and merge his own.  You could argue 

least in terms of putting up an implementation, but that wasn't 
enough.  Not saying it was a waste, as it's still up on dub, for 
anyone who prefers it to use.

Your original description of getting things done is mostly 
correct, just didn't like you saying it's not "about ideas," 
because it very clearly is that too.  No doubt you're right that 
the "bestest idea" won't matter if it's not championed by someone 
who will build it, but let's not diminish ideas.
Apr 12 2017
parent reply qznc <qznc web.de> writes:
On Wednesday, 12 April 2017 at 07:51:28 UTC, Joakim wrote:

 On Tuesday, 11 April 2017 at 19:18:32 UTC, H. S. Teoh wrote:

 On Tue, Apr 11, 2017 at 10:24:01AM -0700, Walter Bright via 
 Digitalmars-d wrote:

 On 4/11/2017 2:18 AM, qznc wrote:

 It usually comes down to charismatic and visionary leaders. 
 Walter and Andrei are good with that, otherwise D would 
 have faltered long ago.


 
 For a socially inept nerd such as myself, with all the 
 charisma of a lamppost, I think D has done very well.


 You underestimate yourself. While you're no charismatic hero 
 by any stretch of imagination, you do carry quite some weight 
 in what you say simply by your history of achievements, as 
 well as your technical expertise and wealth of experience in 
 computer-related issues. It's no surprise that in this crowd 
 full of like-minded nerds who respect technical expertise, 
 you're doing none too badly.  It might be a completely 
 different story if you were in a more "typical" social 
 setting, though. :-P


 I was going to say something similar.  I have seen responses in 
 reddit/HN threads where devs were in awe that Walter Bright 
 responded to them.  In the tech community, which has 
 _completely_ different ideas of what constitutes charisma and 
 vision, Walter and Andrei, with his distinguished history and 
 very entertaining talks, are pretty much the definition.  That 
 is not the issue, D has those in spades.


+1

I'm not sure if Walter can claim to have written a complete C++ 
compiler all by himself. Even if not, he is probably the one 
person on this planet, who is closest.

Walter is also pretty good with nerd-sniping [0]. ;)

[0] Example: 
https://forum.dlang.org/post/mg13tc$2ptk$1 digitalmars.com
Apr 12 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2017 6:37 AM, qznc wrote:

 I'm not sure if Walter can claim to have written a complete C++ compiler all by
 himself.


I can and I did - if you consider a complete compiler as source code to object
file.

I've even written part of a linker (BLINK, the Zortech linker, the bulk of
which 
was written by Bjorn Freeman-Benson).
Apr 12 2017
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 11 April 2017 at 19:18:32 UTC, H. S. Teoh wrote:

 On Tue, Apr 11, 2017 at 10:24:01AM -0700, Walter Bright via 
 Digitalmars-d wrote:

 For a socially inept nerd such as myself, with all the 
 charisma of a lamppost, I think D has done very well.


 You underestimate yourself. While you're no charismatic hero by 
 any stretch of imagination, you do carry quite some weight in 
 what you say simply by your history of achievements, as well as 
 your technical expertise and wealth of experience in 
 computer-related issues.


+1

You're way under-estimating your street-cred :)

And the most impressive to me is actually the way Walter answers 
to D users. If you are reading this forum since years you know 
what I mean. I try to emulate some of this with customers.
Apr 13 2017
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 13 April 2017 at 11:31:12 UTC, Guillaume Piolat 
wrote:


 And the most impressive to me is actually the way Walter 
 answers to D users. If you are reading this forum since years 
 you know what I mean. I try to emulate some of this with 
 customers.


That's really true: I sincerely think that he has a real talent 
in that.
Just keep going on that way, Walter: humble and pragmatic!

(BTW, if someone has access to this: 
https://hbr.org/2017/04/if-humble-people-make-the-best-leaders-why-do-we-fall-for-charismatic-narcissists)

:-P

---
Paolo
Apr 13 2017
prev sibling parent xenon325 <anm programmer.net> writes:
On Tuesday, 11 April 2017 at 19:18:32 UTC, H. S. Teoh wrote:

 While you're no charismatic hero by any stretch of imagination, 
 you do carry quite some weight in what you say simply by your 
 history of achievements, as well as your technical expertise 
 and wealth of experience in computer-related issues. It's no 
 surprise that in this crowd full of like-minded nerds who 
 respect technical expertise, you're doing none too badly.  It 
 might be a completely different story if you were in a more 
 "typical" social setting, though. :-P


Yeah, Intel's "Our rock stars are not like your rock stars" ad 
[1] illustrates the idea really well.

[1]: https://youtu.be/zMlWbTqwkdU (30 seconds)

--
Alexander
Apr 13 2017
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-04-11 00:07, Walter Bright wrote:


 There are many. A random sampling:

 Jacob Carlborg - Objective C support


Actually, this one wasn't my idea originally. It was Michel Fortin that 
started this work and did most of it. I just did the necessary work to 
get it merged (the initial version).

-- 
/Jacob Carlborg
Apr 11 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2017 4:57 AM, Jacob Carlborg wrote:

 On 2017-04-11 00:07, Walter Bright wrote:


 There are many. A random sampling:

 Jacob Carlborg - Objective C support


 Actually, this one wasn't my idea originally. It was Michel Fortin that started
 this work and did most of it. I just did the necessary work to get it merged
 (the initial version).


I.e. you self-selected and emerged as the champion of it, and got it done. 
You're exactly what I'm talking about.

It's not really about ideas, it's about getting **** done, and the people in
the 
D community that get **** done are inevitably the people who decide what gets
done.

Something could be the bestest idea evar, but without a champion it is going 
nowhere.
Apr 11 2017
parent bachmeier <no spam.net> writes:
On Tuesday, 11 April 2017 at 17:28:51 UTC, Walter Bright wrote:


 It's not really about ideas, it's about getting **** done, and 
 the people in the D community that get **** done are inevitably 
 the people who decide what gets done.


As I tell students at the start of their dissertation: "You have 
an idea. You are 1% done. Now you have to go do the other 99% for 
it to have value to anyone else."
Apr 11 2017
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 10 April 2017 at 22:07:11 UTC, Walter Bright wrote:

 There are many. A random sampling:


The vast, vast majority of the stuff I do in D though are for 
myself. I used to want to get more into Phobos, but I just don't 
care anymore - I prefer staying as an independent library other 
than trying to include my batteries in std now.
Apr 13 2017
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Monday, 10 April 2017 at 22:07:11 UTC, Walter Bright wrote:

 There are many. A random sampling:

 Daniel Murphy - moving front end to D
 Jacob Carlborg - Objective C support
 Stephan Koch - newCTFE
 Brad Roberts - autotester, bugzilla
 the gdc and ldc teams
 Rainer Schutze - GC work, Visual Studio support
 Martin Nowak - the releases
 Ali Cehreli - book on D
 Adam Ruppe - book on D
 Jan Knepper - the dlang site server


One thing that's noticeable about all of these is that they are 
all changes to the language implementation (e.g. D frontend, 
newCTFE, GC), documentation (the books, the website), tools (the 
other compilers), and distribution; but none of them are 
significant changes to the language _definition_.

The only one that comes close is the Objective C support and 
that's a supplemental feature (albeit a very useful and important 
one) that's about how D interacts with other languages, rather 
than how D itself works.

Even allowing for the fact that changes to the language 
definition should face a high bar (made higher by the general 
wish for non-breaking changes), that suggests that the 
'champion'-based approach may run into difficulties when it comes 
to more fundamental contributions to the D language.
Apr 14 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/14/2017 7:27 AM, Joseph Rushton Wakeling wrote:

 Even allowing for the fact that changes to the language definition should face
a
 high bar (made higher by the general wish for non-breaking changes), that
 suggests that the 'champion'-based approach may run into difficulties when it
 comes to more fundamental contributions to the D language.


Fundamentally changing the language is a major undertaking. The language is 
complicated, there's a lot of baggage, and the reason things are the way they 
are is usually unclear. Having a handwavy post proposing such things is just
not 
good enough.

It's a fact of life that 99% (made up number) of fundamental language change 
proposals are going to fail. What an intractable mess D would be if the daily 
stream of language proposals were implemented. I have more than enough trouble 
with regressions caused by previous language changes.

Nevertheless, if you peruse the PRs, a number of language changes have been
made 
by various champions. There is the way import lookups are done now - a change 
implemented by myself and Martin, but proposed by others. The way Ddoc works
has 
been altered significantly by others, such as having runnable embedded example 
code. Kenji made many subtle changes to how templates work.

I read deadalnix's posts. I pointed out major unaddressed issues, like how does 
it deal with an application using multiple independent methods of allocating
memory.

If you or anyone else want to self-select as the champion for it to make it
more 
complete, that's how things work. I work every day trying to keep D moving - I 
spent yesterday updating the /dmd/samples so they work again, nobody else
wanted 
to do it. I also spent much time yesterday figuring out why Windows DLL support 
broke again. Nobody else was going to do that. I simply cannot turn every idea 
posted here into a detailed proposal.

Keep in mind that other languages, such as C++, will not even look at any 
proposals that are not detailed and complete. And that's just the start of a 
pretty brutal winnowing process. Their position is that if the proponent of a 
change is not willing to put in the work to make a detailed proposal, why
should 
it be worth their time to investigate it? It can't work any other way.
Apr 14 2017
next sibling parent Shachar Shemesh <shachar weka.io> writes:
On 15/04/17 00:09, Walter Bright wrote:


 I read deadalnix's posts. I pointed out major unaddressed issues, like
 how does it deal with an application using multiple independent methods
 of allocating memory.


Do you have a link? I certainly think his direction rings of better 
engineering than the road you are trying to take right now, and I might 
try to pick it up myself.


 Keep in mind that other languages, such as C++, will not even look at
 any proposals that are not detailed and complete.


While nothing there is perfect, I don't agree with that point. Language 
changes are being proposed on the mailing list all the time. Many of 
them are very very very *very* far from being complete, and a discussion 
is what happens next. Very few of those ideas actually make it into 
proposals.

I'm not saying that the C++ way is perfect, or even necessarily better. 
Just that your point of comparison is stating incorrect facts.

Shachar
Apr 14 2017
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Friday, 14 April 2017 at 21:09:23 UTC, Walter Bright wrote:

 Fundamentally changing the language is a major undertaking. The 
 language is complicated, there's a lot of baggage, and the 
 reason things are the way they are is usually unclear. Having a 
 handwavy post proposing such things is just not good enough.

 It's a fact of life that 99% (made up number) of fundamental 
 language change proposals are going to fail. What an 
 intractable mess D would be if the daily stream of language 
 proposals were implemented. I have more than enough trouble 
 with regressions caused by previous language changes.


I'm not disputing that, and I would always defend your right, as 
the person with ultimate responsibility for the language, to have 
the ultimate veto.


 Nevertheless, if you peruse the PRs, a number of language 
 changes have been made by various champions. There is the way 
 import lookups are done now - a change implemented by myself 
 and Martin, but proposed by others. The way Ddoc works has been 
 altered significantly by others, such as having runnable 
 embedded example code. Kenji made many subtle changes to how 
 templates work.


Out of curiosity -- when did these things happen, and what was 
the process people went through?  It could be interesting to 
understand if these contributions were easier because they 
occurred at a time when the language definition was less well 
defined and so it was easier to champion changes.


 I read deadalnix's posts. I pointed out major unaddressed 
 issues, like how does it deal with an application using 
 multiple independent methods of allocating memory.


To be clear -- I don't want to make this about the specifics of 
Deadalnix's proposal.  I chose to use that as an example for 
discussion ... on which I'll follow up in reply to your next 
remarks:


 If you or anyone else want to self-select as the champion for 
 it to make it more complete, that's how things work. I work 
 every day trying to keep D moving - I spent yesterday updating 
 the /dmd/samples so they work again, nobody else wanted to do 
 it. I also spent much time yesterday figuring out why Windows 
 DLL support broke again. Nobody else was going to do that. I 
 simply cannot turn every idea posted here into a detailed 
 proposal.

 Keep in mind that other languages, such as C++, will not even 
 look at any proposals that are not detailed and complete. And 
 that's just the start of a pretty brutal winnowing process. 
 Their position is that if the proponent of a change is not 
 willing to put in the work to make a detailed proposal, why 
 should it be worth their time to investigate it? It can't work 
 any other way.


I agree that, broadly, this is how things need to work, and I'm 
not suggesting that it should be your responsibility to take 
other people's skeleton ideas and flesh them out.  But note that 
C++'s process is possible at least partly because there is such a 
scale of people involved, that probably (i) they _have_ to 
operate this brutally just in order to get the number of 
proposals down to a manageable scale, and (ii) there's always 
going to be another person willing to pick up a good idea, if the 
original proponent drops out.

What I'm suggesting (and I won't repeat myself from my post above 
<https://forum.dlang.org/post/cwoezrgcspdoibmrwkuc forum.dlang.org>) is not
that you load yourself with even more work, but just to consider some specific
short-term measures to try to raise the level of confidence people have in
engaging with process.

I.e. invest in changing people's perceptions of process now, to 
drive much more productive engagement with process in future.
Apr 15 2017
prev sibling parent Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Thursday, 6 April 2017 at 07:24:28 UTC, Nick B wrote:

 But, it seems that while Walter and Andrei are prepared to put 
 a proposal out on the newsgroup, and then discuss it with the 
 community, and then LATER, if its any good,
 state they will formally document it into a DIP.

 For the community, it seems different rules apply. In-depth 
 news-groups discussions for new proposals are firstly 
 encouraged and then later discouraged, with the ultimate
 response that the proposal MUST be in the form of a 
 time-consuming DIP, to be considered, even if it will 
 ultimately wastes everyone time, and cause resentment in the 
 community.


Hi,

I am only familiar with the Lua world from a language design 
point of view - in that world, only the Lua core team decide what 
features can go into the language. In fact they don't even accept 
code contributions - everything is coded by the core team - even 
when they accept an idea.

I don't think a language can be designed by a committee. My 
impression is that Walter is very decent about replying to 
criticisms, even though there is no need in my view for him to do 
so.

I would in fact urge the D team to make it explicit that D 
language design rests solely Walter and Andrei - and while others 
can make suggestions as to what should go in, only Walter and 
Andrei decide what actually goes in.

Regards
Dibyendu
Apr 07 2017