The Case Against Autodecode

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 15 May 2016 at 01:45:25 UTC, Bill Hicks wrote:
> From a technical point, D is not successful, for the most part.
>  C/C++ at least can use the excuse that they were created 
> during a time when we didn't have the experience and the 
> knowledge that we do now.

Not really. The dominating precursor to C, BCPL was a 
bootstrapping language for CPL. C was a quick hack to implement 
Unix. C++ has always been viewed as a hack and was heavily 
criticised since its inception as a ugly bastardized language 
that got many things wrong. Reality is, current main stream 
programming languages draw on theory that has been well 
understood for 40+ years.  There is virtually no innovation, but 
a lot of repeated mistakes.

Some esoteric languages draw on more modern concepts and 
innovate, but I can't think of a single mainstream language that 
does that.


> If by successful you mean the size of the user base, then D 
> doesn't have that either.  The number of D users is most 
> definitely less than 10k.  The number of people who have tried 
> D is no doubt greater than that, but that's the thing with D, 
> it has a low retention rate, for obvious reasons.

Yes, but D can make breaking changes, something C++ cannot do. 
Unfortunately there is no real willingness to clean up the 
language, so D is moving way too slow to become competitive. But 
that is more of a cultural issue than a language issue.

I am personally increasingly involved with C++, but 
unfortunately, there is no single C++ language. The C/C++ 
committees have unfortunately tried to make the C-languages more 
high performant and high level at the cost of correctness. So, 
now you either have to do heavy code reviews or carefully select 
compiler options to get a sane C++ environment.

Like, in modern C/C++ the compiler assumes that there is no 
aliasing between pointers to different types. So if I cast a 
scalar float pointer to a simd pointer I either have to:

1. make sure that I turn off that assumption by using the 
compiler switch "-fno-strict-aliasing" and add "__restrict__" 
where I know there is no aliasing, or

2. Put __may_alias__ on my simd pointers.

3. Carefully place memory barriers between pointer type casts.

4. Dig into the compiler internals to figure out what it does.

C++ is trying way too hard to become a high level language, 
without the foundation to support it. This is an area where D 
could do well, but it isn't doing enough to get there, neither on 
the theoretical level or the implementation level.

Rust seems to try, but I don't think they will make it as they 
don't seem to have a broad view of programming. Maybe someone 
will build a new language over the Rust mid-level IR (MIR) that 
will be successful. I'm hopeful, but hey, it won't happen in less 
than 5 years.

Until then there is only three options for C++ish progamming: 
C++,  D and Loci. Currently C++ is the path of least resistance 
(but with very high initial investment, 1+ year for an 
experienced educated programmer).

So clearly a language comparable to D _could_ make headway, but 
not without a philosophical change that makes it a significant 
improvement over C++ and systematically adresses the C++ 
short-comings one by one (while retaining the application area 
and basic programming model).