Computer programming as an art (1974)
dl.acm.org
dl.acm.org
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.
That is the clearest distinction I've seen yet between these. Thank you for that insight.
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.)
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.
Not sure in what sense you find the view reductionist, but I suspect it could be from inadequately expressing what I mean
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.
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).
http://www.paulgraham.com/knuth.html
Past discussion:
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.
https://ars.electronica.art/aeblog/en/2014/11/04/code-die-sp...