Re: simple vs complex languages

Lex Spoon <>
20 Jun 2003 00:06:11 -0400

          From comp.compilers

Related articles
[38 earlier articles]
Re: simple vs complex languages (David Chase) (2003-06-05)
Re: simple vs complex languages (Yiorgos Adamopoulos) (2003-06-05)
Re: simple vs complex languages (Dave Thompson) (2003-06-05)
Re: simple vs complex languages (Lex Spoon) (2003-06-05)
Re: simple vs complex languages (2003-06-08)
Re: simple vs complex languages (2003-06-08)
Re: simple vs complex languages (Lex Spoon) (2003-06-20)
| List of all articles for this month |

From: Lex Spoon <>
Newsgroups: comp.compilers
Date: 20 Jun 2003 00:06:11 -0400
Organization: Georgia Institute of Technology
References: 03-04-095 03-05-182 03-05-199 03-06-010 03-06-034 03-06-066
Keywords: design
Posted-Date: 20 Jun 2003 00:06:11 EDT writes:
> The problem is with computer languages that make it too easy to write
> something "close to it" without noticing that it doesn't actually say
> what we mean. To me, infix operators with complicated precedence and
> association rules is absolutely begging for trouble.

I was with you until this example. There is a difference between
*looking* close to it, and *behaving* close to it. In the precedence
example, usually the behavior will be radically different if you
parenthesize wrong. Thus, for people that actually test their code,
most precedence mistakes are only minor gotchas. (Not that you'd want
to have even minor problems!)

On the other hand, thread synchronization mistakes can be subtle even
under testing. The program can act correctly for 100 tests and then,
on the 101st test, lose a race and corrupt memory. Worse, tweaks to
the operating system can nail you, because the thread scheduling
algorithm changes.

An even better example is input functions that try to guess the data
type to return. For example, they may return a string if the input is
"abc", but a number if the input is "123". This can really "getchya"
:) if you are inputing file names and someone has a file named "51".
It would be easy to overlook this possibility both during writing the
program and testing it.

So, I just wanted to say that it is worse to have subtle *behavioral*
differences than subtle *syntactic* differences, so long as the
programmers are doing at least some minimal testing.

Post a followup to this message

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