What are the worst parts of D?

[Dicebot via Digitalmars-d]

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