Knuth: Computer Programming as an Art (1974)
paulgraham.com
paulgraham.com
The delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of imagination. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself.
I wrote more on this subject in "Why I Love Coding" http://henrikwarne.com/2012/06/02/why-i-love-coding/
I think this could equally be said for computer programming, except it is given life. We can see theory animated.
Programmers work with abstractions, rather than with wood or clay. And their craft is as cerebral and intellectually demanding as an art or a science. But it's still a craft.
We have scientists/researchers who focus on the theoretical aspects. We have engineers who have a reasonable understanding of the theoretical aspects and tend to work in the design space. And we have craftsmen/technicians who have a reasonable understanding of design and tend to spend most of their time coding.
A sort of pastime of mine is to follow arguments on technical subjects and see if I can see these groups talking at cross purposes because they see the world from their perspective. Although if it relates to Haskell I don't bother as it's a gimme.
Where I do see a difference between software and aerospace is that, in software, there's a more noticeable feeling of hierarchy. To paraphrase: Haskellers look down on C programmers look down on Javascript programmers (like some sort of geeks' That Was The Week That Was sketch).
Maybe it was like this in aero too (I was quite young). What I do know is that I was in awe of the skills of the crafties I worked with. Unless you've watched a chap spray paint a propeller to a finer tolerance than a purpose built robot, you only have a partial understanding of the word exquisite.
Consequently, Haskell is one of the few places where any interesting progress is being made in the field of programming. The pure theoreticals continue spinning off into ever-more-rarified lands of type theory that are already all but impossible to use in practice, and the practicals are stuck shuffling around the same things over and over again in the same basic languages they've had since the late 1990s, just with a few more fancier curlicues added. (Every once in a while they'll import an idea from the academic side, but not without pretending they came up with it on their own while still sneering at the very thought that maybe if one thing was useful from over there, other things might be useful too....)
(Rust may someday also be an exception, though I'm currently unsure whether Rust's community will make progress in the general field of programming, or whether they'll make Rust-specific progress. A certain amount of Rust-specific progress is required either way before we can tell.)
We try to create this machine that does things that exist only in the virtual world. Abstract operations and abstract data are the primitives or so it seems. The problem is these constructs are limited. We cannot have an unlimited amount of data nor can we have an unlimited amount of computing speed.
Why is this supposedly purely virtual abstraction limited? Because nothing can be purely virtual. Abstract data and procedure are both in itself abstractions on top of physical objects that are limited by the laws of the physical world (aka the laws of physics). There is a deeper physical primitive that exists underneath this abstraction we call information. Every virtual bit in a computer is an abstraction on top of this physical primitive.
What is this primitive?: silicon, aka Clay (SiO2).
So in short, if computers are artistic clay sculptures, then programmers are working with clay. Thus every time you program you are doing "arts and crafts." Programmers are both artists and craftsmen, the terms are one and the same.
I think this is a confusing essay, because in everyday speech "art" is employed to mean something very different from "an art" and we get lost in semantics. The continued references to obsolete definitions confuse things further.
In practice, the phrase "an art" is usually used in the same way as "an artform", as it is not meant to be taken literally; a commentator may say "there's a real art to mastering the offside trap" in football, but he does not mean that the defender should be put in a glass case in a contemporary art gallery.
The whole art/science classification of programming appears to me to be people defending their philosophy or encampment. If you're working in formal methods, you're likely to say "it's about the science", but if you're hacking the last cycle out of a console processor in the games industry you might say "wow, that was really clever, it's really an art this isn't it?"
I'd say both of these views are daft. "Science" is usually synonymous with Physics/Chemistry/Biology, which are inescapably different from programming or Computer Science. Similarly, fine arts is not isomorphic to programming.
What we usually do is much more like a craft. Sure, it has elements of engineering and maths, and in CS research we borrow some of the scientific method some of the time, but you could probably say the same about any craft, e.g. making jewellery, pottery, etc.
All crafts can strive for both beauty and utility, and can borrow from scientific methods and engineering when appropriate, but "pure" science or "pure" art they ain't. There's no ground truth in craft, and there's a strong degree of utility, which precludes it from being science or art respectively.
I've heard this discussion dozens of times. Always the mathematicians want CS to be a science, and the hackers want it to be an art or maybe engineering, but I think the argument is counter-productive. Programming is quite unique, but if you really want a relative description, it's kinda like a craft that uses certain maths and engineering in places.
I think dropping "science" from "Computer Science" would help immeasurably. Simply renaming a university department to "Computing" might stop students and staff worrying what they are.
CS can be a craft. It's not one of the arts, not even if it's beautifully put together, because the arts are not primarily about technique - they're about capturing and distilling human experiences using allusions and associations to (re)create those experiences. Fluent technique is a useful tool that help with that, but it's not the point.
(Modern art is a bit more limited than that, but that's more or less what art meant for most of Western history.)
The experiences created by the most timeless art are focused, but also ambiguous and complicated. You can get lost in them, and although there's often a clear theme, you can't define the rest of what's happening with absolute final precision.
That's almost exactly the opposite of what good code does. Which is why "That's a clever, clean solution" is an experience that exists in the craftsman's world, and is either peripheral or completely absent from an artist's view.
>I think dropping "science" from "Computer Science" would help immeasurably.
At my university the joke was always that it should be called "Computer Studies." Only a nugget of algorithmic research is genuinely scientific, and that lives in a tiny corner of the rest of the Pure Math. There could be a lot more formal provability, but going down that route would put a lot of programmers out of work, because the level of difficulty is much higher than that needed to crank out some JavaScript.
What's left is usually neither rigorous nor beautiful.
To which I reply: Did you actually read the essay? Since you started the ad hominem argument, I feel free to continue in that vein.
What is interesting is that most "programming" is exactly "capturing and distilling human experiences using allusions and associations to (re)create those experiences". What else is coding a front-end to an application that saves time and/or labour, and/or makes possible things that were, before the program, impossible? An Art, a Craft or a Science? From your very definition, "Art" would be the answer.
And yet, you begin your criticism with "It's simply nonsense"
I'm not sure what you're implying here, but Knuth does know what art is, as he almost majored in Music. See this for some recent work: https://www.youtube.com/watch?v=e_1a6bHGQGo
What are you implying? That studying some Music makes you an artist?
Whilst I know a little about art, I'm not confident enough in my own experience to put it so strongly.
> because the arts are not primarily about technique
Agreed. I think your subsequent definition of art is a brave one! It's difficult to define, but I get where you're coming from. As you hint at in the subsequent paragraph.
> What's left is usually neither rigorous nor beautiful.
A bit harsh! But yes, there's a large body in the middle that just gets things done.
Sounds like you may be immersed in the arts world, and I've already cited these before, but you may enjoy the Grayson Perry lectures if you haven't listened to them already. I found them refreshingly straight-talking:
Programming is art for many of us. For some it's a craft. If you are original and independent thinker in our profession, have creative ideas nobody had prior to you, you are much closer to an artist. If you just reuse what somebody else created, you are closer to a craftsman. Where do you stand?
You equate art with originality, but Knuth do not, and most arts except "Contemporary Art" did not either. Just turn your eyes to Quattrocento or Chinese landscapes: these artists are not trying to invent something or be original. Listen to Bach: where is the inventions? It is just a natural flow of notes in a structuring harmonic frame. I do not imagine Bach thinking "Let's do something unheard" when writing his partitions.
My view is that most people that view programming as a craft are middle managers that somehow need to get ants working on whatever they need. However if your innate inspiration comes from somewhere else, if you "feel" the algorithms and their optimality, wake up during nights when inspiration knocks on your the door of your mind to start working on an idea you just saw with your inner eye, you won't view programming as a craft at all.
The difference being that we primarily create things valued for their utility, rather than their aesthetics. Video games being the possible exception, although even there the programmers are essentially building a vehicle for the art-stuff (story, graphics, gameplay, music) to shine through.
--Programmer Man
There was an article outlining a continuum between art and science, where engineering was somewhere in the middle. Art is the least rigorous of them, while science has the most rigor.
Being a science enthusiast, reading on quantum physics, evolutionary biology, etc., I've learned more/less how scientists think. It has a lot to do with coming up with not only good explanations, but explanations that are extremely hard to vary. Explanations that risk falling apart if you try to change any aspect of it. This together with a mountain of evidence supporting said explanation, makes for good science.
Art on the other hand, is arguably vague by definition. Art that is doesn't leave room for interpretation is often bland. Art also has a huge human component, whereas science tries to do away with it.
In my opinion, programming can easily be both an art and a science. There's no need to constrain it to either one. On one hand, you have the mathematical theory of information, describing a hard-to-vary explanation that is backed up with great math(s). On the other, you have an infinite set of tools from which you can craft whatever your imagination is capable of coming up with. Programming, having its foundations in mathematics, leverages its infinite potential, and with it the possibility of creating both works of art, and scientific facts. It is this universe of possibility that takes only the toughest of minds to venture and explore.
Perhaps a way to refine this understanding is to consider a different medium more typically believed to be artistic: film.
A director will construct the artistic vision (akin to the requirements/concept) and then work with film music composer to add music (analogous to development). Is the composer and artist practicing art? I would suggest that the word "craftsman" is better suited to the work the film composer does (assuming that they aren't also directing). That doesn't mean that a film composer cannot also be an artist in his/her own right, but in this context their input is arbitrarily limited by the artistic vision of the director... even if the director's vision allows for significant discretion by the composer.
Most development work, as you point out, has this separation of creative impulse from the implementing crafts. I do think there is "art" involved in programming, but only when the creative impulse is joined with the craft of development in a single mind.
I would argue that in those cases, programming is not an art because the arriving at the solution is very mechanical and there is literally zero room for creativity. Thus imo this answer isn't broad enough to fully define "Art"
Slathering paint onto a surface isn't always art.
Big Oh has to do with large N.
"If a program manipulates a large amount of data, it does so in a small number of ways." --- Epigram 5, Alan Perlis
"For every polynomial-time algorithm you have, there is an exponential algorithm that I would rather run." -- Alan Perlis
"Don't do things that scale" -- P. Graham
>Concept + skillful rendering = art
This statement does not fully cover the definition of art.
Change the x that the big O is about, for example by using vector instructions.
Implement a theoretically less efficient algorithm that is faster (examples: switch to a O(n^2) sort for small data set, or to a linear search for smallish arrays)
Unfortunately, that is frequently also the recipe for a big ball of mud [1]. I guess the beauty is in the eye of the beholder...
I love the way Knuth expresses himself.
"The science without the art is likely to be ineffective;
the art without the science is certain to be inaccurate."Herzog: Never. All I've ever wanted to be is a foot soldier of cinema.
When the most efficient solution to a problem isn't known we rely on art and design to fill the void. When the path to the most efficient solution of a problem is known we rely on "science" or technical procedures to deduce the best possible answer.
For many problems in programming we know the best possible solution. However, for most of the apps we build to solve problems in the name of entrepreneurship or business, no efficient solution is known. In fact, in these situations, the problem isn't even clearly defined. When we don't know the "best" solution we use intuition and creativity to come up with a solution that we only intuitively know to be somewhat efficient.
Programming isn't the only area where this occurs. All of engineering relies on art and design to solve problems where the most efficient solution isn't known.
For example, what is the shortest distance between point A and point B? The answer is a straight line. There is no design or art as part of this solution because a straight line is mathematically proven to be the most efficient possible answer. The answer, in essence, was calculated and thus no "art" or design was involved. Utilizing art in this case would be as pointless as drawing an artsy squiggly line between point a and point b.
Now, allow me to modify the problem to make it a little more complex. Instead of calculating the shortest path between two points, how do I find the most efficient way to transport a person from point A to point B?
The most efficient answer is mind boggling complex, you have to account for the personalities and definitions of "efficient" for every possible person you can transport, energy, speed, obstacles etc etc. There probably is a most efficient solution but know one knows it.
Here, where it is very hard for us to deduce the most efficient solution we rely on Art.
With "art" we can come up with multitudes of solutions to the problem on how to transport a person from point a to point b. Cars (thousands of different models), flying vehicles (thousands of different innovations as well) are two possible examples out of many forms of locomotion. The reason why there are so many models/solutions is because we can never concretely determine which "solution" was the most efficient.
This is what we mean when we use the word "Art" in the context of "The Art of Programming" or "The Art of combat." We are essentially describing a problem domain space that is so complex our pathetic human minds our reduced to a sort of aimless wandering (aka creativity) to come up with a solution that isn't even the most efficient one.
I use the word aimless because we iterate over our solutions endlessly in an endless quest to arrive at the best solution. The "quest" is essentially endless because our "path" is aimless. We will never ever create the most efficient OS or iphone app of all time because we don't even know what the hell that even means. Instead we are cursed to iterate endlessly over our programs creating version after version for all eternity.
The majority of problems in the real world rely on a bit of "art" to arrive at a solution. In fact, most of the problems where an "efficient" solution is known are just theoretical conjectures that only exist in an idealized virtual universe.
I see this as a good thing. Art is fun.
Well not only that but we actually stuffed two misnomers in there. It is not really a science, and it is not really about computers. Chip design, graphics, storage, input devices is more about computers as such.
0: https://en.wikipedia.org/wiki/Computer_science#Name_of_the_f...
I consider the term "computer science" historically motivated and anachronistic. Similar to how old people would stereotypically describe their child's job as "something with computers", we muddled subtopics of various sciences together just because they're doing "something with computers".
With computing technology and methodology now permeating nearly all areas of science, art, and engineering, maybe it's time to tear down the computer science departments and reintegrate their pieces back into the appropriate departments.
Or maybe we shouldn't, for we would lose the extremely diverse curriculum that a CS degree includes.
Actually all these things are studied in "computer science." At least, I did at my school.
I can go with engineering (but licensed engineers might object to that), art or craft perhaps.
There isn't??
I was going to list some formal percolation theory studies in as an applied version of imaginary network routing protocols or could be seen as a very weird emulation of a CA, kinda, but that's probably going way too far. Practical simulation of a specific algo is obviously cheating, but simulation of an abstract concept is maybe not cheaty. Possibly there is, or will be, an analytic topological pure math theory that could be applied to mathematically prove constants currently only discovered by experiment in perc theory. If you're ever bored and want to run some simulations, perc theory is very project euler like in that a short(ish) question quickly results in "I guess I gotta run it and see".
Another "stretch the limits" is there is no unclassified explanation of some peculiar corners of some crypto algos. Hard to know if they're truly random, determined by experimental runs against possibly classified cracking techniques, or intentional back doors, or intentional classified design techniques. But relying on military intel classification "we can't rule out experimental methods being used in secret" is kinda cheaty in the spirit of the discussion.
Seriously, just about everything we do in computer science is experimentation, at least if it involves...physical computers.
Every time we run a program, we run an experiment. At least if we have some expectation of what we want the program to do. Every time we write a test, or run a test suite, we are running an experiment.
Every time we implement some sort of abstraction, every time we vary a parameter, every time we optimize a program, we are running experiments.
At least if we're doing it right.
If you're not doing experiments, I have a hard time categorizing what you are doing as computer science.
In physics, we do experiments because we don't know the rules of the natural world. That's the only way we can learn them.
In CS/programming, if we're doing any experiments, they're done because we're too stupid to infer the right answer beforehand. Insofar as you're dealing with the theoretical part of the problem, you shouldn't need any experiments, because the results are purely mathematic and should be perfectly predictable. And if you're doing hardware experiments, it's not computer science either - that's electrical engineering or applied physics. Whatever other tests you may be doing to save some time are still the engineering type.
The point is, computer science doesn't have any area in which it could use experiments for discovery. It's fair to say then, that it's not really a science. (It's also fair to point out that the line between science and engineering is getting blurry nowadays.)
> done because we're too stupid to infer the right answer
That's the same as for physics. In theory, there is no difference between theory and practice. In practice, there is.
More specifically, for CS: what you're describing is an alternate universe where the halting problem[1] doesn't exist, or rather has been solved. In short, there is no way to predict, in the general case, whether a program will terminate or not, other than running it (= doing the experiment).
More generally, if you have a mechanism that predicts with perfect accuracy what the output of my program is, more quickly than running the program, then I will just call that new mechanism "the program", and use that instead of the original program. And then you're back to running the program to find out what it does.
UPDATE: To me, this is a (if not THE) fundamental results of theoretical computer science: a precise description of its limits. And since this is an article by Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it"[2]
CS is big-O, Chomsky hierarchy, finite automata, type theory, and computability classes. It's the study of algorithms & data structures, not their implementations. In other words, CS is a branch of math.
Theoretical computer science is a division or subset of general computer science and mathematics that focuses on more abstract or mathematical aspects of computing and includes the theory of computation.
Yeah you "explore stuff" in any field. Science, art, math, every day life, when learning a craft (welding etc). Just because you explore doesn't mean that is what the core of what computer science is.
> Every time we implement some sort of abstraction, every time we vary a parameter, every time we optimize a program, we are running experiments.
Ok, what in life then isn't science because well everything is running experiments? I am going to buy milk -- it's an experiment to see what happens. Maybe I won't find parking. I am drinking coffee in the morning, it's an experiment to see if it will still keep me awake.
By that token we've diluted the word science to not really mean anything anymore.
And you do experiments in many fields!
"An experiment is a procedure carried out to verify, refute, or establish the validity of a hypothesis. Experiments provide insight into cause-and-effect by demonstrating what outcome occurs when a particular factor is manipulated. Experiments vary greatly in goal and scale, but always rely on repeatable procedure and logical analysis of the results."
https://en.wikipedia.org/wiki/Experiment
Particularly debugging, if you aren't completely random, usually takes on the form of repeated experiments.
http://c2.com/cgi/wiki?DebuggingAndTheScientificMethod
I have done a lot of performance work in my career, and there you run experiments almost continuously. At least you do if you actually want to have an effect. Admittedly, many people try to optimize without running experiments. That tends to not be very effective.
And yes, computer systems are easily sufficiently complex that reasoning it out ahead of time without running the experiment tends to be completely futile except for the most trivial arrangements. In fact, even in some situations that seem completely trivial.
> I am going to buy milk -- it's an experiment to see what happens.
If you have a hypothesis and you're trying to find out if it is true or not, sure, that can be an experiment. Usually it probably won't be.
> I am drinking coffee in the morning, it's an experiment to see if it will still keep me awake.
That certainly can be an experiment, for example if you vary the amount of coffee to see how much of will be keep you awake. Though it seems unlikely that you will be isolating the variables sufficiently. With computers, isolating the variables is often a lot simpler.
> By that token we've diluted the word science to not really mean anything anymore.
Going with your straw-men: probably.
See you are proving my own point. Just because you do exploratory stuff and run "experiments" that doesn't make what you science. What isn't science then?
> I have done a lot of performance work in my career, and there you run experiments almost continuously
Yes me too. But I am not a scientist like Einstein.
There is a stretch in going from I am debugging some program and trying various things to saying I am a scientist.
You can sure call yourself a scientist but you have to explore why you want to do that. Is to make yourself feel better because the word "programmer" is boring or implies a lower status. What about craftsman, you are" crafting software" is that imply something undesirable, if so why? What about business problem solver?
Licensed engineers even scoff at software "engineers" even calling themselves "engineers" (even though what most computer scientist do is kind of like engineering), because they don't have a license etc.
Look, I tend to say that "Computer Science" is a bit pretentious, "playing with computers" is overall more appropriate for the level our field is at. Not sure where you got Einstein from. And, in the words of Wolfgang Pauli: "Ach, that isn't even wrong".
Bringing Einstein, who was a theorist, into a discussion about experiments is downright silly, and makes me question whether you have any idea as to what you're talking about.
Second, assuming for the sake of argument that Einstein was an experimenter, it would be just about the biggest straw-man imaginable. If experiments are only experiments if performed by one of the greatest scientists who ever lived, then science effectively doesn't exist and there are no scientists, to several significant figures.
However, the question was not who is an awesome scientist, but whether there are experiments in CS, whether empiricism is relevant especially vs. the entire field being a trivial application of mathematical theory.
And that is, for me, easy to answer: it is a highly empirical field. If you think it is a trivial application of mathematical theory, you don't know what you're talking about, neither in theory nor in practice.
And yes: there is a lot of science being done that isn't at the level of Einstein or the people at CERN or Fermilab.
In this sense, your run-of-the-mill Rails app is the IKEA table of coding.
I laughed out loud at that.
Submitters: please use the original title except when it is misleading or linkbait. This is in the HN guidelines: https://news.ycombinator.com/newsguidelines.html
What's next? Symphony No. 9 by Paul Graham? Theory of Relativity by Paul Graham? The Bible? :-)
Paul Graham's copy is plain HTML, sitting on the open web where anyone can see it and index it, and while for the rest of us its availability is dependent on PG's continued goodwill presumably he likes being able to rely on it staying there as long as he wants unless he's explicitly forced to take it down somehow.
Searching for "Computer Programming as an Art" the PDF comes up as the second link (below PG's rip off). Not that it's even relevant because it's given as a direct link.
A scanned PDF is a closer reproduction to the original presentation, and easier to save for later to read.
I trust the ACM's "goodwill" to continue hosting it more than I trust it to remain on PG's website.
Sure, if you search for its title. But if you search for text within it, you'll find it doesn't come up at all.
> I trust the ACM's "goodwill" [...]
Sure. My suggestion is that Paul Graham trusts his own goodwill more than the ACM's and that that's one reason why he's put a copy on his website.
What I find truly astonishing is that this 1974 paper is so relavent today.
Computer Programming as an Art
By Donald E. Knuth
It's that simple.
So true. Robert Rodriguez filmed El Mariachi with almost no resources. It's why the demoscene produced - and still produces - such amazing creations within its self-imposed strict limits. It's one of the reasons why the Raspberry Pi is so popular and why you see the most beautiful ARM assembly on the Gameboy.
And conversely I think it's why Web development is collapsing under the weight of too many shiny things. It's lethargic and living in the lap of luxury. I watched a video the other day of AirBNB talking about the evolution of its Web site. The 2008 version was fine: Rails, a database and dynamic page output. The 2015 version was insane: Rails, React, Node, all sorts of dependencies, some stuff I'd never heard of but that the speaker assured was good, complex mobile optimization when you could instead, you know, just write lean and mean mobile-friendly HTML.
Limit yourself instead and see what happens - the results might just be awesome.
Let me know if you've seen any program that can be described as aesthetically optimal.
Do you honestly think that writers, painters or composers doesn't know it, or it stopped them from striving?
Millions of little pieces - Data modules from GHC, especially logic, lists, big chunks from Erlang stdlib, lib9, libbio, libutf from Inferno, parts of various Lisps, tons of code from carefully written books (PoFAD, PAIP/ALMA, OnLisp, etc) well-crafted projects like nginx, or even something like this:
http://karma-engineering.com/lab/wiki/Bootstrapping8
[shit removed]
My response was not meant to be in opposition to yours, it's just a remark. There was no need to say that. Don't start shit. Your comment needs to be flagged.
Ahh yes, the logical arrangement.
Programming Law #1: Thou shalt tab to indent.
Programming Law #2: Nested loops shall indent deeper to the right.
1. Perspective - 2-point, 3-point...
2. Lower on canvas is closer, higher is further away
3. Atmosphere - clearer is closer, blur is further
3b. Color intensity - higher saturation is closer
4. Chiaroscuro - the next alternation is further (combination of #2 and #5)
5. Overlap - this behind that
6. Scale - bigger is closer
Or, you know, go to art school.