In 1957, the military draft was very active, so instead of waiting to be drafted at an importune time, right out of high school, I joined the U.S. Marine Corps, to have some influence over my destiny. Through some luck and some good high school math skills, I was assigned to work in the new area then called Data Processing. Machines were used to read cards and do calculations for science, business, and government problems. We obtained an IBM 604 Electronic Calculating Punch, similar to the one in Figure x.1. The machine was programmed by a pluggable patch panel. See Figure x.2

Pluggable Patch Panel

Figure x.2

My situation reminds me of a part of the following poem I read many years ago:

"I'm sixty-eight" he said,

"I first bucked hay when I was seventeen.

I thought, that day I started,

I sure would hate to do this all my life.

And dammit, that's just what

I've gone and done."[1]

Little did I know that 50 years later I would still be programming computers just like the man in poem was still bucking hay 50 years later. An early job often influences our employment for the rest of our life.

I have tried to trace particular programming statements from the beginning through several revisions into modern languages. This is tricky for several reasons. First, a programming language or a statement is not born at a particular moment. Programming statements have a birth more similar to a plant than an animal. With animals, like us humans, we can determine that Dennie was born at a particular date. But plants are more difficult to date. Is a plant born when the seed falls to the grown, or when the seed opens and geminates, or when the plant becomes visual above the ground? I bet some biologist can tell me the answer. Programming statements are discussed, mentioned in a research paper, used by some experimental group, and then finally used in a couple languages. During all this, the statement may be improved and changed, and finally standardized.

Besides this issue of birth, there is the problem with my memory and knowledge. I can only talk about languages I am aware of, or languages I have researched. Luckily for both of us, I have used most of the languages discussed in this book, and a few others not mentioned much like APL, RPG, SPSS, GPSS, LISP, SNOBOL, etc., and others. And finally ones memory plays tricks, especially when comparing numerous similar statements and languages. If you find areas that you think I have missed, send me e-mail or a letter, and I will consider it for the next edition.

Another problem is where I discuss a topic. Often there are several places. For example, should we discuss comparison when we cover loops, if statements or while statements, or should comparing values be discussed separately? When there is more than one obvious place to discuss a topic, I have tried to cross-reference the other places. Sometimes on a small topic it is easier to discuss it right there again, then to point you to some other place.

Other books compare languages, but this book compares programming statements. When we look at how a particular command has evolved (e.g. case statements) we can sometimes see how the command has improved. But sometimes we will not have agreement about some of the “improvements.” Also, commands will reflect the environment they are used in. For example, a case statement used with a scientific programming language like FORTRAN or C++ will be different than a case statement used in a character scripting language such as Tcl or Python. One is not better than another. The two variations have different purposes.

Some commands are interesting because they were available very early (if statement), are still similar and vary little between languages. Other commands had a later difficult birth (switch statement), and still vary drastically between languages. While the if statement is mostly the same with few variation, the assignment statement has at least seven variations, probably because it is the most used statement.

This book has three obvious uses, which are:

Survey of programming language course.
Historical study of programming language statements.
Reference document for variations of program statements.

Junior level programming students often have only programmed in two or three languages and these languages may be in one family of languages, such as the C family (C, C++, Java). By looking at different language families programmers will discover there are other good ways to solve problems.

Readers interesting in the history of programming statements will find this book a rich source of early language design and see how commands have changed and improved.

New languages are still being designed and promoted. For these people designing new languages this book should provide a fast reference on how commands have evolved and the many variations available across a wide variety of languages.

Finally, I wrote this book for myself. I have over four decades of programming experience in my head and have worked in dozens of programming languages. It has always been interesting to me to see how programming commands are similar but also different. I wanted to write down my observations and hope they are useful to you as it has been for me to trace through the historical language in my life. Thank you for letting me do this and good luck.

Typographical Conventions Used in This Book

