Papers on Programming Language Design

Comments on:

N. Wirth. (1974). On the Design of Programming Languages. Proc IFIP Congresss 74, pp. 386-393.

Hoare, C. A. R. (1973). Hints on Programming Language Design. ACM SIGACT/SIGPLAN Symposium on Principles of Programming Languages.

Comments from:

Peter Brown, Michael Claveria, Davis Hart, Alex Leach, Brad Miller, Angeline Namai, Mark Nettling (missing), Dimitar Tasev (missing), Dave Ventresca (*).

I'm not sure what to say about these two readings. They weren't exactly smooth and easy but they did have some interesting aspects.

You're reading primary literature, written for other professional computer scientists. I doubt that much of it will be smooth and easy.

Hoare and Wirth take fundamentally different approaches to programming language design - Wirth desiring to improve upon the high-level language and Hoare wishing to simplify languages to resemble their low-level counterparts. Hoare demands more of the programmer than of the language through his ideal - requiring better documentation and a more thorough understanding of the language, and principles of programming. These desires are completely impractical in today's industry and academia, where projects have reached such massive proportions that attempting them in a language similar to Fortan would be rediculous. Wirth, understanding this, describes his interest in improving high-level languages to prevent careless programming errors, and support, through the carrot of heightened clarity and efficency of code, rather than through the stick of bugs and seg faults, expansion of a programmers understanding of the language.

Some very large projects are still written in some of the old-school languages.

Both Hoare and Wirth wrote about simplicity in the beginning parts of their essays. Hoare's discussion centered on the problem with substituting the objective of simplicity with modularity. In some respects modularity, the concept of suggests that a programmer can still work with only a section of understanding rather than full knowledge, does contribute to simplicity. However Hoare also remarks that in practice simplicity is much easier to achieve than modularity. Wirth's discussion on simplicity centered around not containing too many concepts or too many words. The key for this would be more about "keeping the facilities of language simple to understand and their consequences of usage free from unexpected interactions when combined," (24). Hoare commented that the user was the greatest beneficiary for simplicity in language even as he wrote that the language designer and the compiler need simplicity in order to work. I suppose a big thing is for the programmer to remember and learn all the features fairly easy so that he or she can concentrate on problems rather than using the tools.

Some designers feel somewhat differently - They want a tool design that shapes how people concentrate on solving problems.

There were some statements I was curious about in the readings. On pg. 23 Wirth said, that group was surrounded by skepticism, as word passed that some of these people did neither know Ohm's law nor Maxwell's equations. So did people diss each other in Berkeley back in the day by saying, Your mama's so stupid, she doesn't even know Maxwell's equations. I suppose knowing about circuits and electricity was important back then with their many wires.

I would expect that electrical engineers still expect everyone to know these basic concepts.

Comments on Wirth: His points are solid, but I don't like his point about not equating simplicity with lack of structure or limitless generality. I think Perl is a good example of a language that does equate simplicity with a lack of structure. I guess Perl has some structure, but it's nowhere near as rigid as most other languages.

I'm not sure that Perl is simple. My experience suggests that most Perl programmers only learn a little bit of Perl. If it were truly simple, you could (and would) easily learn all of it

Comments on Hoare: I really appreciated his points on different conventions, especially the one on commenting out lines of code. I found the bit on type definitions to be quite interesting, how language designers might disagree on whether or not to check if different types are being compared. This reading seems to focus more on the specifics from the programmer's end, where Wirth's focuses more on how the language itself will work.

Hmmm ... I read both as considering how the language will work. Both certainly have some focus on efficiency and a natural translation to efficient code.

The thing that struck me most about the articles was how much thought goes into designing a language. I guess I never thought about it before, I always asumed that comeing up with a design was simpler then the articles make it out to be.

Language design is easy. Good language design is hard.

