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.
