[TUHS] Systematic approach to command-line interfaces

[Douglas McIlroy <douglas.mcilroy@dartmouth.edu>]

> 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