Programming Language Design Principles Language design is difficult

Programming Language Design Principles • Language design is difficult and poorly understood. • The practice of language design is a creative process. But one must know many language design principles and must know about many different languages in order to do it well. • People cannot create anything ex-nihilo. You need to work with some materials. In the case of programming language, the materials are programming language constructs. Lecture 4 PLP Spring 2004, UF CISE 1

Language Design Principles • Attempts have been made to make programming languages obsolete (specification languages like The Last One, which was supposed to be the last program to be written). While more detail in current programming languages is needed than was hoped by those who proposed specification languages, because of libraries and frameworks less programming detail is needed than naysayers would have predicted. • Remember that every program you write embodies the language problem of mapping inputs to outputs. The form of input language may vary, but it is a language. Lecture 4 PLP Spring 2004, UF CISE 2

Execution Efficiency • In early years, the most important design criteria was execution efficiency. • Remember that execution efficiency was the driving force behind the FORTRAN design and implementation. • Execution efficiency was soon displaced by program writability, and with increasing software project sizes was displaced by the goal of readability. Lecture 4 PLP Spring 2004, UF CISE 3

Translation Efficiency • Louden makes the case for worrying about translation efficiency too well. Especially in the case of error checking, time spent during translation is well-rewarded. • Improvements in memory size and processor speed have made it possible to do much more at translation time that was done in the past. This means we can do more for less at translation time. Consider changes in % of time spent compiling, vs. % of time executing, vs. % of time coding. Increasing ambition and desire leads to ever increasing program complexity and coding time. • Dynamic error checking, however, will still consume roughly the same proportion of code and will, thus, yield the same proportion of execution speed degradation. Obviating dynamic error checking, is, thus, a good thing. • Difficulty of language translator implementation can impair language acceptance. (e. g. Ada) • Wirth may have said that "Language design is compiler construction, " but he ignores that fact that there is much more to designing a language than merely implementing an interpreter or compiler. Lecture 4 PLP Spring 2004, UF CISE 4

Efficiency of Writing Programs • Once we can make a program run fast, and we can translate it quickly, our interest becomes in writing the program quickly to save human effort. • The primary writability property that Louden addresses is Regularity which he says is ill-defined but can be subdivided into three conceptual areas: generality, orthogonality, and uniformity. Lecture 4 PLP Spring 2004, UF CISE 5

Generality • This is the concept that there should be no special cases in the language. All the elements you expect should be there. • Louden’s examples: – Pascal: no procedure variables? – Pascal: no variable length arrays? – C: no nesting of functions? – C: structs/arrays: no comparison via ==? – FORTRAN: no named constants (ancient implementation problems with constants) Lecture 4 PLP Spring 2004, UF CISE 6

Orthogonality • All constructs should be combinable with other constructs in meaningful ways that do not cause unexpected behavior. • Louden’s examples: – Pascal: functions return only scalar/pointer types? – C: local variables can only be defined at block beginning? – C: Passes all parameters by value except arrays (by reference) • Other examples: – C: blocks and statements cannot return values and be manipulated like other values : x=if (x) {f(x); } else {g(x)}; Lecture 4 PLP Spring 2004, UF CISE 7

Uniformity • Things that look similar should have similar meanings • Louden’s examples: – C++: Semicolon required after class definition, but forbidden after function definition. – Pascal: Return value of function is specified with an assignment statement that assigns to the function name. (This is doubly non-uniform. ) • Other examples: – C: Use of & for address-of (prefix) and bitwise-and (infix). Lecture 4 PLP Spring 2004, UF CISE 8

