www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - OT; Donald Knuth on beauty, efficiency, and the programmer as artist

reply "Laeeth Isharc" <laeeth nospamlaeeth.com> writes:
An old essay that may yet be relevant today at a time when 
intellectual fashion has continued in the direction he was moved 
to address in his speech.

"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 really enjoy wiping off the dining room 
table, day after day, if it is a beautifully designed table made 
from some fine quality hardwood."

"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. The 
present surge of interest in structured programming has revealed 
that none of our existing languages is really ideal for dealing 
with program and data structure"

http://www.paulgraham.com/knuth.html

CACM, December 1974

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 [2]:
"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 
toward transforming the art of programming into a science" [26]. 
Meanwhile we have actually succeeded in making our discipline a 
science, and in a remarkably simple way: merely by deciding to 
call it "computer science."

Implicit in these remarks is the notion that there is something 
undesirable about an area of human activity 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; and 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."

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 doing.
...
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. For example, the preface to a 
textbook on mineralogy, written in 1784, said the following [17]: 
"Previous to the year 1780, mineralogy, though tolerably 
understood by many as an Art, could scarce be deemed a Science."

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 [32]: "The work of science is to substitute facts for 
appearances, and demonstrations for impressions."

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.
...
 From this standpoint it is certainly desirable to make computer 
programming a science, and we have indeed come a long way in the 
15 years since the publication ot the remarks I quoted at the 
beginning of this talk. Fifteen 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. It 
is only in recent years that we have been learning about the 
processes of abstraction by which programs are written and 
understood; and this new knowledge about programming is currently 
producing great payoffs in practice, even though few programs are 
actually proved correct with complete rigor, since we are 
beginning to understand the principles of program structure.
...
A scientific approach is generally characterized by the words 
logical, systematic, impersonal, calm, rational, while an 
artistic approach is characterized by the words aesthetic, 
creative, humanitarian, anxious, irrational. It seems to me that 
both of these apparently contradictory approaches have great 
value with respect to computer programming.
...
When I speak about computer programming as an art, I am thinking 
primarily of it as an art form, in an aesthetic sense. The chief 
goal of my work as educator and author is to help people learn 
how to write beautiful programs. It is for this reason I was 
especially pleased to learn recently [32] that my books actually 
appear in the Fine Arts Library at Cornell University. (However, 
the three volumes apparently sit there neatly on the shelf, 
without being used, so I'm afraid the librarians may have made a 
mistake by interpreting my title literally.)

My feeling is that when we prepare a program, it can be like 
composing poetry or music; as Andrei Ershov has said [9], 
programming can give us both intellectual and emotional 
satisfaction, because it is a real achievement to master 
complexity and to establish a system of consistent rules.

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 Poley's SOAP II assembly program in 1958; you probably think 
I'm crazy, and styles have certainly changed greatly since then, 
but at the time it meant a great deal to me to see how elegant a 
system program could be, especially by comparison with the 
heavy-handed coding found in other listings I had been studying 
at the same 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!
..
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 now 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.

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.

We shouldn't be penny wise and pound foolish, nor should we 
always think of efficiency in terms of so many percent gained or 
lost in total running time or space. When we buy a car, many of 
us are almost oblivious to a difference of $50 or $100 in its 
price, while we might make a special trip to a particular store 
in order to buy a 50 cent item for only 25 cents. My point is 
that there is a time and place for efficiency; I have discussed 
its proper role in my paper on structured programming, which 
appears in the current issue of Computing Surveys [21].
...
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 once wrote for a primitive minicomputer which had only 
4096 words of memory, 16 bits per word. It makes a person feel 
like a real virtuoso to achieve something under such severe 
restrictions.
...
When we teach programming nowadays, it is a curious fact that we 
rarely capture the heart of a student for computer science until 
he has 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.
...
How did they develop their skill? The best film makers through 
the years usually seem to have learned their art in comparatively 
primitive circumstances, often in other countries with a limited 
movie industry. And 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.
...
In a similar vein, 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 innerproduct procedure in such an unusual 
way that it calculated the mth prime number, instead of an 
innerproduct [19]. Some years ago the students at Stanford were 
excited about finding the shortest FORTRAN program which prints 
itself out, in the sense that the program's output is identical 
to its own source text.
...
Another characteristic of modern art is its emphasis on 
creativity. It seems that many artists these days couldn't care 
less about creating beautiful things; only the novelty of an idea 
is important. I'm not recommending that computer programming 
should be like modern art in this sense, but it does lead me to 
an observation that I think is important. Sometimes we are 
assigned to a programming task which is almost hopelessly dull, 
giving us no outlet whatsoever for any creativity; and at such 
times a person might well come to me and say, "So programming is 
beautiful? It's all very well for you to declaim that I should 
take pleasure in creating elegant and charming programs, but how 
am I supposed to make this mess into a work of art?"

