Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!clyde!burl!codas!usfvax2!pdn!alan
From: alan@pdn.UUCP (Alan Lovejoy)
Newsgroups: comp.lang.misc,comp.software-eng
Subject: Re: Software Technology is NOT Primitive
Message-ID: <1706@pdn.UUCP>
Date: Tue, 3-Nov-87 01:53:16 EST
Article-I.D.: pdn.1706
Posted: Tue Nov  3 01:53:16 1987
Date-Received: Sat, 7-Nov-87 10:35:53 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <3603@sol.ARPA> <596@l.cc.purdue.edu>
Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy)
Organization: Paradyne Corporation, Largo, Florida
Lines: 49
Xref: mnetor comp.lang.misc:860 comp.software-eng:60

I detect a basic philosophical disagreement over the purpose of an HLL
in this discussion.  Is an HLL meant as an abstraction that provides a
standard, portable paradigm of computation, or should it be a set of
abstraction mechanisms, or should it be both?

An HLL which is just a set of abstraction mechanisms would be based upon
the machine language and programming model of some cpu, and would rely
upon the programmer to define his own abstractions, including
information hiding, type checking, operator/procedure overloading,
inheritance/subclassing, and parameterized data and process
abstractions.  Macro assemblers are a rather primitive example of this
type of language, Forth is another (slightly more advanced, but not a
pure example).  The idea has a certain stunning simplicity, but no one
has ever actually implemented anything like this that really matches
the ideal.

Most HLL's present the programmer with an invariant, take-it-or-leave-it
computational paradigm.  The problem with this is that the paradigm may
not interact well with the underlying hardware architecture (or with 
the application--but that's a different issue).  No one has demonstrated
that there is some 'optimum' computational paradigm, and so each
hardware and language designer happily does his own thing.  One of the
major arguments for RISC is that the level of abstraction of the computational 
paradigms of most of the popular languages is too near--yet too
different from--the level of abstraction of most hardware computational
paradigms.  By 'reducing' the abstraction level ('complexity') of the
hardware paradigm, the job of producing an efficient translation from
the software paradigm into the hardware paradigm becomes easier, because
the hardware instructions make fewer assumptions (do less) that conflict
with the semantics of the software instructions.  The term 'reduced' in
RISC should be understood as 'more generalized'.  The more microcode
executed for each machine instruction, the more likely it is that the
user didn't *need* all those microcode instructions to accomplish his
task.  Imagine being forced to program in assembly language with only
push, pop and JSR instructions.  Why call a subroutine when all you
wanted to do was increment an integer by one?

Of course, the problem can also be tackled by raising the abstraction
level of HLL computational paradigms.  This leads to the problem
of the oversized screw-driver:  it can be indispensible for some jobs
but fail miserably for others.  What's needed is a tool chest which
contains screw-drivers of every size (a language or languages that
can operate on a wide range of abstraction levels, from bare hardware
to referential transparency, polymorphism, data hiding and lambda
functions).

--alan@pdn

the popular languages are too near the a