RE: Assembly programmers do it a byte at a time

True;

But even if there was no performance difference between a procedure and a
subroutine I would still use subroutines to segment logic within the
procedure which does not require the attributes of a procedure.

Use the appropriate tool for the appropriate job, IMHO a procedure is a
sledge hammer, and a subroutine is a finish hammer, which you use depends on
the job: breaking up concrete or putting up molding.  

Duane Christen

-----Original Message-----
From: Bob Cozzi [mailto:cozzi@xxxxxxxxx]
Sent: Friday, June 24, 2005 9:23 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Assembly programmers do it a byte at a time


What C (on the 400) is missing is an INLINE compiler feature, as is RPG IV.
This would probably solve the subroutine vs subprocedure performance
disparity. 

-Bob Cozzi
www.RPGxTools.com
If everything is under control, you are going too slow.
- Mario Andretti


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Christen, Duane J.
Sent: Friday, June 24, 2005 8:21 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Assembly programmers do it a byte at a time

Alan;


I have coded C for 30+ years and to me what C needs but does not have is
subroutines. 

Subroutines are great for segmenting logic, like you do with sql, within a
procedure. When logic needs to be segmented for readability,
maintainability, logic flow, and there is no need to export or partition
(recursively call, isolate variables etc...) the logic then why create a
procedure?

Every procedure I create contains at least two subroutines, initialize and
exitProcedure.

Duane Christen     

-----Original Message-----
From: Alan Campin [mailto:Alan.Campin@xxxxxxx]
Sent: Thursday, June 23, 2005 6:45 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Assembly programmers do it a byte at a time


>> You are mixing design principles. ILE and OO are not the same, ILE and
RPG IV 
>> are not the same (Vernon already stated that, rightly so), database
design and 
>> OO are not the same (Relational DB and Object DB are different concepts).
You 
>> do not need  OO principles to develop a programme; it is all based on 
>> functional decomposition or better: modularization. Subroutines are the
lowest 
>> forms of modularization, functions and (service) programmes are the
higher 
>> levels.

I apologize if I was not clear. My intent was not to say that they are all
somehow equal. What I was saying that they all grew out of the study of
better ways to do programming and out of that came certain software design
principles. 

If I am creating a database, I am going to want to use the principles of
normalization. If I don't, I have a mess. If I am writing a program, I am
going to want to use the principals of functional decomposition and
information hiding, otherwise I am going to have a mess. So and so forth. 

As far as subroutines being at some level of modularization, I see what you
are saying but I am uncomfortable with the idea that subroutines are part of
modularization. I still have to use them with embedded SQL rather than doing
/Free and /End-Free all over the place but other than that, subroutines
should be dead, dead, dead. They provide nothing that you really need to
write good code. When we had nothing else in RPG III, that was what you had
but did not let you do much of anything in software engineering. Makes me
shudder to remember the days of trying to write good code in subroutines.
Like living a long running nightmare.