Re: RPG V? -- RPG400-L

On Jan 8, 2010, at 10:24 AM, Hans Boldt wrote:

But, at that time, the concensus was that there weren't really any
significant advantages to making other specs fully free-form, and that
other enhancements took priority. That's probably still true today. I
think RPG still needs some work in certain areas, such as namespace
support, an IBM-supplied procedure library, and externally described

procedures.

I tend to agree with you Hans - but not for the same reasons. Like others I don't agree with your "window of opportunity" argument. V5 was too late for free-form on that basis - but we got it and it has helped in bringing younger programmers to the language.

There is some virtue in free-form D-specs - but in training non-RPGers (i.e. PHP and Java coders mostly) to use RPG IV I have never found this to be a barrier. The first "style" thing you're taught about data definition in most any language is to keep it tidy and line things up - the D-specs do that for you and the youngsters we have trained recognize that. They just get a bit ansi when they are forced to use ellipses when trying to indent names and they hit the 14 character area limit. The alternatives based on CL style syntax with the resulting typing (and in my case mis-typing) has always been one of the things about CL that I disliked - makes it almost as bad as COBOL.

More to the point, as you say, there are other things that are much more important. Namespaces and externally described procedures I agree with. There's also the silly stuff like getting rid of the /Free and / End-Free requirement. That needs nothing more than a change in the compiler's internal rules - it is really not needed at all even now since checking for blanks in 6 and 7 could do all that is needed. The current requirement is one of the most frustrating things for those new to subprocedures and /Free and drives Java and PHP programmers nuts.

The F-spec may get something of a re-vamp when the "Open I/O" (or whatever it ends up being called) comes out hopefully in 7.1 - it isn't essential - but why not tweak it while you're at it. Once the basics of "Open I/O" are in place then I suspect a lot of attention will be given to enhancing it in future releases.

Steve's desire for pre-compiler changes is probably too late - that window of opportunity was definitely missed as far as SQL was concerned. But some notion of opening the language to permit it to be extended by others has always interested me. It wasn't possible with the old compilers - but with today's Service Program procedure based model it becomes a far more practical possibility. "Open I/O" is a beginning - I suspect that how much further we go may well depend on how well adopted that feature is.

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com