Skip to content

Comment on Knuth: Computer Programming as an Art (1974)

Comments

Programming is much more of a craft than it is either an art or a science. Good craftsmanship combines beauty with utility, as does good coding.

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.

The way I tend to picture roles in software is in analogy to my old job in aerospace.

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.

The reason I find Haskell interesting is precisely that it's the only place I know where the theoretically-minded and the practically-minded get together and interpollinate. Everywhere else the one group pretty much just sneers at the other. If it doesn't always go 100% smoothly in Haskell-land, well, it's not as if we collectively have a lot of practice in getting along across that boundary.

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.)

Very insightful comment, thanks. I've never thought of things that way before. I guess the practice/theory intersection explains what I find so appealing about Haskell.

In CS you build abstractions on top of binary data and binary data operations. Who says I can't build abstractions on top of wood or clay? What is the true nature of an "abstraction"? What is a computer?

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 agree, craft is much more appropriate.

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.

I agree, but I'll go further than you - I don't think this essay is confusing at all. It's simply nonsense - the kind of thing someone clever writes when they're discussing a subject completely outside their area of competence.

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.

"more or less what art meant"

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 agree, but I'll go further than you - I don't think this essay is confusing at all. It's simply nonsense - the kind of thing someone clever writes when they're discussing a subject completely outside their area of competence.

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

I'm not sure what you're implying here, but Knuth does know what art is, as he almost majored in Music.

What are you implying? That studying some Music makes you an artist?

I agree, but I'll go further than you - I don't think this essay is confusing at all. It's simply nonsense - the kind of thing someone clever writes when they're discussing a subject completely outside their area of competence.

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:

http://www.bbc.co.uk/programmes/b00729d9/episodes/downloads

Things named "X Studies" are almost always empty bullshit.

Imperial College, London has the Department of Computing (in the Faculty of Engineering) for this very reason.

http://www.imperial.ac.uk/computing

I think Computer Science is the branch of maths that studies computing. Things like Computability, Complexity Theory and Information Theory are clearly branches of Maths, and Math is a science. Now, most CS courses are not about this: they are engineering courses at heart, that only use CS in the way a Civil Engineering course may us Physics.

Michelangelo was working with chisel, colors, palette - was he a craftsman? How about guys that were replicating his work? They would have been closer to the 'craftmanship' side.

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?

if you are original and independent thinker

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.

They might not try to invent something original, but they end up with something original and touching people deep in their psyche. Compare that to a perfectly fluent user interface you "just love". Is that a craft? Or is there something more in it? Can you really quantify and automate the process of coming up with it?

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.

I think it's more of an art in the classical sense (which is like a craft), in that we are artisans rather than artists.

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.

I am learning technology so that I can express my ideas and share them with the rest of the world, and have fun with likeminded people. I also do photography at the pro level, movies, compose music in a world-class home music studio etc. I assume if you want to be great at art, you have to be great at techn(ology/ique). In my case it means I need to write superb pixel shaders, create VSTis producing sound nobody else has produced before and still awesome, stabilizing hyperlapses with my own computer vision algorithm, making robots dance and so on. For that I need to study whatever I find at MIT/Stanford/Harvard/etc even if it is very very difficult. So is this a craft?

Craftsman by day, artist by night.

--Programmer Man

If I recall correctly this was Brooks stance - can't remember if it was the mythical man month or one of the related essays. But they're approaching it from different angles: Brooks manifesto was very much in the commercial setting. Knuth perhaps inhabits that more platonic problem domain. For me it's quite a philosophical pursuit and for those programming in an applied scientific context maybe it's more em scientific.

you're absolutely right, i've seen beautiful, useful interfaces impossible to maintain due to lack of backend skill, i've seen great core functionality let down by bare-boned interfaces that don't let the user easily do the multiple parts of a particular task without too much effort involved in manually doing each part of it.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.