Well, it's true, not all programming tasks are going to be fun. 
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 
really enjoy wiping off the dining room table, day after day, if 
it is a beautifully designed table made from some fine quality 
hardwood.
...
Therefore I want to address my closing remarks to the system 
programmers and the machine designers who produce the systems 
that the rest of us must work with. 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." Even job 
control languages can be designed so that they are a pleasure to 
use, instead of being strictly functional.
...
  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. (I have been trying to avoid misdirected 
automation for many years, cf. [18].)
...
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. The 
present surge of interest in structured programming has revealed 
that none of our existing languages is really ideal for dealing 
with program and data structure, nor is it clear what an ideal 
language should be. Therefore I look forward to many careful 
experiments in language design during the next few years.
...
We have seen that computer programming is an art, because it 
applies accumulated knowledge to the world, because it requires 
skill and ingenuity, and especially because it produces objects 
of beauty. A programmer who subconsciously views himself as an 
artist will enjoy what he does and will do it better. Therefore 
we can be glad that people who lecture at computer conferences 
speak about the state of the Art.
====
https://www.simple-talk.com/opinion/opinion-pieces/don-knuth-and-the-art-of-computer-programming-the-interview/

I think of a programming language as a tool to convert a 
programmer's mental images into precise operations that a machine 
can perform. The main idea is to match the user's intuition as 
well as possible. There are many kinds of users, and many kinds 
of application areas, so we need many kinds of languages.

...
I realise this is an enormous question, but what is the link 
between the design of a language and the design of software 
written with that language?
DK:
The software writers who have particular ways of thinking about 
algorithms need a language that matches their thoughts so that 
they can efficiently transform those thoughts into working code.

Different thought processes result in different structures.
Mar 26 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
Hmm... science exists only as long as we don't understand 
something, then it disappears and only knowledge remains. Looks 
like he talks about engineering, but calls it science.
Mar 27 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Friday, 27 March 2015 at 11:33:39 UTC, Kagamin wrote:

 Hmm... science exists only as long as we don't understand 
 something, then it disappears and only knowledge remains. Looks 
 like he talks about engineering, but calls it science.


One dismisses Knuth discussing the topic for which he is 
rightfully exceptionally well known at one's peril.  He may be 
wrong, but one should agonize before being sure this is the case 
and read widely and carefully about the topic first.  Often in 
our society people resolve cognitive dissonance by dismissing the 
awkward perspective that causes such discomfort, when one would 
reach a fuller perspective by putting up with the discomfort for 
a while before attempting to reach intellectual closure.

I don't believe he is making the confusion you suggest.
Mar 27 2015
parent reply "Messenger" <no u.blarp> writes:
On Saturday, 28 March 2015 at 01:09:44 UTC, Laeeth Isharc wrote:

 On Friday, 27 March 2015 at 11:33:39 UTC, Kagamin wrote:

 Hmm... science exists only as long as we don't understand 
 something, then it disappears and only knowledge remains. 
 Looks like he talks about engineering, but calls it science.


 One dismisses Knuth discussing the topic for which he is 
 rightfully exceptionally well known at one's peril.  He may be 
 wrong, but one should agonize before being sure this is the 
 case and read widely and carefully about the topic first.  
 Often in our society people resolve cognitive dissonance by 
 dismissing the awkward perspective that causes such discomfort, 
 when one would reach a fuller perspective by putting up with 
 the discomfort for a while before attempting to reach 
 intellectual closure.

 I don't believe he is making the confusion you suggest.


