On 8/07/2022 7:43 pm, Rony G. Flatscher wrote:
On 08.07.2022 03:38, David Crayford wrote:
On 7/07/2022 7:53 pm, Rony G. Flatscher wrote:
When I select a language for a job, one of the things that I look
at is the ecosystem. I prefer ooRexx to Perl, but I find myself using
Perl for some tasks because CPAN is an awesome resource. Python may
not be the best language for the task at hand, but it pays to check
what packages are available.
Indeed Perl and Python have a great wealth of libraries available to
them.
There is one ecosystem that beats Perl, Python and practically any
others: Java
According to http://www.modulecounts.com/ which shows the number of
unique packages
Methodology: "... Data is collected /by scraping the relevant websites
/once a day via a cron job and then stored in a Postgresql database
for later retrieval. Growth rates are calculated by averaging data
over the last week. I'm gathering counts of separate modules, so
multiple versions of the same module/package/gem only count once
(foo-1.2, foo-1.3 and bar-1.0 would count as 2 total). ..."
Questioning the methodology, completeness, correctness and as a result
the relevance. Did not find any checkbox for Java there hence
wondering where your Java figures come from.
It gets the Java figures from Maven Central
https://search.maven.org/stats. There is no denying that Java has an
gigantic eco-system. And a hell of a lot of it is top notch. The product
I'm currently working on wouldn't exist without Java open source.
Node.js 2019534
Java 483102
Python 386118
Perl 18354
So the undisputed winner as far as ecosystem is JavaScript.
This may be more an indication that there are many shortcomings and
many packages by different authors that try to make the same needed
functionalities available.
... cut ...
Ad Java: JRE comes already with a wealth of packages on board that are
add-ons in other languages.
The gripe I have is that what comes with the JRE is typically not as
good as open source. For example, JDK 11 finally included a half decent
HttpClient but it doesn't support anyway near the feature set of open
source clients such as OkHttp or Jetty
https://www.mocklab.io/blog/which-java-http-client-should-i-use-in-2020/.
To my knowledge there is still no support for JSON or Yaml even in JDK 18.
In addition, almost all important business applications have Java APIs
such that one can regard such applications as additional Java packages
(e.g. OpenOffice/LibreOffice mainly implemented in C++ gained Java
APIs and the ability to implement modules in Java; one result is the
creation of a Java scripting framework for OpenOffice/LibreOffice
which allows any language for which a javax.script implementation
exists to be used as a scripting and macro language; one example for
this comes with BSF4ooRexx).
Or think of the JDBC packages of the different database vendors, or ...
I just downloaded vsam.js to process a VSAM data set in Node on z/OS
and it works well. IBM are certainly giving
Node more love then REXX which will never officially support VSAM.
Indeed this is strange that IBM does not support REXX the same as
other technologies.
IBM also provide a VSAM I/O module for Go
https://github.com/ibmruntimes/go-recordio.
Has that possibly to do (wild guess) that the developers do not know
how to create REXX APIs on the mainframe? As probably C++ has a role
here, then probably CMake based ooRexx 5 with its C++ APIs would make
the creation of external ooRexx function libraries quite simple on the
mainframe as well (judging from the existence of "z/OS XL C/C++
Library Reference SA22-7821" and "z/OS XL C/C++ Programming Guide
SC09-4765").
The REXX programming services on z/OS are built for assembler. Bridging
to C/C++ can be done. I have code to do that but it's tricky. Porting
ooRexx to z/OS is very difficult. I actually managed to build it around
2008. If you look in the oorexx-devel archives you will se conversations
between myself and Rick McGuire. There is a lot of weird pthread stuff
intertwined with message passing that made it unsuitable for running in
an ISPF environment. I put it in the too-hard basket and a a couple of
years later discovered Lua which was simple to port and unbelievably
effecient. Several orders of magnitude faster than TSO REXX.
But then, if ooRexx and BSF4ooRexx were there (and they are available
in the Linux subsystem), then one can use ooRexx to exploit
com.ibm.jzos.ZFile (there seem to be samples on the Internet that
demonstrate using it
<https://www.ibm.com/docs/en/sdk-java-technology/7?topic=SSYKE2_7.0.0/com.ibm.java.zsecurity.api.70.doc/com.ibm.jzos/com/ibm/jzos/sample/vsam/file/package-summary.html>).
The first requirement from users on this list would be to run ooRexx
from TSO. The vast majority of z/OS folks don't know how to use a shell.
I was speaking to one of our ported tools devs a couple of weeks ago and
he told me that a lot of folks are invoke our Git port from TSO using
bpxwunix() in REXX. This is a dangerously close to undefined behavior.
Git needs to be run using Rockets bash for file encoding conversion to
work predictably.
---rony
----------------------------------------------------------------------
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
