> (also note that the language name has been mixed case for decades).

I try to follow local custom; here and in other IBM-related fora I use all 
caps; in wiki and other generic fora I use mixed case.

> Easily extendable: True. Rexx is too, but not that many folks have written 
> Rexx function packages.

I find the REXX documentation much clearer than the Per documentation. I 
haven't look at the Python documentation for writin functions in other 
languages.

> I'm not sure I'd prefer this to reading the code, 

Both have their place. External documentation generated from text and pragmata 
in the code can give a higher level view. Certainly the perldoc help data 
following __END__ are convenient.

> Overall, this is a nice cheerleading article,
> but could have benefited from a more skeptical editorial eye, methinks.

Some of the points are valid, but I agree about the tone.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [[email protected]] on behalf of 
Phil Smith III [[email protected]]
Sent: Sunday, December 19, 2021 12:56 PM
To: [email protected]
Subject: Re: Top 8 Reasons for using Python instead of REXX for z/OS

Interesting. Python is great; we use a ton of it. I'm happy that Guido's
original stupid (yes, I used that word) position that Python would never
support EBCDIC has been overridden. ("How important is z/OS? I'm very
skeptical of the viability of any OS that uses an encoding that is not a
superset of ASCII", and he apparently at one point also said Python 3 would
"never" support EBCDIC.)



I'm unconvinced that Python skills are more valuable on z/OS than Rexx, and
looking at the eight reasons individually, I have comments.



#1: "While REXX is easy to learn, it is not easy to find REXX programmers
outside of the z/OS world"-that's myopic. If you said "Outside of the IBM
world" it would be more true, but still, there is a lot of Rexx on other
platforms (also note that the language name has been mixed case for
decades).



#2: More readable? Maybe. But we've heard this about so many languages
before.and Rexx isn't exactly hard to read.



#3: Easily extendable: True. Rexx is too, but not that many folks have
written Rexx function packages. This is the same reason why Perl "won" over
Rexx: the community wrote the extensions, not that it was necessarily an
inherently superior language (Perl itself, without CPAN, is pretty clearly
not).



#4: Has more extensions-this is the same as the previous item: It is
extendable and people have extended it. This is cheating, repeating the same
reason.



#5: Security scanners: Quickly reviewing scanners for Python code, it looks
like most of them are focused on dependencies-packages that a Python
application might use that are themselves vulnerable. Which makes sense for
a scripting language. Still, this is a good thing, given that folks are
doing such things. Is this inherent to Python? Would it be harder with Rexx?
Not sure: if you use OpenSSL from Rexx, your scanner should find OpenSSL and
scan it, no?



#6: Bandwagon? Ummkay.



#7: Doc tools: Looks like these tools can produce basic reference doc
("function X requires three parameters of types Y and Z") and also extract
marked strings to include in that doc (Doxygen-type stuff). I'm not sure I'd
prefer this to reading the code, if the comments in the code were at the
same level as these tools require. In other words, if you're going to do it
right, I'd rather have one thing than two. I always prefer fewer parts to
keep in sync.



#8: Huh? People change jobs, so we need AI, and therefore Python? There's a
leap there that I cannot follow.



Overall, this is a nice cheerleading article, but could have benefited from
a more skeptical editorial eye, methinks.


----------------------------------------------------------------------
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

Reply via email to