On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu wrote:
> On 10/6/14, 5:42 AM, Wyatt wrote:
>> On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
>>>
>>> No need to explain it here. When I speak about vision I mean something
>>> that anyone coming to dlang.org page or GitHub repo sees. Something
>>> that is explained in a bit more details, possibly with code examples.
>>> I know I am asking much but seeing quick reference for "imagine this
>>> stuff is implemented, this is how your program code will be affected
>>> and this is why it is a good thing" could have been huge deal.
>>
>>> Right now your rationales get lost in forum discussion threads
>>
>> Jerry Christmas, this right here!  Andrei, I know you keep chanting "C++
>> and GC", and that's cool and all, but its also kind of meaningless
>> because we can't read minds.
>
> I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei

Answer:

On Friday, 26 September 2014 at 10:22:50 UTC, Joakim wrote:
> It needs to be a page on the wiki or the main site, which you or any user can link to anytime people want to know the plan.
>
> some sort of public plan of where you want the language to go.  All I'm asking for is a public list of preapproved and maybe rejected features that the two of you maintain.  Dfix might be on the preapproved list, ARC might be on the rejected. ;) You could also outline broad priorities like C++ support or GC improvement on such a webpage.

You and Walter do a good job of answering questions on Reddit and there's certainly a lot of discussion on the forum where the two of you chip in, but what's missing is a high-level overview of the co-BDFLs' priorities for where the language is going, including a list of features you'd like to see added, ie that are pre-approved (that doesn't mean _any_ implementation would be approved, only that feature in principle).

Most users or wannabe contributors aren't going to go deep-diving through the forums for such direction.  Manu and others recently wrote that the traffic on the forum has gone up, making it tougher for them to keep up.  It would help if the two co-BFDLs did a better job articulating and communicating their vision in a public place, like a page on the wiki or dlang.org website, rather than buried in the haystack of the forums or reddit.

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:

> What do you think are the worst parts of D?

The fact that its community, when faced with the question "What do you think are the worst parts of D?", will readily have a 35 page verbal fistfight over what the worst parts of D are.

Don't get me wrong, I'm happy that discussion is happening about such things, but I think it may be better to have it in a more structured manner in the future, and with a little less emotional investment.

That being said, the second worst part of D for me is the current state of documentation, which is something that is often mentioned. I'd be happy to take part in a "docs initiative" where some of us sit together and talk about how we can improve the documentation of the language, collect input from outside, and then implement the changes that are found to be necessary. This would make it easier for people who don't wish to set up the entire build environment for the documentation on their side to participate in documentation adjustments by giving feedback, while a somewhat dedicated group of people then focus on making decisions reality.

On Monday, 6 October 2014 at 15:13:59 UTC, Nicolas F. wrote:
> On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
>
>> What do you think are the worst parts of D?
>
> The fact that its community, when faced with the question "What do you think are the worst parts of D?", will readily have a 35 page verbal fistfight over what the worst parts of D are.
>
> Don't get me wrong, I'm happy that discussion is happening about such things, but I think it may be better to have it in a more structured manner in the future, and with a little less emotional investment.

Heh, I think such self-criticism by the community is great, for example, I loved that I recently stumbled across this page on the wiki:

http://wiki.dlang.org/Language_issues

How many other languages can boast such a page of problems on their own wiki? :) Thanks to Vlad and Mike for writing it.

People in this thread are emotional because they care: I don't think it's gone overboard given the real concerns they're stating.  When the D community starts hiding its problems and stops critiquing its own efforts, sometimes passionately if that's what you truly feel, is when it starts going downhill.

On Mon, 06 Oct 2014 15:22:17 +0000
Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> People in this thread are emotional because they care
yes. i don't think that anybody (including me ;-) wants to
directly insult someone here. D is good, that's why "not-so-good"
features are so annoying that we are writing such emotional postings.

On 10/6/14, 8:08 AM, Joakim wrote:
> You and Walter do a good job of answering questions on Reddit and
> there's certainly a lot of discussion on the forum where the two of you
> chip in, but what's missing is a high-level overview of the co-BDFLs'
> priorities for where the language is going, including a list of features
> you'd like to see added, ie that are pre-approved (that doesn't mean
> _any_ implementation would be approved, only that feature in principle).

Aye, something like that might be helpful. I'll keep it in mind.

> Most users or wannabe contributors aren't going to go deep-diving
> through the forums for such direction.

I'm not so sure that's a problem. It takes some connection to the language milieu before making a major contribution of the kind to be on a "vision" list. And once that connection is present, it's rather clear what the issues are. That's the case for any language.

