Re: [TUHS] Systematic approach to command-line interfaces

[Tom Lyon via TUHS <tuhs@minnie.tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

I always believed that fork() was the very essence of the beauty of UNIX.
So simple, yet so powerful.  And it is far simpler than its predecessor on
Genie, which looked a lot more like spawn().

With fork, the child inherits properties which may not have existed when
the code was written, so it's much easier to reason about the behavior of
sub-processes.  Fork made writing the shell and pipelines much more obvious.

Today we know that threads and shared mutable memory are a really bad idea,
it's just that the hardware gave us no alternatives. I claim UNIX is
directly responsible for the existence of MMUs in microprocessors.  What if
CPU designers would add facilities to directly implement inter-process or
inter-processor messaging?  Sadly, there has to be a dominant software
paradigm for the hardware guys to target, so there's a nasty chicken and
egg problem.  Imagine if the Erlang model of distributed systems had taken
off.  Go gets us part of the way there, but cross-machine messaging is
still a mess.

On Tue, Aug 3, 2021 at 8:02 AM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> > 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*.
>
> > It's not so great for a responsive GUI in front of a multi-function
> interactive  program.
>
> "Single-threaded" is not a term I would apply to multiple processes in
> a  pipeline. If you mean a single track of data flow, fine, but the
> fact that that's a prevalent configuration of cooperating processes in
> Unix is an artifact of shell syntax, not an inherent property of
> pipe-style IPC. The cooperating processes in Rob Pike's 20th century
> window systems and screen editors, for example, worked smoothly
> without interrupts or events - only stream connections. I see no
> abstract distinction between these programs and  "stuff people play
> with on their phones."
>
> It bears repeating, too, that stream connections are much easier to
> reason about than asynchronous communication. Thus code built on
> streams is far less vulnerable to timing bugs.
>
> At last a prince has come to awaken the sleeping beauty of stream
> connections. In  Go (Pike again) we have a widely accepted programming
> language that can fully exploit them, "[w]hich is, y'know, what Unix
> is 'for'."
>
> (If you wish, you may read "process" above to include threads, but
> I'll stay out of that.)
>
> Doug
>


-- 
- Tom

[-- Attachment #2: Type: text/html, Size: 3445 bytes --]