Hoare suggests that good language design minimizes type errors and maximizes assistance in program debugging. I am not very familiar with several of the major programming languages, but based on Hoare's idea, I believe that Java is one of the most programmer-friendly languages. Java forces the programmer to make the type of any object explicit. When I first learned to program in Java, I thought that it was unnecessary to specify the type both when declaring and assigning a value to a variable. However, I found that I made fewer errors in Java than in Scheme. As compared to Scheme, Java reduces the risk of errors when comparing variables, since the programmer is aware of the types in comparison, and can therefore tell when an operation makes sense. While C also makes use of types, the error messages displayed seem to be too general. The classic example of an ambiguous error message in C is the segmentation fault. I encounter this error message when I mistakenly attempt to dereference a null pointer or when I try to access the value at an out-of-bounds index. C leads one to overlook the difference between these two errors. It could be that the length of my array is 6, but that there is nothing at index 3. When I get the segmentation fault, I may be led to believe that I am trying to access a value that is out of range, and it may take me some time to figure out that there is null at index 3. In contrast, the designers of Java decided to implement both the NullPointer and ArrayOutOfBounds exceptions. This may appear trivial, but the fact is that Java's error messages are more specific, and they therefore make it easy to detect and fix errors, and thus save time during debugging. A good programming language should be simple, but not overly simple so as to be too general and confusing to the programmer.

I'm not sure that Java is simple.

The first thing I found myself wondering about, with regard to both articles was the dates in which they were written and what, if anything, has changed since then. The articles, written in the mid 70's, came from a time when FORTRAN and ALGOL are the dominant languages and when languages such as PASCAL and C were just taking form. The Hoare article addresses much more specific concerns, relating to the languages such as FORTRAN and ALGOL and PL/I, but is still able to effectively generalize to cover many of the emerging languages of the day. As a result, I feel that many of the concerns brought up by the authors holds true and, while issues such as computer's space and speed have changed in scale since the time of writing, it still makes sense to try and create the most efficient code possible.

I also found it interesting how both authors treat Language and complier design as a relatively normal task that people should embark on. Wirth even suggests that a new language should be the work of one person if at all possible. When I think of language design, I can't imagine one person doing it all by themselves. I realize that many languages, including FORTRAN, ALGOL and even JAVA are the product of 10s and even 100s of peoples' effort, while other languages do indeed come about due to one or two people with a common goal.

Perl, Ruby, C++, and, in some ways, Python, are all, at least at heart, the work of one dedicated and talented individual.

As we pointed out in class, however, it is interesting to note that while new languages continue to pop up, there haven't been any revolutionary languages since around the time of the 70's. Does this mean that no one followed the authors' advice or that we have followed it too closely and become stuck in a paradigm, and unable to see other, more radical alternatives? To me it seems as though it's a little bit of both. On one hand, people seem happy with the tools.

Backus would tell you that we're stuck in the von Neumann bottleneck (his Turing-award speech was on that topic). But even his alternative did not seem that radical.

One of the major ideals that both authors hold in high esteem is simplicity. This, although it makes a good deal of sense, is a curious notion. It seems that the majority of the high-level languages used today are enormous and simplicity is uncommon. For example, Java is in an almost constant state of expansion. New attributes of the language appear so regularly in fact that an online manual is almost necessary (except if you devote all your time to memorizing Java) in order to effectively code in Java. My question forthcoming is almost obviously, if the ideal for the design of a programming language is compactness and simplicity without detracting from the functionality, then why are modern languages so expansive and complex?

It's easier to make something complex than something pure and elegant, particularly when you're working with a team. There's also a great temptation for feeping creaturism.

I remember from CSC341 that we can represent any function/operation via the combination of smaller functions/operations (e.g. multiplication and division be represented by addition and subtraction respectively, etc). And although this method is extraordinarily simple, it is impractical because every user would create functions from combinations of functions and then add those functions to their libraries, hence customizing the language entirely (which would make the transfer of programs from one machine to another a time consuming matter). So wouldn't creating a language that is a middle ground between the complexities of a language like Java and the simplicity of an unadorned functional language be ideal? What I really don't understand is (beside how to balance between functionality and simplicity), what do these authors have in mind as the best type of programming language?

We'll consider your question in class.