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
