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

[NoMoreBugs]

On Friday, 16 November 2018 at 00:42:05 UTC, H. S. Teoh wrote:
>
> That's ridiculous.  So you're saying, to use C++ effectively 
> you basically have to use only a subset of it?

Yes. That's exactly what I am saying. Although, I would replace 
'effectively' with 'safely'.

A programmer writing secure industrial strength code, must 
understand the features they are using. No exception.

This is why Java is so popular - due to it's limited features - 
which correspond well to the limitations most programmers have 
with regards to much they can continually hold in their head.


> So why do we keep having to haul the rest of that baggage 
> around?

So all the programmers in the world don't have to program in Java 
;-)


> 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.

Well, you *can* restrict yourself to hiring quality, experienced 
programmers though.

>
> 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 statement is more 'Patently ridiculous' .. I mean really.

Library implements need tools most other programmers will not 
need.

The tools needed to write a driver, or kernel, are not the tools 
most programmers will need.

What you don't need to use, you don't need to know about.

> 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.

So, it follows, from your arguments, that we should all use Java. 
Is even that too complex for you?


>
> 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.

A return to common sense. Horray!

> 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*).

Well, a programmer would say that. But you want to be employed?

Now you seem to be arguing for a language that has more 
complexity?

C'mon.. make your mind.


> 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.

Well, a programmer would say that.

But you want to be employed? Start writing correct code - even if 
that means more effort.

> 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.

If there is 'thinking' involved, then bugs will follow. It can't 
be helped.

What's important to me, is being able to very clearly state my 
intent, so that the compiler know it, others know it, and most of 
all, I know it.

How many features the language has is irrelevant, to me. It is 
only necessary that language allows you to clearly express you 
content.

The language should server me. Not I serve the language.

>
> 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.

Again? I cannot determine which side of your two arguements you 
are on.

>
> (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.)

It's old school to have the language deciding for you, what your 
intent is.

I agree that D2 will not change that - nor should it.

But it could provide 'option' that programmers could 'opt into'.

But then people will say 'no, change is to complex for us to 
handle'.

Or (more likely), Walter won't like it. So lets not even bother 
thinking about it anymore.

> 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.

Really? Private state is a trivial notion? Who'd have guessed.

Anyway, the D module is really just a 'God' class (or struct, 
depending on your point of view).

>
> *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.
>

Well, keep poking it ...you'll get its attention soon enough ;-)