I am in the mood to complain today so this feels like a good moment to post a bit more extended reply here.

There are three big issues that harm D development most in my opinion:

1) lack of "vision"

TDPL was an absolutely awesome book because it expained "why?" as opposed to "how?". Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out.

Right now I have no idea where the development is headed and what to expect from next few releases. I am not speaking about wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++ support, thread about killing auto-decoding, recent ref counting proposal - all this stuff comes from language authors but does not feel like a strategic additions. It feels like yet another random contribution, no different from contribution/idea of any other D user.

Anarchy-driven development is pretty cool thing in general but only if there is a base, a long-term vision all other contributions are built upon. And I think it is primary responsibility of language authors to define such as clear as possible. It is very difficult task but it simply can't be delegated.

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.

Same applies to versioning - it got considerably better with introduction of minor version but it is still far from reasonable SemVer and cherry-picking approach still feels like madness.

And current situation where dissapearance of one person has completely blocked and releases simply tells everyone "D is still terribly immature".

3) lack of field testing

Too many new features get added simply because they look theoretically sound. I think it is quite telling that most robust parts of D are the ones that got designed based on mistake experience of other languages (primarily C++) and most innovations tend to fall into collection of hacks stockpiled together (something same C++ is infamous for).

I am disturbed when Andrei comes with proposal that possibly affects whole damn Phobos (memeory management flags) and asks to trust his experience and authority on topic while rejecting patterns that are confirmed to be working well in real production projects. Don't get me wrong, I don't doubt Andrei authority on memory management topic (it is miles ahead of mine at the very least) but I simply don't believe any living person in this world can design such big change from scratch without some extended feedback from real deployed projects.

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.

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).

On 10/5/14, 7:55 AM, Dicebot wrote:
> 1) lack of "vision"

The vision is to expand user base and make a compelling case for using D alongside existing code bases. There are two important aspects to that: interoperability with C++, and using D without a garbage collector.

> Right now I have no idea where the development is headed and what to
> expect from next few releases. I am not speaking about
> wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++
> support, thread about killing auto-decoding, recent ref counting
> proposal - all this stuff comes from language authors but does not feel
> like a strategic additions.

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.

> It feels like yet another random
> contribution, no different from contribution/idea of any other D user.
>
> Anarchy-driven development is pretty cool thing in general but only if
> there is a base, a long-term vision all other contributions are built
> upon. And I think it is primary responsibility of language authors to
> define such as clear as possible. It is very difficult task but it
> simply can't be delegated.

I'm all about vision. I do agree we've been less so in the past.

> 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.

> 3) lack of field testing
>
> Too many new features get added simply because they look theoretically
> sound.

What would those be?

> I think it is quite telling that most robust parts of D are the
> ones that got designed based on mistake experience of other languages
> (primarily C++) and most innovations tend to fall into collection of
> hacks stockpiled together (something same C++ is infamous for).
>
> I am disturbed when Andrei comes with proposal that possibly affects
> whole damn Phobos (memeory management flags) and asks to trust his
> experience and authority on topic while rejecting patterns that are
> confirmed to be working well in real production projects.

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++.

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".

> Don't get me
> wrong, I don't doubt Andrei authority on memory management topic (it is
> miles ahead of mine at the very least) but I simply don't believe any
> living person in this world can design such big change from scratch
> without some extended feedback from real deployed projects.

Feedback is great, thanks. But we can't test everything before actually doing anything. I know how PBD works and I know how RC works, both from having hacked with them for years. I know where this will go, and it's somewhere good.

> 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").

> 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.


Andrei

On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu wrote:
> On 10/5/14, 7:55 AM, Dicebot wrote:
>> 1) lack of "vision"
>
> The vision is to expand user base and make a compelling case for using D alongside existing code bases. There are two important aspects to that: interoperability with C++, and using D without a garbage collector.
>
>> Right now I have no idea where the development is headed and what to
>> expect from next few releases. I am not speaking about
>> wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++
>> support, thread about killing auto-decoding, recent ref counting
>> proposal - all this stuff comes from language authors but does not feel
>> like a strategic additions.
>
> 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.

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.

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.

>> 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? :)

>> 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.

> 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). 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.

> 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.

>> 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.

>> 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? :)

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.

Something like this would be nice:

http://golang.org/s/go14gc

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

> Right now I have no idea where the development is headed and what to expect from next few releases. I am not speaking about wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++ support, thread about killing auto-decoding, recent ref counting proposal

Just to add more salt:

http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx

Raymond Chen: " When you ask somebody what garbage collection is, the answer you get is probably going to be something along the lines of "Garbage collection is when the operating environment automatically reclaims memory that is no longer being used by the program. It does this by tracing memory starting from roots to identify which objects are accessible."

This description confuses the mechanism with the goal. It's like saying the job of a firefighter is "driving a red truck and spraying water." That's a description of what a firefighter does, but it misses the point of the job (namely, putting out fires and, more generally, fire safety).

Garbage collection is simulating a computer with an infinite amount of memory. The rest is mechanism. And naturally, the mechanism is "reclaiming memory that the program wouldn't notice went missing." It's one giant application of the as-if rule."

Interesting, in the comments, the distinction that is made between finalizers and destructors, even if they happen to have the same syntax, for example in C# and C++.

For example here: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx#10047776

I feel difficult to swallow the fact that D classes do not lend themselves to RAII. While I could accept the memory management could be left outside RAII, running destructors (or disposers) deterministically is a must.

