Computer Programming as an Art

I read from the 1974 Turing Award Lecture by Don Knuth.

Biography - Lecture

In this talk, I shall try to explain why I think art is the appropriate word. I will discuss what it means for something to be an art in contrast to being a science. I will try to examine whether arts are good things or bad things. I will try to show that a proper viewpoint of the subject will help us all to improve the quality of what we are now doing.

Hello. My name is Eric Normand. This is my podcast. Welcome. Today, I am reading from the 1974 ACM Turing Award lecture. The award was given to Donald Knuth, Don Knuth. He's something of a legend in computer science. I'm going to read from his biography. I've been waiting to do this one for a while. I hear all these little stories about him, but I had never read this lecture.

Interestingly, from his biography, he was given this award in 1974. He was born in 1938, which makes him 36 years old when he got the award. That's very young. It's younger than I am now. To me, wow, that's pretty accomplished by this age.

Also, we're lucky that he has a lot of lectures and interviews and even podcast appearances that are still happening. You can still hear from him in the voice and you can see him and everything, which is really cool. If you want to learn more about him, that's often a really good way to do it. You get a much richer feel for the person that way.

Lets go into his biography. They tell you what he was awarded it for, so three things, analysis of algorithms, and the design of programming languages, and the art of computer programming. These are all for contributions in general, but three things, analysis of algorithms, design of programming languages, and art of computer programming.

Of course, he is well known for having written the book, the large multi-volume book called "The Art of Computer Programming." He also has what is sometimes referred to as the biggest yak shave in history. I'll get to that. I'll read from here.

I just a have few points from the biography that I want to read. This is about the book that he was writing. "The word got around that he knew a lot about compilers, and in 1962, in his second year at Cal Tech, Addison-Wesley asked him to write a book on compilers. He sketched 12 chapters and signed a contract.

"After receiving his PhD in 1963, Knuth began working on a chapter on sorting, a topic related to some compilers." Just to stop here, the book started out to be a book about compilers, not computer science in general, just compilers.

"He read many technical articles, and noticed the spotty and sometimes unreliable nature of the literature in the, then new, field of computer science. He saw the need for someone to write a book which organized and reliably presented what was then known about the field.

"Knuth was a good writer and had an instinct for trying to organize things, so he decided to tackle it. He used a quantitative rather than qualitative approach, and emphasized aesthetics -- the creation of programs that are beautiful.

"The book grew longer as he wrote it, reaching 3,000 hand-written pages, the equivalent of 2,000 printed pages, by the time he finished the first draft of the 12 chapters in June 1965." There's a little bit more history of how it was published into different volumes and stuff.

Some more about the book. The Art of Computer Programming, emphasized the mathematical approach for comparing algorithms to find out how good a method is. Arguably, the books established analysis of algorithms as a computer science topic in its own right.

Another thing I want to emphasize, this is very...When we talk about like, order and algorithms or n-squared algorithms, that's all what he's talking about in analysis of algorithms. It's like very commonplace today.

It's in all the big companies' interviews, where they want you to figure out how to turn a quadratic algorithm into an N logN algorithm, something like that. The other thing is this duality between using a quantitative method, quantitative approach, and emphasizing aesthetics.

Not using a qualitative approach, but trying to actually pin things down with numbers. Then also emphasizing aesthetics which seem to contradict but that's what he goes into in the lecture. Also the book served as a focal point for developing curricula and as an organizing influence on computer science.

This is a theme that comes up a lot in Knuth's work is just organizing. He's monastically taking all the stuff that we know, and boiling it down into reference, these big books. It takes a certain kind of mind to do that. He's really good at it.

Now we're talking about tech, which is what I was talking about the biggest Yak shave in history. Knuth is well-known for his perfectionism and offers to pay $2.56 for each error found in his books. Finding one confers prestige on the discoverer, many of whom frame and display the hand-sign check, rather than cashing it.

Of course, you'd want to keep the check. It's only $2.50. He revised the first three volumes. Then he was deeply disappointed when in 1973, he saw the typesetting from Addison Wesley for the second edition of Volume Two.

By then, the publishing industry had replaced traditional mechanical typesetting technology with computerized typesetting that did not reproduce the high quality of the original printings of volumes one through three. In 1977, Knuth began developing a new typesetting system to enable high quality computerized typesetting.

He had two goals for his system. One, achieving the finest quality printed documents. Two, creating a system that would be archival in the sense that it was independent of changes in printing technology to the maximum extent possible. Imagine this.

You are 16 years into writing your magnum opus. You realize that the typesetting is not up to your standards. Do you spend another decade? [laughs] Who'd read this?

Knuth thought his typesetting work would take a year or two, but it was not until 1990 that he announced that he would make no further changes to his systems except to correct serious bugs. This is a serious Yak shave. Tech is a system that is widely used all over the world for writing technical papers, or publishing books, etc.

