> They miss discovering that REXX is the most > powerful procedural language, bar none.
I think that crown goes to Python now. I've been doing the annual Advent of Code (https://adventofcode.com/) since 2019. I did the first two years in Regina REXX, then switched to Python. I used Python 2 in 2021 with no IDE, Python 3 with VS Code in 2022 & 2023. I had 30 years of experience in REXX at that point, but still was more productive in Python -- with ZERO years of experience. My first Python program was the day 5 AoC program in 2021. The main reason is that REXX only has 2 data structures: lists of words, and stems. So you're in "if the only tool you have is a hammer, all problems look like nails" territory. It is like coding using a Turing machine: while it is technically *possible* to create any algorithm, it is a lot more work than if you had a language with data structures that directly model your business data structures. z/OS REXX makes this even harder, because you can't iterate over a stem. So now you have to either use just lists of words, or create *two* structures: a stem to hold the data, and another stem or list to index it sequentially. Nor is there a built-in way to sort stems. Or search them for a value. Or join them. And so on. And I know from the AoC puzzles that very long lists of words will really bog down the performance. I'd like to see Python as a first-party scripting language on the MVS side of z/OS, equal in support to REXX. What I mean is, anywhere you can use REXX, you could use Python instead. In particular, as ISPF function code. (You'd be limited to 8 character variable names, just like you're limited in REXX.) -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Hobart Spitz Sent: Monday, July 1, 2024 3:02 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 [Some people who received this message don't often get email from 00000688ad44c805-dmarc-requ...@listserv.ua.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
