What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

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