I'm just converting my header files from Draco (a "strongly" typed
language) to C (a less-"strongly" typed language), and some more of
the subtler differences have been brought to my attention.
- C treats character constants to be of type 'int'. Other languages
typically treat them as type 'char'. I *think* C++ changed this.
- C treats members of an enumeration as of type 'int'. Other languages
treat them as of the new type of the enumeration. This can prevent
a lot of errors when dealing with enumerations.
- C has no 'bool' type. Instead, it uses int's, sortof. This leads to
C having the &&, || and ! operators work on ints, which often
prevents compilers from pointing out logic, precedence or bracketing
errors.
- C has no separate "pointer-to-no-object" value. It uses the token 0
as that value. This can lead to confusion as to whether an expression
is yielding an int or not. (In my C code, I always use "NULL" as
a pointer, reserving 0 only for true integer uses. This appears to
be in direct conflict with what C++ folks want you do do.)
- C's 'if' and 'while' constructs compare their test expressions
against some "special" value for whatever type the expression yields.
For ints, that is 0. For pointers, it is also 0, but differently.
Other languages typically define the conditions as requiring a value
of type 'bool'. This requires a bit of extra typing:
C: if (count)
other: if (count != 0)
C: if (ptr)
other: if (pointer != nil)
C: if (bits & (BIT1 | BIT2))
other: if (bits & (BIT1 | BIT2) != 0) /* precedences changed! */
C: if (flag1 && bits1)
other: if (flag1 and bits1 != 0)
etc.
So, in the sense that C is "sloppier" or "more forgiving" about this
stuff, it is less strongly typed than other languages. However, what it
may gain in perceived convenience, it definitely loses in the ability
of the compiler to tell you about errors of several kinds. And yes, you
can use the "other" forms in C, (I do) but you still won't get the
checking.
As has come out in this list, different people have different preferences
about this stuff. For example, LPC, being based on C, pretty much has the
same rules on this as C does. My AmigaMUD language, being based on Draco,
pretty much has the same rules as Draco does. So, as has been said several
times, the choices here come down to who will be using the language, and
what they are comfortable with. I will claim, however, that if you want
to entice non-programmers to become programmers in your MUD, the simpler
your language is, and the more well-defined it is, the more likely they
are to not get too frustrated. IMHO, a "strongly-typed" language has a
bit more of an initial learning hump than a "weakly-typed" language has,
but once over that hump, the ongoing frustration is less. At least for
a newcomer to programming. For someone who has used a "weakly-typed"
language for 10 years, the initial hump may well never go away.
As for static typing versus dynamic typing, its probably strongly
governed by experience. Someone with a lot of experience with dynamically
typed languages will have developed automatic type-checking skills that
make type errors less frequent. However, that skill depends on uptodate
knowledge of the program in question, and the variables, structures, etc.
that it contains, and what types they are supposed to be. Errors are much
more likely in maintainence work, where the programmer does not have the
uptodate knowledge. It is in that kind of work that I believe the strength
of statically typed languages lies. Unfortunately, very few programmers
are paid to always write new code - they spend much more time maintaining
(adding to, changing, updating, fixing) code, both their own and others.
--
Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA