Interview with Programming Visionaries Donald Knuth and Niklaus Wirth from 1985

Learn about the philosophies of these two men

May 22, 2023

Yesterday, I was searching for some new ads when I ran this dual interview. I felt that I had to post it because this newsletter is about computer history after all. Let me know in the comments if you would like more special posts like this. Enjoy!

Programming Philosophy: Interviews with Donald Knuth and Niklaus Wirth

By Ken Takara

This article examines the attitudes of two computer scientists — Niklaus Wirth and Donald Knuth — whose personal philosophies have profoundly affected the nature of programming.

Donald Knuth, professor at Stanford University, Palo Alto, Calif., is renowned for his three volumes of The Art of Computer Programming, a landmark in formalizing the discipline of computer science. His views of programming as an art have been expressed in numerous articles in Communications of the Association for Computing Machinery and in his 1974 ACM Turing Award lecture, "Computer Programming as an Art."

Niklaus Wirth, currently on sabbatical at the Xerox Palo Alto Research Center, Palo Alto, Calif., from the Swiss Federal Institute of Technology, is creator of the Euler, ALGOL-W, Modulo, and Pascal programming languages. Wirth is equally well-known for his strong advocacy of structured programming. He was awarded the prestigious ACM Turing Award in 1984.

Both men are professors, which is reflected in their common concern for programming clarity. Beyond that, Knuth's background is in mathematics while Wirth is trained as an engineer. These divergent backgrounds reflect the nature of computing — it is an amalgam of mathematics, engineering, and various other disciplines. The mathematician brings theory, proof, and formal rigor. The engineer brings practicality and purpose. Or is this really so?

Donald Knuth

CL: Your books are called The Art of Computer Programming, yet the discipline is called computer science.

Knuth: Calling it Art was my first idea for the title. I later decided to change it to The Analysis of Algorithms, but the publishers wouldn't lei me because they said it would never sell. I'm glad they talked me out of making a change.

Art, in one of its main senses, is something human beings can do, but we don't know how to automate. Science is something we understand well enough to formalize and mechanize. As science advances, we know more about the world. And we're able to automate more.

When someone says, "Let's convert an art into a science," he's saying, "Let's let the science catch up to where the art is, to what human beings can do." What happens is. as science advances, art also advances, but even further. When we learn more science, then our human abilities jump forward too. Then there's more for science to catch up with. I hope science never overtakes art; I can't imagine that happening.

But for me, I really like the meaning of the word in the sense of fine art. That is, it's possible to write grand programs.

CL: How does your paper on literate programming fit in?

Knuth: I've been stressing the notion of style in programming. You can have large programs that are beautiful or small programs that are beautiful. You can have programs analogous to poems or novels. In that paper, I'm trying to emphasize that the best way to program, I believe now, is really to concentrate on explaining to a person what the computer is supposed to do rather than explaining to a machine what it's supposed to do.

That's my new hobbyhorse, to say that people should think about the communication of the program while writing it. This makes it easier to write. The surprising thing is, that even though I'm writing programs that are better documented, it's taking me less time to write the program. I'm not losing time by taking this extra step. It's because I make fewer mistakes when I put myself in teaching mode to another human being. It's a discipline that keeps me from making errors I would make if I was hacking up something just for the computer, not really trying to explain how it works.

I start with an idea. Then I start trying to explain it to a hypothetical person.

For example, last night I needed a data structure to represent a hardware circuit for a sequential circuit. And I knew what kinds of operations I would be doing -- some Al-type heuristic searches. I got an idea about a suitable structure, and before I wrote any code, I started writing down "this data structure is going to contain gates represented in the following way, these are the inputs, these are the outputs." and so on. By the time I was through explaining in English what the data structures would be and how they would work, it was almost trivial to write the code and get it right.

If I started the other way, if I had started by playing around with scraps of code and so on, I would have floundered around a while, and the program wouldn't have worked. So 1 start out with an English description of the data structure and with a small example. Then I write a procedure that prints out the data structure in symbolic form. I get a program that will read the structure and print it out. This program is also an example of how to use the structure. Then I write a routine that recycles or initializes the data and so on. Pretty soon the program is done.

My program is contributing to the documentation too. The best way to document a program is the way science writers have done for a long time— by saying things twice in complementary ways. You say something informally and then formally. The formal reinforces the informal because it makes things precise, and the informal reinforces the formal because it gives you handles on how to store it in your brain.

The same thing goes for programming style, where you alternate between the informal comments and actual fragments of a program. I can hack together working programs fast, much faster than I could years ago. And I used to think I was good then. I think future languages should be a combination of a programming language and a document language. So you have a part where your text is just intended for paragraphs or math formulas and then you go into pieces of program that correspond to what you just said informally.

CL: You've made some comments about programming beauty and elegance.

Knuth: You know, life is hard. There are many unbeautiful things in the world. And the more beautiful things we have, the more tolerable it is. It's important to create beautiful tools.

We see now that a lot of the software is really pleasant for people to use day after day. The hard thing is to make something that will grow with the user— something that is easy to learn, but it's not a hassle six months later when the user has gone to a higher level of understanding.

For example, these mouse-oriented things. If you're a good typist, it's easier to hit the return key a few times to move down three lines than to pick up the mouse, move the cursor three lines, put it down, and so on. But the first week, you may really appreciate that mouse. Well, is there some way to have a system that continually grows? You can change the usage of it so that you can get better using it.

CL: Like a program that has plenty of help screens but where you can turn them off when you no longer need them?

Knuth: Yes. In the simple case, you have these game programs that ask if you want instructions. A tool, if it's really powerful, can change the user. The user becomes a different person after using it for a month and still another person after using it for a year.

This means that it's really inevitable to have "cults" among computer users-- cults in the sense that these people have used a certain powerful tool for a year. Only other members who have been in the same position can understand them. And this separates them from the rest of the world.

WordStar users, for example, or LISP users, APL users— every language user. I used to think it was a menace to have cults. Then, I realized, it's inevitable. I don't know if you would want to spread them too much, but if a tool is good enough, it's got to be good enough to have a cult built around it. It means that a person can do higher level things that make sense only after they've internalized a lot of how they use this tool. I now see that cults are unavoidable and are valuable for their members.

CL: You mentioned programming as a means of communicating to people rather than machines. There seems to be a running battle between people who think programming should be creative and original and those who want clarity and maintainability.

Knuth: Well, originality is important. If your only idea is to be highly original, but nobody can understand what you're doing, then you may score high on the originality scale but very low on the utility scale.

If maintainable means it has to be inefficient and full of banalities, it's because the programmers don't make use of the tools. If you have to do sequential searches instead of binary searches because binary searches are too sophisticated, then you have to limit yourself to things that require no knowledge to verify correct. You have only maintainability but no usability.

For example, Jim Morris invented a new way to find patterns in text. It was better than the obvious way because it didn't have to back up. Otherwise you would have had to worry about negative buffering. It was based on a nonobvious theory that contructs tables to remember how you got where you are; it's called the Knuth/Morris/Pratt Algorithm of Searching now.

Anyway, it's based on some magic tables, and Jim needed some mathematics to justify that it works. After he put it into this system at Berkeley, six months later, some maintainer came along, couldn't understand it, and ripped it all out and went back to an obvious algorithm. It was much slower, but at least the guy understood it.

Now, I don't want everybody to write programs that take a Ph.D. to understand. Lots of theoretical things have been developed that should rarely be used in real programs. The benefits arc often there only if we push things to the limits. The value of these theories is that it gives people more insight into the whole structure. The more theory you know, the easier it is for you to understand the few things that you really do use in a program.

People need this theoretical bent to extend their range. Take lists, for example. If a person knows some of the more complex theories about lists, he might never use those theories in a program, but his programming of even simple lists will be much more fluent.

