3 Aug
2021
3 Aug
'21
3:25 a.m.
On Mon, Aug 2, 2021 at 5:19 PM Jon Steinhart <jon(a)fourwinds.com> wrote:
John Cowan writes:
result
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.
> 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 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".