5626463547 | San Jose, CA 95126

The Natural Transition from Philosophy to Programming

I want to convince you that the move from philosophy to programming is a natural one. By describing this move as natural, I mean only that if one were fully informed of the relevant facts, there would be nothing surprising about a philosopher considering programming as a viable career alternative. (If it helps, the move from philosophy to law is also a natural one.) The argument by which I aim to convince you is not original with me; it was an argument given to me from friends who made this transition before I did. What I will do is fill out the details a little further. Just a note about my terminology: I intend uses of ‘developer’, ‘programmer’, and ‘software engineer’ and the like to all designate the same sort of job. And one final caveat: just as there are different types of philosophers depending on areas of speciality or the so-called analytic and continental traditions, there are different types of developers. I will be focusing on an argument surrounding the type of development that I do.

The Argument Overview

Regardless of what type of developer you are considering, the typical point of connection made in conversation is that philosophers are very logical, and for that reason they would be excellent at programming. After all, there are lines and lines of code so that as data passes through each chunk of code, the developer needs to be able to determine whether the data being received is the right data or not. If it’s incorrect, why is the data incorrect? Was the wrong Boolean operator used? Are the if-then conditionals nested in a funky way that doesn’t make sense? This is similar to working through a logic proof, right? You get the point. The point about logic chopping skills is a fair point, and I don’t want to dismiss it. But it isn’t the interesting point of connection, in my opinion.

The interesting point of connection between philosophy and programming is this: philosophers and programmers use many of the same concepts but for different ends and with different words or descriptions. Since there is, as I will argue, conceptual overlap, philosophers are in a position to pick up many of the skills required to be a decent programmer fairly quickly, and with less struggle than others. This is because they are already familiar with many of the same ideas. That’s why the move from philosophy to programming is natural.

As I said above, the argument here concerns the type of programming I do. Quite often, programming is broken down into two types: object oriented programming (OOP) and functional programming. These types are not totally exclusive of one another. One of the programming languages I work with, C# (pronounced “C sharp”), has elements of functional programming but it is generally built for OOP. So what is OOP? Answering that question will bring us to the next section where I get into the conceptual overlap alluded to above.

Evidence of Conceptual Overlap

My claim is that there is conceptual overlap between programming, specifically (though not exclusively) object oriented programming, and philosophy, and that’s why the move from philosophy to programming is natural. Returning to the question left hanging in the last section, then, what is object oriented programming? Here is how one book describes it:

The world around us is made up of objects, such as people, automobiles, buildings, streets, adding machines, papers, and so forth. Each of these objects has the ability to perform certain actions, and each of these actions has some effect on some of the other objects in the world. OOP is a programming methodology that views a program as similarly consisting of objects that interact with each other by means of actions.

Object-oriented programming has its own specialized terminology. The objects are called, appropriately enough, objects. The actions that an object can take are called methods. Objects of the same kind are said to have the same type or, more often, are said to be in the same class. For example, in an airport simulation program, all the simulated airplanes might belong to the same class, probably called the Airplane class. All objects within a class have the same methods. Thus, in a simulation program, all airplanes have the same methods (or possible actions), such as taking off, flying to a specific location, landing, and so forth. However, all simulated airplanes are not identical. They can have different characteristics, which are indicated in the program by associating different data (that is, some different information) with each particular airplane object. For example, the data associated with an airplane object might be two numbers for its speed and altitude.
– Walter Savitch, Absolute Java, 5th edition. pp 3-4.

So one aspect of object oriented programming is the idea that developers are designing models of objects. If you have an car object that you want to represent in an application, you will create a car “class” that will indicate the attributes that the car will have and the possible behaviors of the car. In this case, you are constructing a model that can be mapped as a partial representation of real cars (or simples arranged car-wise, if that’s the ontology you go for).

In an application, I might have the following sort of code:
class Car
int NumberOfSeats { get; set; }
double SizeOfGasTank { get; set; }
public void Drive (int mph, double distanceVariable)
// some code would go here to make the car drive mph miles per hour and the distance of distanceVariable.

This class is very incomplete; cars obviously have many more attributes and possible behaviors than this. But what I have here is a class that represents a car object (incomplete though it is), and it has two properties: one indicating the number of seats given as an integer, and one indicating the size of the gas tank given by (roughly) a real number. I also have a single method that, when called, makes the car drive at a certain speed and for a certain distance. Given this car class and access to use it (given by the word ‘public’), I can create instances of cars that will have data concerning the number of seats, how big the gas tank is, and which can move when told to do so.

