On Tue, May 1, 2012 at 1:29 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
And any more discussion should be on the
COBOL list or "He who must be obeyed" will
descend upon our heads.
Too late! He has descended. (Perhaps with propagation lag, it was inevitable.)
But I think this list (midrange, rather than RPG or COBOL) was
probably chosen because the question kind of spans languages (as
language questions so often do). My response is explicitly bilingual,
though, so hopefully will be granted some tolerance. (And I'm not
subscribed to the COBOL list.)
Jon Paris also writes:
Why not? Most seem happy to just use a CALL
interface and the IBM i COBOL supports return values.
Before ILE, this was more-or-less the way to do things in RPG. And,
I'm sure we all know this, but plenty of RPG programmers still do
things this way. Not saying it's the best way, but it still works for
a lot of folks. And if there is a language that is even more
traditional and even more culturally tied to the past than RPG, it's
COBOL.
Joel Stone earlier wrote:
In RPG and all other modern widely-used languages,
user-defined functions are the cornerstone of what
makes the language popular and powerful
Not sure I agree with RPG being lumped with "widely used" languages,
but OK, let's go with it. To me, the cornerstone of RPG's power and
popularity is its strong integration with the native IBM i database,
not its "user-defined functions" (I'll assume you mean prototyped
procedures).
Even if ILE had never been introduced, and procedures were never
possible in RPG, it would *still* be approximately as popular today.
Why? Because it would *still* be the best way to do native
record-level access on the i.
And you could make the language much, much more powerful without
adding prototyped procedures or modules or any of that. For example,
you could add much richer data structures (dynamically sized arrays,
associative arrays, and arbitrarily dimensioned/nested arrays come to
mind; and yes, I know you can achieve these to some degree in RPG
today, but they are either cumbersome or they are bolt-on modules
written by other folks with more time and patience).
So, while it does seem quaint that (IBM) COBOL doesn't have
"user-defined functions", it also doesn't seem like much of a pain
point for COBOL users.
John
midrange.com