Without touching on what Kagamin said, one must also take care 
not to fall to argumentum ab auctoritate.
Mar 28 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Saturday, 28 March 2015 at 09:04:51 UTC, Messenger wrote:

 On Saturday, 28 March 2015 at 01:09:44 UTC, Laeeth Isharc wrote:

 On Friday, 27 March 2015 at 11:33:39 UTC, Kagamin wrote:

 Hmm... science exists only as long as we don't understand 
 something, then it disappears and only knowledge remains. 
 Looks like he talks about engineering, but calls it science.


 One dismisses Knuth discussing the topic for which he is 
 rightfully exceptionally well known at one's peril.  He may be 
 wrong, but one should agonize before being sure this is the 
 case and read widely and carefully about the topic first.  
 Often in our society people resolve cognitive dissonance by 
 dismissing the awkward perspective that causes such 
 discomfort, when one would reach a fuller perspective by 
 putting up with the discomfort for a while before attempting 
 to reach intellectual closure.

 I don't believe he is making the confusion you suggest.


 Without touching on what Kagamin said, one must also take care 
 not to fall to argumentum ab auctoritate.


Argument from authority was not a fallacy in the time this began 
to be deployed.  After the European Dark Ages, there simply was 
not anyone alive of the ability, learning and discernment of the 
best minds of the past whose works had survived, and during the 
period of catching up (remember that as late as at the time 
Gibbon wrote classical achievements in urban infrastructure were 
way ahead of what we had in London - no sewers!)

This being said, I did not make anything tending towards an 
argument from authority.  I did suggest a man such as Knuth 
probably understood well the difference between engineering and 
science, and that in these sorts of cases where one is offended 
by reading something because it causes cognitive dissonance, one 
may benefit from suspending judgement temporarily and reading 
more by other authors resonant with the offending piece to try to 
make sense of the discomfort and either reject it on the basis of 
a now deeper understanding, or integrate some or part of it.  
Irritation triggers the growth of pearls, if one lets it.

I appreciate that many of us have better things to do.  But I had 
been thinking about why I find D appealing, and how I would get 
this across to future partners, and had also been thinking about 
various forum comments equating measurement with science, and so 
I found this Knuth piece highly thought-provoking.

Because it goes against the grain of the prevailing tendency, I 
shouldn't expect many to agree.  But there is nothing wrong with 
appealing to minority opinion, provided one does not become a 
crank.  In a sense that is in any case part of how I make a 
living.
Mar 29 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 29 March 2015 at 18:05:28 UTC, Laeeth Isharc wrote:

 I appreciate that many of us have better things to do.  But I 
 had been thinking about why I find D appealing, and how I would 
 get this across to future partners, and had also been thinking 
 about various forum comments equating measurement with science, 
 and so I found this Knuth piece highly thought-provoking.

 Because it goes against the grain of the prevailing tendency, I 
 shouldn't expect many to agree.  But there is nothing wrong 
 with appealing to minority opinion, provided one does not 
 become a crank.  In a sense that is in any case part of how I 
 make a living.


I completely agree with you about the aesthetic appeal of writing 
and reading D, it is one of the major draws of the language to 
me.  I've recently been dealing with some C code and it feels 
like going back to punch cards by comparison.  It is not a minor 
issue and Walter has often talked about optimizing for it.

The white-space formatting requirements of Python were one of the 
main reasons I rejected it early on.  Call it a superficial, 
knee-jerk reaction if you like, but I can't be bothered with a 
language that won't even let me insert temporary debugging code 
without formatting it just right.
Mar 29 2015
parent "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Sunday, 29 March 2015 at 18:51:19 UTC, Joakim wrote:

 On Sunday, 29 March 2015 at 18:05:28 UTC, Laeeth Isharc wrote:

 I appreciate that many of us have better things to do.  But I 
 had been thinking about why I find D appealing, and how I 
 would get this across to future partners, and had also been 
 thinking about various forum comments equating measurement 
 with science, and so I found this Knuth piece highly 
 thought-provoking.

 Because it goes against the grain of the prevailing tendency, 
 I shouldn't expect many to agree.  But there is nothing wrong 
 with appealing to minority opinion, provided one does not 
 become a crank.  In a sense that is in any case part of how I 
 make a living.


 I completely agree with you about the aesthetic appeal of 
 writing and reading D, it is one of the major draws of the 
 language to me.  I've recently been dealing with some C code 
 and it feels like going back to punch cards by comparison.  It 
 is not a minor issue and Walter has often talked about 
 optimizing for it.

 The white-space formatting requirements of Python were one of 
 the main reasons I rejected it early on.  Call it a 
 superficial, knee-jerk reaction if you like, but I can't be 
 bothered with a language that won't even let me insert 
 temporary debugging code without formatting it just right.