So a class, then, looks a lot like the notion of a kind. Obviously, philosophers have different accounts of what a kind is, if they admit there are kinds at all. But even if one wants to deny there are kinds, all that I need for my argument here is that philosophers have a rough enough idea of what a kind is. Whatever the right account of kindhood is (yes, you see what I did there), there are particulars or individuals that instantiate different kinds. Likewise in OOP, there are objects that instantiate classes. In this case, the language is nearly identical.

Another example of conceptual overlap from ontology. Take the question, “what is an object?” I will here focus on JavaScript objects. A JavaScript object, according to W3Schools, is is an unordered collection of variables called named values. And named values are called properties. Simplifying a bit, we can then say that a JavaScript object is a collection of properties. Now consider what is substance is. Isn’t there a view of substance that takes a substance to be merely a bundle of properties? Doesn’t any of this sound familiar to you? If you do metaphysics, it should.

Let me provide an example from the philosophy of language. Take Kripke’s idea that when an object is initially named or dubbed, the name becomes a designator for that object. In programming, when I want to instantiate a new car object, I have to do two things: I have to declare a variable with its datatype (at least in “strongly-typed” languages, like C#), and I have to initialize it. To declare the variable can be as simple as this:

Car carInstance;

The first word “Car” identifies that the datatype is of the Car type given by the Car class above, and not, say, an Airplane type or an integer or char (i.e. single character) type. So “carInstance” cannot be used to represent an integer, but only a Car. The second word, “carInstance”, is the variable that will be used; this is the “name”. So what I am saying is that whatever this variable will be used to refer to, it will be of the kind Car (again: not all languages require strongly typed variables). When I initialize the variable, I can do this:

carInstance = new Car();

What I am doing here is saying that there is a car object, a new one in my application, and I hereby refer to this object via the name “carInstance”. So anytime I use “carInstance”, such as by saying that carInstance has three seats (e.g., carInstance.NumberOfSeats = 3; ), I am designating that specific object which has a specific reference as well in physical memory. That is, if the value 3 is stored at physical location 1187 in memory, I can get to that value again through the name “carInstance” because I designated the word to stand for that object. In any case, the initialization of the object involves a semantic baptism.

I’ve covered a few concepts that illustrate conceptual overlap. Obviously, I didn’t cover them all. I didn’t talk much about events, the relationship between classes and inheritance, which could be mapped to the notion of relations between ontological categories, lambda expressions or methods in LINQ that mirror quantifiers, and so on. But I will stop here since I think I’ve said enough to convince you that there is some overlap. I would have to write a lot more to convince skeptics that there is a lot of overlap, or enough overlap to make the transition natural. For skeptics, I should have said enough to intrigue you.

Final Thoughts

I want to make clear that this is not the only argument that one can give for why the transition is natural. But it is the only one I will give in this post. Let me close by saying, quickly, how this helps. As an ontologist, you are likely asking different sorts of questions and thinking about different types of puzzles than do developers. As a developer, you are also solving problems (as they like to say), but you have a different goal in mind. Knowing that, say, Arthur Prior held such and such view about time is going to be worthless to you when you have to figure out an efficient way to loop through thousands of items without slowing down the server significantly, or what is the best way to map features in your classes to columns in a database without making a one-to-one mapping. It might help, but usually not – at least not in my experience. What the conceptual overlap will do for you, however, is help you get up to speed. Many of the concepts will not be foreign to you, and you will be less fearful of diving into this new area. And you will be able to see quickly what sort of assumptions the authors of the languages were making; this should make learning the material much more efficient for you. And it will speed up the time in which you start building cool stuff and start having fun with intellectually challenging work.

2015-08-24T03:59:30+00:00 August 22nd, 2015|3 Comments


  1. anonymous October 16, 2015 at 12:33 pm

    I do not even know how I ended up here, but I thought
    this post was good. I do not know who you are but definitely you’re going to
    a famous blogger if you aren’t already 😉 Cheers!

  2. Guillaume Bignon April 4, 2017 at 11:16 am

    I’m a software developers and manager of software developers, and I strongly approve of this argument.

Comments are closed.