When it's too hard to explain, they revert to "try it, you'll like it",
or the new buzz-phrase: "good experience".
Previously when I queried/criticised "what's the point of cat-like?",
I got hysterical threats of being cut-off the mailing list. Has that
happened, or has it just fizzled ? My crit/prompt gave good results
in widening my OWN view. For those who can understand, here a paste of
my preliminary design notes towards a cat-like labour saver:-
The data-flow model applies: incrementally transforming to data:
Task: find telephone number of 'Goode'.
eg. 'print the line containing "Goode" in some file in dir ?X?',
in some /root dir of some mounted partition.
Previous method [pre-data-flow paradigm].
1. get list of mounted partitions. = df
2. select and carry-over 'the one' [via mouse cut] = X
3. open a file-viewer at <thePartition>/root> = ls #/*el*
4. visually scan for a likely FileID name = X
5. open the file
6. auto-search for "oode" = # | grep oode
7. mouse cut the corresponding tele-number.
AFAIK joy/cat-style is suitable for data-flow problems.
The above telephone-number-search is a data-flow problem,
but with human intervention at various stages.
How does this relate to the more general notion of:
multiple data-flows merging at various stage/s ?
==> needs human intervention/guidance:
? what are the mounted partitions
? what are likely file-IDs
======
If *nix-shell could do cat-like, the above task would be reduced to:
df X [ls *el*] X [grep oode]
where X is the human-input.
As it is, although *nix-shell can't do cat-like, it can do lisp-like,
and the <previous command> can easily [i.t.o. minimal key-strokes]
be wrapped/bracketed.
=====
Need to do unlimited transform-data via chaining.
==> StageN.Input got from StageN-1.Output
==> stack-based/forth-like is a natural form.
======
To use the powerfull advantage of human-intervention in the data-transformation
process,
the ability to continue [perhaps by re-rolling from the begining ] is needed.
*nix achieves this by single-key:<restore/pop the previous command> and
wrapping it as an arg [thunk-like] for the next stage.
eg. "ls /mnt/FC14/*el*" shows the likely 'telephone-directory' file/s
Since we don't want to have to retype this command string again, we just refer
to it as <the last command> by a single-key-stroke, which I'll call "#".
So now the next stage, of outputting the found-file needs:
cat # [ie. output <the file which you found via your search>]
where "#" is the long previous command.
Astualy it's necessary to wrap # thus `#`; which needs 8 key-strokes, even
as the total command [representing #] evolves to scores of chars.
So: cat `#` needs
# = 1
` = 2
home = 3
cat `=4..8
This long-story about minimal key-strokes, is justified, because it's all about
minimising the cognative load.
==> the whole process must be understandable from the code - by the operator.
==> no deep-debugging/analyis is needed/allowed.
==> the operator must be able to EASILY increment /refine already tested code.
==> the perceived complexity must increase linearly rather than exponentially.
==> "it works up to stage N, now I only need to consider the transformation
from stageN to stageN+1".
Ie. good information-hiding: essential for managing complexity.
==> I don't need to be swamped by the combined complexity of the total first
N-stages.
.. to be continued.
Q. are there, for cat-like design, any published: 'axioms', 'patterns';
rather than "this feels good"?
PS. I've just used concepts [economical tools] which I'd never have considered
before the prompt/controversy of: "what's cat good for?"
"cat ObnScript | strings | fold > /mnt/cdrom/ConCatLang/ConcatCrit/Jan10"
has only 2 concepts:
1. copy something that's been used/tested and works -- the library
routine concept.
Luckily I knew where to find something similar, that I'd evolved before.
2. re-use it with minimal modifications, which are easy to understand,
because of
the lack of clutter of the notaion.
2a. "cat ObnScript" = output [from the current-dir] the file named 'ObnScript'
2b. "| strings | fold" = and transform it so that it is readable, like it was
transformed by the other script that used this, and don't worry about
the details.
2c. "> <the destination>" = and save it to the new place - for editing/mailing.