I suppose it's easier to manage a group of people if you know exactly how they're supposed to do something in advance— if they're just supposed to knock something together following a very predictable set of constraints. But good programming is such an inherently intellectually creative act that it's impossible to keep it to an assembly line process. It's impossible for me to imagine managing a hundred programmers.

CL: What do you think are the important aspects of programming?

Knuth: Elegance comes in many forms. Sometimes I like to have a program that fits in a small number of bytes, and that's the criterion. Some of these game programs, both in arcades and home computers, are incredible works of art. They not only create something that responds to the human psyche, but they've also packed it into a small number of bytes.

Those are highly creative things. Maybe unmaintainable, but beautiful for their purpose. But other things are beautiful because they are maintainable or portable. I wouldn't stress one criterion over another.

CL: Niklaus Wirth says you place less emphasis on structuring code.

Knuth: I'm not sure about that. His Modula language doesn't have any GOTO statement in it. If we're talking about structure at the quantitative level instead of the qualitative level, I'm definitely different. But in more important matters we are in full agreement.

He passes a law against a part of the language, while I tell people why it's bad and how to use it properly. If they choose to use it, I don't make it impossible for them to do so. I make sure they know that they have a reason for what they're doing. So, in that sense, we have a different approach.

For me, structure is a state of mind rather than a set of rules. For example, suppose somebody said they want zero population growth. That's sort of a rule thing, "the population won't grow," instead of a state-of-mind thing, "we want a certain quality of life." And if there was away to have the same quality of life with more population, that would be OK. To make a rule saying "ZPG" because you're hoping that this gives a better quality of life is like saying "zero GOTO statements," because you're hoping that this gives you better structure.

Klaus and I visited recently, and I looked up some examples where I had used GOTO statements in my T F X program. Almost all of them were easy to change into Modula statements, but there was one place where Modula just couldn't handle it at all. And it was a perfectly reasonable program, as both of us agreed. And Klaus said, "Well, you can't have everything. Every once in a while, you have to write a little more program in order to avoid the use of GOTOs." Well, that's where we disagree.

Here's what the issue was: imagine a CASE statement that has 10 parts to it, of which the first three parts are similar except that the first part says, "Do something and then go to a common ending;" the second part does another thing and goes to the same common ending; the third part does a third thing and goes to the common ending; the fourth part skips the common ending. And so on.

This is very common in text processing, where I had several similar cases that I want to handle at high speed. If I reprogrammed it in Modula. I would have to copy the code for the common ending because the Modula language allows you an easy way to split up into several directions but not to collapse some of the directions together.

So my philosophy about structuring is that I use GOTO statements in a limited way. Any time I do so, I have an abstract concept so that I know what the GOTO statement means. That way, I think I avoid the problems of GOTO statements. I've kept track of all the bugs in this T E X program over the last few years; with thousands and thousands of users. I get a lot of bug reports. Naturally I'm finding more and more subtle ones. Out of 500 bugs, something like seven or eight were due to GOTO statements.

This proves that GOTO statements are indeed harmful. But that only covers two percent of the errors! So there are other things that are harmful too, and if we were to get rid of each thing that was harmful, we would be left without a programming language at all.

But Klaus and I do have the same point of view, that a person should understand the structure of his program by having a high-level view of it. The danger of an unstructured program is where the meaning is distributed here and there, and it's impossible to take any part of it and get a clear idea of what that part does. You might think it just happens to work when you put it all together. There's no intellectual way you can understand it as a whole, since it's all mixed up.

In that sense. I believe that structured programming is a very integral part of my own style. But I still think that when I use a GOTO statement, I have an abstract meaning of what that GOTO statement is.

CL: Sometimes it seems that most of programming is a matter of trying to bend the algorithm to fit the constraints or peculiarities of the language you are using. Some people prefer to use the low-level languages like Forth or C in order to get away from some of these limitations.

