In Form Information in Formation

Or, Plato and the programmers.

What is programming? It is worth asking the question again and again, rolling it around your tongue, shifting it around to different parts of your brain to see what results. I don’t just mean, however, how the term itself can be defined, for instance as Merriam Webster does here:

1: the planning, scheduling, or performing of a program

2a: the process of instructing or learning by means of an instructional program

b: the process of preparing an instructional program for a device (such as a computer)

There is nothing controversial in the above, and indeed, such a definition (especially in the somewhat throwaway tail-end of definition 2a) may even seem entirely intuitive, commonplace perhaps. Nevertheless, I am asking more in the vein of how we might categorize programming as a practice in and of itself. Is it an art or a science, or is such a distinction inappropriate, whether here or elsewhere? Are programming languages greater or lesser or just other than the language I’m typing here? Are programs and their implementations the products of pure technical skill, blue-sky theoretical thinking or a type of craft, taking in manual dexterity, design and a lineage of trial and error?

It seems possible to me to say, even from my position of extremely limited knowledge and experience thereof, that programming falls across clear-cut lines of definition; a little of column A, a little of B, perhaps also C, and throw in the rest of the column alphabet for good measure. I mention all this as a preamble to what I want to achieve (or rather, set up) in this post, and hopefully in future ones too. My basic premise is that combinations, even if they don’t ultimately fulfil their intended goals, are useful and interesting, and can lead to unexpected boons sometimes greater than those initially intended. Hybridity can be highly fruitful.

So my intention is to try to mix, in a basic, short-form and preliminary way, some ideas on the world of coding (which as I hint above, already seems something of a mix) and some ideas drawn from the world of letters, the humanities, historical contextualization, the arts, or whatever else it might be called. One world is quite new to me right now, one not so much, and I guess I’ll let you guess which is which.

The object of this particular post is to ask again: what is programming? But this time, said object will in fact delve down a little deeper — to objects themselves, such as they are in what is known as Object-Oriented Programming.

To reframe the question, then, what is an object? Let’s try the dictionary again, only this time the entry is much longer, and so a curtailed view focusing on ‘object’ as a noun:

1a: something material that may be perceived by the senses

b: something that when viewed stirs a particular emotion (such as pity)

2a: something mental or physical toward which thought, feeling, or action is directed

b: something physical that is perceived by an individual and becomes an agent for psychological identification

3a: the goal or end of an effort or activity

b: a cause for attention or concern

4: a thing that forms an element of or constitutes the subject matter of an investigation or science

5a: a noun or noun equivalent (such as a pronoun, gerund, or clause) denoting the goal or result of the action of a verb (such as ball in I hit the ball)

b: a noun or noun equivalent in a prepositional phrase (such as table in on the table)

6a: a data structure in object-oriented programming that can contain functions as well as constants, variables, and other data structures

The very first sense in this still rather lengthy list is perhaps the most obvious and everyday, as in ‘object’ simply used as a synonym for ‘thing’, and the final definition is the one that concerns us most here, but the senses in between are interesting and worth some brief attention too. Senses 1b through to 3b could be seen as surprising, a contrast to the strict materiality of 1a in their sustained focus on ‘emotion’, ‘thought’, ‘feeling’ and ‘psychological identification’, and on to the equally immaterial notions of a ‘goal’ or a ‘concern’. The senses in 5 are simply (or not simply?) metalinguistic, language used to talk about language drawn from grammar, again stand-ins for the solidity and materiality of ‘object’ as physical ‘thing’. Accordingly, it is valuable to rehearse this abundance of figurative over literal senses in order to prepare for 6a which, despite its materially-inclined assurances of ‘structure’, ‘orientation’, ‘containing’ and ‘constants’, still allows for the ethereal uncertainty of ‘variables’ in its explanation of the humble ‘object’.

Ok, pause. Such dictionary pedantry may seem trivial or even facetious, but it does at least highlight something which isn’t entirely obvious in advance: that objects are much more nebulous than concrete, that they could just be mental components or even representations rather than clearly delineated entities in themselves. Essentially, it could be argued that objects are merely the products of objectification, as instantiated by somebody (maybe a subject? That’s a topic for another day), without whom they remain vague ‘things’, if they even exist in their own right (another topic for another day — or never?).

As intriguing as such a view might be, let’s not get stuck down this particular semantic cul-de-sac. I want to shift to what first led me to this point, which was coming across something like the following during my recent introduction to the Ruby programming language:

class Human
  def initialize(characteristic)
    @characteristic = characteristic
  end
