RE: No Subroutines (was Re: Debugging many subprocedures)

 
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Morgan
> 
> To use your analogy.  Why would you want to continue to use a 
> rock to pound a nail when you've just been given a hammer?  
> Get that rock out of your toolbox.  It doesn't belong there.

You see, it's statements like the one above which baffle me. Paul, you're
suggesting that there is no place for subroutines now that subprocedures are
available to us. With all due respect, who are you to make that decision for
me? What do you know of my code base, computing environment, and project
requirements? 

I just finished converting a procedure in one of utility service programs to
use subroutines internally instead of other procedures, because it was the
only way I could improve performance to the point where it would meet spec.
By doing so, I was able to reduce the time for a single execution of that
procedure from 493000ms, to 3000ms. Those little milliseconds can really add
up after a while, and had become unacceptable for one particular type of job
which utilized said service program.

If some in our community had their way, I'm sure that subroutines would be
pulled from the langauge because they're so evil. Then I wouldn't have been
able to utilize this perfectly useful construct to my advantage. I hope the
irony that without the subroutine I would have indeed been forced to create
a monolith is not lost on those folks.

I completely understand someone evaluating a specific piece of code and
saying, "John, you know what, this routine would work better as a
subprocedure. Here's why...".  I don't understand how some have managed to
become so smart and all knowing that they should blindly issue decrees to
that effect.


Regards,

John Taylor