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