Path: utzoo!mnetor!uunet!littlei!ogcvax!pase From: pase@ogcvax.UUCP (Douglas M. Pase) Newsgroups: comp.lang.misc Subject: Re: Modern langauges Message-ID: <1522@ogcvax.UUCP> Date: 2 Jan 88 10:50:23 GMT References: <1520@ogcvax.UUCP> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 141 Since this is a reply to a reply, comments by sommar@enea.UUCP (Erland Sommarskog) will be prefixed by `ES>'. My comments (Douglas M. Pase (pase@ogcvax.UUCP)) will be prefixed with `DP>'. ES> To appreciate a modern langauge you must be a modern programmer. ES> Some of the arguments Mr. Pase presents, and of which we have ES> and will see many times, seems just as conservative as those ES> that must have been around when assembler vs. Fortran was the issue. I quite agree that I am conservative, as long as "conservative" is not being used to mean "unwilling to accept change -- even when change is merrited." I am neither in favor of change nor against it. I am in favor of flexible languages and programmers understanding what they are doing. It seems, however, the intent of the previous paragraph was to claim my arguments were reducible to an aversion to change. This is simply not the case. A far better summary of my opinions, I think, would be "The right tool for the job." I don't use C for combinatorial searches, and I don't use Prolog for system work. I don't use Modula-2 for anything. (I once wrote a 15,000 line compiler in Modula-2, and later maintained a 12,000 line library. The same thing in C would have taken 1/3 the memory, 1/10 the time to write, and run about 2x faster.) ES> [...] a good language should save you many mistakes as early as possible. DP> This is a noble goal. A major problem with this is the definition of what DP> constitutes a 'mistake'. [followed by an example...] ES> [a response to the example, not the statement] As for ES> reading, I think the explicit type conversions help understanding what's ES> happening. This doesn't answer the question. Is it just a matter of type casts? What other expressions are considered `mistakes'? When are explicit type conversions required? Whenever the types do not match exactly? Consider the following list of conversions: int <- char -- types are different, no information lost double <- float -- lower bits contain essentially garbage float <- double -- possibly lose precision, small number becomes 0 int <- float -- ditto float <- int -- may lose bits on the lower end of large ints Problems could arise in all but one of these cases, but it is very rare that such things trouble me. However, it would be tedious and not in the least bit more readable to me if I had to cast every piece of data whenever I wanted a mixed expression. (assume a is int, b is float, and c is char) (float)a + b * (float)(int)c is much less readable to me than a + b * c I may be unusual in this (I doubt it), but programming errors in this area give me few problems. What's more, I've never had much difficulty finding them when they did occur. C does what I expect, and I expect what it does. One area where I believe explicit casts should be required, even though such casts rarely change the bit-pattern of the representation of the value, is is where pointers are used. In my earlier days I ignored casts to pointers because the values did not change. It proved to be the source of my most obscure and difficult bugs. It was not and is not my intention ever to suggest that casts on pointers (when different types are involved) should be ignored. Our C compiler here gives warnings whenever pointer types do not match. But I believe that is as it should be. DP> [arguments about array bounds-checks] ES> A modern language should of course allow dynamic arrays. That, more than almost anything else, is something I use. C gives me that; Modula-2 does not. DP> [Runtime] bound checks are expensive in terms of efficiency. ES> This, I'd say, is an really old-fashioned argument. Some things are simply timeless... ES> when hardware is cheaper than software, buy faster software, don't ES> remove the array checks. Believe, you save the money just in having ES> the program crash on array overrun, than searching for those funny ES> errors caused by having data unexpectly over-written. This is another error I have had few problems with. I am always careful to put the checks in, but I put them in where they are less likely to slow the execution. For example, I build the checks into the preliminary stages of loops, rather than array accesses within loops. That way I check once at the beginning of the loop that the indexes will not overrun, rather than a dozen times within each pass of the loop. Few compilers have the smarts to do equivalent things for me, and I'd usually end up doing it anyway. This whole thing is really a minor point anyway. I wouldn't condemn or avoid a language because it had runtime array checking. That sort of thing just doesn't bite me very often. DP> [C] assumes (rashly) that the programmer knows what s/he is doing. ES> And this is just so wrong, wrong, wrong! We have lived with computers so ES> long that we know that programmers very often only are just dimly aware ES> of what they are doing. This is not the problem of a language, it is the problem of a programmer! If a person does not understand what s/he is doing, how will I have confidence in what s/he has written, whatever the language!?! A programmer is simply a person who translates concepts from one language (that of the application) to concepts in another language (that of the programming model). It is very similar to natural language interpreters. If I were to hire a Russian to interpret for me, I would want one who understood both Russian and English. A failure to understand either one would mean he was not an interpreter. If I hire a programmer, I want him to understand the machine (model) as well as the application. If you were to argue that programmers who know and understand C well are not able to rapidly produce efficient and relatively bug-free code, or that C is inordinately difficult to learn for the benefit it gives, I might be more simpathetic. Its expanding popularity serves as evidence against both of those arguments. All you have argued is that the standards for graduation in computer science are much too lax. ES> [C is used when other languages might be better, because C is more ES> standardized and portable.] Again I say, "The right tool for the job." C has some very nice features, but it is not the only language in town, and it does require a certain amount of skill and caution in its use. Does that mean it should be avoided? Absolutely not! Programmers should know several languages, since no single language can handle all applications (not even Ada). Programmers should also understand what they are doing. If too few can make that claim, then C is not the biggest problem we have. We should require the same professionalism of programmers that we require of most other engineering and scientific disciplines. ES> Erland Sommarskog ES> ENEA Data, Stockholm ES> sommar@enea.UUCP ES> [opinionated comment deleted, again] -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu.csnet