Re: Wanted: testers for heavily revised grog(1)

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Wed, Jun 30, 2021 at 08:15:47PM +1000:

> Since we've dropped groffer from the forthcoming groff release, I expect
> we'll be advising people more to use grog to help them figure out groff
> command lines, and so the quality of its implementation is important
> ("now more than ever", as U.S. politicians like to say).

My conclusion would be just the opposite.  I think we should advise
people to use groff(1), not grog(1).  You know, groff(1) already is
a wrapper, and wrapping another wrapper around a wrapper is almost
invariably a terrible idea.  When people feel an itch to do that,
it often indicates that the user interface wasn't well-designed in
the first place.  I'd go as far as to claim that even the presence
of a *single* wrapper (on this case, groff) is already an indication
of weak user interface design.

Wrappers around wrappers are at best a crutch to work around badly
botched design, but a terrible one because they cause gratuitious
complexity.  Complexity is bad because it forces the user to learn
more, makes the behaviour of the software less predictable, and it
breeds bugs - and maintenance nightmares.

If i were the only maintainer of groff, i would simply delete grog,
too.

But i'm sure other developers disagree, so i'm happy to completely
ignore it.  I'll certainly never use it myself for anything, i'll
not look at bug reports concerning it, and i'll not look at patches
proposed for it or committed to it.  Should it ever cause serious
security vilnerabilities that aren't fixed in a timely manner, i
might just delete it from the OpenBSD port even if it remains in
upstream groff.


Either way, please let us not recommend the use of grog(1).

Yours,
  Ingo