Knuth is wrong and should stick to what he is good at.

You are right to raise doubts. He should have called his book:

‘The Craft of Computer Programming’

Using the word ‘Art’ with a capital ‘A’ is incredibly pretentious and philosophically unjustifiable. He could have gotten away with calling it:

‘The aesthetics of Computer Programming’

Using the word ‘aesthetics’ with a small ‘a’, but I feel that ‘Craft’ is better. After all there are many masterpieces in furniture. Code beauty is also a reasonable phrase to use – one that may be less obscure than ‘aesthetics’ (which actually imply a set of informal rules that may help you achieve beauty and harmony).

Having done a degree in Fine Art which involved writing philosophical essays on all of these topics for the Art History component of the course after which I became a programmer, working on UX and a functional end-user programming language, I can confidently assert that writing software has nothing to do with Art, but that the lessons of aesthetics (harmony, symmetry, coherence, concision, appropriate use of emphasis and the suppression of unimportant details) apply very well to code.

And thanks, I would like to take a look at Beautiful Code at some point if that’s ok! I’d need to clear some space from my desk first though. I have a more-ridiculous-than-usual pile of backed up reading material to get through first.

http://en.wikipedia.org/wiki/Software_Craftsmanship

“Craft” is used in the mediaeval sense; a term that includes portrait painting, bridge building, instrument making, baking and so on. You can choose your metaphor (art, science, engineering, architecture, recipes) to suit your needs.

The Software Craftsmanship movement also espouses the three stages of competence used by the mediaeval guilds:

Apprentice (can get useful things done; has limits)
Journeyman (has the core skills needed on any normal project)
Master (understands the limits of his craft; ready to push the boundaries)

I’m not sure how practical it is to apply these static categories in such a dynamic field, but it has to be better than scribbling “_x_ years of experience in _y_” on your CV.

By the way, if you haven’t got it yet, I have a copy of Beautiful Code you can borrow. The main thing I got from the book is that beauty is in the eye of the beholder. Code is beautiful when it solves a problem and makes you say, “Wow! I didn’t know that was possible.” In other words, it is contingent on the problems you have and repertoire of solutions you’ve tried. The first time I saw a binary tree I thought it was beautiful.

I suspect the API problem is not unique to software development. Large scale (physical) engineering has similar issues. In fact they have a worse one – previously working components can deteriorate and fail over time. Apart from cosmic rays and hardware ageing around it, software is largely immune from this.

Perhaps it is the close coupling of sofware components that is our downfall at the moment. Maybe we need more redundancy, or more flexible abstractions?

I hadn’t read Andrei Ershov’s lecture before – it’s a good recommendation. He has an interesting point about programming resisting assembly line construction. This seems to be true of any creative process I’ve ever witnessed.

I’m not sure how well it bodes for the future though. I think large scale collaborations have value in there own right, and software engineering is tricky to scale up.

However, there is one thing that totally spoils, at least for me, the joy of programming: The API problem — Bugs and other deviant behaviors of third-party API and libraries. Platform APIs, 3rd Party Library APIs — all have bugs. Once we hit these, there’s only so much we can do — put workarounds on top of workarounds. We can fix bugs in our own code, and even learn a few things in the process and feel good about it when its done. But when we are literally working “against” a library/platform, it just sucks the programming juices. It is difficult to feel any kind of joy then, and the elegance disappears. The more complex and ambitious programs that we try to write, the more we must build upon the work of others, the more we hit into this problem.

Also, in connection with this post, two relevant essays the readers might find interesting are Knuth’s Turing Award Lecture Computer programming as an art and Andrei Ershov’s essay Aesthetics and the human factor in programming.