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