Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!tut.cis.ohio-state.edu!ut-sally!utah-cs!donn
From: donn@utah-cs.UUCP (Donn Seeley)
Newsgroups: comp.lang.c
Subject: Re: Another D idea: RPN (and more)
Message-ID: <5333@utah-cs.UUCP>
Date: 9 Mar 88 07:34:06 GMT
References: <5318@utah-cs.UUCP> <12177@brl-adm.ARPA>
Organization: University of Utah CS Dept
Lines: 75

I wanted to desist, I really did, but I forgot the seductions of
netnews...

	From: dsill@NSWC-OAS.arpa (Dave Sill)

	You're missing the point.  We're not so much designing a new
	language as we are pointing out the problems/limititations/
	weaknesses/omissions in an existing one.  ...

You're missing the point, or at best splitting hairs.  This discussion
IS about language design; I see no reason to dither about whether we
are discussing the design faults of C, or a new design for a language
that is 'just like C, but better'.  Without a method to the madness,
without some design goal or programming methodology in mind, a
discussion of language design is pointless.  I'm sorry to be so
didactic -- it's just that over the years my tolerance for bad design
has diminished considerably.

I personally feel that C has met its design goals quite admirably.
Dennis Ritchie has stated these goals more clearly than I ever will be
able to, and if you haven't read his discussion of these goals, how can
you comment intelligently about whether these goals were met?  (Hell,
how can you program in C if you don't know its design goals?)  Language
technology has changed since C was invented, and any new language
design must reflect these changes, which are far more fundamental than
anything dredged up in this 'D' discussion.  I feel quite irritated
that some people are advocating a new language that is 'just like C,
only better' -- not that we shouldn't learn from C's successes, but
that our imaginations should be so impoverished that we see only C and
nothing that has come since C.

Even in the realm of the trivial, I have seen no imagination.  If you
wish to argue that some particular syntax is not 'safe', it would
please me and surely many others if you could propose a design that
really did have 'safety' as a goal, rather than making little changes
in a design like 'C' that is not 'safe' and pretending that the result
has measurably improved 'safety'.  If you really wanted to impress me,
you would cite psychological studies (like those of Don Norman) that
show how real people make mistakes and then show how your design acts
to limit these mistakes, preferably with a follow-up showing statistics
about reduced numbers of programming errors when a sample of
programmers implements a given task in your language instead of in C.
I picked 'safety' as an example here -- if 'safety' isn't your bugaboo,
substitute a better one.

	>Of course, these 'D' proponents have been working from ANSI
	>C's example,

	This is totally unjustified.  ...

Am I slandering the 'D' proponents here, or the ANSI C committee? :-)

My considered opinion is that the ANSI C committee should have
standardized C, keeping the original design goals in mind whenever it
was necessary to bridge some ambiguity or resolve some conflict between
existing implementations.  Instead the committee acted much as some
participants in this 'D' discussion have acted, each member having some
private agenda in mind that would produce a document that enshrined
some favorite new feature of theirs, abandoning any esthetic or
functional unity of C as a language.  I've already expressed my opinion
that this is also a disaster for users, since it guarantees porting
trouble for applications that incorporate these new features.  

	>PPS -- Naturally, this brings up the issue of what should go
	>into the language 'F'...

	Sure, which brings up the question of G...  ...

Another person who missed the joke...  Now I know how Mr. Limoncelli
felt.

At greater length than originally intended,

Donn Seeley    University of Utah CS Dept    donn@cs.utah.edu
40 46' 6"N 111 50' 34"W    (801) 581-5668    utah-cs!donn