[Oberon] Incremental evolution of piping system?

[eas lab]

> It is dangerous as piping is typeless.
> Jörg
======
That is correct: at the level which you are seeing it.
But I'm considering a higher level.

Yes, wasn't the <space-craft disaster> of some decades ago, avoidable
 by typing.
But the human aspect trumps the technology, in IT.
That's why ETHO is so great: they got the HCI right; which is much more
important [increase productivity] than technology to increase speed.

I'm not proposing casual-piping for going to Mars.
I'm talking about improving the efficiency [cost-benefit] for
<scratching your ear>.

When I discussed transferring info between my MOBO and the RPi lying on
the table next to it, they told about eth0 with secret decoding.
That's as aburd as using the National railway system to fetch a glass
of water from the adjacent room.

Consider an extreme example of what I'm proposing:-
[since I'm using M$ now I must just guess the syntax]
I want to count the number of times that <string> appears in files:*name*.

MANUALLY this might go:
 System.Directory *name* returns a Frame listing the files
 <Find.Domain & Find.All ^ <string>  as I remember finds the matches
and I don't know how to fit-in the counting.

In *nix the 3 FUNCTIONS are something like:
 find <directory> -name files"name*
 | .... grep <string>
 | wc -l

Do you want to enforce strict type declarations here?
How do you want to do this in ETHO.
With piping/functional/concatenative the 3 functions are independent
re-usable modules. And there are no extra variables to consider
[burden the mind with].

As I've repeately pointed out: ETHO's manual method, already
uses piping, where the stages consist of extra Frames.

== Chris Glur.