Download Methodology for Designing Programming Languages and more Study notes Programming Languages in PDF only on Docsity!
THE DESIGN OF USABLE PROGRAMMINGLANGUAGES*
Michael Hammer Project MAC Massachusetts Institute of Technology Cambridge, Massachusetts
A methodology for the design of programming languages is set forth. The principal objective of this approach is the development of languages that are easy to use; i t is argued that conventional language designs do not satisfactorily achieve this goal. The basic principles of the proposed approach are restriction and discipline: by appropriately limiting the programmer's freedom of choice, the number of decisions he must make can be reduced. In particular, i t is argued that languages should be designed for individual problem areas, and that each language should be built around a style of problem solving, an algorithmic structure appropriate to its application domain. Principles of de- clarative and data-oriented programming, which avoid a processor-oriented view of computation, are also set forth.
I. INTRODUCTION
By now the celebrated "software problem" is a commonplace. I t is generally recognized that the cost and d i f f i c u l t y of constructing and maintaining r e l i a b l e software is the major impediment in the way of dramatically increased and more e f f e c t i v e application of computers [ I ]. In response to this problem, there has been much a c t i v i t y of l a t e in "software engineering", in the development of programming methodologies and standards, and of languages to support them, in order to ease and streamline the programming process.
However, many of the proposals being set forth seem to be concerned with developing improved tech- niques f o r using conventional tools, rather than with designing new and d i f f e r e n t tools. The primary thrust of most research in "software engineering" has been the development of principles f o r the use of so-called general purpose, higher level programming languages, the use of which should r e s u l t in better designed and more r e l i a b l e software. By setting forth elements of s t y l e that a programmer should follow in u t i l i z i n g the power- ful and b a s i c a l l y unstructured f a c i l i t i e s of a general purpose language, the hope has been f o r the developement and use of some l i m i t e d standard techniques f o r program construction. Structured programming [2], modular and top-down design {3,4, 5], and goto-less programming, f o r example, are a l l methodologies intended to encourage a s t r u c t - ured and disciplined use of programming languages, in contrast to indiscriminate coding. The develop- ment of such protocols has spawned research in the design of the precise set of basic l i n g u i s t i c features that support and encourage the chosen style of programming [6,7,8,9].
These emerging ideas and theories certainly make an important contribution to the evolution of a science of programming languages. But much of the current research is b u i l t on certain tacit assump- tions about the nature of programming; these un- spoken attitudes havemajor consequences for the way languages are designed and evaluated, and deserve examination.
- GENERALITYAND FLEXIBILITY
Primary among these postulates is a strong emphasis *This research was supported by the Advanced Research Projects Agency of the Department of Defense under ARPAorder No. 2095 and by ONR Contract No. N00014-75-C-0661.
on 9enerality. The domain of discourse of software engineering is almost always software systems construction in general, rather than in any one limited area. The goal of most work in this area seems to be the development of what might be termed "algorithmics", a science of devising general lang- uages and techniques to describe all kinds of computational algorithms. In this context, any problem is (almost) as important as any other one. As a consequence, a high premium is put on f l e x i - b i l i t y and power as a criteria for judging pro- gramming languages. That is, a language is ex- pected to provide the basic f a c i l i t i e s for express- ing all kinds of algorithms; i t may encourage or support certain very broad styles of programming, but i t is not supposed to confine the programmer within these loose constraints. In these lights, a language must be flexible enough to adapt to any use to which the programmer wishes to put i t ; i t must not inhibit or inconvenience him in the selec- tion of a problem or an algorithm to solve i t. A language offers the programmer basic computational units, but i t may not t e l l him how they are to be combined into whole programs. Constructing algor- ithmic specifications from computational primitives is seen to be the province of the programmer, the act of programming, on which the language and its designer are not to intrude. A programming lang- uage, in this view, must offer the right kind of support, and provide the best stage, for the exer- cise of the programmer's talent. This attitude is related to the vision of programming as an "art" ~lO], a forum for the exercise of inventiveness and creativity. I t follows that a language designer should encourage a programming a r t i s t to u t i l i z e sound programming practices, but must not unduly interfere with the exercise of his craft.
As a consequence, most of the lanouages that are surfacing in the wake of the software engineering movement, are so-called general purpose, higher- level languages, usually derivative of ALGOL or LISP. Ine novel features of these languages tend to be rich control structures and definitional mechanisms that allow a programmer to define the data structures he wants to use and the procedures appropriate for their manipulation. While the particular details and syntax of these languages vary greatly from one to another, they are all motivated by the view of programming set forth above, and share a common view of the computation process as well.
Though contemporary programming languages are called "higher-level", the model of computation which they
embody is in r e a l i t y a very low-level one, and not far removed from that provided by classical von Neumann architecture machines (and their formal mathematical models). In particular, most of these languages have a processor/memorymodel of program execution. The abstract computing device which defines the semantics of a language is assumed to possess a central processor which performs oper- ations on values, and a memory wherein these values are stored. A program is viewed as a l i s t of pro- cessor instructions, which are sequentially inter- preted; at any point in time, the status of the computation specified by the program can be de- scribed by the locus of control in the program and by the contents of the memory. The processor operations tend to be binary arithmetic and logical operations, similar to those available on most real machines. Most of the "high-level"aspects of such languages tend to be purely syntactic in nature, their semantic capabilities being decidedly "low- level". Even much vaunted, "high-level" control structures such as do-while, case, and recursive procedure calls, a r e ' - n ~ g ~ t h a n syntactic sugar, macros locally expandable in terms of basic machine instructions.
- PROBLEMORIENTED LANGUAGES
Another approach to the design of programming languages has been that of domain specific languages each applicable to a r e l a t i v e l y narrow range of applications [ l l , 1 2 ]. Of course, even "general purpose" languages, while Turing complete, are best suited for some particular problem area; but these areas tend to be very broad, such as "non-numeric computation". The domain of application of a specialized application language is much narrower.
Most domain-specific programming languages can be categorized in one of two ways; either as a "sugared"" general purpose language, or as a data presentation language. In the former case, the language designer investigated the chosen problem domain and determined the data types and structures, and operations on them, that are fundamental to the f i e l d ; these features were then grafted onto some general-purpose language of the designer's choosing. In the result, i t is argued, the application programmer has available to him the basic constructs appropriate to the domain, which he can manipulate as desired.
The foregoing scenario has often been used to j u s t i - fy the development of extensible language systems, for the f a c i l i t i e s of such systems promote this kind of language development. But this scheme does not really produce a domain specific language. The resulting "specialized" language is just a mildly disguised version of the general purpose language. Nothing fundamental to the problem domain has been deeply embeddedin the language.
This is not to say that this scheme is without merit. I t does represent the rudiments of a metho- dology for adapting a general purpose language to use in a narrow domain, in order to produce more reliable programs. The definition and maintenance of a level of abstraction is an important step in reducing the complexity of general purpose program- ming. But i t is not the same as building a language tuned to the problem area. In using an abstraction, the basic character and structure of the supporting general purpose language is not tampered with; the style of programming, in fact the style of problem solving, embeddedin and supported by that language remains unchanged. The applications programmer is indeed provided a few specialized units but must build his own structure into which to f i t them. I t remains the case that, in order to devise and de- scribe his algorithm, the applications programmer must think in terms of abstract processors that are
not far removed from Turing machines; the only im- provement is that this processor can perform some special operations that the programmer w i l l fre- quently use. But the organization and structure of a user program is not at all specialized; i t is b u i l t out of the same general building-blocks that apply to every problem domain.
A few specialized data types and operators do not constitute a specialized language. We believe that the basic ways in which the algorithms in a special- ized domain are composed, in which the various in- dividual units are tied together, are of a special- ized character and are peculiar to the problem domain; and a domain-specific language should in- corporate these algorithmic structures. Furthermore, the algorithmic structure of many an application domain, the problem solving methodology most natural to the f i e l d , cannot be easily described in terms of the computational model provided by general purpose languages.
The other classical model for domain-specific lan- guages is that of the so-called "problem-oriented" languages. Here, the language designer so narrowly restricts the domain of application that he is able to exhaustively l i s t all the application-related actions which a user might need. No capabilities for the construction and representation of algorithms are provided in the language; there is no need for them, for the designer has f u l l y anticipated all the user's needs. The user w i l l only be able to specify which actions he wants to perform, in what order, and to what data. These languages boil down to what may be called data presentation languages; in their use, the user does l i t t l e more than parametrically activate certain pre-canned routines.
I t is to this class that most non-general purpose languages belong [13,14]. For example, in the c i v i l engineering languageSTRUDL [15|, a user describes a structural situation, using problem-oriented terms such as GRID, TRUSS, FRAME; he then may ask for the load, stress, strain, etc. to be computed at various points in the structure. Someproblem-oriented languages are more sophisticated than this; but to call them programming languages, is to push the term to its extreme. In r e a l i t y , "programs" in these languages are just formatted data to an appli- cation package. The problem domains addressed by these systems are too small to make this approach widely applicable.
- VERYHIGH LEVEL LANGUAGES
Recently, there has been a commendable trend towards the design of so-called "very high level" or "non- procedural" languages, intended to ease the programming task [16,203. These languages attempt to reduce the level of detail specified by a pro- grammer by making available constructs that faci- l i t a t e expression of intent. Someof these features constitute a real departure from the tradition of von Neumann computer architecture. These languages variously provide non-machine-oriented aggregate data structures (such as sets and relations), to- gether with f a c i l i t i e s for accessing and manipula- ting them (such as i m p l i c i t loops, i m p l i c i t data structures, and associative referencing) [17,18,19].
While such features do provide for significant local simplification in the expression of algorithms, much of the current effort in very high level language design is directed towards the development of general purpose very high level languages. This research hopes to discover a basic set of non- computer-oriented primitives that w i l l suffice for the expression of all algorithms over a wide range of applications. The overall structure of such languages is usually reminiscent of ALGOL, with the
~2] and PLANNER ~3]. In each case, a preferred model of problem-solving for the domain was select- ed, and was b u i l t into the language.
PLANNER is primarily intended for a r t i f i c i a l i n t e l - ligence applications. The language design is based on the proposition that backtracking is a natural mode of algorithm structure and organization for most problems in the AI area. The basic PLANNER control structure is pattern directed multiprocess backtracking; this algorithmic organization ties language primitives together into programs. This structure is deeply embedded in the language and may be i m p l i c i t l y used by the programmer. Other algorithmic structures, however, must be achieved in roundabout ways. (We note that for our design program to succeed, the problem solving regime em- bedded in the language must be a good one. For example, i t has been argued that automatic back- tracking is not a good structure for the AI appli- cation area ~4]. The language designer must ob- viously have a great f a m i l i a r i t y with programming in the problem domain.)
Similarly, the structure of the RPG language, with its use of indicators to drive the calculation and production of outputs, provides a skeletal frame- work in which a programmer can work. The popularity of RPG, despite its many shortcomings, testifies to the appropriateness of this computational struc- ture for many data processing applications ~5].
- DECLARATIVEPROGRAMMING
Having argued that the incorporation of an algo- rithmic organization into a programming language is a prerequisite for the language's facile use, i t remains to be decided how this structure is to be expressed, what kinds of linguistic constructs should carry i t. To further simplify the program- ming process, we shall rely on less procedural and more declarative modes of expression; the l a t t e r provide descriptions of the result of a computation rather than e x p l i c i t instruction to a processor. Our fundamental attitude is that a user understands the data with which he is concerned, and the mani- pulations which are to be performed on this data, and even how these manipulations are to be organ- ized, provided this organization is expressed in terms of the data. People have trouble with con- verting a data-oriented algorithm into an algorithm description based on avon Neumann machine model.
The control structures of a program provide a skeleton to support the body of the program, the data manipulations. The use of abstract processor- oriented control structures causes an unfortunate mismatch between the data operations which are performed and the program organization which directs their performance. Thus we need ways to express the structure of a program in terms of the data being manipulated, with the "flow of control" being i m p l i c i t l y specified.
One such mechanism for program organization is the idea of data flow programming ~6J. There has been a recent trend towards the development of machine architectures based on the notion of data flowing between nodes in a network, where each node rep- resents a computation to be performed on the data entering i t , and a node is activated when i t re- ceives inputs. The flow of data is usually char- acterized as a stream of atoms, with the nodes per- forming simple operations on them. This idea has been developed primarily to provide a better model of computation for purposes of detecting and cap- talizing on the parallelism in a system; and data flow models have been used to express the formal semantics of conventional programming languages. However, the idea of data flow also forms an attractive basis for a user-oriented programming language; and i t has been used in a language for
operating system construction [27].
One can also build domain-specific languages using this concept. In such a language, the elements of data flowing between nodes could be complex data structures or even aggregates; and the nodes could be drawn from a set of powerful manipulations or could represent functional modules written in some other syntax. (The l a t t e r approach has been em- ployed in BDL, a language designed for the construc- tion of business data processing systems [28, 29].) Data flow has proven to be very effective for ex- pressing the organization and global "flow of control" in a program. I t is especially powerful for describing the operation of complex systems whose different parts may be working asynchronously. The user can i m p l i c i t l y specify that certain parts of his program are to be executed in parallel, or that others are to wait until the occurrence of specified kinds of inputs, without having to describe in detail how this is to be accomplished. Using this scheme, the user can easily describe the relationships and dependencies among program modules in a meaningful way, rather than resort to control oriented descrip- tions that simulate the desired process in an indirect fashion.
Control structures which organize local computations can often be formulated in terms of the data being manipulated as well. For example, various languages enable the expression of iteration as "for all elements of an aggregate, do the following", rather than by e x p l i c i t l y incrementing an index. More elaborate iterative structures can also be data driven. For example, a common program structure in many data processing applications is to group to- gether all records in a f i l e with the same value of a given f i e l d , and then to perform some fixed procedure on each such group. This capability is directly provided the BDL user for parameterization: he need only specify the source f i l e , the relevant f i e l d , and the procedure to be repeatedly applied. Thus the programmer can structure his program directly in terms of subsets of the source f i l e , rather than in terms of an abstract processor per- forming the subsetting. This mode of expression avoids a number of purely language-related complex- i t i e s inherent in the conventional specification of such a program organization. For example, expressing this program structure in ALGOL or PL/I requires additional temporary storage, several e x p l i c i t loops, and assorted other machinery, t o t a l l y unrelated to the real problem.
Declarative modes of expression can be found for other abstract control structures, especially when this is done within the context of a programming discipline. For example, the conditional construct may be broadly construed as having two kinds of uses: either determining whether or not a specific data item is going to be subjected to a manipulation, or choosing the identity of an operation to be performed. In mo~t languages, these two usages are not distinguished and may be freely intermixed. In BDL, a discipline is imposed which insists that the two be applied sequentially: f i r s t the arguments of an operation are f u l l y specified; then the nature of the operation is identified; and then the operation is applied to its arguments. To accomplish the f i r s t of these tasks, a purely data-driven construct is employed, which selects the desired arguments from available data items. Of course, this effect could be achieved by using a conventional condition- al; but the processor oriented conditional has been replaced by a descriptive capability referring only to properties of the data.
7, EFFICIENCY
In the foregoing, we have concentrated on the conve- nience of the programmer as the dominant criterion in evaluating a programming language. However, the
issue of execution-time efficiency needs to be addressed. Computer time w i l l always have an associated cost; and for any improvements in proces- sor speed, new applications that require its cap- acity inevitably arise.
The problem we must face is that a language that is easier for a programmer to use because i t diminishes his decision-making role, also impedes his a b i l i t y to tune his program for greater efficiency.
Thus, the need for powerful optimizing compilers be- comes especially acute for the kinds of languages we are proposing. Therefore, i t is fortunate that there are new opportunities for optimizing programs written in these languages, in ways that are far more powerful than the local transformations appli- cable to conventional general purpose languages. Since our programswill be written in data oriented, high level terms, i t w i l l be feasible for a compiler to "understand" what the program is tyring to do, and generate a good implementation of the intent, based on various global c r i t e r i a. For example, no PL/I compiler can rewrite a Shell sort into a bubble sort; but a compiler for a language with the SORT command could decide to generate a bubble sort be- cause of known properties of the data. Another new opportunity for optimization derives from the fact that these languages are intended to be used in specialized areas. Thus i t is possible to build in- to the compiler "knowledge" about the area: preferred algorithmic styles, useful programming techniques, and all the i n t u i t i v e knowledge about tradeoffs that application programmers build up.
- CONCLUSION
To f u l l y develop the approach outlined above, further research and development efforts are required. First, careful study is needed of areas of computer application to determine appropriate domains for specialized languages. Analyses of these problem domains must be made to isolate the basic computa- tional structures that are peculiar to each domain and that need embodiment in its language. Then i t is appropriate to look for the right l i n g u i s t i c features to express these concepts; we have indi- cated that declarative constructs consitute one promising direction. These language designs must not be done in a vacuum. Studies w i l l have to be performed to see how readily real application systems can be coded using these features, and how typical programmers react to them. In this context, i t is appropriate to conduct research on the psych- ology of computer programming: to determine what basic computational primitives people seem to possess, which they are most facile at using, and which they can readily learn. This multifaceted approach should result in the design of t r u l y usable programming languages that make programming a simpler task.
This methodology was consciously applied during the design of the BDL language. Experience with the language to date indicates that in the domain of business data processing, BDL programs are very easy to write, read, and change.
REFERENCES
Ell B. Boehm, Software and its Impact: A Quanti- tative Assessment, Datamation 19, 5 (1973), 48-59. [2] O. J. Dahl, E.W. Dijkstra, and C.A.R. Hoare, Structured Programming, Academic Press, London, England, 1972. [3] B.H. Liskov, A Design Methodology for Reliable Software Systems, Proceedings of the AFIPS 1972 FJCC.
[4] D. L. Parnas, Information Distribution Aspects of Design Mehtodology, Proceedings of the IFIP Congress, August 1971.
[5] H.D. Mills, Top-Down Programming in Large Systems, in ~ T e c h n i q u e s in Large Systems, R. Rustin (ed.), P r e n t i c e T H ~ Englewood C l i f f s , N.J., 1971, 41-55. [6] B.H. Liskov and S. Zilles, Programmingwith Abstract Data Types, SIGPLAN Notices 9, (1974), 50-59. [7] D. Knuth, Structured Programming with go to Statements, ACM Computing Surveys 6,4 (19~), 261-301. [8] W.A. Wulf, D.B. Russell, and A.N. Haberman, BLISS: A Language for Systems Programming, CACM 14, 12 (1971), 780-790. [9] N.-~-~irth, The Programming Language Pascal, Acta Informatica l , I (1971), 35-63. [lO] D. Knuth, Computer Programming as an Art, CACM 17, 12 (1974), 667-673. [ I l l J.E. Sammet, An Overview of Programming Languages for Specialized Application Areas, Proceedings of the AFIPS 1972 SJCC. [12] J.E. Sammet, P r o g r a m m l n g ~ : andFundamentals, Prentice-Hall, Englewood C l i f f s , N.J. 1969. [13] S. Warshall, AMBUSH - A Case History in Language Design, Proceedings of the AFIPS 1972 SJCC. D4] S--~-J~-.~es, Problem-Oriented Languages for Man-Machine Communication in Engineering, Proceedings of the I.B.M. Scientific Computing ~ o n ~ a ~ a ~ C o m m u n i c a t i o n s , 1966. D5] D. Roos, I~-E'S S~stem: General Description, M.I.T. Department of Civil Engineering, R-67-49, September 1967. N6] B.M. Leavenworth and J.E. Sammet, Overview of Nonprocedural Languages, SIGPLAN Notices, 9, (1974), 1-12. N7] J. Earley, High Level Operations in Automatic Programming, SIGPLAN Notices, 9,4 (1974) 34-42. 8] J.T. Schwartz, On Programming: An Interim Report on the SETL P r o j e c t - - I n s t a T l ~ General~ies-~, Computer Science Dept., Courant Institute of Mathematical Sciences, New York University (1973). [19] J.B. Morris, and M.B. Wells, The Specification of Program Flow in MADCAPVl, Proceedings ACM 25th Annual Conference (1972). [20] A, Tuce T , Very High Level Language Design: A Viewpoint, Computer Languages l , l (1975) 3-16, E l l I.B.M. Corporation, System/3 RPG II Reference Manual, SC21-7500-4. ~2] G. Gordon, A General Purpose Systems Simulator, I.B.M. Systems Journal l , l (1962), ]8- [23] ~ i t t , P r o ~ E m b e d d i n g of Knowledge in PLANNER,Proceedings of IJCAI., London, September 1971. [24] G.J. Sussman and D.V. McDermott, From PLANNER To CONNIVER: A Genetic Approach, ProceedinBs of the AFIPS 1972 FJCC. [25] ~ e ~ f t w a r e Battle, System/3 World 1, (1973) 8-I0. [26] J. Dennis, A First Version of a Data Flow Procedure Language, Proceedings of the Programming ~ u m , Paris, Apr-Tl~74. [27] P. Kosinksi, K Data Flow Language for Oper- ating Systems Programming, SIGPLAN Notices 8, 9 (1973), 89-93. {28] M. Hammer, W.G. Howe and I. Wladawsky, An Interactive Business Definition System, SIGPLAN Notices 9, 4 (1974) 25-33. [29] ~ e ~ H o w e , V.J. Kruskal, and I. Wladawsky, The Business Definition Language, I.B.M. Research Report, March 1975.
