Path: utzoo!utgpu!tmsoft!mason From: mason@tmsoft.UUCP (Dave Mason) Newsgroups: comp.lang.misc Subject: Re: Modern langauges Message-ID: <209@tmsoft.UUCP> Date: 4 Jan 88 16:51:11 GMT References: <1520@ogcvax.UUCP> <1522@ogcvax.UUCP> Reply-To: mason@tmsoft.UUCP (Dave Mason) Followup-To: comp.lang.misc Organization: TM Software Associates, Toronto Lines: 129 Pase & Sommarskog have been bashing each other for a while now, and both of them have made some valid points. Let me just add another viewpoint in case anybody else is interested in this debate. (Hmmm 45 minutes later this has gotten rather long, but there are some newish (and maybe even interesting :-) ideas, and only about 70 of the lines are mine, the rest are context) In article <1522@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes: >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. >I am neither in favor of change nor against it. I am in favor of flexible >languages and programmers understanding what they are doing. > >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 think part of the point here is that there aren't many `modern languages'. Particularly not in this discussion (here I don't mean modern to mean `recently designed', but rather `designed with new and better ideas'). C, Modula2, Pascal and to some extent Ada are equivalent languages, 15 years old with minor syntactic sugar differences. The major differences are in how strictly the compilers enforce language rules. (Ada does have some `new' (and maybe even some `better') ideas. Prolog has some `new' (and probably `better' for some application areas) ideas.) >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...] > >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? > ... >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. I feel there are 2 areas where C is more error prone than the Pascal class of languages: parameters and pointer arithmetic. I think the new ANSI C definition with function prototypes addresses all the problems with value parameters, and wish the compilers required function prototypes all the time. I feel previous C compilers left too much of the consistency validation to `lint', which because it is a separate program is too often forgotten. var parameters in C are a design flaw, but I don't think they cause TOO many bugs (not of the lurking type anyway). Pointer arithmetic is a trade off: lots of power ==> potential errors. I think it's worth the trade-off. >DP> [Runtime] bound checks are expensive in terms of efficiency. >ES> This, I'd say, is an really old-fashioned argument. > >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. I agree with both on this one. Bounds checks are worth having (partly because not all programmers have DP's discipline, and you usually over-run bounds when the program has been in place & working for years (unless you test it RIGHT)). I have a language I've designed that combines the best of pointer arithmetic & checked bounds and is easy to compile. (I.e. the efficiency of pointer arithmetic, with checked ranges, but the check is done at compile time or outside the loop) So I feel it's a language design problem, but that the Pascal languages didn't solve it right. >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! Yes, and no. At a certain level, we better hope the programmer knows what they are doing (regrettably hope is often all we have). But that does not mean that the language should stand idly by and watch the programmer foul up. All of us as programmers can deal with certain levels of complexity & detail (with order-of-magnitude differences between programmers). The more the programming language helps us deal with and hide the complexity and detail, the more likely that Klutze Programmer's weapons control system will work rather than start WWIII (and the more likely that the genius programmers among us can build Truly Great And Important Programs to Better Our Way Of Life). >ES> [C is used when other languages might be better, because C is more >ES> standardized and portable.] That's the main reason I use it (although I'm an assembler hack at heart, too, so the `portable assembler' nature of C attracted me). I used to use Pascal, but as I started using more different systems, the only thing they had in common was C, and as I was getting too old to re-write all my tools for every new environment, I standardized on C (and Unix when I can get it). > >Again I say, "The right tool for the job." Good in theory, but if you want to stay portable, C is often the only tool (except for Fortran, of course :-). That doesn't mean I don't use other languages. But rarely for anything big. If it's big, I'll probably want it in several different environments, and also that it's worth my time writing the utility functions to give me the power that the other (`better') language would have given me. One of the most important reasons for knowing other languages though is the introduction of other programming paradigms. I'm currently playing with LOGO, for exactly that reason (and cuz there's a couple good books by Brian Harvey, and I'm considering teaching first year computer science in Logo). > ... We should require the same >professionalism of programmers that we require of most other engineering >and scientific disciplines. Now that's a REALLY scary thought! (Baupal, India; Challenger; Love Canal) >ES> Erland Sommarskog >ES> ENEA Data, Stockholm >ES> sommar@enea.UUCP >Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu.csnet ../Dave Mason, TM Software Associates (Compilers & System Consulting) Ryerson Polytechnical Institute ..!{utzoo uunet!mnetor utcsri utgpu lsuc}!tmsoft!mason