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

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.

> As you black boxing, now you're adding overhead to your program for
> copying things into and out of common variables.  That is, of course,
> unless you're using reference variables, which makes the procedure that
> much less flexible.  Picture this procedure: ClearScreen.  You could let
> it work on the global screen variables, or else pass in every field from
> the screen to be cleared.  Which is "better"?

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.

> 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.

> 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.

david