He was doing this in order to typeset his own book. Spent years and years developing this, probably alongside each other. Let's be honest.

He kept developing it because he still had things he wanted it to do that he needed for his book. That's big as Yak shave in history. I'll just conclude with this. "He credits much of the work of his..."

I'm sorry. "He credits much of the success of his work to combining theory with practice. Knuth is the rare theoretician who writes many lines of code every day.

"Programming is an art he practices often." When I was younger I thought it was sad that he was dedicating his life. He retired early so that he could work on the book more. It just seemed very final to dedicate your life to something like that, but he's having fun and he's still programming stuff on the side.

He still publishes lots of research papers. I think that maybe it's not so sad to have a project like that that's having such a big influence on the industry. Now that I'm older, it would be really nice to have a project where like, "I know what I'm doing for the rest of my life." Let's get into the lecture itself.

Just as a reminder, I'm not going to read the whole thing. I'm just going to exert some sections and I will give my own comments. A lot of them will just be personal opinions and commentary. It's not super technical.

Sometimes it gets technical and my commentary is more like, I did some research to figure out what he was talking about, or what the author was talking about. In this one, it is not so technical so it's going to be a lot more my personal reflections on it.

There is a citation at the beginning which by that they mean and little introduction to the person and to why they got the award. This one was written by Bernard Galler who is chairman of the committee. I'm just going to read one little sentence from it.

"The vocabulary, the examples, the algorithms and the incite that Don Knuth has provided in his excellent collection of books and papers have begun to find their way into a great many discussions in almost every area of the field."

That just shows his influence and why he's the one who got the award that year. I think they read like, "I have a degree in computer science." They were just throwing out his ideas left and right like they were just in the textbook, but a lot of them just came right out of him. He doesn't get as much credit as he deserves.

Now I'm going to start. This is called "Computer Programming as an Art" by Don Knuth.

"When communications of the ACM began publication in 1959, the members of ACM's editorial board made the following remark as they described the purposes of ACM's periodicals, 'If computer programming is to become an important part of computer research and development, a transition of programming from an art to a disciplined science must be effected.

Such a goal has been a continually recurring theme during the ensuing years. For example, we read in 1970 of the first steps towards transforming the art of programming into a science. Meanwhile, we have actually succeeded in making our discipline a science in a remarkably simple way merely by deciding to call it computer science." [laughs]

That's a funny joke. "Implicit in these remarks is the notion that there is something undesirable about an area of humanity that is classified as an art. It has to be a science before it has any real stature. On the other hand, I have been working for more than 12 years on a series of books called, The Art of Computer Programming.

"People frequently ask me why I picked such a title. In fact, some people apparently don't believe that I really did so. Since I've seen at least one bibliographic reference to some books called 'The Act of Computer Programming.'"

He made another joke. That's good. Get the crowd warmed up with these little jokes. Now I've read this part already. "In this talk, I shall try to explain why I think "art" is the appropriate word. I will discuss what it means for something to be an art in contrast to being a science.

"I will try to examine whether arts are good things or bad things and I will try to show that a proper viewpoint of the subject will help us all to improve the quality of what we are now are doing."

Like I said, this isn't going to be very technical.

He's talking about the meaning of the word the art and science and comparing them and how they've changed over time. "If we go back to Latin roots, we find ars, artes meaning skill. It is perhaps significant that the corresponding Greek word was techni. The root of both technology and technique.

"Nowadays when someone speaks of art, you probably think first of fine arts, such as painting and sculpture, but before the 20th century, the word was generally used in quite a different sense. This older meaning of art still survives in many idioms especially when we are contrasting art with science."

The thing I want to mention in this little section is like he's really diving deep into these words.

Earlier, he says that art must be one of the most interesting words in the English language because he spent days researching this.

I really find it when I do something like that, when I deep dive on a word like what does it mean? Where does it come from? I know a lot of words, like we all do, but have I really figured out what it means and where it comes from?

When I do that, because I sometimes will do that, I feel it's refactoring my understanding, refactoring my mind. I've got new ways of thinking. That's what he's doing here, and he's trying to impart that.

"In medieval times, the first universities were established to teach the seven so-called liberal arts, namely grammar, rhetoric, logic, arithmetic, geometry, music, and astronomy. Note that this is quite different from the curriculum of today's liberal arts colleges, and that at least three of the original seven liberal arts are important components of computer science."

What I think he's referring to, logic, arithmetic, and geometry, maybe rhetoric instead of geometry. Geometry is probably more like it.

"At that time, an art meant something devised by man's intellect, as opposed to activities derived from nature or instinct. Liberal arts were liberated or free, in contrast to manual arts such as plowing. During the middle ages, the word art by itself usually meant logic, which usually meant the study of syllogisms."

This is interesting that there were an enumerated list of the liberal arts. That was what you learned at a liberal arts university. It's quaint, but they probably understood these better than we do today, even having taken a class in grammar.

