Code is Poetry: Programming as an Aesthetic Endeavour
updated over 1 year ago; latest suggestion over 1 year ago
We have often heard code compared to poetry or other artistic pursuits. Most of those comparisons are attempts to add legitimacy to what is still a fairly new profession. But what if looking at code as poetry could actually teach us to write and read code better?
I’ll treat code and poetry in this talk as an aesthetic pursuit and by highlighting parallels I will argue that knowledge of one (poetry) can inform our practice of the other (code). I will take a bottom-down approach by looking at examples and piecing things together to see how far we can take this analogy.
It is futile to argue about individual aesthetic preference, but people usually can collectively agree whether something is actually good or not. Similar judgements can be made about code using this lens.
I will talk about definitions and then build up an argument of parallels using the basic structures of both code and poetry. From there on I will draw conclusions about the craft of software development and see whether it is possible to codify these practices into our every day tools.
- What is poetry?
- Code and poetry both exist as mechanisms of compression and abstraction.
- They both employ significant whitespace.
- Both contain a mechanism of indirection that can expand indefinitely.
- What is aesthetic theory?
- What parallels are there between poetic structure and code?
- Form, rhythm, meter
- Semantic functions
- Lots of examples
- What conclusions can we draw from these analogues?
- Is this way of looking at code productive?
- Will it help us resolve disputes and holy wars?
- Can we automate this way of reading and formatting code?
- Will the craft of code suffer the same fate that poetry has?
- Knowledge about poetry and aesthetics
- A different way to think and talk about code formatting
About the speaker
I am an experienced public speaker with over a decade of experience as a programmer. I’ve spent the past year cleaning up a legacy Objective-C/Swift codebase and have seen almost every possible (and suboptimal) way of formatting code. This process has left me with opinions.
You format all your Swift code as limericks now, don't you? :)