Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!oddjob!hao!noao!mcdsun!sunburn!gtx!edge!doug
From: doug@edge.UUCP (Doug Pardee)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Any reasons for using C on a PC (is it the fastest thing around?)?
Message-ID: <670@edge.UUCP>
Date: Tue, 21-Apr-87 14:25:58 EST
Article-I.D.: edge.670
Posted: Tue Apr 21 14:25:58 1987
Date-Received: Fri, 24-Apr-87 05:33:16 EST
References: <3180@jade.BERKELEY.EDU> <874@chinet.UUCP>
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 66

I have to agree with everyone else; C is almost certainly here to stay.  It's
the high-level language which is most likely to join the ranks of FORTRAN and
COBOL as "immortal" languages.

In the specific case of the PC, the existence of Turbo Pascal has given the
Pascal language a temporary boost.  It didn't do much for other computers,
though.

So, if you have a reason for programming in a high-level language, and if
the application doesn't immediately suggest using some other language (for
example, a structural engineering program would be best written in FORTRAN),
then C is indeed the language of choice.

But but but but...

If you're writing a program that you hope to sell commercially (a software
product, that is), pay no attention to the folks who tell you to use C, or
for that matter, *any* high-level language on the PC.

Yes, it's true that there are a lot more software products written in C and
Pascal than there are written in assembler.

It's also true that nearly all *successful* software products for the PC
are written in assembler.

Quotes like this one:
    >   As microprocessors become more powerful, the programmers' time becomes
    > more important - productivity reigns over program speed.
come from programmers who are concerned about doing a minimum amount of work,
*not* from potential customers.

If you try to tell some poor guy who has a 256K PC that in order to run your
program he "only" has to get a 10MHz Turbo-AT with 640K of main memory and
then not have a RAM-disk, and he can't load Sidekick or any other pop-ups,
just to run your wonderful program, guess what he's gonna say!

There's a reason that people are buying ATs, Turbo-ATs, and '386 boxes:  they
want/need *speed*.  And there seems to be never enough memory in any given PC,
especially with all of the TSRs (Terminate-and-Stay-Resident programs) that
people like to keep around.

And now for a cheap shot:

>   A popular way to develop programs for the PC is to write the entire
> application in C, then if it isn't running fast enough, run an execution
> profiler to find where you are spending time.  Then, re-write these
> routines in assembler.

This is a popular thing to *talk* about doing.  Almost nobody ever does go
back and profile and rewrite.  Can't say as I've seen any discussion on
the net about the "best" profiling package.  Having been involved in the
profiling business, I can testify that everyone who has ever really used
a profiler has very strong opinions about which ones are good and which are
bad.

Besides which, there are "distributed" inefficiencies in any high-level
language that won't appear on a profiler, and couldn't be individually
recoded in assembler anyway.  The two most common ones are a) procedure
call overhead, especially parameter passing, and b) overall size of the
instruction code.  A third distributed inefficiency can occur when there
is no straight-forward way to implement a major data structure, and every
reference to it has to be done with a kludge.

I'll skip the details, this posting is already ghastly long.

-- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona