Programming language for GIMP fork's rewrite

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Jul 2 23:10:43 UTC 2020


On Thu, Jul 02, 2020 at 09:02:28PM +0000, Meta via Digitalmars-d wrote:
> On Thursday, 2 July 2020 at 16:11:27 UTC, H. S. Teoh wrote:
[...]
> > I've rewritten a medium-sized C++ project of my own before (nowhere
> > near as big as Gimp though), and I started out with the piecemeal
> > approach, but found it quite frustrating. Eventually I opted to just
> > dive cold turkey into rewriting it in D from ground up.  It took a
> > while, but I'm quite pleased with the result, and have taken new
> > directions with the code since, which has been much easier with D
> > than C++.
[...]
> What were the main issues you ran into with the piecemeal approach?

The main frustrations were caused by having to stick to the C++ ABI
between the C++/D boundary. This meant I can't use any D-specific
features across this boundary, which greatly limited what the D portions
of the code can do. Basically I had to write C++-style code in D in
order to get it to work, which sorta defeats the purpose of rewriting it
in D in the first place.

In theory, of course, once the entire codebase was in D then I could
start refactoring it to be more idiomatic, but that meant a lot more
effort was required: first transliterate C++ into D, then do piecemeal
rewrites in D.  In contrast, rewriting the whole thing cold turkey from
ground up meant I could dispense with the first step and do the second
more easily (because I wouldn't have to work around old API design
problems while doing the piecemeal rewrites -- I could just start fresh
with a better design).

There remains, of course, what Joel Spolsky said about rewriting
software from scratch: old bugfixes may be missing from the new code and
therefore old bugs are reintroduced.  IME, however, getting a fully-D
codebase up and running faster meant I could invest more time and effort
into writing unittests until I achieved functionality on par with the
old code.  The old code didn't even have unittests in the first place,
so there were all sorts of latent bugs and regressions that I uncovered
while reading the old code in the process of writing the new D code.  In
contrast, the D code, while initially very buggy, was quickly kicked
into shape thanks to a quickly-growing series of unittests, and later
on, an external test suite that I threw together (with a convenient test
utility -- written in D, of course, which meant I could put it together
very quickly).  It also so happened that this particular project was
heavily used by my website project, which used it in many non-trivial
ways, so that also served as a large test case to ferret out all the
obscure bugs that the unittests and test suite missed.

I'm rather pleased with the result, which has a much better design than
the original C++ code. Not having to go through a transition stage where
I had to pass everything through the old API meant that I could fix
fundamental design issues from the get-go, instead of carrying it over
into D and then doing another massive refactoring to fix them as a
second step.

Of course, a lot of this is very specific to my specific codebase and
use case; so YMMV, caveat emptor, et al.  DMD would serve as a
counterpoint, where the translation to D was essentially a direct
transliteration from C++, and even to this day is still gradually being
rewritten piecemeal to take advantage of D features.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you fail to deliver after.


More information about the Digitalmars-d mailing list