On Thursday, 23 October 2014 at 22:20:28 UTC, ketmar via
Digitalmars-d-learn wrote:
i love D and i want D to be widespread, but what makes me love
D is
it's attitude to fixing stupid legacy we have in C and C++. and
now it
seems to me that someone should start "BetterD" project to fix
legacy
we already have in D. ain't the desire to fix legacy cruft was
one of
the big driving forces of D creation? it's a pity for me to see
that D
starting to follow some of the worst C++ aspects.
_Every_ language ends up with legacy cruft if it ever gets any
kind of widespread use in the real world. If you want a language
that never has legacy cruft, I expect that you will be forever
disappointed. The question is what is and is worth changing and
at whether you ever reach the point that you're _never_ allowed
to break code (which is pretty much where C++ is). I certainly
hope that D never reaches the point that we'll never break code
even when it truly makes sense to do so, but we _have_ reached
the point where the reasons have to be much stronger.
Some stuff that could currently be considered legacy cruft will
probably be changed, but it's generally a hard sell, particularly
because Walter is _very_ paranoid about breaking people's code
(arguably too much so). Though it should be noted that the vast
majority of D users never post in the newsgroup, and many of them
probably have never visited it, so basing anything on what's
discussed in the newsgroup is basing it on the most dedicated
users, which aren't necessarily representative of the user base
sa a whole, which always makes it difficult to figure out which
decisions that would break code are okay and which aren't and is
probably part of why Walter overreacts to some of the comments on
places like reddit.
Regardless, you can certainly try and lobby for the attribute
names to be normalized, but I don't expect it to change, in this
particular case, while I'd certainly be open to it if Walter want
to get rid of all of the @s on all of the built-in attribute
names, I also don't really care if they stay the way they are.
It's a minor annoyance, but I never found it hard to learn which
ones had @ on them and which didn't (just treat it like one extra
letter to learn in the keyword), and I'm light years beyond the
point where I memorized them all. The primary annoyance about it
at this point is having to answer questions on it when yet
another user tries to figure out why some have @ and some don't
as if there's a discernable pattern to it, and there isn't. And
that sucks, but it doesn't actually cause bugs (unlike allowing
const on the left-hand side of a member function, which
definitely should be deprecated), and it's actually pretty easy
to explain.
- Jonathan M Davis
