C, please die,

n Wed, 3 Dec 2014, Toby Thain wrote: Very true. A lot of the problem [,if there is one] is "baby duck syndrome". For example, students will stick with what they learned in school - BASIC was developed for TEACHING programming; as such, it was a fairly good choice for being built-in to generations of personal computers. When Pascal was developed for TEACHING programming, we got a whole generation who had learned on it, were never told, or never accepted, that it was intended for TEACHING, not for real world applications, and proceeded to use it when they got out into the real world, with mixed results. When C was the language that was taught, we got generations of C programmers. Now, will we be getting generations of SCHEME programmers? A well designed language (and compiler) will excel at what it was designed for, and is not likely to be the best possible choice for other purposes. Nevertheless, these languages are generally capable of doing tasks outside their specialty. And, if somebody's experience is with some specific tool, will forcing a change to other tools because of their potential better suitability be worth the setback in experience? If you employed Tony, and used state of the art diagnostic systems, would you ask him to give up his voltmeter and logic probe? Some things, such as runtime error checking are great for a teaching language, but lose some of their benefit in the real world. For example: Y = 100 / X could be disastrous if X == 0 Should the compiler add error checking? IF (X == 0) ... ELSE Y = 100 / X But, if you KNOW that X is not 0 IF (condition) X = 2, else X = 5 Y = 100 / X do we really want the bloat and slowdown of checking whether X is 0? Do we expect the COMPILER to have kept track of what possible values X might have at that time? (possible in this trivial case, not in anything much more complex) WE might know what X was used for, and therefore its range of possibilities, the compiler wasn't a party to all of the design conferences. The programmer still knows more about what is intended than the compiler does. If you DON'T know that X is non-zero, then YOU should insert appropriate tests. But, too many programmers will write Y = 100 / X without including the essential safety test. The fault is with the programmer, not the language. Similarly, F = C * (9/5) + 32 (note that 9 and 5 are integers!) or IF(((float)X/3.0) * 3.0 == X) . . . or (int32)X<<32 might be programmer errors. It would be NICE if the compiler would notice the mistake and WARN us, but it is not the fault of the compiler if we make the mistake, or even if the compiler author didn't include code to check for our particular mistake. The task of the compiler is to do what we ASKED for; secondarily, it would be nice if it does what we WANT. (cf. old yiddish curses) Likewise, X << N would be treated as X << (N & 31) by 80386 X << 32 would be treated as X << 0 by 80386 It is still the programmer's responsibility to learn all such DOCUMENTED characteristics, and even the UNDOCUMENTED ones that have already been encountered. Oh, I remember it well. Aerospace had just collapsed. In some areas, auto garages were full of EEs working as mechanics. In 1973, I declared that I would get back into computers when "tabletop computers" became readily available, and I opened an auto repair shop working on Honda cars. For a while, my employees chided me about being the only one who hadn't been through graduate school, and only had a BA. I was fascinated by S100, but the coming of TRS80, Pet, and Apple brought me back. Yes, "a lot of". Way too many of my friends have died. -- Grumpy Ol' Fred cisin at xenosoft.com