Let's continue on, but before we continue, I want to re-emphasize "an art meant something devised by man's intellect." Of course, he's using man to mean human. At that time, an art meant something devised by human intellect.

Next, "The word science seems to have been used for many years in about the same sense as art. For example, people spoke also of the seven liberal sciences, which were the same as the seven liberal arts," so equivalent.

"As civilization and learning developed, the words took on more and more independent meanings, science being used to stand for knowledge, and art for the application of knowledge. Thus, the science of astronomy was the basis for the art of navigation. The situation was almost exactly like the way in which we now distinguish science and engineering."

Science is knowledge, and the art the application, just like we use engineering for the application of science even though it's not exactly what it means. You can have engineering without science.

"As I was looking up these things about the meanings of art, I found that authors have been calling for a transition from art to science for at least two centuries. According to most dictionaries, science means knowledge that has been logically arranged and systematized in the form of general laws.

"The advantage of science is that it saves us from the need to think things through in each individual case. We can turn our thoughts to higher-level concepts. As John Ruskin wrote in 1853, 'The work of science is to substitute facts for appearances and demonstrations for impressions.'"

I don't know if I would pull out a book from 1853 to understand words for a lecture I was giving, but maybe I should. Maybe that's why he's getting the Turing Award, and I'm never going to get it.

"It seems to me that if the authors I studied were writing today, they would agree with the following characterization. Science is knowledge, which we understand so well that we can teach it to a computer and if we don't fully understand something, it is an art to deal with it.

"Since the notion of an algorithm or a computer program provides us with an extremely useful test for the depth of our knowledge about any given subject, the process of going from an art to a science means that we learn how to automate something."

If you can write a computer program to do a thing, then you understand it in a scientific sense, it's mechanical. It's something you can automate. But if you don't understand it, it's still an art. You can do it, but you don't understand what you're are doing, not in the way that you would understand science.

"Artificial intelligence has been making significant progress yet there is a huge gap between what computers can do in the foreseeable future and what ordinary people can do. Nearly everything we do is still an art." Still true, even though we have GPT-3. Somehow, it's not quite there.

"From this standpoint, it is certainly desirable to make computer programming a science. We have indeed come a long way in the 15 years since the publication of the remarks I quoted at the beginning of this talk. 15 years ago, computer programming was so badly understood that hardly anyone even thought about proving programs correct.

"We just fiddled with a program until we knew it worked. At that time we didn't even know how to express the concept that a program was correct in any rigorous way. When we write programs today, we know that we could in principle construct formal proofs of their correctness if we really wanted to, now that we understand how such proofs are formulated.

"This scientific basis is resulting in programs that are significantly more reliable than those we wrote in former days when intuition was the only basis of correctness." He's saying that we've done quite a lot to make it scientific in the sense of being able to formalize and automate something.

"The field of automatic programming is one of the major areas of artificial intelligence research today. Their aim is to create machines that write programs better than we can given only the problems specification.

"Personally, I don't think such a goal will ever be completely attained but I do think that their research is extremely important because everything we learn about programming helps us to improve our own artistry. In this sense, we should continually be striving to transform every art into a science. In the process, we advance the art."

Remember, he's talking about art and science. "That science is the knowledge, and art is the practice, is the application. The more we can turn into knowledge, say, you could write it down and maybe write a computer program if it's really formalized enough, the better, because that actually pushes what we can do, in pract, our applications grow.

"The application of programming grows as our formalized part grows. They work in tandem. Our discussion indicates that computer programming is by now both a science and an art, and that the two aspects nicely complement each other. Apparently, most authors who examine such a question come to this same conclusion, whatever their subject is." That's really interesting. He gives some examples.

"Actually, when I chose the title of my books, I wasn't thinking primarily of art in the sense. I was thinking more of its current connotations. Probably the most interesting book which turned up in my search, was a fairly recent work by Robert E. Mueller called "The Science of Art.""

He observes, "It was once thought that the imaginative outlook of the artist, was death for the scientist. And the logic of science seemed to spell doom to all possible artistic flights of fancy." He goes on to explore the advantages which actually do result from a synthesis of science and art.

So interesting, right? That they do work together. If you have both the creative-artistic side, and you have the logical-scientific side. "When I speak about computer programming as an art, I am thinking primarily of it as an art form in an aesthetics sense.

"The chief goal of my work as educator and author, is to help people learn how to write beautiful programs. My feeling is that when we prepare a program, it can be like composing poetry or music.

As Andrei Ershov has said, "Programming can give us both intellectual and emotional satisfaction, because it has a real achievement to master complexity and to establish a system of consistent rules."

Just a personal reflection here. I remember when I was in high school, maybe early college, I read an essay where someone was talking about why they liked programming. They'd also talk to other people about it, and there are some agreement about it.

