Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!whuxlm!akgua!sdcsvax!sdcrdcf!hplabs!hao!nbires!opus!rcd
From: rcd@opus.UUCP (Dick Dunn)
Newsgroups: net.lang.c
Subject: Re: assembly vs HLL
Message-ID: <1051@opus.UUCP>
Date: Fri, 25-Jan-85 05:09:44 EST
Article-I.D.: opus.1051
Posted: Fri Jan 25 05:09:44 1985
Date-Received: Mon, 28-Jan-85 06:10:07 EST
References: <282@decwrl.UUCP>
Organization: NBI,Inc, Boulder CO
Lines: 21

> >	For the bare language, I might agree. However, any macro programmer
> >worth the name after a year or so will have developed a set of macros
> >that enable high level constructs but still allow precise control of
> >the machine. I personally have a set of macros that give me more
> 
> 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?  It helps to
know a little of the syntax of ALGOL 68.  Of course, not even the mighty
cpp can transform C into ALGOL 68, 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).  A compiler
is just a clever macro-processor for a specific set of macros, with the
macros usually optimized so that they're expanded by inline code instead of
interpretively.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Keep your day job 'til your night job pays.