Economics and Mechanisms Economics, economic theory, and mechanism design

Object-oriented thinking in economics

I have been meddling with the programming language Python for some years now in order to become self-sufficient in programming simulations. In doing so, I learned the basics of object-oriented computer programming (OOP for short).

OOP is a style of writing computer programs, with some languages, such as Java, heavily supporting it (Java enforces it, in fact) and other languages, such as Python, supporting it strongly. Coming to OOP from economics was conceptually easy. Now I am thinking that OOP has something to tell us regarding how we teach economics or how we present it to the wider world. This post is my first written rumination on this topic.

First, let me define an object in the OOP sense. I need to give you some background first. I expect you are aware, even if you never wrote any computer code, that such code is a string of data, ultimately encoded in binary notation, that tells the computer to do certain things with part of this data. To take a simple example, if you want the computer to choose randomly between the names of participants in a lottery, you have to include the names in your program (data) and write commands that result in one of these names being chosen randomly and this choice being communicated to the user. This little program has data (it "knows" some things) and it has ways of acting on these data (it "knows" what to do with the things it knows).

In any reasonably complicated programming problem, it helps us as programmers to compartmentalize the code. We make a chunk of code to perform task A, another to perform task B, and so on, and finally we write code to coordinate these chunks as they go along merrily doing their thing. Each one of these code chunks has some data it knows and some things it can do with the data it knows. (Computer scientists, I know I am simplifying. I only want to convey the basics of OOP here.) An object in OOP language is a chunk of code that has some data and some things it can do (usually called "methods", but you can think of them as commands specific to this chunk). The programming language in which you are specifying these objects provides ways for objects to communicate with each other, passing data around, and to ask each other to perform one of its methods (execute one of the commands it has).

How is this relevant to economics? You are probably already chomping at the bit to answer, but here is my take. When we set up any model in economics, at least if our model is "microfounded" as we say, we have some agents who know certain things and do certain things. Suppose, for example, that you want to make a computer model of an exchange economy. You need a number of individuals, each with an endowment and a preference relation over the commodity space. These individuals need to be able to perceive prices, decide which net trades are feasible given a particular price vector, and, finally, they need to be able to propose and execute trades with each other. (OK, maybe you wanted a Walrasian auctioneer thrown in as well? I leave it as an exercise then to determine what data and which methods the auctioneer object in the code will need.)

I cannot think of a mainstream economics model that cannot be conceptualized in these terms. Indeed, computational economics has flourished in the last several years and you can find plenty of examples of what I am talking about by visiting, for example, the amazingly comprehensive website that Leigh Tesfatsion has set up. (This kind of "microfounded" computational economics goes by the name agent-based computational economics.)

So why don't we teach our students using the concept that each economic agent in our models is an object (in the OOP sense) that interacts with others based on rules set up by the institutional infrastructure of the economy and physical feasibility conditions?

I can think of two answers right now, one deeper than the other. I will examine each one and argue that they do not convince me, starting with the shallower one.

The shallow answer is that our students will find it hard to understand the OOP language of objects and their interactions. I am much more likely to agree that our students in introductory courses will not understand supply and demand graphs or the simple linear equations we try to use to overcome their math anxieties. But almost all students in introductory courses will have played computer games. For them, all you have to do to introduce OOP objects is to refer to an avatar in an online role-playing game or a tile in Tetris. Stepping from these examples to explaining economic objects in code does not in fact impose the need for a computer language at all. You can use pseudo-code and the ideas stand; any time your students feel shaky, just bring in another computer-game inspired example.

The deeper answer is that while encapsulating an individual in an exchange economy in the language of OOP objects is easy, if we start thinking in the algorithmic terms this mental shift suggests, things like arriving at a Walrasian equilibrium become hard problems. There might even be a student in your class who knows enough computer science and will tell you to your face that our cavalier approach of taking shortcuts like calculating an equilibrium with Lagrange multiplier techniques and setting supply equal to demand is a rotten approach, as it hides the remarkably difficult problem of arriving at an equilibrium.

So how can I deal with this answer? My point is that we should adopt the OOP viewpoint precisely so as to force our students or readers to confront the fact that reaching an equilibrium in an economic model is much trickier a proposition than the typical paper in Econometrica or JET lets on. As economists, we have internalized the mental shortcuts that make us jump to equilibria in fairly complicated models and then analyze the properties of these equilibria. But there is much to be learned by confronting the need to specify exactly how economic agents interact in time, each with its own data an abilities to perform actions such as buying and selling, manage to get to an equilibrium (if they do). Do we really want a Walrasian auctioneer who gropes around in price space to find an equilibrium? What if the economy happens not to have a stable equilibrium (the question can arise whether we are looking at a market model or any other kind of agent-based model). These are not idle concerns; they show clearly some of the limitations of economic theorizing and to ignore them is intellectual arrogance at best, dishonesty at worst.

There is one final point in my mind about this, which I will leave to be developed in a future post. Thinking in terms of institutional infrastructure can be considered the overall code of our economic computer program. This can encompass the ways information gets passed around from agent to agent as the economy operates as well as the outcome function that determines what allocations occur and when as the agents take various actions. The more precise we are in specifying these the better, just as much as the more careful we are to specify computable ways to reach an equilibrium (see the previous paragraph) the better. As this post already exceeds 1250 words, however, this final point will have to be explored later.