I have tried to follow the standard typographical conventions used in programming books. Reserved or keywords are usually in bold, which is gets a bit tricky deciding when I am talking about the return of a value or the command return. When you read the section on reserved words, you will find out it is not always obvious what are reserved words (e.g. sqrt), and thus what should be in bold. Finally, code examples are meant to be in a fixed font like Courier. Otherwise, we cannot align items, as we need to. Deciding what case to type program statements has been a quandary for me. I have tried to type the statements in the case the language used at the time period being discussed. Thus for C language, I use lower case, but early FORTRAN or BASIC I use UPPER case. Then in modern versions of these languages I have switched to lower or mixed case as the languages evolved.

Often I attempt to show you the general form for statements. When I do, it often looks something similar to this:

FOR var = initial-value TO terminal-value

[STEP increment-value]

DO {WHILE | UNTIL} condition

Keywords such as FOR or DO are in bold and parts you need to supply are italics. Optional items are in square brackets, such as [STEP increment-value]. Items in braces separated by a vertical bar such as {WHILE | UNTIL}, indicate we must choose one of the items. It is not always easy to indicate correct general format since languages change over time in versions or dialects. And it helps me say something like this, since it covers up my errors.

So any error you think you find in this book is carefully crafted attempt to teach you to spot errors and test your knowledge of the material. You should also know that your teacher uses the same technique in her lectures. She is just testing your knowledge and attention to see if you will politely point out the problem.

Terminology

The terminology used to describe programming concepts is not always agreed on. The use varies by language. For example, some languages use the words identifiers for field names while others use variables. Next we have functions, procedures, routines, subprograms, and subroutines which are all functions in C. For declaring variables we use definition and declaration. Finally, for objects we use class, object, module, and package.

Often the terminology has changed. In modern languages there are commands to manipulate part of an array, such as a row or column. Nowadays, this is called a slice of an array, at least in Perl. But previous languages such as PL/I, this was called cross sections of arrays. I have tried to use the terminology used with that language being discussed. Often, I explain that today this concept is called such and such. For example, when describing records in older languages, I explain they are really the same as structures in newer languages.

Lexical Structure

When we use a written language, there are units or lexical items in that language. For example, we have words, punctuation, and spaces. Programming languages also have units or lexical items. These lexical items are often called tokens in programming languages. Examples of tokens are identifiers, reserved words, literals, operators, separators, and comments.

Identifiers are names chosen by the programmer to identify items. Examples are variables and function names. A special type of word is a keyword or reserved word. Commands such as for, while, and if are keywords and often reserved words. Identifiers and reserved words are covered in detail in the Identifier Chapter.

Early Computer History

In order to understand why early computer languages and statements were done in ways that may seem strange to us now, we need to understand some of the limitations on early hardware, especially computer keyboards. For example, early keyboards had no lower case letters (abc…). They only had upper case (ABC…). Thus case sensitivity could not be used for statements or variable names.

Also, the keyboard character set was extremely limited, having uppercase letters, numbers, a very few punctuation or arithmetic characters. There were only round parenthesis and no square brackets […], or curly braces {…}. These pre-1970 keyboards had a colon, but no semicolon, so the “invention” of the semicolon statement terminator had to wait.

Since all computer input was done on computer cards (no CRT screens for a long time) everything was very line (card) oriented and position oriented. Cards had 80 positions. And a card (line) could be retyped, discarded, or inserted in the card deck. Since we were working with cards it is clear why lines were so important, but looking back it is not clear why position was so important, but it was.

These 80-column cards still affect us. Most computer screens were set up to handle 80 columns and are still that width, 40 years later. It is interesting how long a historical coincidence (80-column cards) affect the future.

Both early FORTRAN and BASIC used comments that had to be indicated in position 1. A FORTRAN comment was indicated by a C in position 1, and BASIC used REM (for Remark) in positions 1-3. FORTRAN programming statements must be in positions 7-71 and COBOL statements much be in positions 8-71. Both COBOL and FORTRAN used positions 73-80 for optional sequence numbering of cards in a deck, so you could put the deck back in order by hand after dropping the 226-card program deck on the floor.