Knuth: I found that this was very true at the beginning, when structured programming became a moral code. People saw so much virtue in introducing a new Boolean variable just so that they could avoid a GOTO statement. While it took extra lines of code, the program was still quite safe and understandable. Most of the bad GOTOs were the kind a good programmer would never have written in the first place. There were other kinds that good programmers would naturally write. But the easiest thing was to abolish them. I thought it was silly. I wrote a long paper about it back in '73.

It's so much easier to pass a rule that abolishes something than to educate people and say, "Here's what it means when we use something." It's easier to give some sort of a quantitative rather than qualitative solution. That's where art comes in, balancing the quantitative and qualitative things.

There's another case where I've had arguments with Klaus— the question was, in a language, should you be able to compare pointer variables with each other? Say you have two pointers, could you test for Pointer X < Pointer Y? I believe most high-level languages forbid this because they say pointers are somehow special even though they arc just numbers inside the computer. The prevailing opinion among language designers is that we shouldn't give a meaning to whether one pointer is less than another.

One of the arguments is, of course, that you might have garbage collection taking place at any random time and that would change the value of all the pointers. Some garbage collection schemes would change the values so that ordering relationships would be maintained. But other garbage collection algorithms would maybe change the pointers, so sometimes the relation would be "less" and later on it would be "greater." You couldn't possibly have a decent program if this were the case.

So you can make a good argument for either side. But let me point out that if you can't compare pointers in a program, then you're forcing yourself to inefficient algorithms in certain ways. You cannot, for example, have a binary search algorithm that searches a table of pointers. You have to resort to an algorithm based on equality/inequality testing instead of less-than/greater-than testing. And it's known that the best equal/not-equal algorithms are much slower than algorithms that use comparison. This means that your language is forcing you to write a program that might be 1 00 times slower than one you could write in assembler. Or in Forth.

CL: How do you teach programming?

Knuth: Well, I haven't taught beginning programming for a long time. I teach the course after that. My views are very much like John Bentley's, in his book of efficient programs. I try to get students in that second programming class to realize what is going on inside the computer so that their high-level programs are based on a knowledge of what the costs are.

In a way, this is a handicap because it takes their minds off the applications they're programming. But in other ways, it's not really a handicap because no matter what application they have, they're going to have many ways to write it. They're going to have to choose the one that seems to them to be the most efficient, whatever their notion of efficiency is.

So I try to give them a realistic notion of efficiency rather than a language-only notion of efficiency. When they write in a language, they sometimes think that if they can express something in fewer lines of code, then they have a better solution for a problem. But it might, in fact, be the worst way to do the problem as far as the machine is concerned.

I'm basing efficiency on the real cost of what the real machine does, not on the number of characters in the program or something like that. I don't want to say that efficiency is the number one thing to have in mind, but everybody has some notion of efficiency. So in my programming course I try to give a good model for what that is. But I don't want people to be hung up on it as the first priority.

CL: How about programming elegance?

Knuth: Right now I'm writing programs in Metafont. where 1 have a choice between two styles. I can write code that makes the machine work harder yet it explains my intentions better. Or I can write a program that would be much harder to read but that would run much faster. In this case. I'm trying to make these programs so that somebody can read them and modify the letters I'm designing. Even though it's going to take more computer time to generate the fonts, each font generation is not going to be done every day. So I'm putting the emphasis in this case on readability.

But if I'm writing the Metafont compiler itself and confronted by the choice between readability and efficiency, I would choose efficiency: and 1 would add to my documentation, explaining why the program does what it docs, I would have long documentation for a more inscrutable program. But I won't do that for a program where the reader is more important than the execution.

When I taught introductory programming. I tried to emphasize there, again, that people would have some kind of a model of what the machine was like underneath as well as the algebraic language itself. I found it was more effective if I started by giving the people a little idea about what registers and such things were like.

CL: What languages do you use when you teach?

Knuth: I work with assembler when I teach my second year class and then a high-level language, usually Pascal. But I combine the two. I say, "Here's what the differences are between them." I think one of the most important things for people to learn is the ability to flash rapidly from the high level to the low level and back. That's what I tend to emphasize. I think that's what distinguishes the really good programmers from the ordinary ones— the ability to shift levels quickly.