end

In this code snippet, what we have is an instance of the class ‘Object-Oriented Programming Language Class’. Sound like gibberish? It isn’t, or not quite, at any rate. A ‘class’ here means a type or a general idea, while an ‘instance’ is a concrete example of that type or general idea. So my code snippet itself is an example of the type of thing known as a ‘class’ in a language such as Ruby. Still a little gibberishy? Let’s look at the snippet itself.

In this class definition, the sole capital letter is the giveaway for the name of the particular class being defined: Human. The snippet shows (in a very stripped back way) how some programmer-creator, drunk with power, might go about creating new instances of the class Human, or new people if you prefer. This very basic class only allows each instance of Human (or each human — notice the lower case ‘h’ here, and thus the relationship between instance and class) to have a single characteristic. The Ruby method bookended by def and the first end is what gives the wannabe god-figure the power to create people (in our limited sense, you’ll be pleased to read), and it is here we find the stock Ruby way of instantiating from a class: initialize. Thus, one can call said method on the class by appending .new to the class name, and passing in an argument (which is basically a placeholder term, equating in this case to the content of that poor person’s solitary characteristic) between brackets afterwards:

Human.new("angry")

or

Human.new("tubby")

or

Human.new("philosophically-inclined but holding it down for the purposes of looking cooler than is actually the case")

or maybe just

Human.new("Derek")

And this is what “angry” human, “tubby” human, the closet philosopher human and plain old Derek all have in common: they are all objects, which is to say that they are all instances of a class called Human. Each has been objectified into existence from the general idea of a human with a single characteristic.

Encountering just such an objectifying relationship between the class Human and each one-dimensional human-instance reminded me of philosophy classes I had as a teenager, and learning about Plato’s Theory of Forms in The Republic. I thought this was quite the informed, clever link to be making, but of course, it turns out the link was there by design. As internet pioneer John Shoch writes of Ruby precursor Smalltalk, classes and forms are essentially equivalent:

‘An effort to trace the roots of the epistemological base of Smalltalk — classes and instances — leads one all of the way back to the work of Plato; […] Plato’s theory of Forms postulates the existence of an abstract Form, an essence which reflects the common aspects of many different objects’.

John F Shoch, ‘An Overview of the Programming Language Smalltalk-72', p. 70

Going all the way back to Shoch writing about Object-Orientation in 1979 in turn takes us ‘all the way back to the work of Plato’. What is interesting, though, is that my swift gloss above on ‘object’ in the dictionary led to a largely immaterial view of objects, perhaps as mental constructs or attitudes or representations of what is for many the physical, tangible, ‘real’ world. This seems to fit well with the programmatic sense of ‘object’, where classes can stand in for other concepts, but also conceptualize (that is, reduce to concepts, or objectify) ‘real-world’, physical items, and even the ‘class class is no more (and no less) real than is any other class definition’ (Shoch, p. 71). But Shoch’s bracketed aside that classes are ‘no less real’ than anything else is telling; as Antero Taivalsaari observes:

‘Plato viewed forms — stable, abstract, “ideal” descriptions of things — as having an existence more real than instances of those things in the real world. Class-based languages […] are Platonic in their explicit use of classes to represent similarity among collections of objects’.

Antero Taivalsaari, ‘Classes vs. Prototypes: Some Philosophical and Historical Observations’, unpaginated

In Ruby, an object is no more (or less real) than its class and all the other instances thereof. But could it be more real than the supposed ‘real-world’, as Plato suggests? Not immediately answerable, if at all, but food for thought nonetheless — and certainly others have thought about the philosophical lineage of Object-Oriented Programming beyond the strictures of Plato’s views.

I personally find the reduction of ‘real-world’ situations to relationships between hardcore abstractions of objects (whether physical, mental or anything in between or beyond) to be incredibly useful in practice, as well as fascinating; but for the time being at least (I’m still a beginner, after all), I also find it just that — a reduction, handy in its immediacy and manipulability, but still somehow incomplete and dissatisfying. I wonder how this tension will play out for me, and how other people like me who are not at all well-versed in programming yet feel about such things (as opposed to high-flyers in that world who built such theoretical suppositions into the languages in the first place, and are well placed to authoritatively comment, but perhaps also carrying years of habit and/or bias with them). And I wonder, if these aspects of coding in languages such as Ruby have such a pronounced philosophical basis, could reading philosophy alongside code help to navigate these new seas— or is doing such a thing just a way of threshing up these waters yet more, and sure to result in shipwreck?