I covered this so you understand why lines and positions were so important for early computer statements and why this influence continued after card use faded away. ALGOL was the first language allowed programmers to write code free field, without regard to position or card boundaries. ALGOL statements may begin anywhere on the input line, and may end anywhere on the same line or on a succeeding line. This was a new concept.

Any one interested in programming languages might want to look at a few of the significant dead and live languages that have had large influence on programming languages. First, is ALGOL that has had major influence on the C family of languages, which include C, C++, and Java and their variations. For those interested in record processing, COBOL is a good place to start. COBOL not only was one of the most successful languages, but it pioneered how to handle records and influenced later database languages such as SQL and database applications. Ironically, COBOL is seldom mentioned in most histories of programming languages.

When wanting to see what a language can do, then we need to look at PL/I and Perl. PL/I was designed and supported by IBM in the 1960’s. PL/I (Programming Language One) was an attempt to provide one language for ALL programmers. The language designers looked at all the then present programming languages (COBOL, FORTRAN, assembly languages, list processing languages, system programming, etc.), and developed one language could do everything. PL/I was used for business processing like COBOL was good at, for scientific programming like FORTRAN was used for, for assembly language tasks, for list processing, and any thing else you wanted. PL/I had a huge following for a decade or more. But PL/I’s size and the fact that PL/I was a propriety language owned by IBM is what probably caused its demise. But if you thinking about how to design or implement some set of features, you might want to look at PL/I. Those that do not like PL/I will probably tell you that you the best approach is to not look at PL/I.

A modern language that is smaller in size, but has adopted many clever features is Perl. The brilliance of the design of Perl is impossible to miss. Other similar brilliant modern languages are Ruby, Python, and PHP. These languages have large cult followings and will be interesting to watch in the future as far as their durability and number of users.

The sources of a language influence the language design. Some languages were designed by one or two people (C, C++, Perl, Python, PHP, and Ruby). You can see the conciseness and completeness in these languages. At the other end of the language design spectrum, are languages that were designed by large groups of people (COBOL, Ada). These are large languages and not so logically neat. Then there are corporation languages that were designed and are sponsored by a company. Example of corporation languages are PL/I (IBM), Java (Sun), and both C# and Visual Basic from Microsoft.

Obsolescence and Survival

Some languages become obsolete as new programming knowledge becomes available. But other languages evolve and survive by changing instead of dying. For example, FORTRAN IV could be said to be obsolete since it does not have block structure, required type declarations, nested control structures, and other features of newer languages. But FORTRAN IV is still used. By contrast ALGOL had all those features and is not used any more. One way FORTRAN was saved is its numerous revisions which include FORTRAN II, IV, ANS FORTRAN (66), 77, 90, 95, and 2003 to mention the most obvious ones. Also, FORTRAN had a powerful corporate supporter (IBM) and ALGOL did not a sponsor in the U.S.

Two ways to revise languages have crept in to language revisions. If we look at HTML, which is used for developing web pages, we labeled items as obsolescent and deprecated. A feature is often deprecated before becoming obsolete. A deprecated feature is an existing feature that has been outdated by newer constructs or is no longer viable. A feature is obsolescent if it is a command or feature that may be dropped in later versions of the language. This feature is deprecated, meaning that it is currently supported only for backward compatibility with existing applications. Future versions of the language may no longer support this function.

Language Names

On older languages, it is often difficult to even figure out the correct name for the language. For example do we use BASIC or Basic? Since BASIC is an acronym you may feel all caps is correct, but then comes Microsoft Visual Basic, and then do not use all caps for Basic. Then do we use FORTRAN or Fortran? Early versions of FORTRAN were always capitalized. IBM came up with the name FORTRAN as a contraction of the rather quaint "FORmula TRANslation". But starting with Fortran 90 the official language name is no longer capitalized. Both versions are commonly used. Next, we get into language dialects and exactly how to indicate them. Do we use ALGOL 60, or ALGOL60, or ALGOL-60? With FORTRAN we have FORTRAN II, FORTRAN IV, FORTRAN 77, 90, and 95 to worry about. There are often at least two solutions. There may be the official language name, BASIC, but also the more common usage, Basic.

