× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Sat, Jan 19, 2019 at 4:25 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

My problems tend to be in the App Dev area. Thins like I need to do X (create a spreadsheet, send and email, query a web service, whatever) that is well suited c/o available libraries to being done in PHP/Python/Node/whatever and want to just invoke it on request from the RPG or CL that I'm running. Ideally I want to do that in a manner as close to simply calling a Service Program procedure as I can.

This is what I was actually trying to touch on when I said "Python is
the whole story" when people say something is easy to do in Python.
Buck and I have had lots of conversations about this, because he is
thinking in the same terms you are.

Python is not *particularly* well suited to being a "delegate the
exotic stuff to it" language. I mean, you can certainly use it like
that, and actually communicating via database or stream file is not an
unreasonable way to do that. Sure, it may seem like an "old batch
process" because you know the plumbing. But if it's fast *enough* then
does it really matter? Back in the day, it was pretty easy to write
Pascal or C code that compiled to something that ran, in very real
terms, quite slowly by today's standards. Python is a very, very slow
language, compared to, say, C or RPG. But Python today is
approximately as fast as C was on the equipment available to me when I
was starting out. (Python would have been impractically slow on that
hardware.) Are we going to be grossed out by the horrible inefficiency
of our browsers and smartphones (which often need hundreds of
megabytes of memory to do anything at all), just because we used to
write tight code that ran on our one-megabyte-or-less machine? Well,
OK, many of us *are* grossed out by that... but so much so that we
don't go ahead and use our browsers and smartphones anyway? (And maybe
even *enjoy* them, and at times *marvel* at them?)

So, if you want to dip your toes into Python application development,
while keeping the bulk of your RPG-centric code in place, then the
most *straightforward* thing to do is put up with a clunky-seeming
(but for many purposes, easily fast enough) interface. If you want to
best *leverage* Python, it's generally better to think of Python as
the main implementation language (replacing ALL of what you would
normally do with CL, RPG, and Java), and just delegate the performance
hot-spots to RPG.

Indeed, this is the standard model for Python in the rest of the
computing world: Do *everything* in Python, and if it performs well
enough, you're done. If it's too slow, do some profiling to find the
bottlenecks, and rewrite those in C, and call that from your Python
code. Obviously, for most midrangers, RPG will serve the role of "fast
compiled language" instead of C, if you have to write it yourself.
(The folks at IBM are rapidly making the most important C-implemented
packages for Python available via yum. Special kudos to Kevin Adler
for his efforts in this area.)

I fully appreciate that even people who love Python will usually have
a ton of existing, working, production RPG code that it certainly
doesn't make sense to throw away. We certainly have that situation at
my shop. So I (and apparently Jack) use clunky-but-effective means to
transfer information, and the customers are happy, so we're happy. And
of course I personally do most of my "green field" IBM i programming
in Python.

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.