Path: utzoo!mnetor!uunet!husc6!hao!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!uoregon!omepd!littlei!ogcvax!pase From: pase@ogcvax.UUCP (Douglas M. Pase) Newsgroups: comp.lang.misc Subject: Re: Modern langauges Message-ID: <1524@ogcvax.UUCP> Date: 8 Jan 88 08:06:07 GMT References: <1520@ogcvax.UUCP> <1522@ogcvax.UUCP> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 63 In article sommar@enea.UUCP(Erland Sommarskog) writes: >On type conversions: (Explicit or not?) > The key word here for me is data abstraction. Even integer to integer >may be wrong. Had I known you were referring to data abstractions we would have been in agreement long ago. I absolutely agree that they are extremely useful. The Pascal derivatives, unfortunately, do not implement them either. That is one of the advantages I had in mind when I said earlier that Ada has some good points. CLU is another excellent language which has this feature. >Array-index checking: >If you write checks yourself, that seems like a source of error to me. >More brutely said, it sound like the NIH syndrome... If you* wait for the compiler or runtime system to tell you when you make a mistake, that's lazy, perhaps even irresponsible programming to me. If you understood what you were doing, you would have reasonable confidence in your code. This does not mean that such checks are not useful, but a heavy emphasis on them suggests such programmers don't know what they are doing. Again, I am not maligning array checks -- I am saying that programmers should understand their own code! [*"You" in this paragraph is the "generic" form. It does *not* specifically refer to ES.] >On "knowing what he's doing" >Yes. But he should get as much support as possible from the language. Thus, >the compiler should suspect any input. Not the compiler -- THE PROGRAMMER! The compiler can't help much when user enters data the program isn't prepared to handle. In fact, it can't even recover. It can only blow up. Programmers should make reasonable checks to insure the data conforms to expectations, BECAUSE COMPILERS CAN'T. >> [A programmer is simply a translator] > >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. And how do you suppose he gets the words right if he doesn't understand what he's saying? Does "The vodka was good but the meat was rotten" ring a bell? >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. Wonderful. You have just constructed a "straw man" to tear down. You could as easily have complained about C's lack of pattern matching ability, or the fact that it has no backtracking. My comments were never designed to defend C for all applications, nor do they assert that improvements could not be made. They do not even assert that C is better than every other language. I do intend to say that C can be very useful as a tool to a programmer who takes the time and effort to use it correctly, and those who condemn it as a language are unjustified. >Erland Sommarskog >ENEA Data, Stockholm >sommar@enea.UUCP > [I blame no one, but the comment is deleted, again] -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu.csnet