Xref: utzoo comp.std.c:295 comp.lang.c:12035 comp.arch:6135
Path: utzoo!attcan!uunet!husc6!mailrus!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.std.c,comp.lang.c,comp.arch
Subject: Re: Third public review of X3J11 C (a scientist speaks up)
Message-ID: <3732@bsu-cs.UUCP>
Date: 23 Aug 88 23:26:08 GMT
References: <64919@sun.uucp> <8358@smoke.ARPA> <4566@saturn.ucsc.edu> <8365@smoke.ARPA> <887@l.cc.purdue.edu>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 25

In article <887@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
[wish list for HLLs]

I agree that many of the features wished for ought to be in higher-
level languages.  But to put all of them in C would no longer leave
the relatively small, simple, low-level language that C was designed
to be.

Nearly all of the features that Herman Rubin wishes to see *are*
already in HLLs, only not all are in each HLL.  C++ has some.  Ada has
*many* of them, especially fixed point arithmetic and functions
returning structured values.

The real problem is not with C designers.  The real problem is with
Fortran designers, who have always had an explicit mandate to design a
language for scientific computing, and have continued to fail miserably
to achieve this.  In a way the C users who do numerical computing want
to put on C the burden that Fortran was supposedly designed to carry.

The trouble with doing so is that other users will lose.  Each new
feature added to a language increases the complexity of the language
translator, and *all* users, even those who don't need to use these
features, will pay in money, disk space, and CPU time.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi