Re: Which language pays most? Smalltalk, not C++ nor Java.

[dewar@merv.cs.nyu.edu (Robert Dewar)]

G Shwarz replies to Kaz:

<<> A strictly conforming program may not define any external
> name that begins with 'mem' followed by any combination of letters,
> digits or underscores.
Ok. Define void memfoo() { } and see if it compiles.
It does.
>>


It is perhaps one of the most common serious misconceptions about what
language definitions mean to write a reply like this:

A standard specifies what strictly conforming programs do. The fact that
you can observe xyz behavior from a compiler when given a non-conforming
program is perhaps interesting, but has nothing whatsoever to do with the
standard.

I think this inability to understand the fundamental distinction between
the set of things that a standard defines, and the set of behaviors seen
experimentally from a given implementaqtion, is one of the most common
serious lapses of knowledge among programmers. Note that this understanding
must precede the realization that you cannot write correct programs in a 
given language without knowing the standard for that language well. It always
amazes me how badly many C programmers are acquainted with the standard.
Many C programmers have never even *seen* the standard, let alone studied it
carefully to know exactly what it says.

People often argue over the relative merits of languages from a portability
point of view. While it is true that there are some important technical
differences (e.g. dealing with varying size of integer types in C and Ada), 
these technical differences are often swamped in practice by the differences
in level of knowledge of the standard defining document, and very often
"portability" problems are just bugs where clearly non-conforming code has
been written.

OK, so your compiler can compile memfoo without compiling. Wunderbar! But
that does NOT mean that you can actually go ahead and call a routine memfoo
if the standard forbids it. To do so would be incompetent programming.