For what it's worth I consider programming a "craft", and myself a "craftsman" - or, if you prefer, an "artisan". I'd say the key difference between what I see as "art" versus "craft" is the primary purpose. The purpose of art is to express one's self; the purpose of a craft is utility. Note that this does not mean that self-expression is not possible through craft; on the contrary, it certainly is. The big difference is that when I'm creating software and am met with a situation where self-expression and utility conflict, I reconcile them with an emphasis on utility. In order for software to be beautiful, it must serve a function.
IMO the purpose of art is psychological and emotional concentration, distillation, and abstraction.
You can express yourself in all kinds of ways, but the ways that connect with an audience are the ones that create a novel and intriguing experience. One of the most reliable ways to generate resonance and intrigue is to generate some element of psychological/cultural/emotional insight and mirroring.
Technical skill in a medium is nice to have, but if there's no emotional payload or cultural reflection it doesn't work well as art.
Some reflections are superficial, over-familiar, and banal, which is where art drifts into cliches and entertainment. Others are so rich and deep people have argued about them for centuries.
Code in itself is unlikely to do any of the above. It can be made with skill and elegance, and even with a certain kind of self-expression. But there isn't usually much artistic psychological mirroring in - say - a kernel scheduler or a device driver.
You can argue that you need psychological insight to write good applications - and that's true. But the difference is that art gives an audience a staged non-trivial experience and insight into itself. Code doesn't usually do that. It doesn't even try to.
(Which is also why generative art is often so dull - it's just code statements flapping around semi-randomly with no expressive purpose or insight.)
It's a nice distinction. I wonder whether we can go further though, and not even need that distinction. Here's my take on it.
Any human endeavour is worth its salt if it succeeds at discovering and expressing beauty. It can be a mathematical proof, a theory in physics, an elegant algorithm, a painting, a dance, a novel, a relationship - the list is as endless as the number of ways humans can come up with, and can be as deep and complex and subtle as they wish to make it, but it always comes back to finding and expressing beauty.
I'm embarrassed to say that I wasn't aware of Keats' writings and your comment sent me to get more educated about him, which I found very interesting, so thanks for that :)
Not sure in what sense you find the view reductionist, but I suspect it could be from inadequately expressing what I mean
It's not a particularly new insight, most of us have this idea through intuition and it seems to be popular in the philosophy of aesthetics - the question comes when we have certain items like watches or even beautifully written computer programs, or mass-culture "art" which arguably exists to serve the utility of making more money. There's even an art to writing well, but we could do with the utility of a bullet point list, etc.
Scott McCloud defined it thus in "Understanding Comics":
“Art, as I see it, is any human activity which doesn’t grow out of either of our species’ two basic instincts: survival and reproduction.”
A building serves a utility, yet can we call all architects craftsmen? Can we say that an architect is limited to the extents of the utility in design or do those constraints actually impose a new form of art?
Similarly, cinema is an art form, yet movies are built collectively by many craftsmen. There is no mutual exclusivity there.
I think, however, artistry of software comes from the design, not the code per se. The end product can be an artpiece, or a utility, depending on how its designed.
Let’s also not forget the pure art form of software: demos. What they are to the software is what sculptures are to the architecture.
>I think, however, artistry of software comes from the design, not the code per se. The end product can be an artpiece, or a utility, depending on how its designed.
Which fits your building analogy. Architecture and design are artistry, welding steel is a craft.
The thing about the OP is that while Knuth makes a survey of meanings that the term "art" has, it doesn't seem like survey captures the difference between craft, artisanship and art as they have developed historically.
I believe in art history, art as distinguished from craft develops as artists of note appear with sufficient that their works reflect an unique personal vision while still encompassing the skills of the craftsperson (this view has been implicit since fairly early art history - see artist and art-historian Giorgio Vasari[1]).
In this art/craft distinction, it would seem that, yes, computer programmers are solidly on the craft side. The computer programmer can very creative but the results of the programmers aim to avoid personal expression. Even a programmer who cobbles together a game in their own unique style of assembler doesn't want how the game was created to visible to the end user. Creating a games' design may an art but the programmer aims to make the implementation of the game completely invisible (in most instances, everything that appears from a game implementation detracts from play - pauses, artifacts, pixelation, etc).
The one thing about programming that differs from artisanship is that programmer can face a wider variety of challenges and be more often forced to create entirely new approaches. This is the realm of computer science and software engineering - it is a creative realm but creative in the fashion of the mathematician or scientist rather than the artist (as the artist has been historically distinguished).
You can not separate self expression and utility absolutely. In my opinion, lisp is art, sketchpad is art, TeX is art, the first spreadsheet is art, emacs is art, and others that show something extrodinary, that make you breathless, that feel like great music and painting, can all be called art.
I went to a great conference back in the beginning of 2000 at Ars Electronica, if you haven't gone I would highly recommend it, it's been around since the late 70es and is where art, technology and academia meets.
Anyway in 2003 I was there the talk was about Code as language.
Many interesting talks and debates that year. I think many of the talks are video-recorded.
For what it's worth I consider programming a "craft", and myself a "craftsman" - or, if you prefer, an "artisan". I'd say the key difference between what I see as "art" versus "craft" is the primary purpose. The purpose of art is to express one's self; the purpose of a craft is utility. Note that this does not mean that self-expression is not possible through craft; on the contrary, it certainly is. The big difference is that when I'm creating software and am met with a situation where self-expression and utility conflict, I reconcile them with an emphasis on utility. In order for software to be beautiful, it must serve a function.