C. A. R. Hoare (1973). Hints on programming Language Design. From Proceedings of ACM SIGACT/SIGPLAN Symposium on Principles of Programming Languages. Reprinted in Horowitz, E. (ed.): Programming Languages: A Grand Tour (3rd Edition). Rockville, MD: Computer Science Press.
Hoare spends a significant number of lines at the beginning of page 33 belittling debuggers, because of their inconsistency and high cost, in terms of system resources. Now that many quality debuggers have been produced for a wide variety of languages, and system resources are plentiful, are Hoare's disparaging remarks still valid?
Hoare has such an emphasis on simplicity; what would he think about a modern object oriented language like Java that requires what is, for most people, a non-intuitive approach to solving problems?
Is simplicity still possible when, as appears to be the general consensus, to continue to receive the exponential performance gains promised by Moore's law, all programs will have to be written to allow concurrency, a fundamentally complicating concept?
How well do you think the Java's implementation of modularity fits with
Hoare's ideas on simplicity and modularity?
When talking about efficient object code, Hoare mentions that "In the future we must hope that hardware designers will pay increasing attention to reliability rather than to speed and cost." Have the trends in the hardware industry between 1973 (when Hoare wrote) and now gone against Hoare's hope?
iI don't really understand what the compiler actually does and how that is
related to programming errors. On page 32 Hoare states that "Certain
programming errors cannot always be detected in this way...in no case can they
be allowed to give rise to machine or implementation dependent effects..."
How would compiled code give rise to a correct yet errored program without the
machine producing wrong output or runtime errors?
And later (pg. 32) "...and it is irritating when their proponents claim that
future hardware designs..."
How can a programming language rely on future hardware designs? I thought all
languages worked with the same machine?
Page 33, "...it is absurd to make elaborate security checks on debugging runs,
when no trust is put in the results...". What is the purpose of testing using
well thought out test cases?
Can you also explain the different ways that compilers are sped up...Prescan,
Precompile, Dump.
Hoare seems to argue in some points that a program language designer should always do things in a certain way, either to give programmers more control over their program or to prevent programmers from making mistakes. It seems that one can draw a parallel between program language designers and the political spectrum in the following sense that there is a question of how much faith a program language designer should have for the average programmer. Hoare seems to be straddling the fence on this point; on one hand he fears that bracketing comments (/*COMMENT*/), could cause a programmer to lose track of comment context, but he also discourages languages which allow users to let the programming language deal with unmatched types. Thus the question becomes, where should a programming language designer be dogmatic? What are the key areas that programming language designers of the modern area can agree on?
My question is about Hoare's comments about program design in the first section. He says that a good programming language should aid the programmer in expressing how the program is to run. I wonder if you could say that the basic way in which a program is designed is determined by the specific paradigm in which the programming language belongs. For example, if you were writing a program in an object-oriented programming language, you would design in terms of classes and objects.
I do not agree with Hoare's principle of disjointness of variables (p. 38). The example he gives (p. 38) is valid, but his fix would disallow:
matrix multiply (A,B,B)
which is a perfectly legimitate request to let matrix A be the square of matrix B. If a language actually enforced `disjointness of variables,' it would not have `procedure calls and parameter passing [that produces] very compact code' (p. 38).
In the "Hints on Programming Design" reading, Hoare suggests that features of lesser relevance should not be implemented in a language in order to preserve overall simplicity. If we were to then keep secondary features in a library it would seem to circumvent the issue of simplicity while allowing the language greater dexterity. Would any undesired effects such as inefficiency arise from this tactic?
I'm curious about the languages that don't allow references (Fortran for example). This makes for simpler analysis, but how can they be efficient? I know Fortran is used for heavy numerical work... are there compiler tricks involved?
Obviously since this paper was originally published in 1973, many of the 'hints' suggested have been implemented and have become common place. The author mentions independent compilation as "a solution to yesterday's problems; today it has grown into a problem in its own right." Have any of the 'hints' in this paper which have been applied become problems in their own right, and should more thought be put into the potential long term problems that certain fixes might cause.
Hoare says that modularity and orthogonality can have bad effects on
program simplicity but goes on to say that these principles could be used
as a means to an end to create simplicity. What are examples of
simplifying uses of orthogonality and modularity? How does this relate to
what Guy Steele said about a programming language beginning simple
and gaining complexity through user input? If Hoare's approach is the
same as Steele's I think I understand it. If his approach is different I
would like to explore what exactly that approach is.
How do Hoare and Steele see eye to eye? It seems that they took very divergent tacks in their language design philosophy. Has the vision of those such as Steele replaced that of Hoare, have they found common ground, or do they simply continue to disagree?
On pg. 32. What is orthogonality? Is it similar to the concept that Guy
Steele discussed in the video on Monday about the addition of new features to
a language?
;
Check with Bobby