What they said was that, "People like programming because it gives them control over a complicated complex piece of equip." You typed in the program, and it does the thing. If it doesn't do what you expect, it's your fault because you typed it in wrong. You got a syntax error or something. When you get it right, you get credit for it, right?

There's something about that that they found appealing. Now when I read that, it just did not ring true with me. That is not why I like programming. I thought about it for a while. It's not the control. I don't want to have control over a machine. That's not satisfying to me. What I like is what he was saying.

"This real achievement to master a complexity." Not the complexity of the machine, but the complexity of ideas and to establish a system of consistent rules. This idea that you can actually explore ideas. That is what really appeals to me.

It probably shows if you've listened to this podcast before, that that's kind of what I'm into. I feel a camaraderie with Don Knuth because I feel like his expressing my feeling of it. That I'm not just a plumber who feels good about having his pipes all in order and everything. No, I want consistency of ideas.

That the computer can show us where our ideas are inconsistent, and help us understand them better because they have to run. If they don't run, they don't do what you expect. Maybe your ideas aren't fully clarified.

That was my personal reflection. That's what I thought of when I read that. Furthermore, when we read other people's programs, we can recognize some of them as genuine works of art. I can still remember the great thrill it was for me to read the listing of Stan Polys' "SOAP 2 Assembly Program" in 1958. This is not 20 years later.

When was this again? 1974, so 16 years later. "You probably think I'm crazy and style has certainly changed greatly since then. But at that time, it meant a great deal to me. To see how elegant a system program could be. Especially by comparison with a heavy handed coding I found in other listings I have been studying at the time.

"The possibility of writing beautiful programs even in assembly language, is what got me hooked on programming in the first place. Some programs are elegant, some are exquisite, some are sparkling. My claim is that, it is possible to write grand programs, noble programs, truly magnificent ones."

Now at this point, I feel like he's really on a roll because I highlighted everything. This is going to take a while. I've really tried to find stuff to skip. This is the part where he even mentions that this is what he feels the most passionate about.

I want to comment on this section I just read. It's a big regret of mine that most of my friends don't program. I find it hard to share it with them. If I made a painting or a piece of music, I could be proud and show them, "Look what I did." You know, maybe they won't think it's impressive but I just want someone to see it.

But if I show them the code, they're like, "I don't know. That's like reading cling-on. I don't know what that is." I think that that sucks. [laughs] That really sucks that you can't share this works of art with non-programmers. I don't know if there's anything to do about that. I don't know.

"The idea of style in programming is now coming to the forefront at last, and I hope that most of you have seen the excellent little book on 'Elements of Programming Style' by Kernighan and Plauger.

"In this connection, it is most important for us all to remember that there is no one best style. Everybody has his own preferences, and it is a mistake to try to force people into an unnatural mold.

"We often hear the saying I don't know anything about art, but I know what I like. The important thing is that you really like the style you are using. It should be the best way you prefer to express yourself." Again, I caught this. It's really weird to say it nowadays. This is 2021. If someone wrote this now, it would be very awkward.

He wrote, "Everybody has his own preferences." Everybody obviously includes women. His, it sounds weird. I apologize for that. Just for historical, I don't want to edit what he's writing. It's hard to do it in the moment. Everybody has their own preferences is how I would say it.

He's saying that he's not trying to say that there is even a possibility of comparing styles. There's no better style, worse style. It's a matter of personal preference. Edsger Dijkstra stressed this point in the preface to his "Short introduction To the Art of Programming."

"It is my purpose to transmit the importance of good taste and style in programming, but the specific elements of style presented serve only to illustrate what benefits can be derived from style in general. In this respect, I feel akin to the teacher of composition at a conservatory. They do not teach their pupils how to compose a particular symphony. They must help their pupils to find their own style and must explain to them what is implied by this."

They have to find their own style. That's the key of an art teacher, to help that student find their own style. We must ask ourselves what is good style and what is bad style? We should not be too rigid about this in judging other people's work.

The early 19th century philosopher Jeremy Bentham put it this way. "Judges of elegance and taste consider themselves as benefactors to the human race, whilst they are really only the interrupters of their pleasure."

Hang on a second because this is from the early 19th century. We're going to have to go through it again. I'm going to read it once through, and we're going to go through it a little at a time. I'll start the Jeremy Bentham quote again.

"Judges of elegance and taste consider themselves as benefactors to the human race, whilst they are really only the interrupters of their pleasure. There is no taste which deserves the epithet good, unless it be the taste for such employments which, to the pleasure actually produced by them, conjoin some contingent or future utility.

"There is no taste which deserves to be characterized as bad, unless it be a taste for some occupation which has a mischievous tendency."

Let's go through it one sentence at a time. I had to, myself, reading this. "Judges of elegance and taste consider themselves as benefactors to the human race, whilst they are really only the interrupters of their pleasure."

