Why is D unpopular?

[H. S. Teoh]

On Sun, May 15, 2022 at 10:21:18AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/15/2022 4:55 AM, H. S. Teoh wrote:
> > There is, of course, the option of rewriting said C library in D.
> In my experience, it is not an option to rewrite working C code into
> D.
> 
> Note that I have successfully converted small and medium C code
> projects to D. I've done other translations of programs from one
> language to another.

I've converted a medium-sized C++ project into D. (Not a library,
though, which would entail different mechanics because there'd be
external code that uses it, so API compatibility becomes an issue.)


> 1. if you don't have a test suite for the program, a successful
> conversion becomes an order of magnitude harder

Very true.


> 2. converting a program all at once does not work. It must be done
> incrementally, one function at a time

On the contrary, with the C++ project that I converted, I found it too
onerous to convert one function at a time. I started off that way, but
quickly found it too painful because of tight coupling in the original
code -- converting a single function sometimes actually requires
converting 15 functions because they are all interdependent and/or use
share the same data structures.

In theory I could've done it, I suppose. But I eventually threw in the
towel, and decided to leap into D cold-turkey. Strictly speaking it was
more a complete rewrite in D from ground up than converting, using the
C++ code more like an external reference for comparing behaviour than
actually converting the code itself.  Fortunately, I had a largish
website that provided plenty of actual use cases for the program, so
even though it wasn't technically a test suite it did serve as a check
for whether I failed to match the old C++ behaviour, as well as a
progress meter of how far the D code has progressed.

Now the entire project is in D, and I'm mighty proud of it. It's much
more maintainable than the original C++ codebase, and thanks to D's
modern features it's much easier to implement new features without
constantly getting bogged down by the amount of babysitting that C++
demands.


> 3. even so, when faced with a large, complex project, there's just no
> business case for doing a conversion
> 
> Even just converting the .h files to D can be a major, rather
> unpleasant undertaking. We've put a lot of time into converting the
> various system .h files into D for druntime. There's always a risk of
> a mistake, and we've made them and the result is bizarre crashes
> because of ABI mismatches.  Hand-checking them is error-prone, tedious
> and very boring work.
[...]

Yes, automatic conversion is the way to go.  Even when I'm
"hand-copying" C prototypes into D, I always use cut-n-paste + edit
afterwards, rather than typing it out from scratch, because the latter
is so much more error-prone.  My latest project, which uses libxcb
heavily, has a sed script for doing 90% of the work recasting C types
into D -- routine stuff like uint8_t -> ubyte, etc..  Routine work is
the most dangerous in terms of likelihood of human error, because humans
are bad at doing repetitive things accurately. After the first 5 times
your brain just zones out and defers to muscle memory, and mistakes
creep in that you're not even conscious of.


T

-- 
Береги платье снову, а здоровье смолоду.