Beauty will save the world.

But it's not mere indulgence because an accurate image of reality 
is beautiful, and programming is a human activity and emotional 
and psychological considerations cannot be wished away.

I can put up with the white-space stuff, but the lack of 
compile-time checking disturbs me and it seems like one needs the 
scarce resource of discipline more to write good code there.  (I 
do not claim to be an expert on Python).
Mar 29 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 27 March 2015 at 06:31:40 UTC, Laeeth Isharc wrote:

 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 doing.
 ...
 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. For example, the preface 
 to a textbook on mineralogy, written in 1784, said the 
 following [17]: "Previous to the year 1780, mineralogy, though 
 tolerably understood by many as an Art, could scarce be deemed 
 a Science."

 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 [32]: "The work of science is to 
 substitute facts for appearances, and demonstrations for 
 impressions."

 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.
 ...
 From this standpoint it is certainly desirable to make computer 
 programming a science, and we have indeed come a long way in 
 the 15 years since the publication ot the remarks I quoted at 
 the beginning of this talk. Fifteen 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. It is only in recent years that we have been 
 learning about the processes of abstraction by which programs 
 are written and understood; and this new knowledge about 
 programming is currently producing great payoffs in practice, 
 even though few programs are actually proved correct with 
 complete rigor, since we are beginning to understand the 
 principles of program structure.
 ...
 A scientific approach is generally characterized by the words 
 logical, systematic, impersonal, calm, rational, while an 
 artistic approach is characterized by the words aesthetic, 
 creative, humanitarian, anxious, irrational. It seems to me 
 that both of these apparently contradictory approaches have 
 great value with respect to computer programming.
 ...
 When I speak about computer programming as an art, I am 
 thinking primarily of it as an art form, in an aesthetic sense. 
 The chief goal of my work as educator and author is to help 
 people learn how to write beautiful programs. It is for this 
 reason I was especially pleased to learn recently [32] that my 
 books actually appear in the Fine Arts Library at Cornell 
 University. (However, the three volumes apparently sit there 
 neatly on the shelf, without being used, so I'm afraid the 
 librarians may have made a mistake by interpreting my title 
 literally.)

 My feeling is that when we prepare a program, it can be like 
 composing poetry or music; as Andrei Ershov has said [9], 
 programming can give us both intellectual and emotional 
 satisfaction, because it is a real achievement to master 
 complexity and to establish a system of consistent rules.

 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 Poley's SOAP II assembly program in 1958; you probably 
 think I'm crazy, and styles have certainly changed greatly 
 since then, but at the time it meant a great deal to me to see 
 how elegant a system program could be, especially by comparison 
 with the heavy-handed coding found in other listings I had been 
 studying at the same 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!
 ..
 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 now 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.

 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.

 We shouldn't be penny wise and pound foolish, nor should we 
 always think of efficiency in terms of so many percent gained 
 or lost in total running time or space. When we buy a car, many 
 of us are almost oblivious to a difference of $50 or $100 in 
 its price, while we might make a special trip to a particular 
 store in order to buy a 50 cent item for only 25 cents. My 
 point is that there is a time and place for efficiency; I have 
 discussed its proper role in my paper on structured 
 programming, which appears in the current issue of Computing 
 Surveys [21].
 ...
 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 once wrote for a primitive minicomputer which had 
 only 4096 words of memory, 16 bits per word. It makes a person 
 feel like a real virtuoso to achieve something under such 
 severe restrictions.
 ...
 When we teach programming nowadays, it is a curious fact that 
 we rarely capture the heart of a student for computer science 
 until he has 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.
 ...
 How did they develop their skill? The best film makers through 
 the years usually seem to have learned their art in 
 comparatively primitive circumstances, often in other countries 
 with a limited movie industry. And 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.
 ...
 In a similar vein, 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 innerproduct procedure in such an 
 unusual way that it calculated the mth prime number, instead of 
 an innerproduct [19]. Some years ago the students at Stanford 
 were excited about finding the shortest FORTRAN program which 
 prints itself out, in the sense that the program's output is 
 identical to its own source text.
 ...
 Another characteristic of modern art is its emphasis on 
 creativity. It seems that many artists these days couldn't care 
 less about creating beautiful things; only the novelty of an 
 idea is important. I'm not recommending that computer 
 programming should be like modern art in this sense, but it 
 does lead me to an observation that I think is important. 
 Sometimes we are assigned to a programming task which is almost 
 hopelessly dull, giving us no outlet whatsoever for any 
 creativity; and at such times a person might well come to me 
 and say, "So programming is beautiful? It's all very well for 
 you to declaim that I should take pleasure in creating elegant 
 and charming programs, but how am I supposed to make this mess 
 into a work of art?"

 Well, it's true, not all programming tasks are going to be fun. 
 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 really enjoy wiping off the dining room table, day after 
 day, if it is a beautifully designed table made from some fine 
 quality hardwood.
 ...
 Therefore I want to address my closing remarks to the system 
 programmers and the machine designers who produce the systems 
 that the rest of us must work with. 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." Even 
 job control languages can be designed so that they are a 
 pleasure to use, instead of being strictly functional.
 ...
  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. (I have been trying to avoid misdirected 
 automation for many years, cf. [18].)
 ...
 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. 
 The present surge of interest in structured programming has 
 revealed that none of our existing languages is really ideal 
 for dealing with program and data structure, nor is it clear 
 what an ideal language should be. Therefore I look forward to 
 many careful experiments in language design during the next few 
 years.
 ...
 We have seen that computer programming is an art, because it 
 applies accumulated knowledge to the world, because it requires 
 skill and ingenuity, and especially because it produces objects 
 of beauty. A programmer who subconsciously views himself as an 
 artist will enjoy what he does and will do it better. Therefore 
 we can be glad that people who lecture at computer conferences 
 speak about the state of the Art.


