I submit that there is something else to consider. People tend to approach any new language thinking in terms of the language that they were most skilled in previously. Because REXX is so flexible, there is little need to learn some of the unique features of REXX. Some people never take off their "training wheels". They miss discovering that REXX is the most powerful procedural language, bar none. To cite some examples that I have observed:..
- Stems are multi-key tables, not arrays. - Internal routines are almost always faster than repetitive code. The less code, the less tokenization phase overhead. Internal routines let you write more general code, and you might hesitate to deal with an unlikely case where something has to be changed in 30 (e.g.) places. - The procedure statement and stems can be performance tools. Each has a structure separate from the simple marin variable pool. Variable searches focus on smaller numbers of targets than if all were in a single pool. - EXECIO 1 is a dog. - Algorithm efficiency matters, more so in REXX than in other languages. A recursive Fibonacci function of 100 might take hours or days depending on the platform. If you save intermediate results in a global stem, Fib(100) takes seconds or less, only slightly longer than the loop method. - Typing and sizing are non-issues in REXX. How often has a compiled language program needed to be updated because a field length changed or a table overflowed? Whatever you do in any other procedural language can be done more easily and with less down the line maintenance in REXX. I could go on. OREXXMan Q: What do you call the residence of the ungulate with the largest antlers? A: A moose pad. :-D Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Mon, Jul 1, 2024 at 1:58 PM Seymour J Metz <sme...@gmu.edu> wrote: > probably means here files; inline with the source code. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Phil Smith III <li...@akphs.com> > Sent: Monday, July 1, 2024 2:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank > you! (Re: z/OS 3.1 Enhancements & Support News > > Paul Gilmartin wrote: > >Lack of closure: I don't believe a function package, much less a > >command environment can be coded in REXX. those must be coded in > >another language, therefore less portable. > > Well, that's a good point. OORexx makes that somewhat better, but not like > P/P. But I could imagine writing an interface to enable this. The tricky > part with Classic Rexx would be variable passing, but Pipes demonstrates > that it's quite doable. I think it'd be easier with OORexx, no? > > >I've written some utility packages which I concatenate with > >SYSIN, REPRO to a temporary member, and execute that. > >Ugh! > > You mean so you have your program + "standard" functions, glue 'em > together, and thus the standard functions are local and can access > variables easily? Cool. Can't quite imagine doing that on CMS! > > >Lack of support for instream data. > > Not sure what you mean here--is it that it's not native/trivial to read > from a DD * in Rexx? > > >Lack of elementary functions, made a challenge by the > >desire to support arbitrary precision. (Can a function > >package, in whatever language determine the caller's > >NUMERIC settings at the instant of call?) > > No, though I've never wanted that. Not saying it's not a valid > requirement: had the Rexx ecosystem developed more, stuff like this would > have become necessary and presumably been enabled. > > This is a fun discussion. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
