Andrej Mitrovic via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/31/14, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On 12/30/14 7:32 PM, Manu via Digitalmars-d wrote:
>>> void mayEscape(ref int x); // <-- may escape this ref arg
>>> 
>>> void t()
>>> {
>>>    int onStack = 1;
>>>    mayEscape(onStack); // <- perfectly legal, and equally unsafe
>>> }
>> 
>> DIP25 puts this code in illegality. I don't think the proposal has been explicit about that, will fix. Thanks! -- Andrei
> 
> Wait, what? Passing stack variables by ref will be disallowed?

Only to functions that return ref.

On Wednesday, 31 December 2014 at 03:25:24 UTC, Manu via Digitalmars-d wrote:
> His point is similar to my other point elsewhere though. I don't think
> he's talking about 'power' in the sense you describe, what he's really
> talking about is consistency or uniformity. His original scope
> proposal wasn't 'powerful' (even though it was effectively more
> powerful), it was holistic, and without the edges that seem to have
> been introduced to try and 'contain the concept into a smaller space',
> if that makes sense.
>
> In this particular case, I think practical 'complexity' is being
> expressed in the form of awkward edge cases, and the reason that
> happened I suspect, is precisely what Andrei asked me to do; talk
> about the specific problem case, not the general problem that's
> recurring in numerous problem cases.
> I feel like the current proposals are to effectively add yet more
> edges to address specific cases, rather than removing the edges that
> are already present causing the problems in the first place.
> Address the problem, don't add layers of patches to round off rough edges.

This mostly matches my current opinion of DIP25 + DIP69 as well. It is not as much problem of lacking power but utterly breaking KISS principle - too many special cases to remember, too many concepts to learn. Path of minimal necessary change is tempting but it is path to C++.

On Wed, 31 Dec 2014 09:40:17 +0000
Tobias Pankrath via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > another "cosmetic issue" that bugs me alot.
> >
> > p.s. and with pointers it's easy to write something like this:
> >
> >   auto parseNumber (string s, bool* error=null);
> >
> > yes, i know about exceptions... which blocks `@nogc`. not yummy.
> 
> You could preallocate the exception or use an out parameter.

i can do alot of things here... and something is not possible with `ref`. this will not work:

  auto parseNumber (string s, ref bool error=null);

ther is no way to point ref to dummy temp by default, sure, i can write two functions:

  auto parseNumber (string s, out bool error);
  auto parseNumber (string s) { bool dummy; return parseNumber(s, dummy); }

see how it's turning to messy code with copypasta? the thing is that `ref` params can't be ommited by specifying `null` here, and there is no `dummy` placeholder for refs. the same is true for `out`s, of course.

and preallocating exception is loosing valuable information about the place where that exception was thrown. or i have to write a module which emulates `new` for exception objects and don't forget to check if it is "D exception" or "my exception" in `catch` block, so i can manually release my exceptions. ah, i'd better go with my ugly pointers.

On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
> I did want to say something about this. I've given a close read to the "Lost a
> new commercial user this week" thread, through and through. It seems I've
> identified a problem that belongs to us. ("Us" is a vacuous term meaning "the
> leaders of the D community").
>
> My initial read of your complaint went like this: it's about Windows (I don't
> even have an installation), it's about vibe.d (haven't used it yet), and it's
> also discussing documentation (which is something we can indeed improve and I
> know how to). So a large part of the problem wasn't even mine to work on.
>
> Others harbored similar perceptions. The corollary has been that essentially
> you're asking them to stop working on D aspects they do care about and start
> working on D aspects you and others care about - all on their free time.

