It is the year 2020: why should I use / learn D?

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Nov 16 00:42:05 UTC 2018


On Thu, Nov 15, 2018 at 11:03:56PM +0000, NoMoreBugs via Digitalmars-d wrote:
[...]
> C++, at least, is boldly going where..perhaps it should not go ;-)
> 
> .. but at least it's moving in a direction that is (speaking for
> myself) making programming in C++ at little less brittle (*if* you
> stick to particular features, and learn them well).

That's ridiculous.  So you're saying, to use C++ effectively you
basically have to use only a subset of it?  So why do we keep having to
haul the rest of that baggage around?  Not to mention, you cannot
enforce this sort of thing in a project of any meaningful scale, short
of draconian code review institutions.  As long as a feature is there,
SOMEBODY is bound to use it someday, and it will cause headaches to
everyone else.


> Trying to learn all of C++ is just complete nonsense (as it is for
> almost any language). It would take decades just learning it all (and
> it's a constant moving target now, making it even more difficult - i.e
> Scott Meyers).... and nobody needs to use all of the language anyway.

Patently ridiculous.  What's the point of having something in a language
if nobody's going to use it, or if nobody *should* use it?  A language
should be a toolbox for the programmer to draw upon, not a minefield of
dangerous explosives that you have to very carefully avoid touching in
the wrong way.  You should be able to combine any language feature with
any other language feature, and it should work without any surprising
results or unexpected interactions. (Not even D fully meets this
criterion, but C++ hasn't even made it on the chart yet!)

Which also means that every new feature or change added to a language
not only brings the intended benefits, but also comes at the price of
technical debt.  The larger the language, the less people can fully
comprehend it, and the less you can comprehend it, the more chances you
will not use something correctly, resulting in bugs that are hard to
find, reduce productivity, and waste time.  A language that cannot be
fully comprehended by any one person is far too large, and has the
stench of bad language design.


> D is no exception to this - it is also a rather complex language with
> far too many features that any single programmer would need in
> totality. Pick a subset, get good at using it. Preferably the subset
> that can best provide guarantees of software correctness ;-)

Actually, I've used most of D's features myself, even just in my own
projects.  Won't lie, though: some parts look dark and dirty enough that
I wouldn't go beyond reading about it, if I had the choice.


> As for the next 'paradigm', it won't be 'unbridled freedom', I
> guarantee that.
> 
> The programmers may certainly want that freedom (I certainly do), but
> the institutions/corporations who will be impacted by that 'unbridled
> freedom', will want better guarantees around software correctness -
> not more freedom.

Then screw the institution.  Programming is about facilitating the
programmer to express what he wants to the computer, not about binding
him in a straitjacket and making him jump through hoops just to express
the simplest of concepts (*ahem*cough*Java*sneeze*).

It's a big lie and a great fallacy that language restrictions lead to
software correctness.  Restrictions only reduce productivity, and sweep
the problem under the rug -- you may get rid of the superficial
mistakes, but fundamental errors committed through inexperience or a
faulty paradigm will continue to promulgate.

Real support for correctness in a language comes from a careful, well
thought-out design of language features such that the paradigm itself
leads you to think about your programming problem in a correct way that
results in correct code. Most correctness problems stem from thinking in
the wrong way about something, which manifests itself as the symptoms of
leaky (or outright unsafe) abstractions, programming by convention,
needless boilerplate, and so on.  These in turn leads to a proliferation
of bugs.


> So in my opinion, the language that can best provide such guarantees
> (with consideration to other constraints that might apply), is the
> language that people will flock too.

Common fallacy: popular == good, unpopular == bad.

I couldn't care less which language people flock to.  In fact, in my
book, people flocking to the language is a strong indication that I
should probably avoid it.  People flocked to Java back in the day -- I
was skeptical.  And recently, after having gotten over my skepticism, I
finally conceded to try it out.  Did not last long.  In the process,
although I did find one or two pleasant surprises, my overall experience
was that 85% of my time was wasted fighting with a crippled,
straitjacketed language, rather than making progress in the problem
domain.

Same thing with C++ a year or two ago, when I went back to try to fix up
one of my old C++ projects.  Found myself fighting with the language
more than getting anything done in the problem domain.  Ended up
spending about half a year to rewrite the whole thing in D (which is a
small fraction of the effort it took to do it in C++), with far better
results.


> D provides a lot in that area (which is what attracted me to it), but,
> it breaks awfully in other areas ( I'm thinking implicit conversions
> (so old school),

Yawn. Another common fallacy: old school == bad, bandwagon == good.

(Not saying that implicit conversions in D are any good -- in fact, I'm
in favor of killing off outdated C-style implicit conversions
altogether, even if this will only ever happen over Walter's dead body
-- but seriously, "old school" as the reason? Wow. Never seen a more
rational argument.)


> no concept of private state *within* a module (what! really!), no
> appetite at all for addressing many issues, ...etc..etc).

Yawn.  Still not over the hangup over 'private', I see.  Missing the
forest for the trees.  There are far more important issues in
programming than such trivialities.  But hey, such things require too
much thought to comprehend, so why bother?


> C++ is the Bear. Poke it at your risk.

*snort* The Bear, eh? :-D  A sickly and overweight one, no doubt, with a
deteriorating heart condition dangerously close to a stroke, still
clawing the edge of the cliff in memory of its former strength even as
it slowly but surely falls off the stage of relevance into the dusts of
history, dragged down by its own weight of backward compatibilities and
layers of bandages upon patches upon bandages that paper over
fundamental design problems that will never be truly fixed.  Yawn.


T

-- 
Your inconsistency is the only consistent thing about you! -- KD


More information about the Digitalmars-d mailing list