× 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.



Simon wrote:
>>This is the "dynamic array" issue.  As I've said before, handling
>>undetermined quantities of data is probably better handled in the
>>database, and not within program code.
>
>Ahh, but you might not writing a database program.  In my case I need this
>sort of dynamic array support when I can not afford the cost of the I/O.
>It is much quicker to scan main storage than DASD and a based array is
>faster than any sort of messing with SETOBJACC.  Who among you uses based
>arrays, dynamic storage, qsort() and bsearch()?  They certainly don't
>feature in all my programs but sometimes they are a godsend and we
>couldn't do it without pointers.

But, if you're doing a largely compute-bound program, you're
basically in the realm of "systems programming".  (I know that's
a bit of a simplification.)  Systems programming is best done
with a systems programming language, such as C.  RPG is better
suited to applications, which are generally I/O bound.  It all
falls back to using the right tool for the job.

On the other hand, if that particular program is part of a
larger I/O bound application, then what't the advantage to
low-level coding to improve performance?  And aren't all
applications on the iSeries somehow involved with a database?
Ultimately, all applications involve I/O of some sort, since
heavy use of memory will generally involve paging.

>>(I like how undetermined quantities of data are handled in other
>>languages like Python, Rexx, Perl, and Ruby.  Varying sized lists
>>and hash tables are fundamental data structures in these languages.
>>But then, these have the advantage of being interpreted, not
>>compiled languages.)
>
>Yes, I'd like these sorts of things in RPG too.  However, dynamic lists,
>hash tables, stacks, queues, and sundry other things can all be
>implemented once you have access to pointer support and dynamic storage.
>The internal workings, ugliness, and dangerous code can all be
>encapsulated in procedures and hidden behind a nice, friendly interface.

As I said, languages like Perl, Rexx, Python, and Ruby can have
nice structures like dynamic lists and dictionaries (hashes)
because they are interpreted, not compiled.  If these were
added to RPG, it would be equivalent to adding a complete
run-time environment equivalent to what those interpreters have,
which would also mean performance equivalent to interpreted
programs.  (That's not necessarily a bad thing, especially if
you're in an I/O bound environment.)

>...
>>Function pointers are a different issue from the current
>>discussion that involves basing pointers.  If you're looking
>>at a lot of "call-back" functions in your application, you
>>probably should be using an object-oriented language instead.
>
>Yes, but since true OO requires a significant investment on the part of
>the programmer, callbacks are a useful mechanism to "embrace and extend".
>They are also language independent which OO is most certainly not.  Again
>they are not commonly required but very useful none-the-less.  Who among
>you have implemented callbacks for some of your procedures?  Who among you
>have written the callbacks required by qsort() and bsearch()?

Well, I for one have implemented call-back functions within
the RPG IV compiler.  Actually, I think I'm the only one who
has done that here!  They are handy sometimes.  My point is
that if you're thinking in that style generally, you may well
be more comfortable in an OO environment.

Regarding your statement "true OO requires a significant
investment on the part of the programmer", in some ways
you're correct.  But in other ways not.  True, languages
like C++ and Java are not easy to learn.  (I know from my own
experience that OO cannot be learned from a Borland C++
manual!)

But I believe that a person can understand the elements of
OO if (and this is a big IF) they approach it properly.  I
believe that languages like C++ and Java give the unfair
impression that OO has to be difficult.  IF your first
language is something like Python (or Object REXX), I do
believe that OO can be easily learned.  On the other hand,
if you've had some exposure to C++ or Java, you may well be
tainted, and the learning will still be difficult.

>Much of this falls into the serious pointyhead programmer arena but it
>would be interesting to know how many of us:
>>
>          a) Understand and use this stuff when required
>          b) Have heard of it and would like to try it out
>          c) Have heard of it and wouldn't go anywhere near it
>          d) Have no idea what I'm talking about :)

Interesting questions.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.