Re: The value of ILE

On Sun, Jul 20, 2014 at 4:50 AM, Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx> wrote:

John,

Just one question Would you write a program (1 member) for a single or only
a few statements?
As long as you are working with OPM only I'd expect you'll answer no.
Even though the statement is complex (for example nesting multiple
built-in-functions) you'll copy it or maybe you'll copy the few statements
into a subroutine.

Well, I think it's verging on silly to write a program for one (RPG)
statement, because then what's the benefit? (One SQL statement is of
course almost arbitrarily long and complicated.) But if you mean a
small, focused function that fits on one screen, sure, my answer is
absolutely yes. I do it often.

Another approach would be using copy members, even thought I'd expect you'll
not create and use a copy member for a single statement.
If something has to be changed, you need to find all occurrences, revise
them and recompile your programs.

I practically never use copy members.

Using the ILE concept you may split all your programs into reusable small
pieces (exported procedures), that are located in multiple service programs
according their functionality, i.e. you may group all string procedures
together, all date time procedures, all insert, update, read, delete
procedures for a single file/table etc.
What you need for exploiting the ILE concepts, is to learn thinking really
modular.
When we started with ILE, I thought we were modular, because all our
programs were split into multiple sub-programs.
Today I get tears into my eyes, if I remember what I interpreted as modular.

Birgitta, I know what you mean. Where I work, our codebase is
definitely not very modular, by any standard. We have many programs
that are several thousand lines long; at least one is something like
20,000 lines. And some of the large programs are not even organized
into subroutines; it's crazy.

Most of our procedures are really small (less than 50 statements with a few
exceptions) and almost all procedures can be called from outside.
In this way we are very flexible and can easily write and modify even very
complex programs.

50 statements! At the beginning of this response, you were limiting
me to "a single or very few" statements! ;)

But I get your point. I would like to add to what you're saying:
Learning good design is typically harder than learning ILE, or any
particular programming language. It usually takes a lot of
experience, because it's an art form.

You have to balance a lot of competing concerns. If your procedures
are too small, then the overhead of prototyping them is more than what
you would spend in just in-lining the code. If they are not general
enough, their reusability is limited, and you wind up writing more
procedures. If they are too general, they tend to grow larger and
grow too many parameters and become difficult to maintain (and in some
cases even difficult to use, because of so many parameters).

John Y.