RE: "Real ILE"

Comments in-line:>      

That's where it seems to get difficult.  I may write a procedure to
update a file, for example, and it occurs to me that this same kind of
update might happen in more than one application, so maybe I should put
it in a service program or something.  But then, I can't really forsee
the specific needs of the "future" application which doesn't really
exist yet, so I don't know how to make the procedure "generic" enough to
avoid having to write a slightly modified copy of the same thing later,
which would seem to defeat the purpose.
> This is why we only put the field level update logic for all fields in the
PF with a pop up window that tells the user what data changed that they also
changed.  The module returns a Boolean - 0 = successful and 1 = error, file
not updated.

Another difficulty is the fact that we probably have several
applications out there already which could benefit from the procedure.
Is there value in rewriting all of those to use it ?
> Well that depends on how often the code might change.  If you are making a
change to some business logic that is used in multiple areas, make it a
module or service program and change all the programs to use it.  New stuff
I would make modular.  Now a new program using the same as an existing, I
would still make modular but I would not go back and change the working
programs if there is no change to the code.  But I would note the new module
in comments in the source so next time changes are made to the program, you
can incorporate the new module. 

Our manager had our PC guys give us a two hour run-down on OO and .Net
one day, and they talked about classes where you could have a parent
class and child classes which inherit everything from the parent, but
can have modifications of their own.  I don't know if ILE has a
counterpart to that.  It sounds cool, but then it also sounds like
something that needs some serious organization to keep track of.
> yes it does take serious organization.  We have a folder to document all
of our modules and service programs that the programmers must read and
update.

I keep wanting to keep things simple by putting them all in one program.
One of the things I like best about /free is the way it simplifies using
QCMDEXC.  Now I can write the whole string out instead of having to
concatenate a bunch of constants together, so I'm more likely to use it,
where in the past I would have called a CL to execute commands.
>But when you need to change some code, you have to remember everywhere you
put it and update multiple programs.  If it is in a service program, update
that and you are done provided there are no parameter changes.

But I get the impression that my preference for being able to read a
program like a novel runs counter to the way object oriented programming
works.  It's just a little difficult to see how all this re-usability
really works out in the real world.  I can understand it in terms of
little utilities like date converters and such, but we were doing that
in RPGIII by calling the utility program and passing parms.
> Those are the first object to put into service programs.  When you call a
program, you have to resolve to the object to get the pointer every call
while the pointer is resolved at compile time, not run time.  More efficient
use of the system. 

Maybe I would see it more clearly in the context of real application
design.  Our shop, like most I expect, uses third party software
(written in synon produced RPGII code), and our job is to write
interfaces, reports, and workarounds to make it function for our
business needs.  That's part of where my earlier comment about "real
programming" comes from.  It seems like "programmer" is a relative term
that describes a very wide variety of different skill levels.  Applying
that term to myself seems like calling the local handyman a "builder" or
worse, an "architect".  
> Agreed.

There's a pretty good, though somewhat bizarre, discussion of some of
these concepts in a strange work called the Programmer's Stone, which
can be found at http://www.reciprocality.org/Reciprocality/r0/.  The
crux of it is a discussion of thinking styles, where "mappers" are the
visionary types who can see the big picture and understand why things
need to be the way they need to be, and "packers", who tend to memorize
lists and see things in a linear fasion, step 1 leading to step 2, with
no concept of what step 5 might be like until step 4 is reached.  

I think one needs a pretty strong "mapper" mentality to do good
programming, especially good programming design.  But I also think our
world is so immersed in information technology that a place must be
found for the packers as well.  Ideally, all programmers would be
mappers, but I think that the best which can be achieved is for every
shop to try to find one or two good mappers to do the design, and lots
of packers to implement it.