Re: [netrexx-pipelines] Migrate OS/2 pipelines to NetRexx Pipes

[<hp...@we...>]

Hello Jeff!

Am 23.06.2022 um 18:02 schrieb Jeff Hennick:
> I too am and have been in the user/hobbyist category.  I took a very early
> retirement during a reduction in force, about 30 years ago.

3 decades is a almost half a life time. But after all those years
you are still convinced CMS Pipelines are missing on PCs. Me also.

> [...]
> An example of what I mean by Rexxifying Pipelines, with your example, is in Rexx
> statements end with ";" *or* an end of line.  Pipelines could use the same
> flexibility with stage separators.

Hmm..., when I look at the example in chapter 3.5 'Compiled from
an .njp file', there are still stage separators. A new line could
imply it like REXX adds self-acting the ";" to end the clause.

> NetRexx Pipelines at least don't need all
> those quotes and commas (but doesn't support the comments; I had to add a
> COMMENT stage, "--", which is not so flexible).

Well, why only "--" as 'begin comment', why not also "/* .. */"
bracketing style comments? I assume you use a pipe filter to sort
out all 'only human related' content the compiler could disturb.

> Rexx is specifically designed for human reading.

Reading only? ;)
BTW, at first glance it seemed to me a poor joke, "NetREXX is a
human-oriented programming language", found in the introduction of
the QuickStart Guide. Are not all programming languages made for
humans? Are there some for dogs? Pavlov’s dog? Or is there a
mistake in my translation? Maybe yes, since "C is a
machine-oriented programming language" doesn't mean, machines will
do programs in C.
(BTW, said this, when somebody states, "REXX is the new C", it
could be understood as distinct critic that it once /was/ a
human-oriented programming language.)

> Pipeline stage options could use some more, optional, "fluff
> words," that would limit the need for external comments/documentation.

I'm not convinced. The designation of stages is (up to now)
derived from their function, for example 'juxtapose' -- but that
is not sufficing to describe _why_ it is needed at this spot of
the pipeline. "Fluffy stage names" will lead to fuzzy pipelines,
nobody can fathom, after few month not even the author. Even
inline comments are unable to give a 'big picture' about the used
method. You think, 'fluffy words" could cure this:

> /* setup a lasting lookup for XFN                                 */
> "ADDSTREAM both xfn"              /* add streams for in and out   */
> "ADDPIPE (end ?) *.out.xfn:",     /* link to output of this REXX  */
>  '!a:lookup w1 f3 master',        /* lookup in table              */
>  '! substr f4',                   /* return designation only      */
>  '!b:faninany',                   /* get unknown XF too           */
>  '!*.in.xfn:',                    /* feed back in to this REXX    */
>  '? < 71EXT FUNCTS',              /* read xFn list                */
>  '!a:',                           /* to LOOKUP                    */
>  '! fblock 2',                    /* separate LEX-ID and Fnc#     */
>  '! insert /00/',                 /* ensure unsigned conversion   */
>  '! spec pad 0 w1 x2d 1.3 r',     /* convert to dec               */
>  '! join /;/',                    /* string together              */
>  '! strip leading /0/',           /* not my idea                  */
>  '! insert /XFN{/',               /* mark as unknown external fn  */
>  '! insert /}/ after',            /* nice :D                      */
>  '!b:'                            /* to FANINANY                  */

In addition, I detest programming languages with a vast set of
keywords, which all do almost the same. I'd prefer less commands
but more options to modify its behaviour, like 'unique' with
first/last/multiple/pairwise/single.

Best,
M.

Attached another example you may translate to "Fluffish" if you
like to convince me.