Path: utzoo!mnetor!uunet!mcvax!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.lang.misc Subject: Re: Modern langauges Message-ID: <2582@enea.se> Date: 5 Jan 88 22:51:48 GMT References: <1520@ogcvax.UUCP> <1522@ogcvax.UUCP> Reply-To: sommar@enea.UUCP(Erland Sommarskog) Followup-To: comp.lang.misc Organization: ENEA DATA AB, Sweden Lines: 78 Since this discussion is getting embarassingly long, I'll try to stay brief. I had intented to write no more articles on the subject, but Doug Pase makes some points that tempts me continue a little more. On type conversions: (Explicit or not?) The key word here for me is data abstraction. Even integer to integer may be wrong. Say we have a data structure which has an index array (IA). Each record contains a pointer to a data block. So to address a specific word we need two indexes, one in the IA and on the block. We declare two types: (Using Pascal here) SIA_range : (some interval); (* Index in the IA *) DIL_range : (some interval); (* Index in a block *) Assignment from type to the other does seem like a error. (Easy swapping the parameters in a procedure call.) The compiler I have doesn't mind, so I had to have my eyes open for such. With Ada, for instance, I could left this task entirely to the compiler. It is these kinds of logical mistakes I talk about. Not the risk of losing some accuracy. (But allowing reals to integer without explicit conversion was something I thought only Fortran did. C does also?) Array-index checking: >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 If you write checks yourself, that seems like a source of error to me. More brutely said, it sound like the NIH syndrome... Another comments on range checking in loops: It's only safe to leave them out if the index can't be altered while in the loop. Don't know about C, but this is certainly possible in Pascal. Ada, on other regards the loop index as a constant. Generally, a good compiler should give you the possiblity to surpress checking, either for the entire program, or just a part of it. So you can always the remove the checks on delivery. The quetsion is just: Dare you? The hostile user's may provide data you've never dreamt of. On "knowing what he's 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 Yes. But he should get as much support as possible from the language. Thus, the compiler should suspect any input. > 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. Not really. Your Russian interpreter doesn't need to have a full notion of what you are talking of as long as he gets the words right. But the programmer must. He must understand everything in the specification he has. Very often he can't. The text may not be too clear. The one who wrote it may not even know what he really meant, because he knows not what he want. What have this to with C? Well, a powerful language with good possibilities abstracting the data is a help here to see: "What is to be done?". Does C have the good devices for this? I doubt. Strong type checking is a must here, I believe. >ES> [opinionated comment deleted, again] You'll see it soon again. It happens to have been part of my signature file for a while. Anyone taking it seriously, has to blame himself. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP C, it's a 3rd class language, you can tell by the name.