🚀 go-pugleaf

Herman Rubin writes:
>There is also the problem of optimizing.  I have used the CDC6500 a lot (for
>some time it was THE production machine at Purdue) and the 6600 a little. 
>These machines the same instructions, and, barring pathologies, any program
>on one will run on the other and give the same answer.  Nevertheless, the
>programming should be different because of timing problems.

And Steven Ryan (smryan@garth.UUCP) writes:
>I feel the language should provide access to every instruction the hardware
>provides. Programmers can then abstract out machine independent operators
>if they wish. A good extensible language would permit infix operators to be
>defined as the programmer sees fit.

It surprises me that these ideas still hang on. In these days when 
man power is expensive and machine power is cheap the computer should
do as much job possible. This includes translating abstract descriptions
of what to do and make these translation as effective as possible.
This helps me to concentrate on such things the machine can't handle.
Describing the problem to be solved, deciding what the program should
do in different situations. If the program runs too slow you can always
buy a faster machine. But if you don't get the code on time, what do you
do? Buy a faster programmer?

Now, we should not forget that there are different applications. 
Advanced number crunching and things you run on a Cray still requires 
much more handicraft in the coding. However, I imagine that these 
things are fairly straight-forward in terms of requirements, so you 
have more time fro optimizing. But the main part of the programs
written today solves problems that are much more complicated than
mathematical equations.
 
My opinion is that the language should help the programmer to be
as portable as possible. This means that he should be able to
encapsulate OS-calls and similar. (Hardware-dependent parts should 
really be avoided or cut down to a minimum.)

Even more important is that the language should help me to express 
my ideas as clearly as possible, not for the machine, for anyone
else who is reading my code.) It should help me to make distictions
between entities and then hit me on the fingers if violate them.
For example, I should be able to define:
     Apple : Apple_type;
     Pear  : Pear_type;
In many old-fashioned languages I can't do this. (Fortran, Cobol, C?).
Other languages let me do this, but when I by mistake write:
    Apple := Pear;   or
    Eat_an_apple(Pear); -- Parameter is of Apple_type.
the compiler will not always warn me. (Pascal, Modula-2?, Oberon?)
  Some languages that enforce this string type checking are Ada, 
Eiffel, Simula and C++(?). Hardly just a coincidence that all of 
them but Ada are object-oriented. 
  You may wonder why this is important. Let me just answer with a
common, but good, clich'e: Get the errors out early.
-- 
Erland Sommarskog            ! "Hon ligger med min b{ste v{n, 
ENEA Data, Stockholm         !  jag v}gar inte sova l{ngre", Orup
sommar@enea.UUCP             ! ("She's making love with best friend,
                             !   I dare not to sleep anymore")