Xref: utzoo comp.std.c:282 comp.lang.c:11983
Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!haven!umd5!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: Third public review of X3J11 C (a scientist speaks up)
Message-ID: <8365@smoke.ARPA>
Date: 20 Aug 88 20:09:32 GMT
References: <64919@sun.uucp> <8358@smoke.ARPA> <4566@saturn.ucsc.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <4566@saturn.ucsc.edu> joseph@chromo.ucsc.edu (Joseph Reger) writes:
>The draft may not be 'badly broken' but is missing out on the opportunity
>to make C a convenient language for numerical computing as well.

I happen to use C for numerical programming, despite occasional flaws
such as those you mention, primarily because it offers much better
support for data structures than do other alternatives such as FORTRAN.
I agree that there are some changes that could make C more convenient
for such applications.  Hough's suggestions are for the most part good
ones, but they haven't been receiving sufficient committee support.

The fundamental problem is that IT IS MUCH TOO LATE to be making
significant changes to the proposed standard.  Look at all the trouble
the last-minute addition of "noalias" caused.  The public review
period is intended as a REVIEW of work done by the committee, not as
an opportunity for language design.  Where were all these scientific
users of C when the design work was being done?  By leaving that up
to people who didn't think the flaws you perceive were significant,
you did not get those flaws addressed in the proposed C standard.
It's easy to complain about other people's work; much easier than
helping with the work.  I suggest that you GET INVOLVED in drafting
the NEXT (revised) standard.

Obviously I am not speaking for X3J11 officially here..