The whole art/science vein of these Knuth quotes seems like a lot 
of BS, trying to situate computer programming in the 
long-standing and overblown science/humanities "divide."

He characterizes the artistic approach as "aesthetic, creative, 
humanitarian, anxious, irrational."  But of course, there are 
aesthetic elements to any human endeavor: the scientific camp 
simply favors different aesthetics.  Anything beyond the most 
rudimentary science requires a great deal of imagination and 
creativity: it just requires learning a great deal of technical 
concepts first that may be harder to manipulate mentally.

Of course art is "humanitarian," as it's subjective and aimed at 
a human audience.  Hard to argue the science that brought us 
modern civilization isn't a hundred times more humanitarian, far 
beyond the superficial sheen of "humanitarian" art he's talking 
about.  "Anxious" and "irrational" are human emotions often 
possessed by artists, not qualities applied to art, fitting given 
they cannot produce anything of the great value of science.

He is really arguing against the likely prevailing view of the 
time of programming as a dry, functional process and pointing out 
and pushing for the aesthetic qualities in programming, which is 
all fine.  But he then gets caught up in the false dichotomy and 
claptrap of the science/humanities debate, a lot of mumbo jumbo 
that is not worth getting caught up in.

He should have stuck to calling for more aesthetically pleasing 
programming languages and tools- the best contribution he could 
have made is to more precisely define what he thinks that 
aesthetic should look like- instead of needlessly laying out 
worthless and overly simplistic platonic definitions like the 
mindsets of Art and Science.  At least his piece gave us that 
"premature optimization" line, which is worth far more than 
everything around it.

