Xref: utzoo comp.arch:4607 comp.lang.misc:1542
Path: utzoo!mnetor!uunet!husc6!mailrus!tut.cis.ohio-state.edu!osu-cis!att!att-ih!cuuxb!mmengel
From: mmengel@cuuxb.ATT.COM (~XT4103000~Marc Mengel~C25~G25~6184~)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Universal OS (was Re: Survey of
Message-ID: <1779@cuuxb.ATT.COM>
Date: 4 May 88 15:56:00 GMT
References: <2845@mmintl.UUCP> <1543@hubcap.UUCP> <768@l.cc.purdue.edu> <9545@agate.BERKELEY.EDU>
Reply-To: mmengel@cuuxb.UUCP (PUT YOUR NAME HERE)
Organization: AT&T, Data Systems Group, Lisle, IL
Lines: 40

In article <768@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
<We cannot do even a fair job if the job is done by those who have designed the
<present stuff.  We need people with imagination, who are aware _that we are
<essentially ignorant_, and who are willing and eager to ask for what is wanted.

...
<able to use notation which he considers easy to read, as long as that notation
<is not already coopted, and in some cases it might be necessary to change
<existing notation.  This is done in mathematics all the time, and does not
<lead to problems.

That sounds great, but the real problem with that sort of a solution
comes in the maintenance of a program.  In our imperfect world, most
of the cost of a software product is in maintenance, not initial 
development.  The people who do maintenance work are often not the 
same people who  wrote the product originally.  In this universe
(a.k.a. "The Real World") the real problem with extensible, cusotmizable
languages is that a person who does maintenance programming  must be 
constantly switching back and forth from one persons notation to another.
People also have a tendency to assume their notation is "obvious" and
therefore do not document it sufficiently.

When an important factor in the program you write is that other people 
have to be able to understand your code quickly; an extensible, customizable
language where the semantics associated with a given syntax are not
constant detracts from the  goal of having understandable code.  The
original author may be able to follow it more easily, but any other
poor soul who has to read the code may be hoplessly confused.

The C preprocessor already gives us a glimpse of the horrible things
that one can do with #defines by making things that look like
function calls that aren't.  When you extend that to every nook and
cranny of the language, it gets more and more confusing for people
to read who are not familiar with the "notation" chosen by the original
programmer.
-- 
 Marc Mengel	

 attmail!mmengel
 ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmengel