Editor's Notes
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?