Re: Assembly programmers do it a byte at a time

Thanks Paul, Charles, Joe, Alan, anyone else I forgot.

Sound like some good reading suggestions.  I'll start with the Wiki's,
on account of ease of accessibility and no-cost.  

I think Joe hit the nail somewhere near the head when he mentioned how
it's a business decision how far to take this stuff.

Part of what is driving my inquiry, is that our Director has actually
given myself and my manager an annual goal of implementing ILE standards
(or as he put it " a class library of reusable modules") in our shop, so
I'm trying to define what that really means for us.  Sounds like it will
likely come down to a project by project basis.  We'll just have to
learn as much as we can about how re-usable modules *can* be used on the
AS/400, then try to make good business choices on how to implement what
we've learned for each project.

Greg  
------------------------------

message: 3
date: Tue, 28 Jun 2005 10:36:08 -0400
from: "Paul Morgan" <pmorgan@xxxxxxxxxxxxxx>
subject: Re: Assembly programmers do it a byte at a time

Greg,

I think you're really trying to learn two types of programming.  The
first is to 'structured programming' - break the code down into pieces
and how do you organize those pieces.  The second is 'object oriented
programming' - structure your data as well as your code.  Structured
Programming is more 80's technology which Object-Oriented Programming is
more 90's technology. ILE deals more with structured programming but
OS400 does have objects so it's an odd mix of structured and object
oriented technology.  You can apply object oriented concepts to
structured programming so it's worth studying both even though ILE RPG
isn't an object oriented language.

Structured programming
(http://en.wikipedia.org/wiki/Structured_programming)
had a lot of different proponents back in the 80's - James Martin,
Edward Yourdon & Michael Jackson were authors I read.  I personally
liked Jackson's method for designing a program
(http://en.wikipedia.org/wiki/Jackson_Structured_Programming) because it
was a data oriented approach.  The program structure was derived from
the format of your data inputs and outputs.

Object-Oriented Programming
(http://en.wikipedia.org/wiki/Object-oriented_programming) goes further
than structured programming.  Instead of having a program that reads in
data, does something with it then spits out data/reports you have
objects which wrap the data with code.  Then you put the objects
together into systems. The concept of a program separate from the data
disappears.  Booch, Rumbaugh, and Meyer are all good authors on this
topic.

The Code Complete book already mentioned is more about Software
Engineering (http://en.wikipedia.org/wiki/Software_development).  You
can look a programming from three different points of view - a trade, an
art, or a profession.  Software Engineering is working towards turning
programming into a profession.  I.E. you must know x, y, z and follow
specific guidelines to be a Software Engineer.  Right now we're not sure
what x,y & z are so don't let someone masquerading as a Software
Engineer intimidate you.

There is another topic called Patterns with a different view on
designing systems.  Patterns are a way to describe how objects work
together to make a system.  They are techniques you can use to solve
more specific problems in a design.  They are sort of templates you use
to write your code.  The Design Patterns book
(http://en.wikipedia.org/wiki/Design_Patterns) by Gamma, et.al.
(nicknamed the Gang of Four) is the first and best book on patterns.  I
wouldn't recommend this book until you understand something about object
oriented programming.  Patterns might be the x,y & z of Software
Engineering.

You know more about object oriented programming than you might think.
You've been working on a successful object based (everything is object
oriented except there is no inheritance) operating system so a lot of
the concepts will be familiar.  You have a leg up on a mainframe, unix
or PC programmer trying to learn about object oriented technology.
Learning will never end so don't be concerned if you don't know
everything - you never will.

Paul