What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

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