[TUHS] RIP J.F.Ossanna

[Steffen Nurpmeso]

Larry McVoy <lm at mcvoy.com> wrote:
 |On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
 |> Larry McVoy <lm at mcvoy.com> wrote:
 |>|On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
 |>|> 1977 marks my entry into the world of UNIX.   I've always stated \
 |>|> there was
 |>|> only one person who truly understood nroff and he was dead.
 |>|> I mourn the fact that of all the UNIX greats I've met, I missed out on
 |>|> Ossanna.
 |> 
 |>|I think one could argue that James Clark has a pretty good handle on
 |>|roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
 |> 
 |> And Werner Lemberg, who carried the torch for the last almost two
 |> decades.  He brought in some really great improvements, like
 |> arguments for strings, which allows to write pretty much TeX like
 |> a.k.a. inline if you want to (as in "this is \*[I talic] text").
 |
 |Yep.  James exited stage left and Werner stepped in.  I mean no disrespect
 |to anyone, I was just saying that James has a really good handle on roff,
 |he redid it all.  I admire him for doing so (even though I curse the fact
 |that he did it in C++).

The original source was no free code back then, so he did it for
the free and open software world.  Thankfully.  And i do not know,
i mean C++ was in 1989-1992, when he did most of the work as far
as i can tell from a shallow look, a class, later template
extension layer for plain C, not that overly huge stands-by-itself
monster that i call it now.

I am absolutely in favour and a of classes and objects, the
encapsulation they provide, the method-on-object rather than
object-on-function that you have with C.  (Multiple) Inheritance
including automatic upcasts (to the given parent).  Virtual
function pointer tables, automatically managed.  And "simple"
templates.  For example, myself, in the process of creating my own
fork, can write (globbering the global namespace)

   color &assign_rgb(rf_ui32 r, rf_ui32 g, rf_ui32 b){
      m_scheme = scheme_rgb;
      return set_red(r).set_green(g).set_blue(b);
   }  
   color &set_red(rf_ui32 c){
      rf_ASSERT(scheme() == scheme_rgb);
      m_comps[0] = rf_min(c, max_val);
      return *this;
   }
   ...

instead of

  rf_color *rf_color_assign_rgb(rf_color *self, rf_ui32 r, ....){
    self->c_scheme = rf_COLOR_SCHEME_RGB;
    self->c_comps[0] = rf_MIN(r, rf_COLOR_MAX_VAL);
    ...
    return self;
  }

and programming all that out over and over again.  (Or using
macros with side-effects.  Or relying on inline functions.)
And that is a simple object with a short name.
References are unfortunate in my opinion, but you will not see any
light if you try doing C++ without them because they are
omnipresent for core functionality like standard copy constructors
etc.  Like many other things, including the complete departure
from an underlaying C standard.  C++03/C99 or so i would have
appreciated.  But as long as -fno-rtti -fno-exceptions is possible
i can somehow live with it.  (Let aside the fact that i have to
live with it no matter what bloat the C++ standard introduces
next.)  And then C is not what it was no more, too, and
unfortunately the usage-makes-fun guideline from what Plan9
documents and extends onto ISO C89 was not what the ISO C people
looked at when they did.  Well.

Maybe if he would have known what C++ ends up as he would have
used C instead?  That would be an interesting question.  Myself
i currently appreciate coming back to a C++ codebase, however,
because thinking in objects is my personal way of dealing with
programming, that is how i really got used to it, anyway.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)