This post is nice, but I think it misses one of the key ways in which code is art: the structured expression of creative thought.
When I have thought long and hard and really truly understand how to implement a solution to some tricky problem, I have often broken it down in my head into conceptual functions that make it easy to understand how it works. These conceptual functions often map on to functions in the code. Physically writing out the code is equivalent to saying to someone (and the computer!) "hey, you can think about this problem like this".
It's similar in nature to a mathematical proof. Sometimes when I'm reading someone's code, I see a seemingly difficult task accomplished in a few simple lines. When I pore over those lines, I have a lightbulb moment. The same can happen when reading a mathematical proof. In Lockhart's brilliant essay A Mathematician's Lament[0], the author talks about teaching the formula for the area of a triangle to school students. There is a brilliantly simple and pretty proof of the formula (in the case of unslanted triangles) on p.3. Looking at this diagram is like looking at the code implementing an ingenious short algorithm for solving a thorny problem.
I see a lot of discussion about readability in the sense of making the code as easy as possible for another person to understand with as little thought as possible. And that's very valuable. But I think there's also a lot of value in occasionally encouraging the reader to think in a new way.
Thanks for expressing this. When I hear "code as art," I think of code that is itself poetic, which I think is the same thing you're saying here. Like natural language, computer code can be prosaic or poetic.
graphical notation for the predecessor function λn.λf.λx.n(λg.λh.h(g f))(λu.x)(λu.u) on Church numerals. The others use the freedom in formatting of regular C code to depict a (binary) lambda calculus interpreter shaped like a greek letter lambda, or a Hilbert curve generator shaped like a Hilbert curve.
The IOCCC[1] (International Obfuscated C Code Contest) often features submissions where the source code is formatted to be works of art in itself. Sometimes the source code is also used as input to the program, where the formatting affects how the program behaves.
For example this program, which approximates the decimal digits of pi while having source code formatted to look like a circle:
An idea that I have mused over but haven't attempted to pursue is a code repo (with history, pull requests, etc) as a vehicle for epistolary fiction. There are short stories as sequences of news articles or letters, novels given as diaries, etc -- so why not a story told through issues, pull requests, and the code base? In comparison to code as the text at a given point in time, the whole repo and its presentation of history would let you see both concepts and characters (contributors) changing over time, and a let a reader/user infer certain events outside of the repo (e.g. a merge is followed an hour later by a PR to revert it, with a curse-laden description and rapid approval lets us know that something broke).
Making something that really works in this form both involves a creative insight (What's the story that makes this format shine? What's the code that our characters are building?) and some technical nuggets (writing scripts+tools that generate git history and/or github/gitlab/whatever API calls, acting as multiple parties).
Definitely a workable idea. I used to play a lot of Rimworld and, as is good practice in heavily modded long-run games, would frequently make manual saves. The names of those saves weren't in the style of commit messages (more like episode titles) but it was a similar idea, expressing the current state of the world or my intentions or my reactions to events. Reading back the save names in chronological order is always a fun little way to relive the story of that colony :)
I love programming. But I'm a CTO. My job is to make sure business goals are met through tech - not the other way around. I'm OK with this, but part of me always found it sad.
Now, if you add the possibility that AI will replace programmers at some point in the future (I'm not on the hype train, but I definitely acknowledge the technical possibility that this could happen at some point in the future), and if I think a bit further and assume humanity will figure it all out and we'll all have more time for our hobbies, even then, what use is my hobby of programming? When all it was ever good for was to achieve business goals?
It's refreshing to think it's really not. That it can be art, human self expression, the exchange of ideas, experiences and feelings, a source of joy for me and others. I feel more OK about the future than before I read this, even though the notion wasn't entirely new to me.
Some interesting parts were about the metaphors that people use to make sense of 'pretty' code (is code like prose? like poetry? like maths? like architecture? are any of those craft activities?), and about the role of tools (from IDEs to languages) in affecting what we consider to be nice or not.
I've been chipping away at something similar. I mostly keep writing "what is art," "who are artists," and "what is programming" "what is a programmer?" So I may reach out. It's not formal, but is inspired from my academic career and interests.
> The first step in our study of aesthetic standards in source code will identify the aesthetic ideals ascribed by programmers to the source code they write and read; that is, the syntactic qualifiers and semantic fields that they refer to when discussing program texts. To that end, we first start by clarifying whom we refer to by the term programmers , revealing a multiplicity of practices and purposes, from massively-distributed codebases to ad hoc , one-line solutions, cryptic puzzles and printed code.
Even this paragraph is similar how I've written in terms of word choice. :)
Nice bibiliography too. Happy to see Tractatus there.
Code can have aesthetic value, but I don't think it's like other art. I think the analogy between code and an art like painting is that painting is "expression-complete" in the same way that C is a Turing-complete language, whereas code is not. Code "as art" cannot really express fully everything than painting as an art can, but it can represent some aspects.
> But aesthetically, the source code used to construct the latter array is more "readable" than the former.
Not aesthetically, visually.
Article has some pretty great links.
Programming and aesthetics (Art) are probably the two things that itch my mind the most.
There's a certain type of mindset that people that do and participate in creative programming/digital art have in common with other passionate/creative types. Part of it is the discovery, the inquisitiveness, the plasticity, and the unexpected.
In general sarcastic prose. When you focus more on the creative side you get the general purpose dynamic, memory managed languages. Just make something cool. When you focus more on the comp sci side you get the strongly functional languages, Haskell, Ocaml. And if you mix them together you get lisp.
I also see code as art, not in a simple visual sense but in a sense of elegant, clean and smart engineering solutions and use of language capabilities.
Visual text part is something a linter should take care of for practical reasons.
Elegant, clean and smart are not symptoms of artistry but craftsmanship.
We can debate how much we want about the overlapping of the two boundaries, but you can be an extremely great painter (I've seen insane paintings and copies done by skilled painters) but an unremarkable and uninspired artist.
If you wrote code that is smart, maintainable and clean, you achieved this by maximizing several engineering concerns (finding the best intersection among different concerns), there's no artistry involved.
But at the end of the day, there's really not much to debate here, because unless we give a precise definition of what is and what is not art we can't make conclusions on something being artistic or not.
Its interesting, because in my native language the word Art and word Craftsmanship have common root and they are used in describing a great level of skill and mastery over something.
I feel like in English people mostly use word Art to talk about visual things. While someone can make a painting with a few random drops of paint (or even just a black square) and people will call it art, for example in music there is clearly no art without a great deal of craftsmenship and skill. Similarly I see art of engineering (and computer science) connected with a great skill and insight.
> for example in music there is clearly no art without a great deal of craftsmenship and skill.
You're missing out on a whole world of experimental and ambient music, which may or may not demonstrate great skill and technique (although much of it does). The most obvious and extreme example of such art is: https://en.wikipedia.org/wiki/4%E2%80%B233%E2%80%B3
Art and craftsmanship definitely have overlap, but I think a well accepted Anglosphere understanding of art is that it is expressive. High levels of skill and technical knowledge will naturally lend to an artist being able to be more expressive through nuance and variety. But they're neither separate nor identical concepts.
In any act of creation, both craftsmanship and artistry can be evaluated separately. I think very high levels of craftsmanship naturally lend toward raising the level of artistry, and vice-versa, but they're describing different features of the creation. Craftsmanship is largely about technical quality, choices of material/medium, soundness, precision, etc. Whereas artistry will describe how it feels to perceive the creation.
On the other hand, I just don't see any "artistic" part in software engineering, but again, it boils down to what exact definition you give to the art word.
To me, code has none of the characteristics of true art.
I can applaud the craftsmanship, creativity or originality, but at the end of the day it just does not generate strong emotions nor communicate political, spiritual or philosophical ideas, nor it generates any sense of beauty at all.
If you stretch it literally anything can be art, but I really feel like what we're looking for in general is craftsmanship, not really artistry.
For sure, in a way because its subjective. Even by your own definition of generating strong emotion, people had been inspired by all sorts of things, like apple falling from a tree. Apples have been doing the art of falling for thousands of years and one human actually noticed that.
Oh nice! I gave a PechaKucha talk with the same title back in 2019[0]. Love the illustrated examples here.
One thing I touched on in my talk was the idea that code is an art form that expresses the values of the artist by making something new possible in the world. The artist is saying "this should be possible for people to do" and then makes it so. I think that's really cool.
I've written on this matter before[1]. Code being appreciated as an artform would, to my mind, benefit greatly both the worlds of fine art and programming.
To me, what's presented here is more "art as code" (not that there's anything wrong with that)
Code can be beautiful in its own right, regardless of syntax. "clean" and/or well-formatted code is nice, but the real beauty comes from the algorithmic logic and structure.
We learned to do that in my second CS class at university. It is a common way to represent a matrix. instead of keeping track of just `i`, you will also have a row index and use the modulus operator on the iterator tracking (i) to get the column index.
The thing is, the ability to express complexity is sharply bounded by display size (and maybe some aspect of human cognition such as the gestalt theory about the number of objects which may be perceived at a glance) --- for a textual program, one has an essentially infinite 2D canvas which scrolls up/down --- for a visual program questions of which direction one moves and how much arise. Literate Programming as advocated by Donald E. Knuth at least allows one to add a TOC, Index, and suitable hyperlinks and so forth:
If one tries to manage complexity by using modules, then one gets back to the textual representation one is trying to escape from --- it's just wrapped up in pretty coloured blocks and/or connected with lines.
And of course, there are the cautionary collections such as:
"The human desire to be creative and express one's individuality does not end where a keyboard begins... code can be used as a medium to create art, but it can also be art itself."
When I have thought long and hard and really truly understand how to implement a solution to some tricky problem, I have often broken it down in my head into conceptual functions that make it easy to understand how it works. These conceptual functions often map on to functions in the code. Physically writing out the code is equivalent to saying to someone (and the computer!) "hey, you can think about this problem like this".
It's similar in nature to a mathematical proof. Sometimes when I'm reading someone's code, I see a seemingly difficult task accomplished in a few simple lines. When I pore over those lines, I have a lightbulb moment. The same can happen when reading a mathematical proof. In Lockhart's brilliant essay A Mathematician's Lament[0], the author talks about teaching the formula for the area of a triangle to school students. There is a brilliantly simple and pretty proof of the formula (in the case of unslanted triangles) on p.3. Looking at this diagram is like looking at the code implementing an ingenious short algorithm for solving a thorny problem.
I see a lot of discussion about readability in the sense of making the code as easy as possible for another person to understand with as little thought as possible. And that's very valuable. But I think there's also a lot of value in occasionally encouraging the reader to think in a new way.
[0] https://worrydream.com/refs/Lockhart_2002_-_A_Mathematician%...