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: 1014db,dab7d920e4340f12 X-Google-Attributes: gid1014db,public 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/19 Message-ID: <31eecd86.514813783@netline-fddi.jpl.nasa.gov>#1/1 X-Deja-AN: 168778686 references: <31e02c32.342948604@netline-fddi.jpl.nasa.gov> <4rr961$hdk@btmpjg.god.bel.alcatel.be> 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,comp.lang.c Date: 1996-07-19T00:00:00+00:00 List-Id: On Thu, 18 Jul 1996 08:52:35 -0600, helink@sandia.gov (Hamilton Link) wrote: >1) programming well is just as easy in assembly as Ada, and My point is that it must be the programmer who writes well; a language cannot force you to write good code. It can certainly help. A poorly chosen algorithm is not an excuse for using assembler to help regain the time lost due to the original poor design. For those occasions where response time has to be measured in micro-seconds or less, HLLs rarely suffice. When they do, use the HLL. >But for this very slight percent speedup, what has been sacrificed? Let's >make a list:...Readability...Portability...Modifiability Which is why it shouldn't be used unless it's the only thing that will make the project work. For commercial applications, and even most OS work, it isn't necessary and shouldn't be used. For embedded applications with special hardware and special requirements, it's likely always to be necessary. >I prefer OS/2 to DOS because when something goes >wrong I can kill the process rather than reboot my machine. Under any circumstances you want to be able to determine the problem. I was speaking more towards writing through a null pointer under UNIX versus under MSDOS. In the former, you get a core dump (or trapped back to your debugger) such that you can always determine where the write takes place. Under MS-DOS, you get a cryptic message when you exit the program, with no way to tell where the offense occurred. This latter tends to make for programs that work by accident, and not by design. I don't think we really disagree (much, anyway). I do not think people should be programming in assembler unless that's what it takes to make things work at all; doing embedded code, the credo is "whatever's necessary" (accent on the necessity). -- #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