What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/24/2014 11:44 AM, H. S. Teoh via Digitalmars-d wrote:
> No, I just named it as a representative case of many such wrinkles
> within existing language features. The fact of the matter is, wherever
> you turn, there's always something else that hasn't been fully ironed
> out yet. Features that interact with each other in unexpected ways.
> Corner cases that weren't considered / are hard to fix due to the nature
> of the features involved. Fixes that require a decision -- which are
> often neglected because there are too many other things being worked on.

I don't know of any language that is "fully ironed out". There's no such thing. 
I can give you a list of such things with C. Furthermore, if your car is missing 
wheels, spending all your time getting the paint job perfect isn't getting the 
car into usable condition.

Corner cases are, by definition, in the corners, not the center of the road. 
Corner cases need to be addressed, but they are not in the way of getting s**t 
done, and getting s**t is the primary purpose of a programming language.

I know I tend to focus on issues that block people from getting useful work 
done. Those aren't the corner cases. For example, the local import thing that 
suddenly became critical - it is not critical. (We still need to address it.) If 
it is causing you problems, you can:

1. not use local imports, put them in the global scope
2. stick with short local names - if a module is exporting a symbol named 'i', 
whoever wrote that module needs to receive a strongly worded letter (!).

It's still good that the import issue is brought up, and we need to make it work 
better. But it is not critical, and does not prevent people from getting work done.

The C++ interop, on the other hand, DOES block people from getting work done.


> Sometimes I wish there were less features in D, but far more refined.
> I'd rather go without the myriad of awesome features in D if I can only
> have a small set of features that have been fully worked out such that
> there are no nasty corner cases, deep-seated compiler bugs, or
> surprising gotchas that lurk around the corner as soon as you start
> writing non-trivial code.

A language that doesn't do much of anything is fairly easy to get right - and 
the very first thing users will do is propose extensions.

May I say that "awesome features" are proposed here EVERY SINGLE DAY, they label 
the features as absolutely critical, usually by the people who argue the next 
day that D overreaches, or sometimes even in the same post.


> I am, as you yourself point out later. But it's frustrating when pull
> requests sit in the queue for weeks (sometimes months, or, in the case
> of dmd pulls, *years*) without any indication of whether it's on the
> right track, and dismaying when your PR is just one of, oh, 100+ others
> that also all need attention, many of which are just languishing there
> for lack of attention even though there is nothing obviously blocking
> them, except perhaps the reviewers' / committers' time / interest.

For some perspective, there are currently 98 open PRs for dmd, and more 
importantly, 3,925 closed ones. There are 39 resolved ones for every unresolved one.

Furthermore, many of my own PRs have sat there for years. std.halffloat, anyone? 
I find it frustrating, too.


> We could at least pay those *some* heed

We are not sitting around doing nothing.