Tom,
May I say that that is a well thought out and sensible retort all this
garbage being spouted, well done.
Steve
qsrvbas@xxxxxxxxxxxx
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
10/10/2007 02:11
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
To
rpg400-l@xxxxxxxxxxxx
cc
Subject
Re: will v6r1 RPG support main procedure recursion?
Steve Richter wrote:
7. Re: will v6r1 RPG support main procedure recursion? (Steve
Richter)
a GC makes the coding and usage of a procedure library much
easier. people post often that they use Java methods from RPG to
do things like create PDF documents or read from spreadsheet
files. RPG procedures and service programs are good. but
arguably not good enough because we have to use a GC language to
get the rich functionality we need.
Hmmm... "we [ have ] to use a GC language to get the rich
functionality we need"...
I disagree. I believe it should be worded "we [ choose ] to use a GC
language to get the rich functionality we need". And I believe that
the reasons for making that choice are based in the same kinds of
things that eventually allowed microcomputers to beat out mainframes
in the Computer Chess Championships.
It wasn't because micros were faster or had better facilities or
better programmers or better tools or better anything. In fact, they
had inferior elements at every single point except one. There were
just so damm many of them! They had become so pervasive and so
available to so many programmers that the various parts of a decent
chess program could be developed independently by _many_
contributors. As algorithms were tuned independently, the best of
each kind could be incorporated whenever possible. A kind of "open
source" environment simply brought things together. Published
papers, open code repositories, you name it.
The very same algorithms could be run on a mainframe or 'super
computer' and they would blow the microcomputers off the planet.
Yet, the development was really only possible because of the
'atmosphere' made possible by sheer numbers. There was no good
possibility that mainframers (at the time) would manage the mind-set
that brought it about. They tended to be isolated, individuals or
small groups at best.
Right now, we _choose_ to use a GC language for such things because
that's where the development of those things has been done. Sheer
volume. There simply aren't enough ILE RPG developers to contribute
to any similar effort. And when we create new functions in a
GC-language, it's often done because so many others have done
similar things before and provided lots of articles to light the
way. The ways to use the various Java (or whatever) classes have
been demonstrated publicly a thousand times.
We use GC-language PDF e-mailers, e.g., because they freely exist.
Not because they _can't_ be created totally in ILE RPG. If we put
effort into it, we could create replacements using nothing but ILE
RPG that would drastically out-perform what's available openly. But
there's no impelling reason to do it. We have work to do that pays
our salaries. Our employers assume that we're more valuable working
directly on our specific projects rather than on community projects,
and few of us have resources to do otherwise.
There aren't enough of us to contribute to something like the
WyattERP/openERP400 project to keep the list active, much less keep
it thriving and advancing. It's not because ILE RPG isn't suitable
for ERP while a GC-language would be. It's not because a GC ERP will
out-perform a RPG ERP under i5/OS.
We're a relatively small population. In any population of
developers, only a limited subset feel comfortable making their code
available to everyone. And fewer of those have the time to do it in
a meaningful volume. If we ever manage to work out some kind of
serious community repository of valuable service programs, the 'rich
functionality we need' will be supplied by us.
In short, we don't "have" to. It just tends to make sense to
"choose" to. We're not dumb. Common sense can sway decisions.
Tom Liotta
midrange.com
