Coding philosophically | Makers Academy Remote, Week Two
As anyone who’s paired with me so far could tell you, I really love making analogies. A class is like a species. A method is like a (bad) habit. Instance variables are like the fact that my cat Emily is orange, fluffy, and a little grouchy. An airport is like a docking station.
My academic background is in Christian Theology, specifically in political and ethical theology. I’ve spent many hours in seminars discussing what things like ‘the good’ and ‘value’ and ‘society’ actually mean, abstracting out the concepts until I felt like an astronaut looking at the Earth from the surface of the moon. But unlike working in philosophy, theology at least supposedly requires you to make those concepts relevant to actual people, in the context of religious communities and institutions. Most people, even those who have found the spare time for God-bothering, do not have the leisure that postgraduate students do to sit around contemplating the nature of goodness. They need to understand this stuff more intuitively- and that’s where analogies come in handy.
So what does any of this have to do with coding, in which God usually only comes into it when you’ve torn out a significant chunk of hair over your unit tests? Week two at Makers gets us to really get our teeth into the concept of object-oriented programming. Everything in Ruby is an object- yes, even you Object class. And to begin with, when we’re talking about things like a Boris Bikes docking station, or an aeroplane, or an Oystercard, it makes sense to think okay, yeah, of course it’s an object. I can go and look at one if I want to. It’s right there in front of me.
But it’s not just nice, clear, friendly class instances that relate to things in real life that are objects. When you do bike.broken? and get back ‘true’, that’s also an object. How is ‘true’ an object? That doesn’t make any sense!
I’ve been trying to hold myself back from saying to people, ‘so this is like Plato, yeah?’. I’ve never actually read much Plato, and I spent several years of my life farting around with philosophy. But one of Plato’s central concepts is what I’ve been leaning on most heavily as I strive to get my head around the idea of ‘objects’ in code.
Plato believed that we are only able to know what things are- that a cat is a cat, a table is a table, and an Oystercard is an Oystercard- because things in our reality are poor imitations of a higher, more truly real ‘form’ of that thing on another plane. Things that we interact with derive their essential ‘thing-ness’ from these forms; a cat is a cat because it is in some way like the form of a cat.
Famously, this is exemplified in the Allegory of the Cave. The people trapped in the cave only see shadows of imitations of the real things in the outside world, and understand them to be all there is to reality. The philosopher who escapes and experiences the world beyond the cave- which represents the world of forms in Plato’s hypothesis- is unable to convince them of what he has seen.
The abstractions we make in code are never proper reflections of the things we are modelling, whether it’s Oystercards or the notion of truth. Like shadows, they have no real substance that we can engage with, beyond an object ID in our REPL or the changing output to a user interface, or the broad notions that they represent. But rather than simply experiencing them, like the cave’s prisoners, we control and change them, and eventually craft things that are themselves real*.
*Omitted: extremely long-winded digression as to whether software is ‘real’. I’m going to take the critical realist approach of A Kitten Named Woof- if you can lick it, it’s real.