There is a great desire by programmers and many other professions 
to see themselves as "artists."  Well, there is art in 
everything, but they're not, and they should be grateful they 
aren't, or they wouldn't be paid anywhere near so well. ;)
Mar 29 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
 The whole art/science vein of these Knuth quotes seems like a 
 lot of BS, trying to situate computer programming in the 
 long-standing and overblown science/humanities "divide."


I should like to see an argument rather than mere assertion.  
Steve Jobs is not an authority on this subject, but I found his 
conception of placing Apple at the juncture of science and the 
humanities rather intriguing.


 He characterizes the artistic approach as "aesthetic, creative, 
 humanitarian, anxious, irrational."


He was making a statement about how it was characterized in his 
time, in order to set the context for his further remarks.  He 
didn't express a view one way or another about whether this was a 
good characterization.


 But of course, there are aesthetic elements to any human 
 endeavor: the scientific camp simply favors different 
 aesthetics.Anything beyond the most rudimentary science 
 requires a great deal of imagination and creativity: it just 
 requires learning a great deal of technical concepts first that 
 may be harder to manipulate mentally.


Yes - so we agree about the most important part, because this has 
implications for how one thinks about language design, programmer 
productivity, quality, questions of measurement, and the like.


 Of course art is "humanitarian," as it's subjective and aimed 
 at a human audience.  Hard to argue the science that brought us 
 modern civilization isn't a hundred times more humanitarian, 
 far beyond the superficial sheen of "humanitarian" art he's 
 talking about.  "Anxious" and "irrational" are human emotions 
 often possessed by artists, not qualities applied to art, 
 fitting given they cannot produce anything of the great value 
 of science.


Interesting perspective; I will leave it at that.


 He is really arguing against the likely prevailing view of the 
 time of programming as a dry, functional process and pointing 
 out and pushing for the aesthetic qualities in programming, 
 which is all fine.  But he then gets caught up in the false 
 dichotomy and claptrap of the science/humanities debate, a lot 
 of mumbo jumbo that is not worth getting caught up in.

 He should have stuck to calling for more aesthetically pleasing 
 programming languages and tools- the best contribution he could 
 have made is to more precisely define what he thinks that 
 aesthetic should look like- instead of needlessly laying out 
 worthless and overly simplistic platonic definitions like the 
 mindsets of Art and Science.  At least his piece gave us that 
 "premature optimization" line, which is worth far more than 
 everything around it.


That's rather the point - one cannot 'precisely define' what 
aesthetic excellence looks like because it uses at a basic 
cognitive level a different kind of mental process to that 
deployed in Cartesian analysis.  Analysis meaning breaking things 
down into their constituent parts, and thinking in terms of 
gestalts being the antithesis.  (That's one of the fascinating 
things about programming: non-programmers perceive it as mostly 
about analysis, but that is not the case).

http://www.ttbook.org/book/transcript/transcript-iain-mcgilchrist-uncut
https://www.youtube.com/watch?v=MDO0yXgpD2w


 There is a great desire by programmers and many other 
 professions to see themselves as "artists."  Well, there is art 
 in everything, but they're not, and they should be grateful 
 they aren't, or they wouldn't be paid anywhere near so well. ;)


There is more art in C and D than Java and C++.  I don't think 
that Knuth was playing a relative status game, but trying to 
bring peoples' attention to a facet of reality that he believed 
to be neglected yet important.  I believe it remains neglected 
and that the aesthetic element matters for good design, but we 
blind ourselves to this if we pretend the field is drier than its 
intrinsic nature truly is.
Mar 29 2015
parent "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 29 March 2015 at 18:41:36 UTC, Laeeth Isharc wrote:

 The whole art/science vein of these Knuth quotes seems like a 
 lot of BS, trying to situate computer programming in the 
 long-standing and overblown science/humanities "divide."


 I should like to see an argument rather than mere assertion.


There is no point in diving into that worthless debate.  Whatever 
arguments I wanted to make are below.


 Steve Jobs is not an authority on this subject, but I found his 
 conception of placing Apple at the juncture of science and the 
 humanities rather intriguing.


