Program Structure Wars (Real)

A Silly Verbal Tempest In An Even Sillier Teapot

Author: Andrew Mark Kuchling
Date: 1993/02/23
Agree? Disagree? : Have Your Say
Buy Books About This Topic At: Amazon UK Amazon US
Send This Article To A Friend: Email It Use Telepathy

Controversy swirls around computers like chocolate in a marbled cake. Aficionados battle over different models, operating systems, and applications. It is a universal fact that the vehemence of an argument is in inverse relationship to the importance of the arguers. Perhaps the most violent of these debates center around computer languages. There are two extremist camps in the debate:

1. The Structured Programming crowd: This camp believes programs should be clearly and logically broken down into small modules, each one of which will be given a separate procedure. They also claim that many errors can be prevented by implementing a strong type checking system so that different data types (such as integer and real numbers) are not interchangeable, and attempting to use one instead of the other results in an error. Truly fanatic Structured Programmers can easily be recognized; they are the ones simultaneously maintaining flowcharts, pseudocode and procedure trees as they develop a program. Their favorite languages require one to memorize countless functions to convert from integer to real, character to integer, Boolean to character, meaning one has to disentangle skeins of conversion functions. This is supposed to make program code understandable at a glance. It doesn't.
2. The Unstructured Programming group: This group hates to have any rules imposed on them. Many of them cut their teeth on tiny microcomputers, and because of this early experience believe that every line of a program must be absolutely optimal for the machine it's running on. Any technique which is not the fastest one possible is unacceptable. For example, benchmarks showed that the Commodore 64's BASIC evaluated a lone '.' as zero faster than it would a '0'. Many BASIC programs were full of lines like 'FOR I=. TO 255', even in cases where the resulting speedup would be nonexistent, such as in initialization code which is executed exactly once per execution of the program. Such programmers dislike leaving anything to a compiler, and prefer to hand-optimize compiled object code. Moving such code to a different system is a nightmarish task, because the instructions were carefully crafted to fit a certain machine; unstructured programmers live in deathly fear of upgrading (with good reason).

The acrimonious debate between the two parties is eternal. Unstructured programmers use languages like Fortran and C; structured programmers like Niklaus Wirth's languages, such as Pascal and Oberon. Enormous amounts of time are spent arguing over which language is superior, and over whether structured programming is a blessing or a curse. Truly intelligent people don't belong to either religion.

The third group in this melee is that of the Moderates. Moderates completely agree that structuring programs logically into procedures, and using type checking to ensure parameters and results are correctly handled, are Good Things. However, they also know that there are an infinite number of programming situations that a language will have to handle, and that no language designer will be able to foresee them all. Therefore, it is best if a language is loose enough to allow dodging some of its constraints while using others to guard against error; otherwise, limitations that seemed reasonable on the drawing board will become straitjackets, forcing the program code into obscure contortions to accomplish its goal.

From this point of view, all languages are fairly even. With enough care, beautifully designed programs can be written in any of them, and there will never be a language in which it will be difficult to write bad programs. But choosing a language carefully means getting the best of both worlds; safety from careless errors and freedom to design elegant systems.