groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] Design and Implementation of *roff


From: Ingo Schwarze
Subject: Re: [groff] Design and Implementation of *roff
Date: Fri, 30 Nov 2018 18:45:07 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

Hi,

Tadziu Hoffmann wrote on Fri, Nov 30, 2018 at 05:48:04PM +0100:

>> You need to be a special sort of crazy (and patient, and knowledgeable) to
>> want to endure the obvious pains of reimplementing such a complex system.

> Wikipedia is amazing!  It pointed me to this:
> 
>   https://www.youtube.com/watch?v=l6XQUciI-Sc&t=1h28m35s

Thanks for the link, the epsiode about Joe Ossanna is indeed funny,
but what the guy in the video is saying at that point is of course
total crap: very untrue in multiple respects and totally irresponsible.

Very untrue for example because not many systems are still running
the original AT&T nroff code, groff has been dominant for about two
decades now.  Besides, illumos - which he specifically mentions
as using nroff - switched the default manual page formatter to
mandoc 13 months before his interview, not ten thousand years after.

Then, the premise that code which is absolutely bug-free and works
perfectly will always work is ridiculous.  There is always maintenance
to do because what needs to be done never stays exactly the same for
infinite times - even though what is needed changes slower in some
areas than in others.  Besides, he admits himself that code is never
absolutely bug-free, which is another reason why maintenance never ends.

His statement about the substrate also makes no sense.  The physical
code is not the substrate that is laid down for eternity.  Code is
always subject to rotting: hardware changes, programming languages
change, new classes of security vulnerabilities are discovered that
necessitate improved programming techniques, and so on.  Instead,
the substrate is the knowledge how to solve problems - both in
general and for very specific tasks, both elementary and complex
tasks.  One can argue that in it's purest and strictest form, that
knowledge is expressed in code, the more so the more specific tasks
you are considering.  But then, not the code itself matters as a
resource for eternity, but the *readability* of the code is what
matters.  In that sense, unreadable code is nothing but harmful.
That's why i like the statement (sorry, forgot the author) that
programming is the art of expressing algorithms in such a way that
both humans and computers can understand them - and that making
them understandable to humans is the higher art and the more
important.

Nobody can avoid running code they don't understand because nobody
can study everything.  Sometimes, it may even be hard to avoid
running code that nobody understands because nobody has the time
to rewrite it properly - but given how man people there are on
earth, that's probably not the usual case.  *Promoting* the use of
code that nobody understands is of course totally irresponsible.

Yours,
  Ingo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]