Comment by JamesTRexx
15 days ago
As I see it, the problem with languages trying to replace C is that they not only try to fix fundamental flaws, but feel compelled to add unneeded features and break C's simplicity.
15 days ago
As I see it, the problem with languages trying to replace C is that they not only try to fix fundamental flaws, but feel compelled to add unneeded features and break C's simplicity.
C is a simple language, but that simplicity leads to non-portable code and lots of klunky, ugly things like using the preprocessor as a substitute for conditional compilation, imports, lambdas, metaprogramming, etc.
You don't have to use unneeded features that are in D. The core language is as simple as C, to the point where it is easy to translate C to D (in fact, the compiler will do it for you!).
"lots of klunky, ugly things" I wonder how much of that is caused by too complex thinking. It seems that simplicity is very difficult for most people.
"You don't have to use unneeded features" True, but that doesn't work in practice, for example the intentions to use only limited C++ features in new projects, that end up bogged down with the other features anyway because of "new toy to play with" effect. What isn't there can't be used and keeps the language lean and clean (and not mean ;-) ).
I agree that often programmers are tempted to use features "just because they are there".
We've introduced the notion of "editions" in D lately, and its purpose is to remove features that have not proved their value over time.
Also they leave a important point of C behind: backward-compatibility.
D supports mixed C and D files in a project. The D code can call C functions and use C types, and the C code can call D functions using C types.
The D compiler will even translate C source code to D source code if you prefer! After using a mixed D/C program for a while, I bet you'll feel motivated to take the extra step and translate the C stuff to D, as the inelegance in C will become obvious :-)