Computer Old Farts Forum
 help / color / mirror / Atom feed
From: bakul at bitblocks.com (Bakul Shah)
Subject: [COFF] Other OSes?
Date: Thu, 05 Jul 2018 16:11:57 -0700	[thread overview]
Message-ID: <20180705231205.14944156E400@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Thu, 05 Jul 2018 13:49:58 -0700." <82df833ae2a587b386b4154fc6051356a3510b19@webmail.yaccman.com>

On Thu, 05 Jul 2018 13:49:58 -0700 "Steve Johnson" <scj at yaccman.com> wrote:
> That's an interesting topic, but it also gets my mind thinking about UNIX
> features that were wonderful but didn't evolve as computers did.
> 
> My two examples of this are editor scripts and shell scripts. In the day, I
> would write at least one shell script and several editor scripts a day.  Most
> of them were 2-4 lines long and used once.  But they allowed operations to be
> done on multiple files quite quickly and safely.
> 
> With the advent of glass teletypes, shell scripts simply evaporated -- there
> was no equivalent.  (yes, there were programs like sed, but it wasn't the
> same...).  Changing, e.g., a function name oin 10 files got a lot more tedious.
> 
> With the advent of drag and drop and visual interfaces, shell scripts
> evaporated as well.  Once again, doing something on 10 files got harder than
> before.  I still use a lot of shell scripts, but mostly don't write them from
> scratch any more.

With specialized apps there is less need for the kind of
things we used to do.  While some of us want lego technic,
most people simply want preconstructed toys to play with.

> What abstraction mechanisms might we add back to Unix to fill these gaps?

One way to interpret your question is can we build
*composable* GUI elements? In specialized application there
are GUI based systems that work. e.g. schematic capture,
layout, control system design, sound etc. (Though for circuit
design HDL is probably far more popular now. Schematic entry
is only for board level design.)

Even if you designed GUI elements for filters etc. where you
can drag and drop files on an input port and attach output to
some other input port, the challenge is in how to make it easy
to use. Normally this would be unwieldy to use. Unless
you used virtaul "NFC" -- where bringing two processing blocks
near each other automatically connected their input/output
ports. Or you can open a "procesing" window where you can type
in your script but it is run until its output is connected
somewhere. Or an "selection" window where copies of file/dir
can be dragged and dropped.

This may actually work well for distributed sytems, which are
basically dataflow machines. [Note that control systems are
essentially dataflow systems.] This would actually complement
something I have been thinking of for constructing/managing
dist.systems.

Note that there are languages like Scratch & Blockly for kids
for programming but to my knowledge nothing at the macro
level, where the building blocks are files/dirs/machines, tcp
connections and programs).


  parent reply	other threads:[~2018-07-05 23:11 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-05  5:56 wkt
2018-07-05  6:29 ` spedraja
2018-07-05  6:40 ` bakul
2018-07-05 15:23   ` clemc
2018-07-05 20:49     ` scj
2018-07-05 21:25       ` david
2018-07-06 15:42         ` gtaylor
2018-07-05 22:38       ` ralph
2018-07-05 23:11       ` bakul [this message]
2018-07-06  0:06         ` lm
2018-07-06 15:49           ` gtaylor
2018-07-06  0:52       ` tytso
2018-07-06  5:59         ` ralph
2018-07-06 15:59           ` gtaylor
2018-07-06 16:10             ` ralph
2018-07-06 16:47               ` gtaylor
2018-07-06 15:57         ` gtaylor
2018-07-06 15:38       ` gtaylor
2018-07-09  1:56         ` tytso
2018-07-09  3:25           ` gtaylor
2018-07-09  3:35             ` crossd
2018-07-09  3:43               ` gtaylor
2018-07-09  3:52                 ` imp
2018-07-09 11:32                   ` perry
2018-07-09 11:50                     ` perry
2018-07-09 11:34                 ` crossd
2018-07-09  5:23             ` tytso
2018-07-09 12:52               ` clemc
2018-07-09 13:06                 ` [COFF] PiDP Obsolesces Guaranteed clemc
2018-07-09 14:39                 ` [COFF] Other OSes? tytso
2018-07-09 14:46                   ` clemc
2018-07-09 11:24           ` perry
2018-07-05 22:51   ` ewayte
2018-07-08 20:31   ` perry
2018-07-08 20:53     ` perry
2018-07-09  2:44     ` crossd
2018-07-10  5:30       ` bakul
2018-07-16 14:49         ` crossd
2018-07-16 16:59           ` [COFF] Capabilities (was " bakul
2018-07-06  0:55 ` [COFF] " crossd
2018-07-06  5:42   ` bakul
2018-07-09  2:51     ` crossd
2018-07-10  5:41       ` bakul
2018-07-06  4:04 ` grog
2018-07-06 16:10   ` gtaylor
2018-07-06 18:27     ` [COFF] Editor Scripts scj
2018-07-06 19:04       ` gtaylor
2018-07-08 20:50 ` [COFF] Other OSes? perry
2018-07-08 23:27   ` bakul
2018-07-09  0:00     ` grog
2018-07-09  0:13       ` perry
2018-07-09  0:05     ` crossd
2018-07-09  0:56       ` lm
2018-07-09  2:23         ` crossd
2018-07-09  0:11     ` perry
2018-07-09  0:19       ` crossd
2018-07-09  2:00         ` bakul
2018-07-09  3:02           ` [COFF] Origination of awful security design [COFF, COFF] bill
2018-07-09 13:10           ` [COFF] Other OSes? david
2018-07-09 13:17           ` perry
2018-07-09 13:13         ` perry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180705231205.14944156E400@mail.bitblocks.com \
    --to=coff@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).