Path: utzoo!attcan!uunet!husc6!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc
Subject: Re: Many people's opinions on computer languages
Summary: 1. The languages do not let me express myself
	 2. The machines are not infinitely fast
Message-ID: <923@l.cc.purdue.edu>
Date: 11 Sep 88 15:20:17 GMT
References: <3938@enea.se>
Organization: Purdue University Statistics Department
Lines: 107

In article <3938@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
> 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?

I use many operations which the languages do not know about.  Now I can
translate them into hardware instructions.  I can even post to comp.arch
that additional instructions would be useful.  But if I have to write
twenty lines of code to even get them clumsily expressed in a HLL, the 
human time which Erland Sommerskog decries is equally wasted.  Especially
if I have many such situations.  In addition, the clumsy encoding in C
or FORTRAN might not be understandable to others.

Programming time is therefore not necessarily faster in HLLs.  Frequently,
I see how to use a machine instruction or instructions to accomplish something
which I consider simple and obvious.  Why should I even have to try to find a
way to do in in some HLL?  The HLL gurus have left out too much.  Now I have
been arguing for a language in which at least much of both worlds can be
achieved.  Would an extensible HLL be that difficult?  

Many have argued that the compiler would be slowed down, or that a many pass
compiler would be needed.  Now you are arguing that machine time is not that
important.  If execution time is not that important, why should compiler time
be any more important?

Furthermore, in many cases the time difference is so obvious that I, the 
algorithm producer, know that a given algorithm is not worth producing on
a particular machine.  I cannot see any way of vectorizing procedures for
generating exponential and normal random variables, which are quite efficient
on many other machines, on the CRAY 1;  even on those machines on which they
vectorize, slightly different algorithms may have running times differing by
a factor of 10 or more.  Certainly procedures designed to be used many times
deserve a considerable measure of time improvement.

You seem to feel that the language gurus have done a reasonable job of handling
your constructs.  I can demonstrate that they have not done that for mine.
I do not expect them to be able to anticipate all that I am likely to want.
I do not believe that they can all be identified at this time.  Thus, extens-
ibiltiy is needed.

> 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.

We disagree about what is important.  I see nothing wrong with that.
I say that for numerical computations, our languages are inadequate.
For anyone using a CRAY or a CYBER, that is what you want.  In fact,
although these machines are used for compilation, I would entertain
the idea that this is a misuse of the resources.  You want strong type
checking.  I want it not to be there.  I see no reason why we cannot
both be satisfied; let the compiler make it an overridable error.

I repeat, what is needed is FLEXIBILITY.  I believe it is possible.
What is impossible is full portability.  Semi-portability is possible.
I liken the languages to a control system which will get your automobile
to a given address in a reasonable manner, but will not let you back it
into the driveway, or let you avoid rush hour traffic.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)