Real ILE" ( tangent from RPGIII compiler vs. Visual Basic) -- MIDRANGE-L

>> That's what the fellows who wrote the Programmer's Stone were getting
>> at.  You have a "mapper" thinking style.  You are presented with a
>> problem, and your mind finds it as simple as water flowing down a hill
>> to map the path to all the pieces needed to resolve the problem, and the
>> principles at deeper levels of abstraction which form the context for
>> that problem.  Packer minds don't flow that way.  They are like two
>> dimensional rats in a maze who can't see the cheese on the other side of
>> the wall and climb over.

This concept has been a part of object oriented languages for sometime and is a 
big part of the draw. You have a few people who build the classes and a lot of 
people who use them. 

Service programs and ILE have the same draw. You don't need to know how Unix 
API's work. You can just a copy of a service program that does IFS and use 
that. As long as the person who wrote the service program did their job well, 
you can just use it.  

What we don't have is the nice things like polymorphism or objects but what we 
do have is blazing performance on the AS/400. 

As to the Mapper and Packer. What you are saying my be true but there is 
another possibility. Maybe it is just the way you are taught in the beginning. 
The problem seems to be once you learn to program in a monolith way, it is very 
hard to break the habit. 

I had an ex-boss I tried to teach some of this to and he just could not get it. 
He was just to used to "I am here, just start typing" that would instinctively 
start doing it again. I have run into the same problem in trying to train 
others. 

I have read again and again that procedural programmers(structured programmers) 
have a very hard time going to object oriented languages. I had a hunch that 
was not true. My guess was that monolith programmers had a hard time going to 
object oriented and my own experience has pretty confirmed that to me. Objects 
are just another level to information hiding. If you have trained you mind to 
break problems down into pieces, objects just flow out. Not used to doing that 
kind of thinking and objects are a bitch. 

The same applies to ILE. Learning to think in an ILE way is huge jump for most 
people. I was talking to a women at Common years ago and she said "Why would 
anyone ever need a subprocedure? I can just start typing and put the code in 
where I need it!". Says it all.

Bottom line. If you want to be a mapper, train your mind to think that way. 
Read about software engineering principles and then try them See what works and 
what doesn't. I have always believed that when you are working on simple 
things, push yourself out. Try the new things and when you get to the hard 
stuff you have the experience. Most people do the opposite. Just bang out the 
simple stuff and try the hard stuff when they are in a big project. 

Since you are questioning, sounds like you a long way down the road. To learn, 
one only had to admit a lack of knowledge. Good luck.