While they'll pry my Rexx from my cold, dead hands and all that, it's hard not to see how powerful Python is. But they're also slightly differently targeted. Rexx was never meant to be a full-featured programming language: its target audience was more the casual, non-programmer user. As such, I'd submit that most of its failings are in the "but it wasn't ever SUPPOSED to do that" category.
Now, does Python manage to serve both audiences? I'm not sure. Forty years ago we had more casual, non-programmer users (or at least a higher percentage of them) who might want to script something--and we did not have GUIs and IDEs and IFTT and the like. And of course it was a command-line world. So Rexx was definitely the right tool for the time; Perl would have been a failure for that audience, even had it been universally available. (I always say I have angry Perl skills, because every time I have to use it, it pisses me off; OTOH I have mad Rexx skills after 40 years.) That's another apples/oranges aspect of things. Would I want to write editor macros in Python? Maybe. As Shmuel notes, ADDRESS or equivalent is critical. What would the alternative be in Python as it exists now? Some keyword in front of each system command, e.g.: TOXEDIT "locate /whatever/" TOCMS "ERASE SOME FILE A" ? I dunno, but I'd be interested to hear from folks with deeper Python understanding what would feel natural for that language! -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Schmitt, Michael Sent: Monday, July 1, 2024 4:35 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 > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