Case of Language Commands

Often, there is the question of what case (UPPER or lower) to illustrate commands in a particular language. Early FORTRAN and COBOL used all upper case, so that is what I use for the for discussing early versions. But both languages adopted mixed case later on, so then we have the choice of using upper and lower case. Pascal started as just upper case, but keyboards with both lower and upper case became popular, so Pascal fastly switched to using both upper and lower case. C uses mostly just lower case. C++ uses more mixed case. Java and C# uses mixed case. I have made some attempt to be consistent to what the language did in the version I am discuessing, but this is often not a easy decision, especially in the mid-period when things were changing.

History vs. the Present

In the 1970s or maybe the 1980s, there was a computer science joke going around as follows: What happens if you have an interesting problem and you ask a computer scientist to write a program to solve it? The answer was they come back a year later, with a new programming language ideally suited for solving the problem.

I think if you tried the same question nowadays, the answer would be that they would use language XYZ (you choose the language) to solve the problem, no matter how bad it fits. A couple decades ago there were a few thousand active languages. Now I expect the number is under a hundred. All problems are attempted to be solved with the same type of languages. So we have gone from one approach of inventing a new language for all interesting problems, to using one language to solve all problems.

Here are a few quotes from famous people about how some language were supposed to take over the world of programming.

Recently Pascal has become the lingua franca or common tongue of the computer science academic community.[2]

Ada will doubtlessly gain a significant share of the programming language market. Its use here is not an endorsement, but the recognition of its scope and its growing importance.[3]

And Pascal, which was developed as a teaching tool, is fast becoming the standard language available on microprocessors and the major language taught in academic departments of computer science.[4]

[For the assignment notation “:=” instead of “=”.] Almost all language all programming languages now use this notation.[5]

Because of these characteristics and the strong support of the Department of Defense, it is anticipated that Ada will be the primary language used by professional programmers by the year 2000.[6]

I give you those quotations to show you how difficult it is for us to know what languages will be successful and which will disappear. All of these people quoted are very smart people, smarter then me, and they still have not been able to correctly predict language success. I could find you numerous examples predicting the death of FORTRAN, BASIC and COBOL and all three languages have outlasted the predictors and most the languages they thought would take over the world. To show you my own skill in predicting the future of computer, here are some of my predictions:

Programmers will always want to use IBM cards, since they are so useful to sit and read.

CRT screens will never be as popular as print devices (teletype), since we want a paper record of our work.

I don’t see how they can improve Microsoft Word any more (made around 1990).

So you can see my predictions are even worse, which will not prevent me from making more predictions.

Language Groups

There are groups of languages that have had a major influence on present day and past computing. Besides their historical interest, we can recognize that since the languages are similar, their syntax and commands are similar.

The UNIX and C Group

We cannot really discuss the C family without recognizing its relationship with UNIX. Most programmers recognize the relationship of C, C++, and Java. Most of the commands are the same in all three languages. But there is a much larger group of languages if we look at UNIX. Then we have UNIX shell programming, awk, sed, and Perl. Another language that has a lot of the same commands and syntax is JavaScript. This is one of the arguments for teaching C/C++ programming as a first language since C syntax is used in so many other languages.

The BASIC Family

The BASIC language has also spanned a group of languages. Examples are QBASIC, Visual Basic, VBScript, and VB .NET. The commands and syntax is all very similar in these languages. And new versions of BASIC has added many modern techniques for programming. The BASIC family is interesting since it started as an independent language but Microsoft was taken it over.

FORTRAN

While the previous two groups have evolved by spawning many new languages and new dialects, FORTRAN has modified itself. We have seen FORTRAN II, IV, 77, 90, 95, and 2003. Each version has integrated a remarkable group of programming techniques.

COBOL