Other Design Principles • Simplicity: – Pascal was the king of simplicity (and died of it). – LISP and Prolog have a simple structure for the user, but have an extremely complex underlying run-time system. – Louden quotes Einstein (though I've seen about four variations of this quotation): ``Everything should be made as simple as possible, but no simpler. '' This is really just a variation of the principle of parsimony put forth by William of Occam: ``One should not increase, beyond what is necessary, the number of entities required to explain anything. '' Lecture 4 PLP Spring 2004, UF CISE 9

Other Design Principles: Expressiveness • A programming language should be expressive, however, people disagree on what expresses meaning best, and sometimes different concepts have different best means of expression. • Hence, a programmer should employ a language whose paradigm best matches that programmer's understanding of the problem at hand. Lecture 4 PLP Spring 2004, UF CISE 10

Other Design Principles: Extensibility • All programs are extensible to some extent. Programmers can declare new types, create named procedures, etc. • Operator overloading in OO languages has both proponents (who applaud the ability to naturally extend operations like +, -, *, /) and opponents who note that extending built-in operators can cause problems. • Nowadays, extensibility of languages usually comprises libraries of functions and classes. In LISP, one can extend the language by providing macros, and can even extend the control structures (in some dialects) by using call-with-current-continuation (which is really cool). • Syntax extension in infix languages is quite difficult. One example would be the macros of the Dylan programming language which are extremely complex, difficult to write, and even more difficult to understand. Lecture 4 PLP Spring 2004, UF CISE 11

Other Design Principles: Restrictability • Louden notes that one might define a subset language so that the subset can be implemented. This appears to be a special mania on his part. • This is not a good idea in general. Why would someone want the crippled language? His allusion to leaving what’s not necessary in a library has nothing to do with restrictability. That represents a choice of the language to be implemented. This might be part of some lucrative marketing strategy, but one that is based on upsetting people, then taking money from them to abate their anger. • The zero-overhead design principle of C++ is a good example of how to reward the programmer for using a restricted version of the language. One need not restrict the abilities of the programmer in order to reward one for using a simple language subset. Lecture 4 PLP Spring 2004, UF CISE 12

Other Design Principles: Consistency with Accepted Notations • Mother, apple pie. • Unfortunately, what one thinks are accepted notations and conventions, another will despise. Lecture 4 PLP Spring 2004, UF CISE 13

Other Design Principles: Precision • Louden refers here to precision in language specification. Such precision relies in implementation relies on precise specification. Lecture 4 PLP Spring 2004, UF CISE 14

Other Design Principles: Platform Independence • A platform is a hardware and operating system architecture combination. (Wintel, SPARCSolaris, IA 64 -Linux) • Most programming languages have many features that are defined in a platformindependent way and a few features that are platform-dependent. • It is best to isolate machine dependencies in some way (such as through platform-specific functions or constants) so that it is easier to identify the platform-specific elements. Lecture 4 PLP Spring 2004, UF CISE 15

C++ Case Study • Bjarne Stroustrup used Simul 67 as a grad student at Cambridge. He found it conceptually valuable but saw many implementation problems (compile/link and runtime performance). Switched to using BCPL in order to finish his thesis on time. • In 1979, working on distributed Unix kernel simulation at AT&T, needed a simulation platform. He wanted the capabilities of Simula 67 with the performance of C. He implemented C with Classes. • This language formed the core of what has come to be known as C++. • The first wide-distribution of C++ came in the form of CFront (a C preprocessor for C++), which was ambitious and disastrous. Despite what your text says, almost no modern C++ compilers are derived from CFront. Lecture 4 PLP Spring 2004, UF CISE 16

Stroustrup’s Principles • Maintain compatibility as much as possible, but no more. • C++ extensions to C should be incremental but not gratuitous. • A language extension must no impact the performance of programs that do not employ it (zero-overhead rule). • The language should support multiple paradigms. • The language should maintain and strengthen type checking. • The language should be learnable in stages. • The language should be compatible with other systems and languages. Lecture 4 PLP Spring 2004, UF CISE 17

Growth of C++ • Between October 1979 and October 1991, the number of C++ users doubled every 7. 5 months (from 1 to about half a million users. ) • At that point it became clear that a standard was warranted. Lecture 4 PLP Spring 2004, UF CISE 18

C++ Standardization • Stroustrup and Ellis produced the Annotated Reference Manual (ARM) in 1989 to document the current state of the language. • ANSI (1990) and ISO(1991) convened committees to standardize the language. The ARM was the base document. • The Standard Template Library (initially developed by SGI) was added in 1994. • Proposed standard (November 1997) was adopted in August 1998. Lecture 4 PLP Spring 2004, UF CISE 19

Retrospective • C++ has been a unique and uniquely successful language. • Stroustrup has identified issues he wishes could have been solved differently: – Garbage collection (he says that though he wishes he could have included it, the language would have been stillborn if he had) – Generic functions (aka multimethods). This is a more general way to handle overloading that first argument dispatch. Lecture 4 PLP Spring 2004, UF CISE 20