This month's Editor's Notes are
written by Tom R. Halfhill, Editor of COMPUTE! . -Robert C. Lock,
Editor-In-Chief.
We received some interesting letters in response to our September 1985
Editor's Notes. As you may recall, it was argued that machine language
(ML) will remain the dominant language for commercial software, even
though many of the first programs appearing for the newest generation
of personal computers-such as the Atari 520ST and Commodore Amiga-are
written with compilers such as C. The argument was that ML is and
always will be the computer's native language, and since higher-level
languages run slower and consume more memory, they will always be
superseded by ML for commercial software.
Here's a dissenting letter from reader Jeff O'Neil
in Plano, Texas:

I feel there will
continue to be a migration away from assembly language with more use of
higher-level languages, such as C, for application programs. The
driving force is programmer productivity-being able to quickly bring
good products to the market and also being able to quickly port the
same program from one machine to another. Languages such as C can be
effectively used on- the newer micros because of better compilers and
because of the larger memories available. No longer do you have to
spend an inordinate amount of time trying to squeeze the code into 64K.
Assembly language will continue to be used for operating systems and
compilers, but less and less for application programs.

While last month's Editor's Notes presented one side
of the higher-level language discussion, Mr. O'Neil presents a point
of view also shared by some editors.
One of the lessons of industrialization is that a
machine will always take over a task from a person if it can do the
work faster, better, or less expensively. A compiler, in effect, is a
device that generates object code from the programmer's high-level
source code. Because high-level code is easier to write, compilers make
it possible for programmers to finish a program faster than if they
were writing in low-level ML to begin with. Certainly, none of the
highlevel compilers currently available can generate object code as
good as that written by an experienced ML programmer using an
assembler. But they don't have to. They need only be good enough.
For example, the vast majority of application
programs announced to date for the 520ST and Amiga are written in
compiled C. Potentially, they could be even better programs if written
directly in ML. But it would take longer to write and debug the
programs in ML, increasing development costs accordingly. To recover
this larger investment in programmers' time, the software companies
would be forced to charge a higher price or accept less profit. By
transferring a task to a machine-in this case, using a compiler to
generate the object code-they finished the job faster and still created
good programs. That's the classic equation for greater productivity.
This principle has been demonstrated time and again
for hundreds of years. In all probability, the clothes you wear, the
car you drive, the furniture you own, the books you read, the TV set
you watch, and so on were not painstakingly handmade by skilled
craftsmen. Most of these things are manufactured largely by machines.
Handmade versions are available, but top quality is not always the
ultimate consideration. If it were, people would hire freelance
programmers to write custom programs entirely in ML, no matter what the
cost.
Furthermore, compilers are constantly being
improved. Someday-especially if there are breakthroughs in the field of
artificial intelligence-we may have compilers which generate object
code that matches or even surpasses the code written by good ML
programmers. At the very least, compiled languages will continue
getting better, and the most time-critical routines can be rewritten in
ML-just as many other products today are made partly by machine and
partly by hand.
And don't forget another factor that affects
programmer productivity - training time. The rapid pace of computer
technology means that ML programmers have to master the instruction set
of an entirely new chip every few years. But high-level languages can
be implemented on any chip, so programmers only have to learn the
language once.
The programmer productivity factor also is closely
tied to marketability. If software companies invest the programmer
time in writing all-ML programs, they risk missing a window of
opportunity. And in the fast-moving world of personal computing, a few
months can make or break a commercial program.
Portability, too, is related to productivity. If
programmers can write a major program in a high-level language and
translate it for noncompatible computers with a minimum of fuss, they
can double or triple the potential market and reap a higher return on
their time.
For a preview of what's to come, look at the world
of minicomputers and mainframes. Application programming is
increasingly done in high-level languages. As personal computers keep
growing more powerful, we too will see more and more application
software written in high-level languages instead of ML. The extra
horsepower built into the machines will make it less necessary for
people to spend tedious hours building extra horsepower into the
programs.
Computers are boosting productivity and reducing
sweatwork in hundreds of occupations; why should computer programming
be any different?