- number of basic constructs/features: if there are too many, the more likely a program will be hard to read (because reader might know a different subset of language than programmer). If there are very few (e.g., assembly language), code can be hard to read because what may be a single operation, conceptually, could require several instructions to encode it.
- feature multiplicity: the existence of multiple ways of doing the same operation. Examples: incrementing a variable in C-based syntax, looping constructs (while, do while, for), Java's conditional ternary operator (?:).
- operator overloading: can aid readability if used with discretion, but can lessen readability if used unwisely (e.g., by using + as a comparison operator).
- particular combinations are forbidden (as exceptional cases) or
- the meaning of a particular combination is not evident from the meanings of its component parts, each one considered without regard to context.
- A function can return a value of any type, except for an array type or a function type.
- According to Sebesta, an array can hold values of any type, except for a function type or void. (Note that material on the WWW indicates that you can place pointers to functions in an array!)
- Parameters to functions are passed "by value", except for arrays, which are, in effect, passed "by reference". (Is this a valid criticism? After all, one should understand a variable of an array type to have a value that is actually a pointer to an array. So passing an array to a function is really passing a pointer "by value". This is exactly how Java works when passing objects to methods. What is being passed is really a reference (i.e., pointer) to an object, not the object itself.)
- In the expression a + b, the meaning of b depends upon whether or not a is of a pointer type. (This is an example of context dependence.)
Example from assembly languages: In VAX assembler, the instruction for 32-bit integer addition is of the form
where each of the opi's can refer to either a register or a memory location. This is nicely orthogonal.
In contrast, in the assembly languages for IBM mainframes, there are two separate analogous ADD instructions, one of which requires op1 to refer to a register and op2 to refer to a memory location, the other of which requires both to refer to registers. This is lacking in orthogonality.
Too much orthogonality? As with almost everything, one can go too far. Algol 68 was designed to be very orthogonal, and turned out to be too much so, perhaps. As B.T. Denvir wrote (see page 18 in "On Orthogonality in Programming Languages", ACM SIGPLAN Notices, July 1979, accessible via the ACM Digital Library):
Intuition leads one to ascribe certain advantages to orthogonality: the reduction in the number of special rules or exceptions to rules should make a language easier "to describe, to learn, and to implement" — in the words of the Algol 68 report. On the other hand, strict application of the orthogonality principle may lead to constructs which are conceptually obscure when a rule is applied to a context in an unusual combination. Likewise the application of orthogonality may extend the power and generality of a language beyond that required for its purpose, and thus may require increased conceptual ability on the part of those who need to learn and use it.
As an example of Algol 68's extreme orthogonality, it allows the left hand side of an assignment statement to be any expression that evaluates to an address!
- Identifier forms: Should not be too restrictive on length, such as were FORTRAN 77 and BASIC. In COBOL, identifiers could include dashes, which can be confused with the subtraction operator.
- Special words: Words such as while, if, end, class, etc., have special meaning within a program. Are such words reserved for these purposes, or can they be used as names of variables or subprograms, too?
The manner in which the beginning/end of a compound statement (e.g., loop) is signaled can aid or hurt readability. E.g., curly braces vs. end loop. - form and meaning: Ideally, the semantics of a syntactic construct should be evident from its form. A good choice of special words helps this. (E.g., use if, not glorp.) It also helps if a syntactic form means the same thing in all contexts, rather than different things in different contexts. C violates this with its use of static.
- 1.3.2.1 Simplicity and Orthogonality: Sebesta favors a relatively small number of primitive constructs (simplicity) and a consistent set of rules for combining them (orthogonality). (Sounds more like a description of "learnability" than of "writability".)
- 1.3.2.2 Support for Abstraction: This allows the programmer to define and use complicated structures/operations in ways that allow implementation details to be ignored. This is a key concept in modern language design. Data abstraction and process (or procedural) abstraction.
- 1.3.2.3 Expressivity: This is enhanced by the presence of powerful operators that make it possible to accomplish a lot in a few lines of code. The classic example is APL, which includes so many operators (including ones that apply to matrices) that it is based upon an enlarged character set. (There are special keyboards for APL!) Typically, assembly/machine languages lack expressivity in that each operation does something relatively simple, which is why a single instruction in a high-level language could translate into several instructions in assembly language. Functional languages tend to be very expressive, in part because functions are "first-class" entities. In Lisp, you can even construct a function and execute it!
- 1.3.3.1 Type Checking: This refers to testing for type errors, either during compilation or execution. The former is preferable, not only because the latter is expensive in terms of running time, but also because the earlier such errors are found, the less expensive it is to make repairs. In Java, for example, type checking during compilation is so tight that just about the only type errors that will occur during run-time result from explicit type casting by the programmer (e.g., when casting a reference to an object of class A into one of subclass B in a situation where that is not warranted) or from an input being of the wrong type/form. As an example of a lack of reliability, consider earlier versions of C, in which the compiler made no attempt to ensure that the arguments being passed to a function were of the right types! (Of course, this is a useful trick to play in some cases.)
- 1.3.3.2 Aliasing: This refers to having two or more (distinct) names that refer to the same memory cell. This is a dangerous thing. (Also hurts readability/transparency.)
- 1.3.3.3 Readability and Writability: Both have an influence upon reliability in the sense that programmers are more likely to produce reliable programs when using a language having these properties.
- Training programmers: cost is a function of simplicity of language
- Writing and maintaining programs: cost is a function of readability and writability.
- Compiling programs: for very large systems, this can take a significant amount of time.
- Executing programs: Having to do type checking and/or index-boundary checking at run-time is expensive. There is a tradeoff between this item and the previous one (compilation cost), because optimizing compilers take more time to work but yield programs that run more quickly.
- Language Implementation System: e.g., Java is free, Ada not
- Lack of reliability: software failure could be expensive (e.g., loss of business, liability issues)
Other criteria (not deserving separate sections in textbook):
Portability: the ease with which programs that work on one platform can be modified to work on another. This is strongly influenced by to what degree a language is standardized.
Generality: Applicability to a wide range of applications.
Well-definedness: Completeness and precision of the language's official definition.
The criteria listed here are neither precisely defined nor exactly measurable, but they are, nevertheless, useful in that they provide valuable insight when evaluating a language.
1.7 Language Design Trade-offs
- Reliability vs cost (of execution): The increase in reliability resulting from index range checking (such as is mandated in Java and Ada) is offset by an increase in the running time of a program.
- Writability vs. readability: A language that allows you to express computations/algorithms very concisely (such as APL, with its collection of powerful array and matrix operators) also tends to be difficult to read.
- Writability vs. reliability: A language that gives the programmer the convenience/flexibility of "breaking an abstraction" (e.g., by interpreting the contents of a chunk of memory in a way that is not consistent with the type declaration(s) of the data that is held there) is more likely to lead to subtle bugs in a program.
1.4 Influences on Language Design
1.4.1 Computer Architecture: By 1950, the basic architecture of digital computers had been established (and described nicely in John von Neumann's EDVAC report). A computer's machine language is a reflection of its architecture, with its assembly language adding a thin layer of abstraction for the purpose of making easier the task of programming. When FORTRAN was being designed in the mid to late 1950's, one of the prime goals was for the compiler to generate code that was as fast as the equivalent assembly code that a programmer would produce "by hand". To achieve this goal, the designers —not surprisingly— simply put a layer of abstraction on top of assembly language, so that the resulting language still closely reflected the structure and operation of the underlying machine. To have designed a language that deviated greatly from that would have been to make the compiler more difficult to develop and less likely to produce fast-running machine code.
The style of programming exemplified by FORTRAN is referred to as imperative, because a program is basically a bunch of commands. (Recall that, in English, a command is referred to as an "imperative" statement, as opposed to, say, a question, which is an "interrogative" statement.)
This style of programming has dominated for the last fifty years! Granted, many refinements have occurred. In particular, OO languages put much more emphasis on designing a program based upon the data involved and less on the commands/processing. But the notion of having variables (corresponding to memory locations) and changing their values via assignment commands is still prominent.
Functional languages (in which the primary means of computing is to apply functions to arguments) have much to recommend them, but they've never gained wide popularity, in part because they tend to run slowly on machines with a von Neumann architecture. (The granddaddy of functional languages is Lisp, developed in about 1958 by McCarthy at MIT.)
The same could be said for Prolog, the most prominent language in the logic programming paradigm.
Interestingly, as long ago as 1977 (specifically, in his Turing Award Lecture, with the corresponding paper appearing in the August 1978 issue of Communications of the ACM), John Backus (famous for leading the team who designed and implemented FORTRAN) harshly criticized imperative languages, asking "Can Programming be Liberated from the von Neumann Style?" He set forth the idea of an FP (functional programming) system, which he viewed as being a superior style of programming. He also challenged the field to develop an architecture well-suited to this style of programming.
Here is an interesting passage from the article:
Conventional programming languages are basically high level, complex versions of the von Neumann computer. Our thirty year old belief that there is only one kind of computer is the basis of our belief that there is only one kind of programming language, the conventional —von Neumann— language. The differences between Fortran and Algol 68, although considerable, are less significant than the fact that both are based on the programming style of the von Neumann computer. .Von Neumann programming languages use variables to imitate the computer's storage cells; control statements elaborate its jump and test instructions; and assignment statements imitate its fetching, storing, and arithmetic. The assignment statement is the von Neumann bottleneck of programming languages and keeps us thinking in word-at-a-time terms in much the same way the computer's bottleneck does.
1.4.2 Programming Method(ologie)s: Advances in methods of programming also have influenced language design, of course. Refinements in thinking about flow of control led to better language constructs for selection (i.e., if statements) and loops that force the programmer to be disciplined in the use of jumps/branching (by hiding them). This is called structured programming.
An increased emphasis on data (as compared to process) led to better language support for data abstraction. This continued to the point where now the notions of abstract data type and module have been fused into the concept of a class in object-oriented programming.
1.5 Language Categories
The four categories usually recognized are imperative, object-oriented, functional, and logic. Sebesta seems to doubt that OO is deserving of a separate category, because one need not add all that much to an imperative language, for example, to make it support the OO style. (Indeed, C++, Java, and Ada 95 all are quite imperative.) (And even functional and logic languages have had OO constructs added to them.)
1.7 Implementation Methods
Computers execute machine code. Hence, to run code written in any other language, first that code has to be translated into machine code. Software that does this is called a translator. If you have a translator that allows you to execute programs written in language X, then, in effect, you have a virtual X machine. (See Figure 1.2.)
There are three general translation methods: compilation, interpretation, and a hybrid of the two.
- identifiers declared within the module that are free to be referenced in other modules,
- references in the module to entities defined elsewhere,
- relative references within the module
See Figure 1.3 for a depiction of the various phases that occur in compilation. The first two phases, lexical and syntax analysis, are covered in Chapter 4. The job of a lexical analyzer, or scanner, is to transform the text comprising a program unit (e.g., class, module, file) into a sequence of tokens corresponding to the logical units occurring in the program. (For example, the substring while is recognized as being one unit, as is each occurrence of an identifier, each operator symbol, etc.) The job of the syntax analyzer is to take the sequence of tokens yielded by the scanner and to "figure out" the program's structure, i.e., how those tokens relate to each other.
To draw an analogy with analyzing sentences in English, lexical analysis identifies the words (and possibly their parts of speech) and punctuation, which the syntax analyzer uses to determine the boundaries between sentences and to form a diagram of each sentence. Example sentence: The gorn killed Kirk with a big boulder.
S V D.O. gorn | killed | Kirk -------+--------+------- \T \w \h \i \e \t (adj) \h boulder -------------- \a \b \i (prep. \g phrase)
1.7.2 Pure Interpretation: Let X be a programming language. An X interpreter is a program that simulates a computer whose "native language" is X. That is, the interpreter repeatedly fetches the "next" instruction (from the X program being interpreted), decodes it, and executes it. A computer is itself an interpreter of its own machine language, except that it is implemented in hardware rather than software.
1.7.3 Hybrid: Here, a program is translated (by the same means as a compiler) not into machine code but rather into some intermediate language, typically one that is at a level of abstraction strictly between language X and machine code. Then the resulting intermediate code is interpreted. This is the usual way that Java programs are processed, with the intermediate language being Java bytecode (as found in .class files) and the Java Virtual Machine (JVM) acting as the interpreter.
Alternatively, the intermediate code produced by the compiler can itself be compiled into machine code and saved for later use. In a Just-in-Time (JIT) scenario, this latter compilation step is done on a piecemeal basis on each program unit the first time it is needed during execution. (Subsequent uses of that unit result in directly accessing its machine code rather than re-translating it.)