There's critics, there's judges who say, "That's no good. That's not good taste. This is better taste." Snooty people, snobs, they think they're doing the world a favor. I'm just paraphrasing. They think they're doing the world a favor, but really, they're only stopping their own pleasure.

There is no taste which deserves the epithet good, unless it be the taste for such employments which to the pleasure actually produced by them conjoin some contingent or future utility.

There's no taste which deserves the epithet good, unless...There are some that maybe you can call good, unless it be the taste for such employments which to the pleasure actually produced by them conjoin some contingent or future utility. It's got utility with pleasure conjoined.

The pleasure, that thing, that taste gives you with utility. That's be useful. There's no taste which deserves to be characterized as bad, unless it be a taste for some occupation which has a mischievous tendency. He's saying like, "If it's just causing havoc, maybe it's not a good taste."

Knuth continues, "When we apply our own prejudices to reform someone else's taste, we may be unconsciously denying them some entirely legitimate pleasure. That's why I don't condemn a lot of things programmers do, even though I would never enjoy doing them myself.

"The important thing is that they are creating something they feel as beautiful." Super important. Taste, style, and programming, even skill in programming.

I'll speak from my experience. "As I've gotten better over the years in programming, there are some things I don't do anymore, that I learned, that I don't like doing because it gets me stuck somewhere, it causes bugs.

"I'll see people who are starting out, they're on their journey, and they're doing those things. Should I condemn what they're doing? I've concluded no. They're in a specific point. They're learning.

"I look at my two kids. They do stuff that I would never do because I know it's no good. [laughs] They need to learn. Maybe even the exploration is pleasurable. If it's not causing harm, if it's not going to be a danger, let them do it. If they want to...I don't know." [laughs]

I'm just trying to think of something silly that I see them do. Color in a certain way with holding four crayons at the same time. OK, do that. That's fun. You're just experimenting with the thing, with the medium. I would never do that because I know what it looks like and I don't like it.

The other thing I want to say about this is I'm so impressed by the depth of the research. He's quoting Jeremy Bentham. Let me figure out exactly what year this book is from. 1811, although it wasn't translated into English until 1825. You're given an award in 1974 and you decide, "I got to brush up on my Bentham."

It reminds me of...The stuff he's saying here. People have known for a long time. Bentham wrote it down eloquently in this book, but people knew it before. I'm just always amazed by how much we have to rediscover in our lives even though people knew it. I'm not a great reader. I know people who are like, "Oh, yeah. I read Bentham." I know people like that who've read thousands of books and they would bring them up in conversations.

You know what I mean, like, "Oh, yeah. Bentham said that years ago, 200 years ago now." I'll be like, "Oh. Well, too bad I didn't read that because I just went through a huge, expensive learning experience, that I could've saved all that time."

I don't know. I wish I could do this. I wish I had a store of knowledge from all the philosophers in the past because it will be really useful. Living hand-to-mouth. In the passage I just quoted, Bentham does give us some advice about certain principles of aesthetics, which are better than others, namely the utility of the result.

"We have some freedom in setting up our personal standards of beauty but it is especially nice when the things we regard as beautiful are also regarded by other people as useful. I must confess that I really enjoy writing computer programs and I especially enjoy writing programs which do the greatest good in some sense.

"There are many senses in which a program can be good, of course. In the first place, it's especially good to have a program that works correctly. Secondly, it is often good to have a program that won't be hard to change when the time for adaptation arises.

"Both of these goals are achieved when the program is easily readable and understandable to a person who knows the appropriate language." Common sense stuff here. Has to work correctly. That's the kind of utility. Being able to adapt it, that's a kind of utility. Being easy to read and understandable, that's another kind of utility.

"Another important way for a production program to be good is for it to interact gracefully with its users, especially when recovering from human errors in the input data. It's a real art to compose meaningful error messages or to design flexible input formats which are not error-prone."

There's another kind of utility. Not being error-prone, or at least having good error messages. "Another important aspect of program quality is the efficiency with which the computer's resources are actually being used. I am sorry to say that many people nowadays are condemning program efficiency, telling us that it is in bad taste.

"The reason for this is that we are experiencing a reaction from the time when efficiency was the only reputable criterion of goodness, and programmers in the past have tended to be so preoccupied with efficiency that they have produced needlessly complicated code.

"The result of this unnecessary complexity has been that net efficiency has gone down due to difficulties of debugging and maintenance."

I think he's going on a little tangent here. He's talking about efficiency, that efficiency is a utility. It's a source of good taste but people are condemning it. He's talking about the reason being that there was a time before when computers were so constrained, that that was a real mark of skill.

That's what people focused on. Even getting the program working in the small memory, making it run faster, use fewer instructions, that kind of stuff was the primary goal of programming, once it worked in theory.

He's saying that sometimes, you focus on efficiency so much that your program gets so complicated, that it's actually not efficient anymore. You can't understand how it works, and because you don't realize it, you don't realize that there might be an easier way or a better way to do it, in a more efficient way because it's so complicated.

