Post by Dave FrobleI will admit, I've never cared for "clever programmers". Too many times
their "clever" turns out to be a problem.
What you are seeing is code written by professionals. Not perfect,
but perhaps necessary given the need to provide tools to the
customer that (a) meet the specifications and (b) give the
_customer_ the least risk of shooting himself in the foot.
Yes, these are clever people. But the job demands this.
Post by Dave FrobleComputers are not clever. They are fast. Give them simple
instructions, and they will blaze through them. Give them "clever" and
they can get confused.
The computers will of course do as they are told.
If the person coding the macro is not clever enough to do it
right, then he's outsmarting himself. Or just "showing off."
Post by Dave FrobleI've also noticed that "clever programmers" all too often avoid the use
of comments. What use do such as they have for mere comments.
Different issue. But in the punched card days, comments
inserted up front might deviate significantly from the
final reality at the time coding and debugging is completed,
and heaven help you after a number of people have touched
the code to repair and improve it. Some have hoped for
so-called self-documenting code (Cobol had that goal), but
of course it was mostly an illusion that writing out
A = B * C in a natural language form might really improve
things.
Nowadays, when bits are cheap, we may actually go back
and pull out the flawed comments and insert appropriate
ones. Maybe. But some don't.
Post by Dave FrobleOk, I've used macros. But not clever macros.
Every time you use a system service macro you invoke
some rather clever macro code that has, over the years,
been very effective at getting the job done while
staying out of the customer's way.
I will mention that in a sense a macro itself is a sort
of optimizer. If you wrote the same code as a general-
purpose subroutine, it would have to have conditionals
to handle all the cases the customer might throw at it,
and that would be duly compiled and would result in
perhaps a significant amount of code that would not be
needed, while some of the code that would be used would
be extraneous in that the customer's invocation of it
would always be taking the same path through the
conditionals.
Macros tend to be designed to generate only the code
that is needed for the supplied arguments. The
conditionals for excluding code are assembly time
only and are not present at all in the object code.
Not that the macro actually generates optimal code -
generally you only put limited effort into achieving
that end - but it generates code that is appropriate
to the specifics of the invocation.
Pardon the rant, but the first programming language
I learned was IBM 1440 Autocoder (assembler), and
I was amazed, first, that there might be computers
that could neither multiply nor divide, and, second,
that there were such things as multiply macros,
with a dozen or more arguments and a penchant for
generating pages of code to perform the necessary
decimal shifts and adds while making adjustmens for
implied decimal points and rounding and who knows
what else. And if multiply was difficult, divide
was of course another level more convoluted than
that.
George
Post by Dave Froble--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486