Related articles |
---|
[9 earlier articles] |
Re: User definable operators neitzel@gaertner.de (1996-12-18) |
Re: User definable operators tim@franck.Princeton.EDU (1996-12-20) |
Re: User definable operators nkramer@cs.cmu.edu (Nick Kramer) (1996-12-20) |
Re: User definable operators hrubin@stat.purdue.edu (1996-12-24) |
Re: User definable operators preston@tera.com (1996-12-26) |
Re: User definable operators burley@gnu.ai.mit.edu (Craig Burley) (1996-12-26) |
Re: User definable operators mfinney@inmind.com (1996-12-26) |
Re: User definable operators leichter@smarts.com (Jerry Leichter) (1996-12-27) |
Re: User definable operators genew@mindlink.bc.ca (1996-12-28) |
Re: User definable operators WStreett@shell.monmouth.com (1996-12-29) |
Re: User definable operators adrian@dcs.rhbnc.ac.uk (1997-01-02) |
Re: User definable operators hrubin@stat.purdue.edu (1997-01-02) |
Re: User definable operators anw@maths.nottingham.ac.uk (Dr A. N. Walker) (1997-01-03) |
[4 later articles] |
From: | mfinney@inmind.com |
Newsgroups: | comp.compilers |
Date: | 26 Dec 1996 14:10:59 -0500 |
Organization: | In Mind, Inc. |
References: | 96-12-088 96-12-110 96-12-147 96-12-163 |
Keywords: | design |
hrubin@stat.purdue.edu (Herman Rubin) writes:
..snip...
> Notation has to be overloaded to be of reasonable length. By the
> time one reads the lengthy variable names which seem to delight the
> computer people, the structure of the expression is lost. It is
> necessary to let the user invent notation, if necessary, and for the
> language and compiler to help, not hinder.
Well said!
This is a point that I have argued for years -- mostly in vain. I
have maintained that the memes spread by Wirth about minimalism in
programming language design is one of the greatest evils to befall
programming. A language should be minimal in the sense that it does
not unnecessarily duplicate function, not in the sense that it uses
the mathematical minimal set of features. What is mathematically
minimal is frequently far from optimal for human cognitive purposes.
It is one thing to disallow two ways of doing *exactly* the same
thing. But the semantic richness obtained by allowing mulitple ways
of accomplishing similar things is completely disregarded. This is in
complete opposition to our understanding of language and cognition.
One of my favorite examples is the "if" statement. I suggest two
variants which I have found to be very useful -- the "when" and
"unless" statements. These have no "else" clause allowed, so the
programmer knows that a simple conditional is involved. And the
difference between the "when" and "unless" is that the "unless" is a
negated version of "when". This means that a conceptual level of
processing can be avoided by "thunking". So the "if" statement now
has three similar, but not the same, variants. It is amazing how much
opposition I have seen to these variants by C/C++ programmers (where
simple macro definitions allow them to be used). But I have never
seen them cause a programmer problems in actual practice, and it is my
belief that they actually help. Even very good programmers who have
no problems with negation can benefit from a reduced cognitive load.
And, of course, allowing additional operators is very desirable as
well. Operators that have come into play recently in mathematics, but
not in programming are ++ and >+ where the first is used for
catenation and the second for list catenation. I have also suggested
that >< be used to mean "incomparable" which cannot be tested for in
most programming languages at this point. However, IEEE floating
point may result in exactly that condition when comparing values.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.