🚀 go-pugleaf

In article <1592@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) writes:
 In article <703@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
 |Frankly, I believe that if someone developed a decent high-level, overloaded
 |operator, reasonable syntax assembler it would have a good chance of
 |supplanting C.  Add the other useful features of C and you have a good
 |language.
 
> .... You'll also discover that your idea of a "perfect language"
> may not be so widely held.

I do not believe that it is possible to design a perfect language.  I may have
gone too far in claiming even that one can get a good language.  However, the
first requirement for an _adequate_ programming language is that if I start
with a reasonable mathematical construct, and the hardware can implement that
construct in a simple manner, that the language must allow the resulting
program steps to be at least that good

Another requirement of mine is that it is not necessary to type a large number
of characters to do something simple.  Compare a typical assembler with CAL.
Mathematicians have been dealing with overloaded operators for centuries; they
have been adding operators for centuries.  If a mathematician needs a new
operator, he introduces it in his paper and defines its properties.  This does
not mean that his symbolism gets adopted.  Similarly, it a new operator is
needed in a program, the programmer should be able to define and introduce
it.

There are two different aims of a programming language.  One is the description
of the procedure.  For this, the current languages are totally inadequate.
They are much too restrictive, as well as lacking in scope.  Consider the 
following problem:  We wish to add the elements of the array _a to those
of array _b, forming array _c.  Most programming languages provide an imple-
mentation of this; in fact C provides at least three.  If this is what we
want done, we should not tell the compiler which of the three to use; that
should be machine dependent.  Thus the language does not provide for the
proper expression of the concept.  On the other hand, few languages provide
for reasonable integer arithmetic, or multiple precision arithmetic, integer
or floating, at all.  They only provide for certain fixed precisions.

The other aim is to provide source code which a reasonable compiler can 
transform into reasonably efficient code for production purposes.  Here 
it is necessary to have the language flexible enough to accommodate
machine dependencies.  It is necessary to have access to the machine
instructions.  It is necessary to restrict portability.  Semi-portability
may still be desirable.  The "super-assembler" which I suggested in my
previous posting is for this purpose.  Most programming languages are bad
attempts in this direction.

It is easy to give examples where the choice of which procedure to use
should be machine dependent, even though the language is powerful enough
to encode each procedure for each machine.

> If you think you really can do better than ``C'' or some other successful
> language, *** DO IT ***. 

If you provide me with the necessary programmers, I will.

>      (Though I generally detest Fortran and Pascal, I
> doubt I could have done much better at the time they were created -- for the
> niches they fill.) 

FORTRAN had obvious inadequacies before it was created.  ALGOL claimed to be
a good language for all of numerical mathematics for all time--it was clearly
inadequate on the machines existing at that time for the problems being done
at that time.  The following is a quote from D. H Lehmer, one of the pioneers
in the use of the computer in number theory.  I do not remember the exact 
words, but the meaning is clear.

	"None of the existing languages is adequate for number theory.
Furthermore, I would not be able to design one."

Clearly, Lehmer did not mean that he could not program number theory computa-
tions.  It is also clear that the standard mathematical expressions are an
adequate means of communicating the algorithms so that a programmmer with
the knowledge required to _read_ the mathematical notation could come up
with some sort of correct implementation.  We still do not know enough to
come up with an efficient implementation by a compiler using source in any of
the existing languages.

>    I would be suprised if your design were much different
> from existing languages (except perhaps in minor details -- 0/1 trip loops,
> 0/1 based arrays, for-do-while vs DO-REPEAT-etc., `;' as terminator/separator,
> and so forth.)
> -- 
> Doug Pase  --  ...ucbvax!tektronix!ogcvax!pase  or  pase@cse.ogc.edu (CSNet)

I agree the above are minor details.  The ability to define types as needed
and operators as needed, to ignore types when necessary, to use such machine
hardware as the language designer does not know about, to use condition codes
when convenient if available, etc., are extremely important.  We have the 
problem and the machine; we must educate people to use the tools the machine
provides to solve the problem.  

We also need to be able to write the necessary constructs with a reasonable
number of keystrokes, and the notation should be reasonably easy to read.
-- 
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