From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dab7d920e4340f12 X-Google-Attributes: gid103376,public From: kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) Subject: Re: C is 'better' than Ada because... Date: 1996/07/18 Message-ID: <31eecb1b.514194522@netline-fddi.jpl.nasa.gov>#1/1 X-Deja-AN: 169571584 references: <31daad10.57288085@netline-fddi.jpl.nasa.gov> <4rgqp7$iv6@btmpjg.god.bel.alcatel.be> <31e02c32.342948604@netline-fddi.jpl.nasa.gov> <4rvr2j$2gb0@info4.rus.uni-s content-type: text/plain; charset=US-ASCII organization: Jet Propulsion Laboratory mime-version: 1.0 reply-to: kdq@emoryi.jpl.nasa.gov newsgroups: comp.lang.ada Date: 1996-07-18T00:00:00+00:00 List-Id: On 18 Jul 96 07:12:10 GMT, nasser@apldbio.com (Nasser Abbasi) wrote: >But on a side point, I dont think measuring productivity of >a programmer by lines of code makes any sense. It certainly makes much less sense now than it used to, when good libraries etc., weren't readily available. >But for someone today to write code in assembler, unless there >is a very good reason to, really do not make sense. Agreed. Bad assembler is worse than bad anything else, except microcode. It should be used only when necessary due to real-time constraints or hardware idiosyncracies. >So I assume you turn off the type checking feature of your compiler when >you compile? :) No, it catches typos that would otherwise take another iteration to find. I also have it set to the highest levels, to catch those occasions when I haven't been careful about casting variables. >Well, there might be truth to this, but this is like throwing the baby >with its bath water . People shouldn't not use those features just because there can be a problem. But it *can* be a problem, especially when the programmer depends on the compiler to catch everything, and then goes to a different compiler that doesn't bother (and the programmer isn't equipped to find the problem). I don't mean to say that this is a common problem/ >Just becuase some programmers will not bother >checking things too carefully befor submitting the code the compiler becuase >they say , lets let the compiler tells use what's wrong, this do >not mean that the whole idea of compilers that do strong checking are >bad idea. I agree, and as I said, I usually invoke the strongest warning levels available. >This is also like saying that cars with strong breaks are bad >idea, becuase some people will then speed up too much knowing that if they >have to stop suddenly, the breaks will always stop the car in time, and >they become sloopy drivers instead of slow carfull driver, so becuase of >this we then should not build cars with strong breaks. Actually, people with ABS brakes on their cars have been sued by people who have rear-ended them. After all, the argument goes, if the car in front didn't have ABS brakes, it wouldn't have been hit. >The more strict the compiler, the better it is. I want the compiler to >be very picky. So do I. >I like picky compilers and picky langauges, I agree with the former but not the latter. -- #include http://emoryi.jpl.nasa.gov/ _ Kevin D Quitt USA 91351-4454 96.37% of all statistics are made up Per the FCA, this email address may not be added to any commercial mail list