It's a big topic to go into. Maybe I shouldn't. It's just his tangent. I shouldn't go into that. There are stories out there of like, "Let's do it in assembly because that's more efficient." Then it turns out that it's way less efficient because you've totally lost control of how it's working.

It's too much to write in an assembly. When you have a higher-level language, it's a relative term. A language that is higher than assembly. In a higher-level language in theory, it's less efficient.

It goes through a compiler. A compiler can't really understand everything you're trying to do. It didn't get that, "Oh, there's this optimization." It could've done this and the compiler couldn't see that.

Or maybe it's doing garbage collection for you but in the end, if you can't understand how it's working, maybe you don't even know if you understand how it's working. You think you understand it but you don't.

You don't know if it's efficient or not. "The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times. Premature optimization is the root of all evil, or at least most of it, in programming."

There's this famous quote, "One rather curious thing I've noticed about aesthetic satisfaction is that our pleasure is significantly enhanced when we accomplish something with limited tools. For example, the program of which I personally am most pleased and proud is a compiler I wrote for a primitive mini-computer, which had only 4,096 words of memory. 16 bits per word."

It makes a person feel like a real virtuoso to achieve something under such severe restriction.

People talk about this a lot. It's commonly known now that constraints help creativity. The creativity and pleasure in what you're doing, the artistry, those go together.

A similar phenomenon occurs in many other contexts. For example, people often seem to fall in love with their Volkswagens but rarely with their Lincoln Continentals, which presumably run better.

"When I learned programming, it was a popular pastime to do as much as possible with programs that fit on only a single punched card. I suppose it's this same phenomenon that makes APL enthusiasts relish their one-liners.

"When we teach programming nowadays, it is a curious fact that we rarely capture the heart of a student for computer science until they have taken a course which allows hands-on experience with a minicomputer. The use of our large-scale machines with their fancy operating systems and languages doesn't really seem to engender any love for programming, at least not at first."

There are always games and things we play, like code golfing. How short can I make this program? It seems like it's not a useful pursuit. Your program isn't getting clearer by shaving off characters here and there, like you do in code golfing, or finding some esoteric syntax that'll let you write something in half the characters.

Certainly, it's not more readable, but it is useful. It's play. It's exploration. It's finding the pleasure and the corners of the language, and relishing the artistry of this tight constraint. We see that a lot. We see these programming competitions, where it's like, "What can you do in 1k of JavaScript?" stuff like that.

Some people do some [laughs] really impressive stuff for just 1k, that's pretty cool. Then there's like the obfuscated C competition. It's like, "How bad can you make your code?" Why are these fun? Why? No one wants to write code that's unreadable, but yet it's fun to do it.

He's saying that the fun, the enjoyment is a utility. It's part of the aesthetic, it's part of the satisfaction. He continues, "It's not obvious how to apply this principle to increase programmers enjoyment of their work. Surely programmers would groan if their manager suddenly announced that the new machine will have only half as much memory as the old.

"I don't think anybody, even the most dedicated programming artists, can be expected to welcome such a prospect since nobody likes to lose facilities unnecessarily." This is really curious. It's a paradox where it's more pleasurable to solve a problem under constraints.

It certainly aids creativity, but then, often the constraints, you don't want to live under those constraints. Maybe if it's forced on you, and you have to accept it, then you can find the creativity, but you wouldn't choose it. If you had a choice, you would not do that.

It reminds me of something...I produce teaching materials, video courses, and stuff I write on my site. I often get complaints, emails complaining like, "Oh, it took me a whole hour to figure out how to do this. Your instructions weren't exactly clear, but I did finally figure it out and I just wanted to let you know, like that you cost me an hour." Sometimes they're very angry.

There are studies that [laughs] show that often people do better on tests after having to figure out the like that there were mistakes in the material. They are more annoyed if you ask them, "How did you feel about this material?" They're like, "Oh, man, there was some mistake. Like, I think they used the less-than sign instead of a greater-than sign, and it was confusing.

"So I had to go look it up and other material. Really work it out by hand, myself. Finally I figured it out. There was a mistake. I think you should fix it. It was really annoying." Of course, they get it right on the test, because they did all that work to correct the mistake themselves.

Does that mean you should insert mistakes? I don't know if there's good research showing that you should randomly insert mistakes into your textbooks. It seems to be the case that building in a little bit, or allowing the mistakes like don't fix them, because it seems like people actually...They get really frustrated by the inconsistencies or something seems wrong, and they want to find out what it is.

I don't know how to resolve that. I don't want people to be frustrated, I don't want people yelling at me about some unclear thing I had in there. I also feel like that person is never going to forget that lesson. Whereas if I gave them the right answer, they might have just copy pasted it. Like let's say it's a command to put into the terminal, they're just copy paste it, and not learn anything about it.