I particularily find bad that D recommends using structs to free resources because the destructor of those is run automatically. Just look at this example:

http://dlang.org/cpptod.html#raii

struct File
{
    Handle h;

    ~this()
    {
        h.release();
    }
}

void test()
{
    if (...)
    {
        auto f = File();
        ...
    } // f.~this() gets run at closing brace, even if
      // scope was exited via a thrown exception
}

Even if C++ structs are almost the same as classes, the logical solit between the two is: structs are DATA, classes are BEHAVIOR. I will not get my head around the fact that I will *recommend* putting methods in a struct.

On Sunday, 5 October 2014 at 21:59:21 UTC, Ola Fosheim Grøstad 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.
>
> Something like this would be nice:
>
> http://golang.org/s/go14gc

(sorry, replying to this answer because is shorter)

Would a strategy where pointers are by default unique, and only become shared, weak and naked if explicitely declared as such?

On Sunday, 5 October 2014 at 22:11:38 UTC, eles wrote:
> On Sunday, 5 October 2014 at 21:59:21 UTC, Ola Fosheim Grøstad 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.
>>
>> Something like this would be nice:
>>
>> http://golang.org/s/go14gc
>
> (sorry, replying to this answer because is shorter)
>
> Would a strategy where pointers are by default unique, and only become shared, weak and naked if explicitely declared as such?

of course, would it be viable?

On 10/5/14, 3:08 PM, eles wrote:
> On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
>
>> Right now I have no idea where the development is headed and what to
>> expect from next few releases. I am not speaking about
>> wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on
>> C++ support, thread about killing auto-decoding, recent ref counting
>> proposal
>
> Just to add more salt:
>
> http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx
>
> Raymond Chen: " When you ask somebody what garbage collection is, the
> answer you get is probably going to be something along the lines of
> "Garbage collection is when the operating environment automatically
> reclaims memory that is no longer being used by the program. It does
> this by tracing memory starting from roots to identify which objects are
> accessible."
>
> This description confuses the mechanism with the goal. It's like saying
> the job of a firefighter is "driving a red truck and spraying water."
> That's a description of what a firefighter does, but it misses the point
> of the job (namely, putting out fires and, more generally, fire safety).
>
> Garbage collection is simulating a computer with an infinite amount of
> memory. The rest is mechanism. And naturally, the mechanism is
> "reclaiming memory that the program wouldn't notice went missing." It's
> one giant application of the as-if rule."
>
> Interesting, in the comments, the distinction that is made between
> finalizers and destructors, even if they happen to have the same syntax,
> for example in C# and C++.
>
> For example here:
> http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx#10047776
>
>
> I feel difficult to swallow the fact that D classes do not lend
> themselves to RAII. While I could accept the memory management could be
> left outside RAII, running destructors (or disposers) deterministically
> is a must.
>
> I particularily find bad that D recommends using structs to free
> resources because the destructor of those is run automatically. Just
> look at this example:
>
> http://dlang.org/cpptod.html#raii
>
> struct File
> {
>      Handle h;
>
>      ~this()
>      {
>          h.release();
>      }
> }
>
> void test()
> {
>      if (...)
>      {
>          auto f = File();
>          ...
>      } // f.~this() gets run at closing brace, even if
>        // scope was exited via a thrown exception
> }
>
> Even if C++ structs are almost the same as classes, the logical solit
> between the two is: structs are DATA, classes are BEHAVIOR. I will not
> get my head around the fact that I will *recommend* putting methods in a
> struct.

The main distinction between structs and classes in D is the former are monomorphic value types and the later are polymorphic reference types. -- Andrei

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:

> The main distinction between structs and classes in D is the former are monomorphic value types and the later are polymorphic reference types. -- Andrei

Why hack them with scoped? The need exists, since you provide a hack for it.

Reference classes in C++ are polymorphic & reference, but their destructor/disposer gets called.

There is a delete that triggers that or a smart pointer. I don't care if the delete or the destructor really frees the memory, but I would like it to get called, to release other resources that the object might have locked and to mark the object as "invalid". Later access to it shall triger an exception: "invalidObject".

Call it dispose if you like, because delete is too much like freeing memory.

Is there an intermediate type between structs and classes?

On Monday, 6 October 2014 at 06:23:42 UTC, 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:
>
>> The main distinction between structs and classes in D is the former are monomorphic value types and the later are polymorphic reference types. -- Andrei
>
> Why hack them with scoped? The need exists, since you provide a hack for it.
>
> Reference classes in C++ are polymorphic & reference, but their destructor/disposer gets called.
>
> There is a delete that triggers that or a smart pointer. I don't care if the delete or the destructor really frees the memory, but I would like it to get called, to release other resources that the object might have locked and to mark the object as "invalid". Later access to it shall triger an exception: "invalidObject".
>
> Call it dispose if you like, because delete is too much like freeing memory.
>
> Is there an intermediate type between structs and classes?

Form that page again:

"I have found (dislcaimer:  this is my experience, your mileage will vary) that because 90% of the time you don't need to worry about releasing a resource in C#, it is easy to forget to do a "using" the remaining 10%.  In C++ you always need to worry about it, which makes it real easy to remember that when obtaining a resource make sure you have taken care of its release as well. (In essence, make sure it is stored in something whose destructor will free it).  I have found this pattern a lot harder to follow in C# than in C++.

Having said all that, there is a lot to like about .NET and C# as well.  I just personally find that the whole "garbage collector saves you" aspect that is pitched in every intro to the language I have encountered more of a trap than a salvation."