CL: Your attitudes seem closer to that of an engineer than a mathematician.

Knuth: Few people realize the gap between a computer scientist's organization of knowledge and a mathematician's organization of knowledge. They think that they're both the same.

There have been a bunch of books lately by some mathematicians who are trying to exposit computer science the way it "ought to be done." And I know I couldn't have written one sentence of those books. Every sentence is, somehow, not a sentence that a computer scientist would write. And most of my colleagues share the same way of thinking.

That's why we're in this department. That's what makes us computer scientists. We have a variety of talents, but the main thing we do is characterized by a way of thinking that's reflected in the kinds of analogies that arc easier for us to understand.

On the days I'm a mathematician, I know I'm a different person. I wrote this book called Surreal Numbers. That's the mathematical me writing. Nothing about computers in there. The things I know about programming and languages and so on are not used at all. There's another part of me that's very unmathematical, very algorithm oriented, and that part of me wrote some parts of T E X and Metafont. Every once in a while I get wonderful opportunities where I can be both at once, and there I feel I'm really doing what I was sent to earth to do. There I know that because I've got this mathematical ability, I can do something more for programming. It's a feeling that I think is one of life's greatest pleasures. You don't have to operate in only one mode all the time. Everybody has chances to build bridges between disciplines, based on a unique combination of talents.

Niklaus Wirth

CL: Docs Pascal reflect your own personal approach to programming?

Wirth: Certainly. And it also reflects my particular field of work. I guess most common programming languages have their own field of application where they are good.

For example, BASIC was developed at Dartmouth College many years ago, mainly with the purpose of teaching introductory programming. I think it is pretty good at doing that to a certain degree, although it lacks certain concepts that are quite fundamental.

C.A.R. Hoare compared programming in BASIC to playing the piano with two fingers. You make very fast progress for the first very simple tunes, but if you have to go further, it becomes difficult. Now, many people who learn programming don't have to go further than just playing a few simple tunes. Also, there are many areas where once you solve the simple problem, you're done, and you forget about the problem.

My interest, however, is systems that arc going to be used by many people every day for many years, like compilers or operating systems or text editors. These are complicated systems. It pays to have a good tool tailored to design complex systems in a structured way.

CL: Everybody talks about "structured" nowadays. Is this really the best way to approach programming?

Wirth: It would be presumptuous to give some kind of globally valid rule for programming style. Programming is much too diverse a field to be condensed to some set of dogma. But, of course, there are principles that have proven to be superior to others.

Basically, the idea of structuring a program is to mirror the structure of the algorithm by the structure of the program text. We must structure an algorithm in order to understand it. We adhere meaning to certain parts of the structure. The structure holds the individual parts together. If we have an algorithm that is 10 pages long, we can't understand it unless we know how to decompose it into manageable portions.

CL: To some programmers, the linear approach seems to make more sense. The business of structuring seems restrictive.

Wirth: Of course, it's nice to have as much liberty as possible to express what we really want to express. But when designing and inventing new programs, it's a good thing to be able to rely on proven guidelines to help us keep our thoughts ordered. I mean, it is well known that we make too many mistakes otherwise. That's really the whole game of it.

Every algorithm has an inherent structure. Maybe it has nested loops. A compiler translates them into a string of bits. The machine is unaware of the structure of the original text. It just sees a mass of bits. But we, the humans, need the textual structure to be able to understand the algorithms.

If I may state one fairly general thing-- I find that most people think of the results of their programming efforts as something that is just being interpreted by a machine, Once the machine works correctly, they think the job is done. I think this is a terribly wrong attitude because the machine, in delivering one correct result, provides no guarantee that the next time, with different input parameters, the result will be correct again.

What I mean to say is that programs must be understood by humans. Programming should be an act directed not at the machines, but at humans. At the very least, one person besides the author should understand what it does. Every program should be written such that you can show it to your colleagues and know they will be able to understand and appreciate it.

