gary lawrence murphy wrote r buckminster fuller it was only after i d completed the geodesic dome that i noticed it was beautiful r buckminster fuller i had cited the information theoretic concept of elegance in my dissertation did a google to find the reference and instead found a really great tech report for uot knoxville by bruce maclennan he cites efficiency economy and elegance but i think he s wrong the middle e should be effectiveness otherwise kudos efficiency is the relation of output to input effectiveness is the total output in information theory something is both elegant and efficient if no smaller or less costly something can product the same output in the same amount of time greg NUMBER URL who cares about elegance the role of aesthetics in programming language design technical report ut cs NUMBER NUMBER bruce j maclennan computer science department university of tennessee knoxville maclennan URL abstract the crucial role played by aesthetics in programming language design and the importance of elegance in programming languages are defended on the basis of analogies with structural engineering as presented in billington s the tower and the bridge this report may be used for any nonprofit purpose provided that its source is acknowledged it will be adapted for inclusion in the third edition of my principles of programming languages NUMBER the value of analogies NUMBER efficiency seeks to minimize resources used NUMBER economy seeks to maximize benefit versus cost NUMBER elegance symbolizes good design NUMBER for the designer NUMBER for the user NUMBER the programming language as work environment NUMBER acquiring a sense of elegance NUMBER references the value of analogies programming language design is a comparatively new activity it has existed for less than half a century so it is often worthwhile to look to older design disciplines to understand better this new activity thus my book principles of programming languages design evaluation and implementation grew out of a study of teaching methods in architecture primarily but also of pedagogy in other disciplines such as aircraft design perhaps you have also seen analogies drawn between programming languages and cars fortran model t c dune buggy etc these analogies can be very informative and can serve as intuition pumps to enhance our creativity but they cannot be used uncritically because they are in the end just analogies ultimately our design decisions must be based on more than analogies since analogies can be misleading as well as informative in this essay i ll address the role of aesthetics in programming language design but i will base my remarks on a book about structural engineering the tower and the bridge by david p billington although there are many differences between bridges and programming languages we will find that many ideas and insights transfer rather directly according to billington there are three values common to many technological activities which we can call the three e s efficiency economy and elegance these values correspond to three dimensions of technology which billington calls the scientific social and symbolic dimensions the three s s we will consider each in turn efficiency seeks to minimize resources used in structural engineering efficiency deals with the amount of material used the basic criterion is safety and the issues are scientific strength of materials disposition of forces etc similarly in programming language design efficiency is a scientific question dealing with the use of resources there are many examples where efficiency considerations influenced programming language design some are reviewed in my principles of programming languages in the early days the resources to be minimized were often runtime memory usage and processing time although compile time resource utilization was also relevant in other cases the resource economized was programmer typing time and there are well known cases in which this compromised safety e g fortran s implicit declarations there are also many well known cases in which security i e safety was sacrificed for the sake of efficiency by neglecting runtime error checking e g array bounds checking efficiency issues often can be quantified in terms of computer memory or time but we must be careful that we are not comparing apples and oranges compile time is not interchangeable run time and neither one is the same as programmer time similarly computer memory cannot be traded off against computer time unless both are reduced to a common denominator such as money but this brings in economic considerations to which we now turn economy seeks to maximize benefit versus cost whereas efficiency is a scientific issue economy is a social issue in structural engineering economy seeks to maximize social benefit compared to its cost this is especially appropriate since structures like bridges are usually built at public expense for the benefit of the public in programming language design the public that must be satisfied is the programming community that will use the language and the institutions for which these programmers work economic tradeoffs are hard to make because economic values change and are difficult to predict for example the shift from first to second generation programming languages was largely a result of a decrease in the cost of computer time compared to programmer time the shift from the second to the third generation involved the increasing cost of residual bugs in programs and the fourth generation reflected the increasing cost of program maintenance compared to program development other social factors involved in the success or failure of a programming language include whether major manufacturers support the language whether prestigious universities teach it whether it is approved in some way by influential organizations such as the us department of defense whether it has been standardized whether it comes to be perceived as a real language used by real programmers or as a toy language used by novices or dilettantes and so forth as can be seen from the historical remarks in my principles social factors are frequently more important than scientific factors in determining the success or failure of a programming language often economic issues can be quantified in terms of money but the monetary values of costs and benefits are often unstable and unpredictable because they depend on changing market forces also many social issues from dissatisfaction with poorly designed software to human misery resulting from system failures are inaccurately represented by the single dimension of monetary cost all kinds of cost and benefit must be considered in seeking an economical design elegance symbolizes good design elegance who cares about elegance snorts the hard nosed engineer but billington shows clearly the critical role of elegance in hard nosed engineering for the designer it is well known that feature interaction poses a serious problem for language designers because of the difficulty of analyzing all the possible interactions of features in a language see my principles for examples structural engineers face similar problems of analytic complexity but billington observes that the best designers don t make extensive use of computer models and calculation one reason is that mathematical analysis is always incomplete the engineer must make a decision about which variables are significant and which are not and an analysis may lead to incorrect conclusions if this decision is not made well also equations are often simplified e g made linear to make their analysis feasible and this is another potential source of error because of these limitations engineers that depend on mathematical analysis may overdesign a structure to compensate for unforeseen effects left out of the analysis thus the price of safety is additional material and increased cost i e decreased efficiency and economy similarly in programming language design the limitations of the analytic approach often force us to make a choice between an under engineered design in which we run the risk of unanticipated interactions and an over engineered design in which we have confidence but which is inefficient or uneconomical many people have seen the famous film of the collapse in NUMBER of the four month old tacoma narrows bridge it vibrated itself to pieces in a storm because aerodynamical stability had not been considered in its design billington explains that this accident along with a number of less dramatic bridge failures was a consequence of an increasing use of theoretical analyses that began in the NUMBERs however the very problem that destroyed the tacoma narrows bridge had been anticipated and avoided a century before by bridge designers who were guided by aesthetic principles according to billington the best structural engineers do not rely on mathematical analysis although they do not abandon it altogether rather their design activity is guided by a sense of elegance this is because solutions to structural engineering problems are usually greatly underdetermined that is there are many possible solutions to a particular problem such as bridging a particular river therefore expert designers restrict their attention to designs in which the interaction of the forces is easy to see the design looks unbalanced if the forces are unbalanced and the design looks stable if it is stable the general principle is that designs that look good will also be good and therefore the design process can be guided by aesthetics without extensive but incomplete mathematical analysis billington expresses this idea by inverting the old architectural maxim and asserting that in structural design function follows form he adds p NUMBER when the form is well chosen its analysis becomes astoundingly simple in other words the choice of form is open and free so we should pick forms where elegant design expresses good design i e efficient and economical design if we do so then we can let aesthetics guide design the same applies to programming language design by restricting our attention to designs in which the interaction of features is manifest in which good interactions look good and bad interactions look bad we can let our aesthetic sense guide our design and we can be much more confident that we have a good design without having to check all the possible interactions for the user in this case what s good for the designer also is good for the user nobody is comfortable crossing a bridge that looks like it will collapse at any moment and nobody is comfortable using a programming language in which features may explode if combined in the wrong way the manifest balance of forces in a well designed bridge gives us confidence when we cross it so also the manifestly good design of our programming language should reinforce our confidence when we program in it because we have well justified confidence in the consequences of our actions we accomplish little by covering an unbalanced structure in a beautiful facade when the bridge is unable to sustain the load for which it was designed and collapses it won t much matter that it was beautiful on the outside so also in programming languages if the elegance is only superficial that is if it is not the manifestation of a deep coherence in the design then programmers will quickly see through the illusion and loose their unwarranted confidence in summary good designers choose to work in a region of the design space where good designs look good as a consequence these designers can rely on their aesthetic sense as can the users of the structures bridges or programming languages they design we may miss out on some good designs this way but they are of limited value unless both the designer and the user can be confident that they are good designs we may summarize the preceding discussion in a maxim analogous to those in my principles of programming languages the elegance principle confine your attention to designs that look good because they are good the programming language as work environment there are other reasons that elegance is relevant to a well engineered programming language the programming language is something the professional programmer will live with even live in it should feel comfortable and safe like a well designed home or office in this way it can contribute to the quality of the activities that take place within it would you work better in an oriental garden or a sweatshop a programming language should be a joy to use this will encourage its use and decrease the programmer s fatigue and frustration the programming language should not be a hindrance but should serve more as a collaborator encouraging programmers to do their jobs better as some automobiles are driving machines and work as a natural extension of the driver so a programming language should be a programming machine by encouraging the programmer to acquire the smooth competence and seemingly effortless skill of a virtuoso the programming language should invite the programmer to design elegant efficient and economical programs through its aesthetic dimension a programming language symbolizes many values for example in the variety of its features it may symbolize profligate excess sparing economy or asceticism the kind of its features may represent intellectual sophistication down to earth practicality or ignorant crudeness thus a programming language can promote a set of values by embodying certain values it encourages us to think about them by neglecting or negating other values it allows them to recede into the background and out of our attention out of sight out of mind acquiring a sense of elegance aesthetics is notoriously difficult to teach so you may wonder how you are supposed to acquire that refined sense of elegance necessary to good design billington observes that this sense is acquired through extensive experience in design which especially in europe is encouraged by a competitive process for choosing bridge designers because of it structural engineers design many more bridges than they build and they learn from each competition they loose by comparing their own designs with those of the winner and other losers the public also critiques the competing designs and in this way becomes more educated their sense of elegance develops along with that of the designers so also to improve as a programming language designer you should design many languages design obsessively and criticize revise and discard your designs you should also evaluate and criticize other people s designs and try to improve them in this way you will acquire the body of experience you will need when the real thing comes along references NUMBER billington david p the tower and the bridge the new art of structural engineering princeton princeton university press NUMBER chapters NUMBER and NUMBER are the most relevant NUMBER maclennan bruce j principles of programming languages design evaluation and implementation second edition new york holt rinehart winston now oxford university press NUMBER 