[Oberon] Building on NW's ideas?

[eas lab]

Although he hasn't developed it into a rigorous theory, clearly Prof Wirth is
aware of the centrality of HumanComputerInterface/HumanCognition in
computing productivety. Eg. he writes:
...the only channel of human users with high bandwidth is the
 eye. Consequently, the computer's visual output unit must be properly
 matched with the human eye.---
... Tool texts can
be regarded as individually configurable private menus. The rarity of
issuing commands by typing them has the most agreeable benefit that their
names can be meaningful words. ---
 But the influence of the
Oberon concept is not restricted to the style in which the computer is
used. It extends also to the way programs are designed to communicate
with the environment. The definition of the abstract type Text in the
system's core suggests the replacement of files by texts as carrier of
input and output data in very many cases. The advantage to be gained
lies in the text's immediate editability. ---

Actually "Oberon concepts" means these HIGHER HumanComputerInterface
concept, which Wirth has incorporated into Oberon, without emphasising
them; perhaps because they're too philosophical and fuzzy.

What 'gems' can we extract from his observations?
=> "meaningful word": ie. leverage our assets that we've already paid for:
 schooling to read/write.

 -But abreviations are more economical to type.
 So don't type, just klux the menuItem.
 -But Menu's consume valuable screen-area.
 So avoid the need for simultaneously-multiple menues.
 -How?
See/design the task as a sequence of transformations [aka unix-pipe],
where, if the output of the Nth-stage is correct, you can forget about
stage(N-2); ie. discard the previous menus, and free-up their space,
and your mind.
Which relates perfectly to NW's above "texts as carrier of input and
output data".

Consider the following arbitrary task:
 count the number of lines in <PROC Init> in the file: *dog*.Mod
  in the grandparent of this directory.

Unix-one-line-jockeys would design/evolve the solution from:
GetTheFile | ExtractTextBetween <PROC Init> & <end PROC;> |CountLines

ETHO-jockeys would do the same; but manually, and <passing each stage>
via a TextViewer, as NW emphasises above.
But let's be able to automate it, like the *nix-boys can do.

Provisional ideas, which can be refined are:
* ET.DO & <Miscl*.Do> already a scripts.
* Can we use <ET.Mark arg> to position a Viewer, as the data-carrier,
  and then delete it, after it's been used, like *nix-pipes are discarded?

 I'll try with ETH Oberon (2.4.3) for Linux x86 [LEO] later, using
 suitable *nix-commands, just as a proof of concept.

Can someone test this idea of ET.DO automatically chaining a sequence
of existing ETHO transformations [eg. Directory & RX.Grep..etc.] via
TextViewers ? Or perhaps with just 2 Viewers, we could
circulate-the-buckets instead of using a pipe-line?

The aim is to automate a sequence of manual steps into 1 klux on:
   ET.Do SequentialTask.

== Chris Glur.