> Manu and others recently wrote
> that the traffic on the forum has gone up, making it tougher for them to
> keep up.

Yah, there's been some growing pains. Traffic is on the rise and unfortunately the signal to noise ratio isn't.

Converting the existing passion and sentiment into workable items is a present challenge I'm thinking of ways to approach.

> It would help if the two co-BFDLs did a better job
> articulating and communicating their vision in a public place, like a
> page on the wiki or dlang.org website, rather than buried in the
> haystack of the forums or reddit.

That's sensible.


Andrei

On 10/6/14, 8:35 AM, ketmar via Digitalmars-d wrote:
> On Mon, 06 Oct 2014 15:22:17 +0000
> Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> People in this thread are emotional because they care
> yes. i don't think that anybody (including me ;-) wants to
> directly insult someone here.

I appeal to you and others to keep language and attitude in check. We all are well intended here, all we need to do is convert heat into work, which should be possible per the first and second principle of thermodynamics. All we need is some cooling :o).

Andrei

On Mon, 06 Oct 2014 08:39:54 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> I appeal to you and others to keep language and attitude in check.
i'm doing my best, rewriting my posts at least three times before sending. i bet noone wants to read the first variants. ;-)

but this thread is a good place to show some emotions. i believe that we need such "emotional ranting" threads, so people can scream here and then calm down. sure it's very flammable; we must keep fire extinguishers at hand. ;-)

On 10/5/14, 9:14 AM, Dicebot wrote:
> On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu wrote:
>> 1. C++ support is good for attracting companies featuring large C++
>> codebases to get into D for new code without disruptions.
>>
>> 2. Auto-decoding is blown out of proportion and a distraction at this
>> time.
>>
>> 3. Ref counting is necessary again for encouraging adoption. We've
>> framed GC as an user education matter for years. We might have even
>> been right for the most part, but it doesn't matter. Fact is that a
>> large potential user base will simply not consider a GC language.
>
> No need to explain it here. When I speak about vision I mean something
> that anyone coming to dlang.org page or GitHub repo sees. Something that
> is explained in a bit more details, possibly with code examples. I know
> I am asking much but seeing quick reference for "imagine this stuff is
> implemented, this is how your program code will be affected and this is
> why it is a good thing" could have been huge deal.

I'm confused. Why would anyone who just comes to dlang.org see unformed ideas and incomplete designs? Wouldn't newcomers be more attracted by e.g. stuff coming in the next release?

> Right now your rationales get lost in forum discussion threads and it is
> hard to understand what really is Next Big Thing and what is just forum
> argument blown out of proportion. There was a go at properties, at
> eliminating destructors, at rvalue references and whatever else I have
> forgotten by now. It all pretty much ended with "do nothing" outcome for
> one reason or the other.

Let's see. We have properties, which indeed need some work done but don't seem to prevent people from getting work done. The discussion on eliminating destructors concluded with "we don't want to do that for good reasons". For binding rvalues Walter has a tentative design that's due for an RFC soon.

> The fact that you don't seem to have a consensus with Walter on some
> topic (auto-decoding, yeah) doesn't help either. Language marketing is
> not about posting links on reddit, it is a very hard work of
> communicating your vision so that it is clear even to random by-passer.

I think one good thing we can do is approach things in private before discussing them publicly.

>>> 2) reliable release base
>>>
>>> I think this is most important part of open-source infrastructure needed
>>> to attract more contributions and something that also belongs to the
>>> "core team". I understand why Walter was so eager to delegate is but
>>> right now the truth is that once Andrew has to temporarily leave all
>>> release process has immediately stalled. And finding replacement is not
>>> easy - this task is inherently ungrateful as it implies spending time
>>> and resources on stuff you personally don't need at all.
>>
>> We now have Martin Nowak as the point of contact.
>
> And what if he gets busy too? :)

Maybe you'll volunteer.

>>> 3) lack of field testing
>>>
>>> Too many new features get added simply because they look theoretically
>>> sound.
>>
>> What would those be?
>
> Consider something like `inout`. It is a very look feature to address an
> issue specific to D and it looked perfectly reasonable when it was
> introduces. And right now there are some fishy hacks about it even in
> Phobos (like forced inout delegates in traits) that did come from
> originally unexpected usage cases. It is quite likely that re-designing
> it from scratch based on existing field experience would have yielded
> better results.

No doubt its design could be done better. But inout was not motivated theoretically. It came from the practical need of not duplicating code over qualifiers.