COBOL has taken the same road as FORTRAN, continually adding new versions. COBOL has versions: CODASYL COBOL, ANSI COBOL-68, COBOL-74, COBOL-85, and COBOL-97. Besides these standard versions there are many versions of COBOL that run on particular hardware or software. And COBOL has heavily influenced database languages with its records and fields.

There are other interesting ways to group languages. For example, there is the Swiss army knife group,[7] which includes PL/I, Ada, and Java. PL/I combined the record handling techniques from COBOL, the block and statement syntax from ALGOL, scientific programming tools from FORTRAN, and tools necessary for assembly language and system programmers. Thus we have one language that has all the tools and features that any programmer would need. The idea is that the programmer only needs to pick the tools they need for their task. The scientific programmer picks tools for scientific programming and the business programmer picks tools for scientific programming. Another term for a language that has everything is kitchen sink language because the language has everything but the kitchen sink.

But programmers may not want to spend their whole day at the kitchen sink. The exact usage of these two language descriptions varies, but kitchen sink language is usually a prerogative meaning, since it is too complex. There are too many features and too many ways to program similar problems. By contrast some people use the term Swiss army knife language (e.g. Perl) as a positive trait because you can do so many neat things with it. Languages often start as Swiss army knife languages, and become kitchen sink languages as more and more features are added. This seems to be a very difficult pressure to resist. For example, neat C has turned into C++ and Java with many features, Fortran has gone through numerous revisions, all adding more features. Even neat Perl is criticized for its added features.

Other groupings interpretive languages like BASIC, APL, and Perl, vs compiled languages like COBOL, C, and Java. File processing languages would be COBOL, PL/I, Ada, SQL, and database languages.

Answering Questions

In many of the exercises, I ask you to compare some language feature in two or more languages. The comparisons are often (but not always) boring if you compare language in the same family such as C++ and Java, or BASIC and Visual Basic. If you compare a C family language to a scripting language such as Python or Perl, you may get some interesting results. But if you compare a language command in the C family, such as Java to a language in the BASIC family such as VB .NET, then the comparison gets much more interesting. So when asked to compare commands in different languages, use different language families as indicated in the past few paragraphs. If I think a comparison between similar languages is interesting such as C++ and Java, or F77 and FORTRAN 90, then I will suggest that. And there are some important differences within language families. For example, C++ and Java differ on how they handle Boolean values, and F77 introduced DO loops with floating point variables. But in general comparing features in closely related languages or language dialects is not very informing or interesting.

Other Language Groupings

There are many other ways to group languages. Another way would be grouping into object-oriented programming languages such as Java, C++, Modula-3, Ada95, and Smalltalk. Then the second category could be imperative programming languages such as C, FORTRAN, Pascal, Basic, and COBOL. Finally the functional languages (Lisp) and the logic languages (Prolog) would be other groupings of this type of breakdown.

Corporate Languages

Some programming languages have sponsors or promoters – usually for economic interest. Examples today are C# and Visual Basic from Microsoft, Java from Sun Micro Systems. Earlier examples are FORTRAN and PL/I from IBM. Finally, Ada has the substantial sponsorship of the U.S. Department of Defense.

Not all sponsorships are successful. Even with IBM behind PL/I, it has faded. It is very difficult to figure out why some languages last and other languages fade away. Even strong powerful sponsorship (IBM for PL/I, and U.S. DoD for Ada) does not make a language successful. By contrast C had no sponsorship and has done very well.

I will make some observations, that may not be correct. Both PL/I and Ada are very large complex languages. PL/I was controlled by IBM and programmers are caution about getting hooked on propriety languages.

Our Programming Language (OPL)

One major component of this book is for you to develop a new programming language. I call this new language Our Programming Language (OPL). After you read about the history and variations of a command such as the switch statement, then you will find exercises for you to develop a new switch statement.

When reading about all the neat programming statements, you may be tempted to provide everything possible in terms of statements. The two languages that did that exact task very well are PL/I and Ada. These two languages have everything. PL/I can be classified as a near dead language. And Ada is not used outside the U.S. Department of Defense (DoD). By contrast, a fairly small language named C, has been widely successful. Other fairly small languages, Perl and JavaScript are very successful today. I have seen too many languages disappear from use (ALGOL, Pascal, Ada, Lisp) that were supposed to take over the world to make predictions on what will succeed.

