I thought gmail had eaten my reply so I took some time to give you a more elaborate reaction. I am still sorry that you need to resort to ad-hominems but I would like to give you some facts. It is not only my undeniable love for Rexx (but I do program in anything that the job requires, even ABAP, well maybe not that anymore), but also for z/OS, and the facts are these:
Rexx has (on z/OS, at least) the following address environments: TSO MVS ISREDIT ISPEXEC ISPF Panel Rexx ISPF File Tailoring Skeleton Rexx CONSOLE LINK, LINKMVS, LINKPGM, ATTACH, ATTCHMVS, ATTCHPGM SYSCALL SDSF DSNREXX IPCS IRRXUTIL RACVAR Then there is: System Rexx Rexx/CICS and I even saw some NetView Rexx only last year. There are very many samples of how to use MQ, DB2, ICSF, DFDSS, VSAM (you told us that Rexx does not support VSAM but that is also plainly untrue, there are many ways to do that), variable record SAM. Someone starting on the platform with only Python in their repertoire would be lost. I fail to see how much computer science gimmickry (which I also enjoy, really, but on the Raspberry Pi and the macbook) that mostly is available in the latest releases of coming and going fad languages (you mentioned Swift as one - Swift I appreciate because of the Objective C integration as not to invalidate people’s code, and those clean OO concepts which make C++ seem overcomplicated) *compensates* for not having these interfaces to the platform. I worry for the platform when its originator deprecates it in an act of self-harm. Personally, I think that Linux is better done in Linux than in USS, at least in Linux on Z, which makes people happy while still running a solid platform. I also like the other languages you mention and I see the appeal of Lua as a macro language for gaming and LuaTeX. Still, numeric support is bad and Unicode support is worse. It does macro language worse than the original macro language, certainly on z/OS. For applications you don’t need those interfaces, but then I would like to see Elixir, and maybe Prolog and APL in open source versions, instead of all those small variations on C, C++, Java, JS - the aforementioned really bring something to the table. Unless a lot of work is done to make Python support the above list of interfaces, it is - in my view - plainly the wrong proposition for the platform. Maybe some good examples of how to use IRXSUBCM, SHVBLOCK, ENVBLOCK, EXECBLK and EVALBLOCK from Python would help in addressing these interfaces. You can interface Python using C routines to those (need examples), but I think that would needlessly complicate things, as opposed to the language that has syntax for that. So I stand by my original propositions, but after being called unprofessional, a luddite, red flagged and whatever after mentioning factual truths, I fear for the quality of the discussion here. To really modernize, lots of device specific code needs to be taken out to adapt to the current reality (DB2 did that some years ago and guess what, taking out the optimizations for non-existing disks made it faster), the strong points of the OS (LPA, LLA) need to be reinforced for newer software, TCP/IP within the boxes still needs to be a lot better, better scripting level tools like Pipelines (that know about the environment) need to be included (doesn’t IBM look at SHARE requirement anymore?), instead of building layers on top of it, like new filesystems added on top or equivalent scripting environments added that can do less than the existing ones. And there is always the danger of fighting the last war. best regards, René. > On 8 Jan 2022, at 07:49, David Crayford < > > Nobody is denying the value of that code. I wrote thousands of lines of REXX > code for system automation back in the 90s > > I just can’t find a use case for writing new REXX code today. Everything had > changed. > >> On 8 Jan 2022, at 19:40, René Jansen < >> >> Well I am explicitly not reacting on another round of namecalling. What is >> worrying to me is the denial of the value of all existing interfaces in the >> OS and infrastructure to the standard scripting language on the platform, >> making the ‘modernization’ effort a reduction to uss, which will be hated by >> everybody used to Linux. But if the reaction consists of ‘unprofessional’, >> I’m done. >> >> >>> On 8 Jan 2022, at 05:43, David Crayford < >>> >>> Why not compile lua to support utf8? >>> >>> Your unrelenting love of REXX worries me. it’s the perfect example of >>> personal preference over a functional requirement which is unprofessional >>> and a red flag. >>> >>>>> On 8 Jan 2022, at 14:57, René Jansen < >>>> >>>> I looked at your list and I am happy to see that these include the things >>>> you find important. JS is undeniably a big factor but “the good parts” is >>>> a thin booklet. As is groovy - slow and nevery had any appeal to me, just >>>> looks messy. I quite like Ruby as an idea but slow as molasses. >>>> >>>> Today I looked at Lua, and although quite elegant, small and snappy, I am >>>> really disappointed that this is one of those languages that gives you >>>> wrong answers for numeric problems and having unicode support in a utf8 >>>> library that is different from the string functions - that is just funny. >>>> I am not implying that all Rexx implementations shine in this regard, but >>>> that is just neglect. NetRexx does, however, as it does in unlimited >>>> decimal precision arithmetic. >>>> >>>> Of course NetRexx can use the Java stream API for functional programming. >>>> That remark is just as odd as ‘it only has one type’. The fact that it is >>>> from 1995 and can use features that only appeared in Java 8 - personally I >>>> find that telling about the quality of the design. But I am not telling >>>> you that you need to like it - like the way we are told that we now need >>>> to like Python more than Rexx, while it cannot do what we need to do - for >>>> all the wrong reasons. >>>> >>>> Looking at your list of requirements I think Scheme had it quite covered. >>>> Some of them are gimmicky and some seem useful. None of them address the >>>> core qualities of the mainframe, which are Channels, packed decimal, DB2, >>>> CICS and COBOL (as long as you forbid dynamic memory). >>>> >>>> I think the discussion has strayed too much from what sparked it, which is >>>> a hitpiece with 8 untruths about Python and Rexx. Yes we like all >>>> languages to be available, and well maintained on z/OS. Please provide >>>> interfaces and precompilers for the main infrastructure. It is remarkably >>>> odd that IBM does not invest in the things that made the platform what it >>>> is, but it is not my problem. If the message is that the mainframe now can >>>> run the same software as the Raspberry Pi or your generic AWS instance, so >>>> be it. >>>> >>>> I think you will find that other people are emotionally attached to their >>>> tools and programming languages, it is a human thing. Also, I found that >>>> not all people can easily switch between a large number of ever-changing >>>> programming languages; which is meant as a compliment to you; but >>>> nevertheless very true. >>>> >>>> So I thank you all for a very interesting discussion. >>>> >>>> Best regards, >>>> >>>> René. >>>> >>>>>> On 7 Jan 2022, at 20:53, David Crayford < >>>>> >>>>> I could go on. Even Java supports functional programming since Java 1.8 >>>>> and which introduced the streams API. It's unusual to see and old school >>>>> loop in modern Java code. Even C++ has lambda's. >>>>> >>>>> I missed "closures" on my list which code hand in hand with "functions as >>>>> first class objects". Very powerful, for example in Kotlin you can easily >>>>> create type safe builders (DSLs) >>>>> That's why I have absolutely no interest in NetRexx. I have far better >>>>> options on the JVM. I don't get emotionally attached to programming >>>>> languages. If a better one becomes available I will quite happily switch >>>>> as I have done >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
