Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site zaphod.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!alberta!sask!zaphod!bobd
From: bobd@zaphod.UUCP (Bob Dalgleish)
Newsgroups: net.works
Subject: Re: Fie on assembly language?
Message-ID: <204@zaphod.UUCP>
Date: Mon, 11-Mar-85 14:50:48 EST
Article-I.D.: zaphod.204
Posted: Mon Mar 11 14:50:48 1985
Date-Received: Tue, 12-Mar-85 22:54:59 EST
References: <792@topaz.ARPA> <836@ames.UUCP> <425@terak.UUCP>
Organization: Develcon Electronics, Saskatoon, SK
Lines: 42

> > the person at hughes [radar systems] was sad to mention
> > large portions of their work in still in assembly language due to management
> > familiarity and pressure.  they were just now moving projects into jovial
> > because young people were taking jobs.
> 
> ... High level languages have their place.  So do assembly languages.
>  
> But as a general rule, the reason for *not* using assembly language is
> because of the initial programming costs.  Once the program has already
> been written and those costs incurred, assembly is almost always
> superior to higher-level languages.
> -- 
> Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug

The reason for *not* using assembly language is the initial programming
cost, debugging cost, and when you finally have a running system, and the
customer needs new functionality or wants different hardware,  the
redesign cost, the reprogramming cost, etc.  The initial development of
a system accounts for only about 30% of its life-cycle cost, the rest is
dubbed Maintenance.  When you look at costs, you have to look at all of
them, including the task facing the designers/programmers that come
after you.

I have traditionally used about 10% assembler code (yes, it does have a
place), mostly where time or space require it.  The rest of the code is
higher-level, mostly because the higher-level language gives me the
leverage I need to accomplish the task.  Performance problems are
addressed during the design stage when critical timings are
identifiable.  Sometimes we have to go back and speed things up when
performance is below acceptable levels.  Performance problems, like bugs
occur where you least expect them.  If you code everything in assembler
(my own experience, remember), you have lost a lot of your flexibility
when you have to recode the algorithm, and you also spend a lot of work
optimizing things that don't need it.  60% of our code is not executed
except during exceptional conditions; it doesn't need to be fast, just
correct.
-- 
[The opinions expressed here are only loosely based on the facts]

Bob Dalgleish		...!alberta!sask!zaphod!bobd
			      ihnp4!
(My company has disclaimed any knowledge of me and whatever I might say)