Re: simple vs complex languages

bear@sonic.net 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.
Lex

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