== vs =

[Herman Rubin]

In article <2727 at mmintl.UUCP>, franka at mmintl.UUCP (Frank Adams) writes:
> In article <7273 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
> >Why are you guys wasting so much effort on a non-problem?
> >If you prefer Pascal, then use it!
> 
> It isn't a non-problem, and we don't prefer Pascal.  For every problem with
> C, there is a problem 3 times as severe with Pascal.  That is no reason not
> to try to fix the problems with C.
> -- 
> 
> Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
> Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108

I agree completely.  Those who say "FORTRAN can do this, so use FORTRAN"
or the same for LISP, etc., are ignoring the problem.  I am using C for
_numerical_ programming because many of the things I want to use, such
as pointers, are not available elsewhere.  I believe that, at present, 
C is the only existing language which allows the programmer to reasonably
efficiently use _some_ of the power of the machine; I cannot expect a
language designer to be so omniscient that my needs can be anticipated.

The intelligent programmer should be able to start with a problem and with
the capabilities of the machine on which the problem is to be implemented
and be able to implement the derived solution with reasonable ease.  At
present, C comes closest to doing this.  Assembler allows good implementation,
but has an unnecessarily complicated syntax, and is totally non-portable.
I believe it is possible to achieve good semi-portable code, frequently
with a choice of procedures for accomplishing the goal.

Telling me that what I want to do in part of my code can be done in
FORTRAN, another part in PASCAL, another part in ..., where each part
is a small number of lines, is stupid.  I do not know of any way to 
combine anything smaller than subroutines from different compilations,
and C suffers from not allowing the user to suggest or even force inline
code, which frequently is far faster than a subroutine call and may even
take less space in the main program than the subroutine call and subsequent
handling of the return.

Do not restrict the programmer!

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (ARPA or UUCP) or hrubin at purccvm.bitnet