assembly vs HLL

[Rob Warnock]

+---------------
| > AAAARGH!!!!!  One of the most common complaints I hear from those
| > who must maintain code is that the programmer had developed his own
| > personal language out of macros.  THIS DOESN'T MAKE CODE EASIER
| > TO MAINTAIN, IT MAKES IT FAR, FAR, HARDER.
| Case in point:  ever tried to work on the Bourne shell code?...
|                                 ...so what you get is a unique language.
| That's the problem with these sets of macros mentioned by >>: each one is a
| different language with different characteristics (and bugs)...
+---------------

Counter-point: When the set of macros is not a "personal language" but
a "project" or "application field" language, the use of macros can have
resounding POSITIVE benefits. The problem is private cryptic code, not the
use of macros per se. A readable external description of the meta-language
helps a lot, as does a clear and consistent style of use.

Example: See the book, "The Macro Implementation of SNOBOL4", by Raplh Griswold
(Freeman 1972). SNOBOL came up fairly easily on many machines.

Example: At a similar time, Bill Waite's STAGE2 macro language was being used
to port a whole host of compilers and tools across machines, much like the
Software Tools in Ratfor today.

Example: Ratfor is "just" a set of macros, yet STUG lives!

Example: The FOCAL interpreters (of the MUMPS/JOSS traditions) were all
written in assembler using a few common macros for certain lexical-analysis
tasks. The same macro names and functions (and often routine names and tags
within routines) survived across many versions and across several machines:
PDP-8, PDP-11, PDP-10. Since the STYLE was the same, any FOCAL maintainer
could pick up another version of FOCAL and understand it clearly, EVEN IF
THE ASSEMBLY LANGUAGE WAS UNFAMILIAR. ["Tip 'O The Hat" to Richie Lary!]


The point is, the undisciplined random use of ANYTHING can produce garbage
which is hard to maintain. Conversely, a little clear thinking about the
problem, combined with the sparing use of powerful tools, can simplify things.
The main simplifying tool we have to work with is "abstraction", allowing us
to "chunk" things into manageable sizes. Macros are a way to create abstract
instructions. Our abstractions can be useful, or they can be clumsy.

"Macros don't create confusion, people create confusion..."

...and clarify it.


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404