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

> From: David Gibbs
> 
> Joe Pluta wrote:
> > See, and this is where the danger lies... the nebulous "future".  I
> > could write everything as a procedure, or I could use a subroutine
and
> > with a few deft flicks of my programming wrist, convert the
subroutine
> > to a procedure when I need all those cool features.
> 
> I'd rather spend a few more seconds writing a procedure with the
> 'future' in mind, then write a subroutine without any consideration of
> the future ... and then have to convert the subroutine to a procedure
> later on.

This is the sort of thing that doesn't make any sense to me, David.
Adding extra overhead on a future event that may never happen is
overkill.  Just because I choose to use a subroutine doesn't mean I
didn't consider the future... it meant I did and I didn't think this
chunk of code wattanted the syntactical overhead.  This attitude that
subroutine are somehow bad programming is simply inappropriate to me.


> The fact that I *CAN* make a procedure a black box doesn't mean I have
> to.  Although I haven't thought about it in detail, in there most
basic
> form, a procedure can be used just about the same way a subroutine
can.
>  It's just a few extra lines of code.  Since the procedure is (at
least
> IMHO) inherently more flexible than a subroutine, the procedure is
better.

And adding extra lines of code to my program that do nothing is not
better, IMHO. 


> > Ah, so young <g>.  Just wait until the 73rd time a compile fails
because
> > you forgot the flinking prototype.  Or forgot to change the
prototype.
> 
> I pay attention to those kinds of details.

With a subroutine, I don't have to.  Trust me, forgetting a prototype is
not a function of competence (although it may indeed be somewhat related
to programming style).


> > You admit you're fairly new to procedures, so you may be finding
them
> > super wonderfully ultra cool because they're new to you, but trust
me,
> > some of the vagaries of the implementation (like those of any
language)
> > can get tedious.
> 
> I've been working with procedures for many years now ... and find them
> as useful now as I did when I started.

Sorry, I misread your post; you're getting to use /free.  Good luck,
it's actually quite fun, and the extra space makes the argument for
procedures a bit stronger.

And I didn't mean to be disrespectful!  Yesterday was a long day of
fighting with SQL Server and a VPN (I LOVE DB2/400, I truly do), so
perhaps my frustration carried into my message unintentionally.  If I
sounded condescending, I certainly apologize.

I just think that, having used procedures for a while, I can honestly
say that there are occasions where subroutines are useful.  You don't,
okay.  But I'm not going to agree that procedures are "better",
especially in the situation where you pass no parameter, use no internal
variables and return no value.  The extra six lines of code (prototype,
procedure begin and end, procedure interface and /free, /end-free) in
two places of the program are not warranted based on a possible future
need.

But that's just me.  As always, YMMV.

Joe