CL: Donald Knuth is involved with something called "literate" programming, which deals with programming so that other people can read what you wrote.

Wirth: I have always admired his work. He perhaps emphasizes somewhat less the urgency of structuring than I do. But Knuth is an outstanding man. He has a very good mind. Perhaps he can follow an algorithm without bothering to structure it so explicitly and carefully. He can afford to be a little more sloppy, if I may say so.

He just recently showed me what he did with his WEB program, integrating text processing with programming, I think it's an interesting approach. It's hard for me to comment, I haven't developed a feeling for it, not having worked with it. What occurred to me, however, was that it is a programming style a book author would invent because he is trying to describe algorithms in books. So there he had it right away. He can refer back and forth.

Now I'm not so terribly sure that's such an awfully good idea— this cross referencing. Computers are good at it, but people have some trouble. Of course, essentially we use the same method. In my books I do the same thing.

CL: How do you approach teaching programming?

Wirth: I must say, teaching by good example is so far the only effective method I have found. Here, of course, I'm in contradiction with our friend, E.W. Dijkstra, who says you must teach from general rules, totally avoiding examples. In my experience, particularly in engineering schools, it is better to start with particulars that motivate the student and then move toward the general. Dijkstra, trained as a mathematician, thinks differently.

CL: One of the ongoing arguments in programming concerns programmer creativity. Some people think programmers should be considered artists. Others disagree.

Wirth: Let's face one thing about creativity. It's probably much less important than we usually would like to believe. In 99% of the programs that programmers write, creativity has very little place, maybe 1%. There are very few complicated data structure's: there are very few intricate algorithms. And if a programmer requires a sophisticated algorithm, he takes it from his collection of subroutines.

The major part is framework— the box it fits in. Think of an extreme example such as business data processing. You have sorting, you have searching, you have some arithmetic. You seldom have much more sophisticated things.

I don't think the use of structured languages presents any danger of reducing originality. To the contrary, a well-structured language is beneficial because it helps you put these collected algorithms into a nicer framework.

You develop a very sophisticated algorithm, like string searching, for example. Or a sophisticated method of finding eigenvalues in a matrix. I don't think the question of programming languages enters at all in the way you formulate the algorithm.

The art in engineering is not so much to make something very complicated. The art is to make a complicated problem simpler. When you develop a program, it's much harder to devise a simple solution than complicated ones. Unfortunately, our computers are terribly uncritical. They swallow anything.

Of course, so many people have argued about this. What I mean to say is that for a vast majority of programming activity, creativity in the higher sense of the word is not an essential ingredient. The interesting kind of programming is exactly the kind that requires some amount of creativity, but for daily work, that isn't true.

Creating the first spreadsheet— now that was highly creative. But there are not too many people who do such creative work with such imagination.

CL: One of the things about Pascal and Modula are their simplicity, which separate them from languages like PL/I or Ada. Is this part of your own philosophy also?

Wirth: Particularly as a teacher you learn to appreciate simplicity. I do not mean simplemindedness. Some people think it's the same thing. It's not. But it's nice to be able to teach clear, straight principles which you can freely combine when making logical deductions. Then the students can find their own suitable combinations where they're appropriate.

Ada set out with the same goal, I'm sure. But of course, already the requirements were baroque— very complicated and by no means without contradictions. Considering these requirements, the designers actually did a remarkably good job. PL/I or ALGOL-68 were definitely worse in this respect.

ALGOL-68 was at least consistent. That brings me to another problem. Ada is very complex. This requires complex compilers and big computers. And some people say this is going to be very expensive.