>> Policy-based design is more than one decade old, and older under other
>> guises. Reference counting is many decades old. Both have been
>> humongous success stories for C++.
>
> Probably I have missed the point where new proposal was added but
> original one was not using true policy-based design but set of enum
> flags instead (no way to use user-defined policy).

Sean proposed that. In fact that's a very good success story of sharing stuff for discussion sooner rather than later: he answered a Request For Comments with a great comment.

> Reference counting
> experience I am aware of shows that it is both successful in some cases
> and unapplicable for the others. But I don't know of any field
> experience that shows that chosing between RC and GC as a policy is a
> good/sufficient tool to minimize garbage creation in libraries - real
> issue we need to solve that original proposal does not mention at all.

That's totally fine. A good design can always add a few innovation on top of known territory. In fact we've done some experimenting at Facebook with fully collected PHP (currently it's reference counted). RC is well understood as an alternative/complement of tracing. Anyhow, discussion is what the Request For Comments is good for. But please let's focus on actionable stuff. I can't act on vague doubts.

>> No need to trust me or anyone, but at some point decisions will be
>> made. Most decisions don't make everybody happy. To influence them it
>> suffices to argue your case properly. I hope you don't have the
>> feeling appeal to authority is used to counter real arguments. I _do_
>> trust my authority over someone else's, especially when I'm on hook
>> for the decision made. I won't ever say "this is a disaster, but we
>> did it because a guy on the forum said it'll work".
>
> I don't want to waste your time arguing about irrelevant things simply
> because I have misinterprete how proposed solution fits the big picture.
> It is still unclear why proposed scheme is incompatible
> with tweaking Phobos utilities into input/output ranges. I am stipid and
> I am asking for detailed explanations before any arguments can be made
> :) And not just explanations for me but stuff anyone interested can find
> quickly.

Again: I don't have a complete design, that's why I'm asking for comments in the Request For Comments threads. Would you rather have me come up alone with a complete design and then show it to the community as a fait accompli? What part of "let's do this together" I need to clarify?

>>> This is closely related to SemVer topic. I'd love to see D3. And D4 soon
>>> after. And probably new prime version increase every year or two. This
>>> allows to tinker with really big changes without being concerned about
>>> how it will affect your code in next release.
>>
>> Sorry, I'm not on board with this. I believe it does nothing than
>> balkanize the community, and there's plenty of evidence from other
>> languages (Perl, Python). Microsoft could afford to do it with C# only
>> because they have lock-in with their user base, monopoly on tooling,
>> and a simple transition story ("give us more money").
>
> You risk balkanization by keeping the things as they are. We do have
> talks at work sometimes that simply forking the language may be a more
> practical approach than pushing necessary breaking changes upstream by
> the time D2 port is complete. Those are just talks of course and until
> porting is done it is all just speculations but it does indicate certain
> level of unhappinness.

It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward.

>>> Don has been mentioning that Sociomantic is all for breaking the code
>>> for the greater good and I fully agree with him. But introducing such
>>> surprise solutions creates a huge risk of either sticking with imperfect
>>> design and patching it (what we have now) or changing same stuff back
>>> and forth every basic release (and _that_ is bad).
>>
>> I don't see what is surprising about my vision. It's simple and clear.
>> C++ and GC. C++ and GC.
>
> It came as surpise. It is unclear how long will it stay. It is unclear
> what exactly is the goal.
>
> Have you ever considered starting a blog about your vision of D
> development to communicate it better to wider audience? :)

Yah, apparently there's no shortage of ideas of things I should work on. Perhaps I should do the same. Dicebot, I think you should work on making exceptions refcounted :o).


Andrei

On Monday, 6 October 2014 at 13:42:35 UTC, Andrei Alexandrescu wrote:
> On 10/5/14, 11:23 PM, eles wrote:
>> On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote:
>>> On 10/5/14, 3:08 PM, eles wrote:
>>>> On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

> It doesn't because they need to be allocated dynamically. That's why there's a need for the likes of unique_ptr and shared_ptr in C++.

Yes, or that delete. And AFAIS not only C++ needs unique_ptr and shared_ptr, this ARC thing is the same in D.


> The intermediate type between struct and class is struct.

D with classes, anyone?

On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote:
> On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
>> On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

> I did comment in this group. -- Andrei

==========================================
IgorStepanov  commented 17 days ago

Ping

===========================================
quickfur  commented 14 days ago

Wow. I have been waiting for this feature for a long time! Can't wait to see this merged. Ping @WalterBright ?
==========================================

IgorStepanov  commented 13 days ago

@andralex Ping. Please comment the tests and conflict resolving semantic.

===========================================

IgorStepanov  commented 8 days ago

@andralex ping

==========================================