Perhaps Jobs early study of fonts and typefaces eventually helped 
with the development of the striking visual design of the iPhone, 
iPad, OS X, iOS, and the various Apple products that are lusted 
after by conspicuous consumers everywhere today, but other than 
that, I always found that conception similarly fanciful.  Other 
than visual design, where is the great influence of the 
humanities on Apple?  Do they build great authoring tools, that 
the majority of writers use to write their books and ebooks?  No. 
  They acquired some nice editing tools like Final Cut Pro that 
had some uptake, but that's about it.


 He characterizes the artistic approach as "aesthetic, 
 creative, humanitarian, anxious, irrational."


 He was making a statement about how it was characterized in his 
 time, in order to set the context for his further remarks.  He 
 didn't express a view one way or another about whether this was 
 a good characterization.


I pointed out that he was wading into an existing debate that was 
overly simplistic and that he shouldn't simply have accepted 
their terms.


 Of course art is "humanitarian," as it's subjective and aimed 
 at a human audience.  Hard to argue the science that brought 
 us modern civilization isn't a hundred times more 
 humanitarian, far beyond the superficial sheen of 
 "humanitarian" art he's talking about.  "Anxious" and 
 "irrational" are human emotions often possessed by artists, 
 not qualities applied to art, fitting given they cannot 
 produce anything of the great value of science.


 Interesting perspective; I will leave it at that.


Feel free to disagree. :) I find terms like "humanitarian" or 
"spiritual" to be so vague and loaded as to be meaningless.


 He should have stuck to calling for more aesthetically 
 pleasing programming languages and tools- the best 
 contribution he could have made is to more precisely define 
 what he thinks that aesthetic should look like- instead of 
 needlessly laying out worthless and overly simplistic platonic 
 definitions like the mindsets of Art and Science.  At least 
 his piece gave us that "premature optimization" line, which is 
 worth far more than everything around it.


 That's rather the point - one cannot 'precisely define' what 
 aesthetic excellence looks like because it uses at a basic 
 cognitive level a different kind of mental process to that 
 deployed in Cartesian analysis.


I didn't ask for him to define "aesthetic excellence" but "what 
he thinks that aesthetic should look like."  It might be 
difficult to analyze or communicate, but if one cannot even 
describe what the output might look like, it is basically 
worthless to even talk about, as we can only happen upon it by 
chance. ;)


 Analysis meaning breaking things down into their constituent 
 parts, and thinking in terms of gestalts being the antithesis.  
 (That's one of the fascinating things about programming: 
 non-programmers perceive it as mostly about analysis, but that 
 is not the case).


It _is_ mostly about analysis, but that doesn't mean it's all 
it's about.  Specifically, programming languages are a user 
interface, and so must be designed differently than some math 
library.


 http://www.ttbook.org/book/transcript/transcript-iain-mcgilchrist-uncut
 https://www.youtube.com/watch?v=MDO0yXgpD2w


I'll take a look at the transcript, the video seems too long.


 There is a great desire by programmers and many other 
 professions to see themselves as "artists."  Well, there is 
 art in everything, but they're not, and they should be 
 grateful they aren't, or they wouldn't be paid anywhere near 
 so well. ;)


 There is more art in C and D than Java and C++.  I don't think 
 that Knuth was playing a relative status game, but trying to 
 bring peoples' attention to a facet of reality that he believed 
 to be neglected yet important.  I believe it remains neglected 
 and that the aesthetic element matters for good design, but we 
 blind ourselves to this if we pretend the field is drier than 
 its intrinsic nature truly is.


I think he was rightly pointing out the aesthetic element, but 
was likely playing a "relative status game" when he unnecessarily 
expanded it out to digressions on how programming is an art, not 
just a science.  Sure, all engineering is an "art" to some 
extent, but in a much more limited way than what artists deal 
with and most technical types honestly probably don't care much 
about the pure aesthetic appeal of what they're building, which 
is why he had to raise the objection in the first place.

I think the field has long since advanced past that with the use 
of languages from ruby to Haskell these days, though they're 
still slotted into certain small niches compared to the more 
"functional" languages like java or C++.  I don't see "slash 
slash JoB" in any language these days, so we've certainly 
advanced past that.
Mar 29 2015