On Mon, 31 Dec 2001, Richard Cobbe wrote:
> No, type-safety is important. Type-safety makes several guarantees, but > the most important for our purposes is the following: > > If an expression E has (static) type T, then the result of > evaluating E is *always* one of two things: > > * the evaluation throws an exception which escapes beyond the > boundaries of E (or otherwise signals an error condition) > > * E's value is a valid object of type T and not some random > collection of bits. > > In particular, this means that if p is of type pointer to T, then > dereferencing p will *always* give you a valid T. > > Languages generally do this by restricting the set of pointer values > (and such restricted pointers are usually called `references' [1]). For > instance, in LISP and Scheme, there is exactly one way [2] to create a > reference to a list: call the function CONS, and the return value is > your reference. The language guarantees that, if CONS returns (as > opposed to throwing an exception), its result is a reference to a valid > list. > > This is in sharp distinction to C and C++. The C++/STL equivalent to > CONS is, more or less, list<T>'s constructor, and that's certainly a way > to get a reference: > > list<int> *l = new list<int>; // safe: *l is a valid list<int> > > Unfortunately, it's not the only way to get such a reference: > > int i; // initialize i somehow---or, better yet, don't! > > l = reinterpret_cast<list<int> *>(i); > > Is *l a valid list<int>? You can tell only if you have very detailed > knowledge of where things are laid out in memory. Chances are, though, > that l is bogus and dereferencing it will segfault. [Remainder of learned treatise clipped] Everything you said is true of course, and I agree with all of it. Frankly, sometimes I prefer people to not weigh in on my side of the debate, as it frequently sidetracks what I was trying to say. I want to reshape and then reiterate my simple point. The computer is a machine, which works in a very predictable and deterministic way. When the CPU is started, it reads some number of bytes from some specific offset, and the result is always the same. This is the nature of computers. It is easy to have a debate about languages, because many ways to program computers have been invented. Some languages have type-safety, some have garbage collection, some have neither. Some have subroutines, some have functions, and some have neither. You can contest which is the best language because there are so many languages and techniques. I submit -- and this has been my only point all along -- that the different attributes and qualities of programming languages exist entirely in our heads. You may say that type safety produces better programs, but what you really mean is that type safety makes it easier to produce a particular program. The CPU hasn't got any concept of type safety or even types so the whole idea of type safety exists only in the programmer's brain. Similarly for object-oriented programming. The computer doesn't care one whit about objects. They exist only to change the way the programmer thinks about the program. Some people propose that technique Y allows multiple programmers to build better programs, or that technique Z avoids a common programming error -- and they may be right -- but these are all different ways to arrive at the EXACT same program. Further, I propose that people have various styles of thinking and perhaps even different forms of intelligence. I have certainly known a number of people who surprised me with their style of learning. If you kindly grant me that point, then I further propose that no programming technique can be evaluated without considering both the program to be written and the programmers who will be writing it. So, this is the only thing I initially meant to say: many programming techniques can be used by many programmers in many different ways to arrive at a given result. It is a fallacy to dismiss any of them, even though they may be out-of-fashion. And it is certainly a fallacy to write a 500-page screed on the subject. -jwb
