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 <[email protected]> wrote: > > 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 <[email protected]> wrote: >> >> 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 <[email protected]> wrote: >>> >>> 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) >>> https://kotlinlang.org/docs/type-safe-builders.html. >>> 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 [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