But I am afraid there is another thing which is much, much more expensive. And that is the time it takes for future generations of programmers to understand it all. I (believe, particularly in our field, you should thoroughly understand the tool you are using. How else can you hope to understand the program?

So it is by this fact also that Ada is an uneconomical language. It throws too many things at you. I don't think you can just learn a third of Ada and be fine. There are places where you tread on one of these spots which you haven't learned about, and it backfires on you.

CL: Of course, some people claim that having many features is an asset. All the tools you may ever need are there. You don't have to build them all yourself, as you do in Pascal or Forth.

Wirth: One of the advantages of Modula over Pascal is the ability to declare operators enclosed in modules. You can compile them separately and stick them into your library. Now you may have a dozen string packages, for example, and you choose the one that is most suitable to your purpose.

It is essential to distinguish between the facilities built into the language and those you can construct. The better a language is, the more you can construct and the less needs to be built-in. Ada potentially has the advantage of being backed by a powerful and well-endowed organization employing thousands of programmers to generate rich libraries. Modula relics on the work of "volunteers," as did Pascal in the beginning.

CL: I know of a fellow who likes COBOL because it provides him with ail sorts of features, including a sort command. And some PL/I programmers I know of wouldn't use anything that provides fewer utilities.

Wirth: First of all, if this fellow is so happy with COBOL, then by all means leave him with COBOL. On the other hand, other systems may have such libraries too. But I think it is essential that a language not be burdened with complicated operations like sorting. Sorting is expressible as a program in terms of simple operations, such as in Modula. You don't need a sort command built in. Otherwise there's no end to it

A similar case is input/output. There is no I/O in a strict language such as Modula. But there are sufficient means for people who can build basic drivers for devices or build routines for number conversion, formatting, etc.

We all use these operations in every program. They are stored as subroutines in the library.

CL: If everyone builds their own, don't you end up with many tools but little portability?

Wirth: I/O in Modula is a primary example of this controversy. But let's face it, it would be preposterous for me to define a single set of I/O routines that would be fit for the whole world to live with. And so, I said, let's build just the basic facilities.

I defined a simple set that many people find adequate, but which is evidently less than adequate for certain applications. It is anybody's own choice to stick to this set, or to use someone else's, or even to create his own. Portability has its price, and it is wise not to standardize every detail.

I haven't the feeling that I can solve all the problems of the world for all the people. I/O was certainly not one of them.

Consider Pascal's standardization. It took about six years to get that document out. It took so long because of some very awkward details that could not be agreed upon. I understand I/O was one of them. So I would have to wait another six years for Modula. It's much better if that went out without rigid standards for that sort of thing.

CL: What is the advantage of strong data typing?

Wirth: The types are the structural template we design for our data. Type checking means you use your operators and procedures consistently with your operands. You can't add two Booleans, for example, or invert a character. By declaring types explicitly, a compiler can check a program's consistency. And this is something we need in our battle against mistakes.

CL: Undoubtedly, there are places where strong typing is not desirable. People sometimes go to great lengths to get around the type checking.

Wirth: Yes. For example, you would like some generic routine that writes data on disk. To this routine, it doesn't matter whether you regard the data as logical, arithmetic, or whatever. So you need a generic read/write routine.

In programming with data types, we use abstraction. That's the whole game of it. For example, although we may know that a character is represented by seven or eight bits, we make no use of this knowledge. To convert a lower-case letter to its capital equivalent, for example, is a basic operation. The routine that writes data to the disk belongs to a lower level of abstraction. In moving from one level to another, we need to be able to relax the datatype rules.

CL: Still, people look tor loopholes when they arc not satisfied with the way the language handles, Sometimes they go to great lengths to get around the restrictions of the language.

Wirth: Yes. of course. That's the long way to avoid assembly language coding. As soon as you use a loophole, your program becomes essentially nonportable. The loophole may be fairly specific to the machine.

CL: Strongly typed languages provide a generic machine model. This means that you're farther from the real thing. Doesn't this limit the ability of the programmer, since he or she may not know what is really happening?

Wirth: Yes, it is definitely a problem. When you leach students only to learn to program in a high-level language, most of them aren't quite satisfied. They'd like to learn more about what is really going on.

For computer science students. I would say it's absolutely essential that they learn about machine structures and assembly coding. Not to become assembly language programmers, of course, but lo gain insight.

A good engineer must have a good understanding of the sort of tools he's using, not just know how they look. He has to know what is underneath. But I think you should be able to produce systems where a person with an understanding of what's underneath can say. "Now that I've learned it. I have enough confidence when I program in higher level instructions that the compiler is so good it will do its job and translate them to those low-level instructions. And even if I take the greatest care. I couldn't do very much better."

Knowing what's going on underneath will help a programmer do a better job using a high-level language. For instance, if he knows how much time a procedure call takes in comparison to an addition or a multiplication, he might use more procedure calls, or fewer, depending on the situation. Of course, to a beginner it doesn't matter. But when you write a systems program or a compiler, you like to have more insight.

CL: Some languages like Forth or C have little type checking. The programmer is totally responsible for what happens. But in return, he gets high performance and total flexibility.

Wirth: I find particularly engineers like to have hands-on ability. They like to know what signals go through the bus and which registers are used for what. For them, the lower level languages are more appealing. But I'm afraid the trend is toward more and more complex systems. And that's where the use of high-level languages with lots of redundancy checking ultimately proves to be not only beneficial but indispensable.

I have also designed a language which, though I wouldn't say is similar to Forth, more or less adhered to the same philosophy. It was in 1965, when I had the task of implementing an ALGOL-W compiler on Stanford's first IBM 360. There was only an assembler available, and I didn't like it so much.

I quickly designed an intermediate language. It's called PL360. It's almost typeless, but it has program structures like for, while, and if statements. In that sense, it's quite similar to Forth or perhaps to C. It's closer to the machine with respect to data but with high-level program structures. I would myself not use it today. I feel a lot more comfortable with high-level languages offering as much checking as possible.

For instance, the Lilith machine we designed does a lot of checking. An interpreter/compiler docs what it can, and those things it cannot do, we do at run time. So every array is checked for its boundaries. If the hardware is done properly, this doesn't cost much. We found that when we turn off the checking, the programs are faster by only a few percent.

But the essence of data types is that most checking can be done by the compiler and does not deteriorate efficiency at execution time.

C is similar to Forth in that respect. By the way, Dennis Ritchie thinks the same way. He also felt that we should go to languages that are more structured and with more redundancy. C is becoming popular because UNIX is written in C. Better learn C when you're using UNIX! But I don't think it's a step forward.

A bad language is really terrible. A language is something you use to communicate with. In programming, we use the term language because of some work dealing with methods of describing the notation in formal terms, like Noam Chomsky proposed to do with so-called natural languages. Of course, he failed considerably, but that's where we get programming "languages." I would much prefer programming "notation." but what has happened is irreversible.

CL: What are the qualities of a good programmer? Are there creative individuals found in this field?

Wirth: I had a discussion recently with one of my colleagues about what should be required of our students. The feeling was this: at the B.S. level one should expect that a student knows how to apply techniques that were taught and that he does this conscientiously. At the M.S. level, he is expected to distinguish between important and less important things — between essentials and details. He should have a taste for solid design.

Even at the Ph.D. level we see an appalling lack of this ability, actually. If somebody docs a good job, has learned the techniques, applies them very well, and has learned to distinguish between important and less important things, that's already the Ph.D. level.

And then, there are a few left who have all that, plus imagination and creativity. They're really the exceptions. They are probably the ones you would call the artists. The really exceptional person needs both. He must have the scientific background: he must know his tools and have the ability to analyze situations and concepts. He must apply the tools accordingly, and if no adequate ones are available, create his own. And generating something new, that's asking a lot.

What's definitely bad is the guy who thinks he's terribly creative but ail he creates is shoddy work. Maybe he can inspire others to do it well, but my experience is that those who are really creative arc often those who also do good, solid work.

The rare person who has the ability to extend the boundaries by creatively and effectively using his tools is the true artist. Every true artist first masters the techniques needed for his art and abhors shoddy workmanship.

Computer Ads from the Past

Discussion about this post