Subprocedures are a great example. They do everything that subroutines
do, plus offer a heck of a lot of value over subroutines. Yet people
insist on still using subroutines because "if it ain't broke, don't fix
it". That's BS. You'll never learn the value of something if you don't
try it. Just like a kid who won't try a new food -- he doesn't know he
doesn't like it... he just won't try it because it's different.
Let me preface by saying that I agree with Scott in terms of goals and I
agree with almost all that he said in the message from which this quote is
extracted.
I suspect (hope) that Scott was referring to new development or new
functionality here. Certainly, if a new "function" is needed in a program,
go after the procedure approach instead of subroutines. But I would caution
that the CONVERSION from subroutines to procedures cannot always be taken
lightly, especially when you start to use some of the key advantages of
procedures, like localized data. Too many times I have seen subroutines
that perform some function, and while they're there they'll inconspicuously
set some esoteric variable (often with a great name like @ or $ or some such
- say the result of a %LOOKUP), and the rest of the program is supposed to
understand that @ has been set in subroutine XYZ. (I don't condone this
sort of weak association, but we have to recognize that it exists.) Now if
you take XYZ and convert it to a procedure, and unwittingly make @ a local
variable, the program stops working. If a lot of maintenance has been done,
it may take quite a bit of debugging to figure out what has gone wrong,
especially if you also took this opportunity to give @ a better name.
But as Scott said, the result is definitely worth while, and what you learn
will benefit YOU as much as or more than it will benefit someone else.
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
Nothing is foolproof to a sufficiently talented fool.
midrange.com
