Re: [stack] Re: Jon Purdy: Why Concatenative Programming Matters

I've become increasingly enthusiastic/obsessed about cat-style.
Clearly there's some ambiguity about 'the definition'.
I'll give my definition AFTER I've shown WHAT problems it solves.
Backus correctly stated the problem before he gave his proposed solution.
That's called goal-directed, and it's the right way, because that's how human.
  minds work. We used to call it top-down-programming.
Almost all write-ups on 'Concatenative Programming' show a solution looking
for a problem.  MvThun claimed that joy could help do formal proofs, since
it allowed algebraic-like manipulation. That would be great; but did anyone
ever see any such problems solved; eg. proof of an algorithm, via joy?

The 'hello world' concept is powerfull, because it's a FULL demonstration,
which can later be successively refined/extended. Cat-style allows this too.

So the meta-problem is:
 how to minimise the concept-counts that need to be handled simultaneously.
I.e. reduce the coupling. It's about the human mind, not technology.

So that eg. you could progress the problem and come back to it next week;
like evolution works: it doesn't NEED to remember and understand previous
steps. And this is vital for serial programmERS.

This little outburst is motivated by another discovery how *nix almost allows
good cat-style: you can 'concatenate the concepts' but not write them linearly
from left to right.

The example problem: I want to reuse a [few-line] script/file, by copying it
to a new-name and editing it. It's called 'Sa'. But I don't know where it is
located. But unix helps with:
 whereis Sa  == Sa: /usr/local/sbin/Sa

But I only want the 2nd 'string/field' so:
 whereis Sa | awk '{print $2}' == /usr/local/sbin/Sa

[DON'T LOOK AT THE SYNTAX: just see blobs concatenated by "|" ]

So that's where Sa is located. But I want to DO something with Sa.

Clearly the evolving structure is:

[[[noun1 verb1] verb2] verb3]
   where any verb can have modifiers: like 'awk' has "2": for the 2nd string.
And [[noun1 verb1] verb2] is the noun that verb3 operates on, because
[noun verb] maps to a noun.

But we don't want a lispy-bracket-style. So use a forth-style, where for
readability, we'll put each stage/data-transformation on a new-line:

Sa whereis |
2 FieldOnly |     ;; "2" is a modifyer, which joins in the 'data flow'
dog CopyFileAsName

What's really annoying me in linux, is that I have to wrap the existing code
and put <copy it> in FRONT, and then put the copy-destination at the end,
i.e. split/bracket my existing code, instead of just concatenating to it.

So:
   cp ` whereis Sa | awk '{print $2}'` dog
does it...
The concatenative concepts are all there in *nix, but the syntax should be:
  Sa whereis | 2 Field | dog CopyFileAsName

So I define cat-style as 'the ability to serially transform data, by applying
a <verb/operation> to it, without needing to know/remember how the data was
achieved, by previous stages of transformation'..
That's the concept, which *nix achieves. It just lacks the good/clean syntax.

Thanks,

== Chris Glur. PS. has *nix not got a: <fileName> <printContents>  command?

I may have asked this before, [I can't get an answer]: How does *nix.
returning 0 for success and non-zero for different types of function's errors,
instead of the conventional boolean approach, relate to cat/pipe-lining?