People don't really know. They don't really have a good sense of their own learning process. They don't realize the process they went through...I'm just complaining about this. It's a similar paradox. You would not want to work on a machine with half the memory. There's all these deadlines and you're already under pressure to get stuff right.

You have to deal with another constraint, or like half the memory that you're used to, what kinds of bugs is that going to cause. At the same time, there's stuff like chaos engineering, chaos monkey, which randomly kills processes on a Unix machine, just like boom, dead, kill it, kill dash nine, terminate. Your service just goes out.

How do all the other services react? What happened? Can they adapt? Can they deal with it? It turns out that if you have a system, no one would want this on a real system, but it actually makes your system more resilient. That it can adapt and handle these failures gracefully.

It's another constraint on your system that you wouldn't choose. If you're programming for...Let's say you're programming mobile phone apps, maybe it's better to have a really old phone, because then you're going to make sure it's fast and smooth on that phone.

When the new phones come out, it's going to be super snappy. If you have the latest phone, and you program for that, only people with the latest phone will have that same experience. Maybe, there is something to this, and there's all sorts of other ways that we put constraints on ourselves.

Some style guides say, "No more than five lines in a function or method. No more than three arguments." Sometimes, you want a fourth argument. "It would be so easy if I just had this fourth argument." You wouldn't choose it in the moment and, often, you ingrown when someone imposes it on you, but it's for your own good. It helps you.

It's a weird paradox. In recent years, the most important things we have been learning about programming seem to have originated with people who did not have access to very large computers. The moral of this story, it seems to me is that we should make use of the idea of limited resources in our own education.

We can all benefit by doing occasional toy programs when artificial restrictions are set up so that we are forced to push our abilities to the limit. We shouldn't live in the lap of luxury all the time.

Since that tends to make us lethargic, the art of tackling many problems with all our energy will sharpen our talents for the real problems, and the experience will help us to get more pleasure from our accomplishments on less-restricted equipment.

"This thing he says in the beginning. I don't know if this is true but let's take it as a fact," he states it. In recent years, the most important things we have been learning about programming seem to have originated with people who did not have access to very large computers.

He doesn't mention what he's referring to, what these most important things recently, and where the people originated, or why they had access to small computers.

This was in the '70s. It's probably lost, what he was referring to, but it's interesting to think about that. I don't understand much about soccer, but I know that there's a kind of odd phenomenon where richer countries, they have much bigger training budgets and better equipment. They have all the free time because they're paid millions of dollars a year.

Where do they recruit from? They often recruit from poorer countries. Why they say that soccer in those countries, it's all they had. A kid would have a ball and would just play all day. They had less fewer resources, and they thrived on playing soccer. Then, when given the resources of a rich country, they, now, are blossoming and amazing and unbeatable.

Whereas the opposite is not true or not the opposite. You take someone who is raised in that rich country, had the same opportunities and more, they had a soccer ball at home, but they also had a million other toys. They grow up, and they're not as good at soccer. At least not at those little technical skills like dribbling and juggling and stuff like that.

I think that relates, it's a similar phenomenon that somehow if you find some restricted, harder area, more constrained area, you can find something new that might apply in the bigger area, but you wouldn't have had to find it if you weren't restricted. I'm running out of steam here, so I'm going to keep going.

Knuth continues, "We shouldn't shy away from art for art's sake. We shouldn't feel guilty about programs that are just for fun. I, once, got a great kick out of writing a one statement ALGOL program that invoked an inner product procedure in such an unusual way that it calculated the Mth prime number instead of an inner product.

"Some years ago, the students at Stanford were excited about finding the shortest Fortran program, which prints itself out. I don't think it was a waste of time for them to work on this nor would Jeremy Bentham, whom I quoted earlier, deny the utility of such pastimes."

On the contrary, he wrote, "There's nothing, the utility of which is more incontestable to what shall the character of utility be ascribed, if not to that, which is a source of pleasure."

I think he's saying, this is a very...It seems very contrived way of writing these days. He's saying that the utility of something that is pleasurable is incontestable because what else is utility for than to be, ultimately, a source of pleasure.

Interesting. What Knuth is saying is that, "It's not a waste of time. It's not always a time to explore and play and find things that have no other utility than pleasure. Not all programming tasks are going to be fun. Consider the trapped housewife..." Sorry for this metaphor. "...Consider the trapped housewife who has to clean off the same table every day.

"There's not room for creativity or artistry in every situation, but even in such cases, there is a way to make a big improvement. It is still a pleasure to do routine jobs. If we have beautiful things to work with. For example, a person will enjoy wiping off the dining room table day after day if it is a beautifully designed table made from some fine quality hardwood."

Imagine this person whose job has no intellectual stimulation. I think this is what he means by trapped housewife, no intellectual stimulation. They're at home all day. They just have to clean the house. It's hard to imagine that.

