On code quality, C, and C++ (was: Proposed: QS/QE macros for quotation in man(7))

[G. Branden Robinson]

Hi onf,

At 2024-12-20T13:59:13+0100, onf wrote:
> > [...] Before the BSD community decided upon the performative
> > wokeness of rabid allergies to copyleft and (at OpenBSD at least)
> > C++.
> 
> I kinda get where they are coming from with C++, though.  Last time I
> tried patching groff, I was fascinated by the stark difference between
> groff's and neatroff's source code.

Let me acknowledge right away that neatroff's code is indeed lucid and
pleasant to read.  More so than groff's.

I don't know how much of that can be attributed to the selection of
programming language, though.

groff was written fast and saw rapid and widespread uptake.  As noted,
even BSD absorbed it.  I don't wish to take anything away from the
magnitude of James Clark's achievement in cranking out a near-total
replacement for Unix troff, including macro packages, preprocessors, and
output drivers, plus documentation for all the extensions he added,
in...what, a year and half, tops?

Neatroff is not, as far as I can tell, nearly as widely used and it has
taken longer to gestate.  These are not flaws--just differences.

I take code readability seriously.  My first impression of any part of
groff that I haven't dealt with before is frequently "okay, what the
hell is this doing?"

My very first impression of neatroff's code when when I first looked at
it a few years ago was, "gosh, that's some smooth stuff."  Neatroff is a
big winner here.

> The latter is just an order of magnitude easier to navigate and
> understand. That may be more a difference of coding style than the
> language itself, of course (just look at Heirloom troff for a
> counter-example),

Right.  Heirloom Doctools troff is descended from Solaris 10 troff which
is descended from DWB 2.0 troff which is descended from Kernighan troff
and ultimately Ossanna troff, which was originally written in PDP-11
assembly language and then side-graded to C, because, hey, C is portable
assembly, right?  It spent a long time passing through a lot of
digestive tracts, and many hands, without the benefit of a ground-up
rethink and rewrite.  Probably Kernighan's work, documented in CSTR #97,
is the biggest refactoring it got, and Kernighan consciously limited the
scope of his revisions.

Incidentally, CSTR #97 and London & Reiser's paper on porting Unix,
including the userland and thus including troff, to the VAX-11/780, are
resources that support my claim about Ossanna "side-grading" troff from
assembly to C.  I may be snarking, but I have a foundation for it.

> but I feel like the language also has an influence; for instance, the
> presence of objects, each with its own methods, definitely made
> groff's source code harder to navigate for me.

This doesn't _have_ to be the case.  But there are warty bits for sure.
Not too long ago I complained about how both groff's `symbol` type and
its `string` type have a `contents()` method.  Both give you back `char`
arrays.  One is null-terminated, the other one isn't...necessarily.

Land mine.

If I had unlimited time and energy to write a *roff from scratch, I'd
write it in Ada 2012 or 2022, exercising pre- and postconditions for
automated, machine verifiability.

https://www.adacore.com/gems/gem-31

I would strive for elegance, but I would not claim that I could match
Ali Gholami Rudi.  Some people have a gift.

Regards,
Branden

signature.asc
Description: PGP signature