Re: simple vs complex languages

nmm1@cus.cam.ac.uk (Nick Maclaren)
5 Jun 2003 22:53:13 -0400

          From comp.compilers

Related articles
[31 earlier articles]
Re: simple vs complex languages vbdis@aol.com (2003-06-03)
Re: simple vs complex languages vbdis@aol.com (2003-06-03)
Re: simple vs complex languages bear@sonic.net (2003-06-03)
Re: simple vs complex languages lars@bearnip.com (2003-06-03)
Re: simple vs complex languages jvorbrueggen@mediasec.de (Jan C.=?iso-8859-1?Q?Vorbr=FCggen?=) (2003-06-05)
Re: simple vs complex languages nmm1@cus.cam.ac.uk (2003-06-05)
Re: simple vs complex languages nmm1@cus.cam.ac.uk (2003-06-05)
Re: simple vs complex languages chase@TheWorld.com (David Chase) (2003-06-05)
Re: simple vs complex languages adamo+news@dblab.ece.ntua.gr (Yiorgos Adamopoulos) (2003-06-05)
Re: simple vs complex languages david.thompson1@worldnet.att.net (Dave Thompson) (2003-06-05)
Re: simple vs complex languages lex@cc.gatech.edu (Lex Spoon) (2003-06-05)
Re: simple vs complex languages zivca@netvision.net.il (2003-06-08)
Re: simple vs complex languages bear@sonic.net (2003-06-08)
[1 later articles]
| List of all articles for this month |
From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 5 Jun 2003 22:53:13 -0400
Organization: University of Cambridge, England
References: 03-04-095 03-05-182 03-05-199 03-06-010
Keywords: design, parse
Posted-Date: 05 Jun 2003 22:53:12 EDT

bear@sonic.net writes:
|>
|> > The need for programming, as with mathematics and serious science, is
|> > something that is precise and unambiguous.
|>
|> It goes a little beyond that. It's not merely something that's
|> precise and unambiguous, it's also ideally something that doesn't map
|> to ambiguous concepts and ideas in the human brain. And that's much
|> harder to accomplish. In natural languages, I think a word's ambiguity
|> is often a vital and irreducible part of its meaning; if we pick just
|> "one meaning or the other" we lose a nuance of what's being
|> communicated. IOW, I think ambiguity is a very important feature of
|> human communication (This is an unorthodox opinion, but I have a lot
|> of professional experience, mostly in natural-language software, and
|> it seems true to me). I can't easily imagine wanting that kind of
|> dynamic in a language that specifies instructions to a machine.


Good heavens! Is it really unorthodox? I know that I do it
deliberately, and that many people do not realise when they are doing
it, but I thought that it was the accepted model.


And I very much agree with your points about the consequences of
"ambiguity of understanding" as distinct from "ambiguity of
specification". Such aspects lead to what I call "gotchas", though I
may have cribbed the term from someone else, which I have spent far
too much of my life failing to persuade standards committees and
vendors are a Bad Thing. They go as follows:


        A specification defines some behaviour in such a way that the
boundary with undefined behaviour is relatively easier for the
specification to define than it is for the programmer or user to
avoid.


        A programmer or user then steps over the boundary by accident, and
the product fails unsafe (often doing something completely bananas,
like corrupting data).


        Somebody then tracks this down and complains to the relevant
authors that this is an error in the specification or product, and is
told "That is YOUR fault - the specification clearly says that is
undefined behaviour."


        GOTCHA!


Regards,
Nick Maclaren.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.