On Mon, Aug 2, 2021 at 5:19 PM Jon Steinhart <jon@fourwinds.com> wrote:
John Cowan writes:
> > fork() is a great model for a single-threaded text processing pipeline to
> > do automated typesetting.  (More generally, anything that is a
> > straightforward composition of filter/transform stages.)  Which is, y'know,
> > what Unix is *for*.
> >
>
> Indeed.  But it's also a very good model for "baking" web pages in the
> background so that you can serve them up with a plain dumb web server,
> maybe with a bit of JS to provide some auto-updating, especially if the
> source data is stored not in a database but in the file system.  The result
> is a page that displays (modulo network latency) as fast as you can hit the
> Enter key in the address bar.
>
> (The weak point is the lack of dependency management when the system is too
> big to rebake all the pages each time.  Perhaps make(1), which Alex Shinn
> described as "a beautiful little Prolog for the file system", is the Right
> Thing.)

We have, of course, had similar discussions many times on this list.
I think that the root issue is the false equivalence of "I don't
understand this well enough to be able to use it effectively to solve
my problem" with "it's broken/obsolete/dated".

That's a bit unfair. One can understand something and see value in it and still appreciate its limitations.

Fork has served us well for more than five decades; I've got no argument with that. However, should we never question whether it continues to be the right, or best, abstraction as the environment around it continues to evolve?

        - Dan C.