A few thoughts on this.  (This turned a bit longer than expected in the writing, so I've highlighted some TL;DR sections to highlight key ideas.)

I think that one of the most common sources of community friction in open source is people mistaking being _asked_ to work on something that someone else cares about, for being _expected_ to do so.

That's very unfortunate, because it means that all too often people will come into a community, full of enthusiasm for this new thing they've discovered, make some suggestions, and get shot down like they're some sort of plague carrier. (The D community is pretty good at not doing this with newcomers, but deals less well with people repeatedly raising ideas; more on that in a moment.)

Obviously, there are people who display an enormous sense of entitlement, who are rude or just throw demands around in a very arrogant way.  But simply saying, "I want this", "I need this", or "I think this would be a good idea" should not IMO be a trigger for criticism or hostility.  Most of the time, people do understand the fundamental constraints of a volunteer community with limited resources, and what they are interested in having is either acknowledgement of a good idea or use-case (preferably with something getting onto a TODO list, but not necessarily with any priority), or feedback that helps them understand alternative ways to solve their problem.  (Caveat: it matters whether the problem is actually solved, or just worked around.)

----------------------------------------------------------------------------
TL;DR: I think it would be good to have a strong community guideline that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves.  The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: "You can ask but not demand".
----------------------------------------------------------------------------

The other observation is that, often, what frustrates core contributors about people coming in with ideas and requests and so on, is that responding to that takes time and effort and often distracts from limited time available to deliver actual work.  It can be very, very wearing having to explain to people time and time again why something is a certain way, or to have to make the case yet again why X is not considered a priority, or whatever.

Now, in some cases, these problems are self-inflicted.  I've encountered core contributors in some communities who simply _could not let go_ of the need to prove someone else wrong, or to explain to the n'th degree why something was not possible.  (This interacts very badly with me, because I find it very difficult to let go of a discussion where I feel that I've been misunderstood:-)  In other cases I've seen core contributors regularly engage in rudeness or sometimes even virulent personal attacks, and then bemoan how demotivating it is having to deal with belligerent arguments on the mailing lists.  Thankfully the D community sees very little of this.

More often, it's simply a result of the discrepancy between numbers of contributors and numbers of (verbally active) users -- and it only gets compounded by the feeling that, if people spent half the time contributing that they spent arguing, far more things would get done and the core contributors would have a much easier time of it.

IMHO there are two important things to address here.  One is to give a lot of priority to entry blockers -- to the things that prevent people from becoming users or contributors.  Difficult installation experiences, obscure dependencies, weird or out-of-date tools etc. are all things that are boring but important to address because the work to solve them can pay off massively in terms of how many people are willing to get involved.  (D's move to GitHub is a great example.)

Obviously volunteer contributors can't be obliged to accept these priorities, but it should be possible to highlight and stress them as key things for the project, as well as maybe engaging in some outreach to try and invite people outside the current community to consider contributing their expertise.  There could also be special rewards for people who deliver particularly important goals (I'm thinking of things like signed copies of TDPL with personalized thank-you notes; personally I reckon such things may be more precious than a financial bounty:-).

----------------------------------------------------------------------------
TL;DR: When setting project priorities, put a real stress on entry problems, and consider outreach if the existing community doesn't seem able or willing to engage with something important.  And be creative with the rewards for good stuff :-)
----------------------------------------------------------------------------

The other is to embrace the fact that past a certain scale, there are always going to be lots of people who are keen to take place in community discussion (because hey, it's FUN:-) but who for whatever reason are not going to contribute code or documentation.  The opportunity here is to ensure that key knowledge is spread among these people, that they have good understanding of the what/where/why of the state of development, so that they are in a position to bear the brunt of the explanation and conversation duties; ideally, they would (simply by doing what they enjoy naturally) take away a lot of the need for core contributors to engage in day-to-day forum conversation.

In other words, you try and scale things so that core contributors primarily talk with and guide regular forum participants, and they talk with other people, and get recognition for the value of what they're doing (any easy reward might be, for example, the right to have an @dlang.org email address).  Note that it doesn't need to be some sort of official role; there must be plenty of people who might balk at the idea of community commitments or duties, who will nevertheless do this well if simply engaged with.

----------------------------------------------------------------------------
TL;DR: Enable enthusiastic forum participants to be the front line of communication, to take the heat off the core devs.
----------------------------------------------------------------------------

> Then I figured we must take ownership of D issues. Your initial post was pure
> and simple user feedback - a knowledgeable and well-informed and well-meaning
> user but nevertheless a user who is not quite willing to roll sleeves up and
> proceed with adding work. If we consider ourselves a free-wheeling grassroots
> tribe, best we can do invite you to do the work and review and merge it in (or
> snicker at you if you're not up for it). If, on the other hand, we want to be a
> real organization, we must take the feedback and own it.

Even allowing for the difference between grassroots vs. organized projects, I personally think it's one of the most counter-productive sides of open source culture, that it's considered OK to snicker at people who don't want to get their hands dirty.  There are lots of reasons people can't or won't contribute at any given moment; it surely suffices to politely point out the limitations of non-involvement, and deal firmly with the handful of nasty people who get abusive when that happens.

I'm really happy to see your resolve on the need to find ways to "take ownership" of user issues.  It's been one of my regular sadnesses, seeing various people (Manu and others) be very committed in providing feedback and use-case scenarios, and not getting the engagement that their insight deserves.

> A simple simile: say you mention to the manager of a grocery store that they
> should have more organic fruit, and mention anecdotes of potential customers
> shunning the store because it doesn't. If the store is a cooperative of folks
> selling stuff they grow on their own, the manager might invite you to join in
> with your produce. If, on the other hand, the store is an established
> supermarket, they'd do good to take your suggestion seriously.

Yes, but :-)  A smart cooperative will still take on board the feedback and consider if it might be worthwhile doing something themselves, even if it's not directly in line with their personal interests.  In terms of how D can do things better, that might include trying to find better ways of documenting user feedback and trying to better highlight worthwhile projects.  That might be possible to organize independent of your next suggestion.

> We're in the "cooperative" stage of D, and we need to move toward the
> "established organization" stage. We should start transitioning to that next
> year; part of it is I plan to look seriously at the non-profit organization angle.

That's really great to hear; I don't want to say anything to anticipate or prejudge what you have in mind, but I am looking forward to further elaboration of this idea.

On 1/1/15 10:45 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
>> I did want to say something about this. I've given a close read to the
>> "Lost a
>> new commercial user this week" thread, through and through. It seems I've
>> identified a problem that belongs to us. ("Us" is a vacuous term
>> meaning "the
>> leaders of the D community").
>>
>> My initial read of your complaint went like this: it's about Windows
>> (I don't
>> even have an installation), it's about vibe.d (haven't used it yet),
>> and it's
>> also discussing documentation (which is something we can indeed
>> improve and I
>> know how to). So a large part of the problem wasn't even mine to work on.
>>
>> Others harbored similar perceptions. The corollary has been that
>> essentially
>> you're asking them to stop working on D aspects they do care about and
>> start
>> working on D aspects you and others care about - all on their free time.
>
> A few thoughts on this.  (This turned a bit longer than expected in the
> writing, so I've highlighted some TL;DR sections to highlight key ideas.)
[snip]

Good stuff, thanks. Question about this:

> TL;DR: I think it would be good to have a strong community guideline
> that people are not to be criticized or treated badly for having
> requests or suggestions, even if they are not willing to implement
> them themselves.  The quid pro quo is that it's necessary to be
> (calmly) candid with people about the limits of _only_ contributing
> ideas or requests: "You can ask but not demand".

What would be an appropriate place to put this?


Andrei

>> TL;DR: I think it would be good to have a strong community guideline
>> that people are not to be criticized or treated badly for having
>> requests or suggestions, even if they are not willing to implement
>> them themselves.  The quid pro quo is that it's necessary to be
>> (calmly) candid with people about the limits of _only_ contributing
>> ideas or requests: "You can ask but not demand".
>
> What would be an appropriate place to put this?
>
>
> Andrei

Any kind of main place, for example first page of dlang.org, but not alone.
I have suggestion in my mind for a month at least:
For D's community is good to formulate something like principles or axiomata. (Because as I see, many discussion goes round and round about similar things).

One of those principle may sound like this for example:

__D is safe by default and fast when need.__

(This about general design of D, for example about garbage collection). Main page has something like this but in descriptive not rule-provided form. After formulating such maxima many discussion calming itself, because part of ideas will follow global goals and another contradict.

In my view such principles have to cover following aspects: design of D (about safety, speed, multiparadigmality, glitchness, smoothness  and so on), evolution of D (in such cases breaking change is allowed and about deepness of breakage, phobos and its topics coverage and so on)  and community cooperation (yes, it is suggested by Joseph Rushton Wakeling community guidline).

IMO discussion about such axiomata (when comunity interesting in) need own topic.

On Fri, Jan 2, 2015 at 7:26 AM, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 1/1/15 10:45 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>
>> On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
>>
>>> I did want to say something about this. I've given a close read to the
>>> "Lost a
>>> new commercial user this week" thread, through and through. It seems I've
>>> identified a problem that belongs to us. ("Us" is a vacuous term
>>> meaning "the
>>> leaders of the D community").
>>>
>>> My initial read of your complaint went like this: it's about Windows
>>> (I don't
>>> even have an installation), it's about vibe.d (haven't used it yet),
>>> and it's
>>> also discussing documentation (which is something we can indeed
>>> improve and I
>>> know how to). So a large part of the problem wasn't even mine to work on.
>>>
>>> Others harbored similar perceptions. The corollary has been that
>>> essentially
>>> you're asking them to stop working on D aspects they do care about and
>>> start
>>> working on D aspects you and others care about - all on their free time.
>>>
>>
>> A few thoughts on this.  (This turned a bit longer than expected in the writing, so I've highlighted some TL;DR sections to highlight key ideas.)
>>
> [snip]
>
> Good stuff, thanks. Question about this:
>
>  TL;DR: I think it would be good to have a strong community guideline
>> that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves.  The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: "You can ask but not demand".
>>
>
> What would be an appropriate place to put this?
>

We could post an FAQ or something FAQ-like every month or so, including things like "can I ask for things I want?" or "what should I post to each forum?".

LMB

On 12/31/2014 3:23 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> So... how does this apply to our problem concretely? Do you believe a full blown
> ownership/lifetime system is "the wrong kind of power"? Remember, we're talking
> about an ideal world at first. If after thorough discussion it turns out that it
> can't be integrated into D, at least we know that it's probably not possible.
> But I haven't seen any indications that this is the case; in fact, it's not even
> been discussed.

I don't believe it is impossible to implement in D, in fact, Bartosz Milewski proposed such a system some years back. I do believe that people will simply reject such a system as too hard to use.

(The reason dynamically typed languages are enduringly popular is that it is easier to write code in them. People are inherently lazy. A full blown lifetime/ownership system laid over a static type system would be an increase in programmer effort comparable to the gap between a dynamic and static type system. I don't believe programmers will go for it.)


>> Also, programmers do not really want a complex annotation system. They want to
>> just write code in the most obvious manner and have it work correctly. Having
>> a powerful (but complex) system is not very attractive.
>
> But a powerful system doesn't need to be complicated. In fact, a system with a
> handful of general and orthogonal features is likely easier to understand and
> handle in practice than one with lots of (even trivial) edge cases and exceptions.

I agree that we all want that, but designing one that delivers such is another matter entirely.

Programmers discover repeatedly that what is general, simple, and orthogonal for computers is grossly unintuitive and non-obvious for people. Successful user interfaces are a mass of code implementing a mass of special cases.

Computer languages are user interfaces.

For a topical example, check out the threads here on the Ddoc syntax. Many have strongly argued against the simple, general, powerful and orthogonal macro syntax in favor of an idiosyncratic mass of special cases. It's classic.

On 02/01/15 10:26, Andrei Alexandrescu via Digitalmars-d wrote:
> Good stuff, thanks. Question about this:

I'm glad it seems useful; I wondered after writing if it was a bit too much of a rambling mess :-P

>> TL;DR: I think it would be good to have a strong community guideline
>> that people are not to be criticized or treated badly for having
>> requests or suggestions, even if they are not willing to implement
>> them themselves.  The quid pro quo is that it's necessary to be
>> (calmly) candid with people about the limits of _only_ contributing
>> ideas or requests: "You can ask but not demand".
>
> What would be an appropriate place to put this?

How about a link at the top of the forum.dlang.org page saying something like, "Before posting, please read our _community guidelines_" ?  With the page linked to containing advice like the above.

I know that there's always been a lot of pride that we've always been able to get along without some kind of code of conduct, but ... well, guidelines are not the same as a code, and anyway, not having guidance just doesn't scale in my experience.

On 1/2/15, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> (The reason dynamically typed languages are enduringly popular is that it is easier to write code in them. People are inherently lazy.)

Considering how much time one has to spend scratching their head what type of a variable something is in Python, I think the *true slackers* prefer statically typed languages. One hit of the compile button and if it works you're 99% done already. :)