[TUHS] Systematic approach to command-line interfaces

[Jon Steinhart]

Bakul Shah writes:
> On Aug 2, 2021, at 6:49 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> > 
> > Bakul Shah writes:
> >> Or perhaps the issue is not having graphics/GUI designers with the
> >> creativity and sensibilities of the early Bell Labs crowd of researchers?
> >> I keep thinking there ought to be something simpler/more elegant than
> >> the current graphics subsystems....
> >> 
> >>> On Aug 2, 2021, at 11:16 AM, Adam Thornton <athornton at gmail.com> wrote:
> >>> 
> >>> It's a measure of Unix having been wounded by its own success.
> >>> 
> >>> 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.
> >>> 
> >>> These days, the vast majority of Unix applications are "stuff people play with on their phones."
> >>> 
> >>> Adam
> > 
> > I thought that I posted something about this recently when someone
> > was arguing for threads being unnecessary and bad.
> > 
> > My two cents is that GUIs were the big driver for threads.  I would
> > personally like to get rid of them as they're "the same but different"
> > with regards to processes.  My preference would be to solve the
> > heaviness of processes problem.  I'm not in the thick of that these
> > days, but I don't see it being solved in software alone; it's going
> > to take some serious hardware/software architecture work.  Might be
> > easier to accomplish now that the world has pretty much settled on
> > the process model.
> > 
> > Jon
>
> AFAIK pretty much all GUI frameworks are (or were) single threaded.
> At least I don't see the GUI as the main motivation for threads.
>
> I was mainly complaining about the complexity of graphics subsystem,
> including user interaction. Don't see what fork() has to do with it.

Not my experience.  At least from what I was working on the 1980s
there was a need to be able to keep complicated state in graphical
programs which is when assembly language versions of threads came
into being.  Made it possible for whatever was generating output
to be interrupted so that input could be handled in a timely manner.
I seem to recall getting some code from Sun for this that I ported
to a different system.

Jon