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 sMessage 1 of 3 , Jan 4, 2010View SourceWhen 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]
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
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
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
.. 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
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,
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
2c. "> <the destination>" = and save it to the new place - for editing/mailing.
... I m going to answer this once and for all... Joy and similar languages likely share the benefits of other pointfree approaches. There are two mainMessage 1 of 3 , Jan 4, 2010View SourceOn Jan 4, 2010, at 7:07 PM, chris glur wrote:
> When it's too hard to explain, they revert to "try it, you'll likeI'm going to answer this once and for all...
> or the new buzz-phrase: "good experience".
Joy and similar languages likely share the benefits of other pointfree
approaches. There are two main differences between Joy and other
pointfree languages like FP:
1) All primitives functions operate on terminated nested pairs (i.e.
2) By convention, almost all primitives can be passed more arguments
than they need which are simply returned unaltered (e.g. '+' returns
everything beyond the top two elements unchanged).
The first point also has a corollary: Functions are never curried;
higher order functions take the functions they operate on in the same
product as the values to be operated on.
The second also has a corollary: Implementations inspired by linear
logic become viable without a resource-aware type system or other
means of enforcement; see Baker's "The Forth Shall Be First" paper.
The utility of this is debatable.
Unfortunately, another corollary of of 2 is that programs can easily
become overly sequential and opportunities for parallel reduction (and
algebraic manipulation) are not syntactically obvious. Other problems
exists but are more subtle.
For the benefits of pointfree programming in general, research via the
links Tom and I posted. For the benefits of stack-based languages in
particular, namely implementation simplicity, meta-programming, and
code refactoring benefits, look to the Forth community.
You shouldn't need any further guidance on this question. If you're
interested in pursuing it, I think there may be some fruitful research
... Yup, understood. ... Don t worry -- I never considered throwing you off the list before this. So clearly, the hysteria level wasn t bad enough then. ...Message 1 of 3 , Jan 4, 2010View Sourcechris glur <crglur@...> wrote:
> When it's too hard to explain, they revert to "try it, you'll like it",Yup, understood.
> or the new buzz-phrase: "good experience".
> Previously when I queried/criticised "what's the point of cat-like?",Don't worry -- I never considered throwing you off the list before
> I got hysterical threats of being cut-off the mailing list. Has that
> happened, or has it just fizzled ?
this. So clearly, the hysteria level wasn't bad enough then.
> My crit/prompt gave good resultsCool! I hope it's a lot of fun -- I'm having fun with my own
> in widening my OWN view. For those who can understand, here a paste of
> my preliminary design notes towards a cat-like labour saver:-
concatenative toy (although mine's a LOT less practical than the one
you're thinking about here).
> Q. are there, for cat-like design, any published: 'axioms', 'patterns';Yes; but it's generally under the rubric of specific languages. Factor
> rather than "this feels good"?
has some idioms of its own; Forth has a LOT (see the "1x Forth" talk
Chuck Moore gave).