On Monday, 30 October 2017 at 22:42:48 UTC, Jonathan M Davis
wrote:
However, I'm sure that it's true that a number of the design
decisions in D stem from the fact that both Walter and Andrei
come from C/C++, and so they're going to tend to make design
decisions similar to C/C++ by default. So, D ends up being
different when there's a feature that's being purposefully
designed to be different from C/C++, but it tends to be similar
when there wasn't a strong reason to do something differently
from C/C++.
But as we can see from this discussion of the elvis-operator
those "rough edges" becomes viral over time as you add more
features. So, whiley some rough edges might not be so visible
when you have few features, they might be amplified as you add
more features. C++ is a pretty good example of this. They add
new stuff that tries to iron out some of the rough spots, and are
fairly successful at it, but they have to do it in ways where
they end up with features clashing or syntactical annoyances. I
haven't used Rust much, but it is interesting that they managed
to stay out of the C-mold. Most other main-stream compiled
languages has not.
Anyway, it often takes several years of practice to discover that
neat features aren't so good after all. I probably wrote much
more terse C code in the beginning. I also have changed my ways
with C++, too much sigils so now I am using "and" and "or" for
booleans. Too much reuse of "&&" and "&" makes code less
readable. As languages get more complex feature-wise I think it
becomes ever more important to streamline. Which is kinda the
opposite of what happens when you let the design over decades.
(so you have to put more work into streamlining how you write
code).