In contrast BASIC, COBOL, FORTRAN, and C/C++ continue on as popular as ever. These old languages have gone through many revisions, and have adopted (sometimes with difficulty) newer programming techniques. What popular computer language used today, do you think will fade away10 years from now?

Designing new Programming Languages

Before jumping in on designing a new programming language, you might search the research on this topic and see if you can find any good advice. One place to start is with Tony Hoare’s The Emperor’s Old Clothes[8], where he offers this observation:

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

Early C and BASIC came close to having no deficiencies. PL/I and Ada often used as examples of languages that have no obvious deficiencies.

Language Standardization and Revisions

Programming languages that last long enough are often standardized or “improved.” The original version of C was defined in first edition of The C Programming Language by Kernighan and Ritchie. This was a delightful book, but readers and people writing C compilers could interpret some of the features differently. So in the second edition they added a “Summary of Changes”[9] This section in the book summarizes how the language changed between the two editions of the book. Other languages have gone through similar standardization and improvements and reading the summary of changes is often interesting.

Condemning or Supporting Language Features

In most cases I report about a language feature or command, but do not judge its value or appropriateness. As you will see so many predictions and pronouncements have turned out wrong, it is dangerous to cheer some language feature. For example, early FORTRAN and BASIC did not declare variables and the variables do not have a type. This feature was widely condemned. So later languages all declared their variables with a type, and often had strong type checking. Then the very successful scripting languages, (Perl, JavaScrip, Tcl, Python, and Ruby) showed up and these languages do not have types and do not need to declare variables.

Archaeology of Lost Commands

A few language constructs have almost disappeared from modern language and programming thought. Examples are internal functions, multiple function entry points, computed goto, label variables, and implied comparisons. Many would say leave these dead features alone, but I have dug them up since history, even its mistakes, are often interesting. In most cases the lost commands are gone since they did not prove useful enough to keep around.

Questions

Find a survey of present use of computer languages. There have been several that estimate percentage use by language. For example, in 1960 one might find 40% FORTRAN and 50% assembly languages. You will need to do some searching and estimates will differ. Even figuring out how to estimate this is difficult.
After doing the above problem see if you can find some older estimates, maybe once a decade for the past 40 years and notice trends.
Draw a flowchart indicating the genealogy of languages. For example, one branch of the tree would be C to C++ to Java. Some other interesting branches are FORTRAN, COBOL, and BASIC.
Try to figure out how many active computer languages there are today. First, you need to develop some guidelines on what qualifies a language as being active.
Find a copy of Tony Hoare's ACM Turing Lecture entitled "The Emperor's Old Clothes" (Hoare 1981), and how his observations apply to modern programming languages.
Tony Hoare made the following comment about the designing large overly-complex languages such as Ada: “The mistakes which have been made in the last twenty years are being repeated today on an even grander scale.” How does this statement apply to our modern large complex languages such as Java, C++, C#, and Visual Basic .NET?
Using a programming language that has been improved or updated, find the list of changes between the two versions of the language and summarize the changes.
Earlier computer languages were classified into generations. The first generation is machine language; the second generation is assembly language. Finish this list indicating dates and some languages in each generation. What is the present generation?
This book provides descriptions of computer programming languages for the past 50 years. Predict where the next 10 or 20 years will lead us.

[2] Ellis Horowitz, Fundamentals of Programming Languages (Rockville, Maryland: Computer Science Press, 1983), p. 2.

[5] Bruce MacLennan, Principles of Programming Languages: Design, Evaluation, and Implementation (London: Oxford University Press, 1987) p. 105.

[6] Douglas W. Nance. Pascal: Understanding Programming and Problem Solving (St. Paul, MN: West Publishing Company, 1986). p. 281.

[8] Tony Hoare, The Emperor’s Old Clothes CACM 24(2), 1981