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

[H. S. Teoh]

On Thu, Nov 15, 2018 at 11:17:43AM -0800, Ali Çehreli via Digitalmars-d wrote:
> On 11/15/2018 06:04 AM, Erik van Velzen wrote:
> > If that's true even templates will be more concise in C++.
> 
> We had similar hopes with C++11's 'auto' keyword and the move
> semantics with 'auto&&'. Anybody who hasn't read explanations of those
> concepts like the ones in Scott Meyers's "Effective Modern C++" are
> fooling themselves about the simplicity of such concepts.
> 
> Another example: Can anyone memorize what C++ special functions does
> the compiler generate in the absence, presence, explicit-defaulting,
> and explicit-deletion (and more? I can't be sure..) states of the same
> functions? No.
> 
> One of the prominent members of the C++ community is local here in
> Silicon Valley. He hinted that the goal is to keep C++ improved to
> avoid it becoming like COBOL, where very few experts remain, who are
> paid $1M salaries. "We don't want C++ become like COBOL." My answer
> is, C++ is heading exactly the same place not through natural death
> but through those improvements.
[...]

And that's the problem with C++: because of the insistence on backward
compatibility, the only way forward is to engineer extremely delicate
and elaborate solutions to work around fundamental language design
flaws.  Consequently, very few people actually understand all the
intricate and subtle rules that the new constructs obey, and I daresay
pretty much nobody fully understands the implications of these intricate
and subtle rules when used together with other equally intricate and
subtle features.  The result is an extremely convoluted, hard to
understand, and fragile minefield where every feature interacts with
every other feature a complex way most people don't fully comprehend,
and every two steps has a pretty high chance of resulting in an
unexpected explosion somewhere in the code.

Writing C++ code therefore becomes an exercise in navigating the
obstacle course of an overly-complex and fragile language, rather than
the language being a tool for facilitating the programmer's conveying
his intent to the machine.  It may be thrilling when you successfully
navigate the obstacle course, but when I'm trying to get work done in
the problem domain rather than wrestle with language subtleties, I
really would rather throw out the obstacle course altogether and hire a
better translator of my intent to the machine. Like D.


T

-- 
What do you call optometrist jokes? Vitreous humor.