The literature of software development contains many references to the “Art vs Science” dichotomy. This article presents a rather short and recessarily incomplete overview of projects, books and papers referring to the subject written in the past 50 years.
Programming As Artisanal Work
A friend of mine, musician turned software developer, once told me that software developers are not so much artists than artisans. His reasoning went as follows: as beautiful as code can be – regardless of your definition of the world “beautiful,” – software is always somewhat defined by its utility. On the other hand, art exists per se, without any kind of intrinsic utility rather than its mere existence, and the sensations it generates to its public.
A piece of software, following this reasoning, must be useful, and hence is not actually art.
But it might as well be classified as artisanal, in the sense that it conveys utility and beauty, just like pottery, knitting garments, or traditional musical instruments made by a luthier.
In the third edition of “Free Software, Free Society” by Richard Stallman, he appears to agree to this definition, from chapter 17, “Words to Avoid (or Use with Care)”:
To speak of “consuming” music, fiction, or any other artistic works is to treat them as products rather than as art. If you don’t want to spread that attitude, you would do well to reject using the term “consume” for them. We recommend saying that someone “experiences” an artistic work or a work stating a point of view, and that someone “uses” a practical work.
I remember back in the 90s, my team was using components made by a company named “Software Artisans,” relatively well-known in the Microsoft galaxy as a producer of prebuilt COM components to be used in Windows and ASP applications.
The word “artisan” conveys a lot of positive values, indeed, including attention to detail, efficiency, quality and support. Countless papers and books touch, directly or indirectly, the world of software craftmanship.
Craftmanship. Even this word suggests cozy feelings and good vibrations.
Programming Languages As An Artistic Medium
Just like thousands of other developers, I discovered the Ruby programming language back in 2005, at a time when Ruby on Rails was becoming a storm that was about to change the face of web development forever.
Yukihiro “Matz” Matsumoto created Ruby to become a tool to make better, more beautiful things, making developers happier and more productive. (Maybe he wanted them to become better artisans?) He mentioned this intention several times in interviews, books and blog posts. His work, started in the early nineties (roughly at the same time as Python,) was virtually unknown to western developers. The “Programming Ruby” (also known as the “Pickaxe” book) by the Pragmatic Programmers was the first (and for a while the only) guide to the language published in English.
Inspired by this philosophy, a developer only known by the nickname of “_why the lucky stiff” or simply “_why,” wrote The Poignant Guide to Ruby, which might as well qualify of the weirdest, funniest, most radically different, programming book of all time. In a sequence of vignettes, mixing tweaked pictures, drawings, and code snippets, _why introduces Ruby, its syntax, and its philosophy.
Unfortunately, in 2009, _why decided to delete all of his online presence. Thankfully there are some online collections of his work.
Programming As A Self-Fulfilling Prophecy
Tom Murphy wrote a “strange paper” for the 2017 SIGBOVIK conference, explaining the structure of a small, experimental C99 compiler called “ABC.” The interesting part of this work is that his paper is the actual compiler. Once saved, a user can execute the contents of the paper (which is also 100% printable) from a Windows command line, and actually use it to generate EXE programs.
Executing this paper in DOS, with an AdLib-compatible sound card (such as the Sound Blaster) configured at 0x388, will play some music. The music to play is specified on the command line, using a subset of a standard text-based music format called ABC [ABC’05]. For example,
will play a segment of the “Now I know my ABC’s” song and then exit.
The paper also contains its own source code, and the author even tried to make it self-printable. During the preparation of this article I installed FreeDOS in a VirtualBox machine in my laptop, copied the paper and executed it, and to my amazement it worked perfectly well, as intended.
Something tells me that Alan Turing would have loved to read this paper.
Programming As An Art School
These days you can become a poet programmer. The School for Poetic Computing defines itself as:
…an artist run school in New York that was founded in 2013. A small group of students and faculty work closely to explore the intersections of code, design, hardware and theory — focusing especially on artistic intervention. It’s a hybrid of a school, residency and research group.
I’d like to begin the class by asking “What is poetic computation?” First, there is the poetics of code, which refers to code as a form of poetry. There is something poetic about code itself, the way that syntax works, the way that repetitions work, and the way that instruction becomes execution through abstraction. There is also what I call the poetic effect of code, which is an aesthetic experience realized through code. In other words, when the mechanics of words are in the right place, the language transcends its constraints and rules, and in turn, creates this poetic effect whereby thought is transformed into experience.
If you are in the west coast, you might be more interested in participating in Dynamicland:
We are a non-profit long-term research group in the spirit of Doug Engelbart and Xerox PARC, inventing a new computational medium where people work together with real objects in the real world, not alone with virtual objects on screens. We are building a community workspace in the heart of Oakland, CA. The entire building is the computer.
Programming As The Antithesis Of Art
In “Mindfire: Big Ideas for Curious Minds,” Scott Berkun makes a point about the characteristic that defines what an artist is, and which might work as a guide for a few of us in the field.
But if you work for clients/bosses in the making of things that you yourself would not consider art, or are beneath your own standard, or that you blame others you work with for ruining, you are not an artist. You are an employee. You are being paid to give someone else authority over your creative decisions. This can involve inspiration, effort, sacrifice, passion, brilliance, and many other noble things, but it’s not the same as being an artist.
Programming As Intuition
A recent paper from Harvard University, “The Periodic Table Of Data Structures” argues that art is driven by inspiration:
Art vs. science. Just because a specific design is a combination of existing design concepts, it does not mean that it is easy to be conceived manually. In other words, when the number of options and possible design combinations is so big, it is hard even for experts to “see” the optimal solutions even when these solutions consist of existing concepts only. This is why many argue that research on algorithms and data structures is a form of art, i.e., driven by inspiration. Our goal is to accelerate this process and bring more structure to it so that inspiration is complemented by intuitive and interactive tools.
Programming Artistry As A Problem
In the classic 1968 “Software Engineering: Report of a Conference Sponsored by the NATO Science Committee” paper, the relationship of programming with art is seen as somewhat problematic, as something that should be fixed for the profession of programming to become a branch of engineering. It remains to be seen whether there has been any progress in the 50 years that passed since the publication of this paper.
Several participants were concerned with software engineering management and methodology, as exemplified by the following remarks.
d’Agapeyeff: (from Reducing the cost of software)
“Programming is still too much of an artistic endeavour. We need a more substantial basis to be taught and monitored in practice on the:
(i) structure of programs and the flow of their execution;
(ii) shaping of modules and an environment for their testing;
(iii) simulation of run time conditions.”
Programming As Joy
The conclusion of this article is that… well, there is no conclusion. Art or Not Art, it does not matter; programming is something we do. In the humble opinion of this author, the joy of programming is what makes it an art; we become artists the moment we find happinness while making things happen in a computer.
And so it happens that this joy is personal, and most often than not, very hard to share with others. We all feel sometimes like a Mark Watney celebrating in Mars, all alone, that something worked. We know that feeling.
Maybe that feeling is the feeling of an artist. Or maybe not.
Maybe it just does not matter. Maybe, just maybe, things just are.
I will leave these references here for you to explore, some of which are well known, some might not; they all touch the subject of artistry in programming in some way or another. Enjoy!
- “The Mythical Man-Month” by Frederick Brooks.
- “The Psychology of Computer Programming” by Gerald M. Weinberg.
- “Hackers and Painters” by Paul Graham.
- “The Art of Computer Programming” by Donald Knuth.
- “Object-Oriented Software Construction” by Bertrand Meyer – for example, on page 878, when he mentions Barry Boehm.
- “A View of 20th and 21st Century Software Engineering”, a paper by Barry Boehm from 2007.
- “Dealers of Lightning” by Michael Hiltzik.
- “Revolution in the Valley” by Andy Hertzfeld.
- “The Tao of Programming”
- “Masterminds of Programming” – for example on page 305, where Anders Hejlsberg talks about C#.
- “Design for Hackers” by David Kadavy.
- “The ‘Future Book’ Is Here, but It’s Not What We Expected”, article on Wired from December 2018 by Craig Mod.
Cover photo by the author, made with an Olivetti Lettera 22 typewriter.