|[38 earlier articles]|
|Re: simple vs complex languages chase@TheWorld.com (David Chase) (2003-06-05)|
|Re: simple vs complex languages firstname.lastname@example.org (Yiorgos Adamopoulos) (2003-06-05)|
|Re: simple vs complex languages email@example.com (Dave Thompson) (2003-06-05)|
|Re: simple vs complex languages firstname.lastname@example.org (Lex Spoon) (2003-06-05)|
|Re: simple vs complex languages email@example.com (2003-06-08)|
|Re: simple vs complex languages firstname.lastname@example.org (2003-06-08)|
|Re: simple vs complex languages email@example.com (Lex Spoon) (2003-06-20)|
|From:||Lex Spoon <firstname.lastname@example.org>|
|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|
|Posted-Date:||20 Jun 2003 00:06:11 EDT|
> 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
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.
Return to the
Search the comp.compilers archives again.