I clean the house. [laughs] I have two kids. I clean a lot. That is, I'm wiping this thing that I just wiped. I clean this table, and now the kids eat on it. It needs cleaning again. It's frustrating. I understand what he's trying to say.

Here's the thing that I'm going to try to apply is that if you have beautiful things to clean, beautiful tools, and the table is beautiful, the table's like a tool for eating dinner, so you want to take care of it because it's beautiful. You have this innate desire to make it beautiful.

If you have an ugly table, it's not so fun. It's like, "It's not going to get much better if I clean it off." That's interesting. He's going to make this plea to toolmaker. "Please give us tools that are a pleasure to use especially for our routine assignments, instead of providing something we have to fight with.

"Please, give us tools that encourage us to write better programs, by enhancing our pleasure when we do so. It's very hard for me to convince college freshmen that programming is beautiful, when the first thing I have to tell them is how to punch slash slash JOB equals so-and-so."

I have to second this plea. We need to make programming more aesthetic. Not just the language but all the tools. It's ugly. It's often very ugly. Going to the command line I'm like, "Let's configure this system. Oh, it looks gross."

"One of the best ways to keep up the spirits of the system user is to provide routines that they can interact with. We shouldn't make systems too automatic, so that the action always goes on behind the scenes, we ought to give the programmer-user a chance to direct their creativity into useful channels.

"One thing all programmers have in common is that they enjoy working with machines, so let's keep them in the loop. Some tasks are best done by machine, while others are best done by human insight, and a properly designed system will find the right balance."

That's a deep, deep thought, that you don't want to automate everything away. You want to keep someone in the loop.

[pause]

Eric: He's going to talk about tools for making profilers, things that are more about efficiency. "It is no wonder that attempts at efficiency go awry so often, when a programmer is never given a breakdown of costs according to the lines of code they have written.

"All that we have been giving programmers is an optimizing compiler, which mysteriously does something to the programs it translates but which never explains what it does." This is what he's talking about. The human's not in the loop anymore.

"Fortunately, we are now finally seeing the appearance of systems which give the user credit for some intelligence. They automatically provide instrumentation of programs and provide an appropriate feedback about the real costs. These experimental systems have been a huge success, because they produce measurable improvements, and especially because they are fun to use."

One thing about these kinds of systems that he's talking about, they're providing instrumentation and feedback. That's something that's very important for fun is feedback. You need to have a sense that you're making some progress.

I'll give an example. My friend invited my family and me to dinner. It was a couple, and they brought a puzzle. Surprise, we didn't know. They busted it out after dinner, and we started working on it. It was 1,000 pieces, maybe 500. I don't remember how big it was, but it took a good hour or two to do.

An hour in, and you're feeling tired. You're still enjoying it. It's still fun, but I realized that if I don't get a piece every now and then and put it into the puzzle, I'm going to get bored really quick. I need some hit of serotonin, something. Give me some dopamine. Give me something to keep going, or I am going to lose interest.

You need feedback. You need to feel like you're making progress. If you're not, if you're just doing a puzzle, you get bored really fast. Bored sounds like, "Get back to work. You're just being lazy." No, I need to engage my brain in the problem.

Boredom is a sign that I'm unengaged. My brain is not working on the problem. The boredom is that feeling that my brain doesn't care anymore. You need fun and flow.

For flow, you need two things. You need fast, rich feedback, and you need to have a sense of progress. You need to know where you're going and see that you're making your way there.

Our tools need to do that. He's showing with optimization, we would actually do better if we made it more fun. We may need to give it more feedback. Fun sounds so non-technical. "It's not about fun. We have to engineer real systems."

Come on. We're humans here. You got to think about the whole system. Humans are programming this thing. You need to engage them. Needs to feel pleasurable to work on it or they're going to shut their brains off. It's just the way it is.

Fun is just another word for the hormonal flush that we get when everything's working well, when we're engaged, when we're solving problems, when we're coming up with good ideas.

Last part. Oh, my goodness. "Language designers also have an obligation to provide languages that encourage good style, since we all know that style is strongly influenced by the language in which it is expressed."

These days, I feel like this is commonsense obvious. The design of the language has to encourage good style. We've all agreed with that. You can't just rely on the programmer to do it.

There has to be some kind of aesthetic component to the language that you can tell when it's not a good style just by looking at it and that the defaults and the idioms of the language tend toward good programs.

That's handwavy. What does that mean? There's a whole science and art to that that probably has developed a lot since the '70s, when this was written.

That was Don Knuth. We're up to 1974. How many of these have I done, 10? There's still more to go. They're still giving out these awards. I don't know if I'll catch up. I'm definitely doing them faster than one a year, so I'll get there eventually.

Please subscribe if you like this. I'm going through all of the Turing Award winners. I'm doing them in order, but I've done a couple out of order before I really started. You can find those. I'll skip them when I get to them.

Thank you for listening. My name is Eric Normand. This has been my podcast. As always, rock on.