Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!hao!boulder!sunybcs!rutgers!iuvax!pur-ee!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc,comp.software-eng
Subject: Re: Software Technology is NOT Primitive
Message-ID: <594@l.cc.purdue.edu>
Date: Sun, 25-Oct-87 07:12:32 EST
Article-I.D.: l.594
Posted: Sun Oct 25 07:12:32 1987
Date-Received: Wed, 28-Oct-87 20:43:07 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <5077@utah-cs.UUCP>
Organization: Purdue University Statistics Department
Lines: 60
Summary: It is both primitive and decadent
Xref: mnetor comp.lang.misc:793 comp.software-eng:9


Unfortunately, software technology seems concerned only with attempts to do a
highly restricted set of operations.  This has also recently gotten into 
hardware development.  I think that the ideas of the software and hardware
gurus can be likened to producing automobiles which can be programmed to
get you to an address you type in, but will not let you back the car out of
the garage into the driveway.  I suggest that the software developers first
consider the power of existing hardware, next the natural power of hardware
(what unrealized operations can be easily done in hardware but are not now
there), and finally the "current use."  FORTRAN, when it was produced, was
not intended for system subroutine libraries.  There are instruction present
on most machines which someone knowing the machine instructions will want to
use as a major part of a program, but which the HLL developers seem to ignore.

I suggest that a language intended for library development be approached by
the developers with the attitude that a machine cycle wasted is a personal
affront.  I think we will find that the resulting languages will be easier
to use and less artificial than the current ones.  Implementing an arbitrary
set of types is no more difficult for the user than the 5 or 6 that the
guru thinks of.  Allowing the user to put in his operations and specifying
their syntax is not much more difficult for the compiler than the present
situation.  For example, I consider it unreasonable to have any language
which does not allow fixed point arithmetic.  It may be said that this would
slow down the compiler.  However, every compiler I have had access to
is sufficiently slow and produces sufficiently bad code that it would be
hard to do worse.

I suggest that there be a major effort to produce an incomplete language
which is 
        1.  Not burdened by the obfuscated assembler terminology.

        2.  Easily extended by the user.

        3.  Designed with the idea that anything the user wants to do
should be efficiently representable in the extended language.

        4.  Restrictions on the use of machine resources should be as
non-existent as possible, and should be overridable by the user if at
all possible.  The restrictions on register usage in the C compilers
I have seen I consider a major felony.

        5.  Remember that the user knows what is wanted.  I hereby 
execrate any language designer who states "you don`t want to do that"
as either a religious fanatic or sub-human :-).  Those who say that
something should not be allowed because "it might get you into trouble"
I consider even worse.

        6.  Realize that efficient code does not necessarily take longer
to produce than inefficient, and that there are procedures which are not
now being used because the programmer can see that the resources available 
to him will make the program sufficiently slow that there is no point in
doing the programming.

I think that if a reasonable language were produced, we will see that there
will be a new era in algorithm development, and that the hackers will be
competing in producing efficient software.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet