When my children were younger, we posted a list of rules on their playroom wall. These weren’t the usual ones, like “no hitting” or “no biting.” We expected the kids to know those already. This list was for the less-obvious rules — like rule two: “Food can’t talk.” Or rule three: “Screaming is only permitted if you are on fire.”
One morning, when she was nearly four years old, my oldest daughter, Ellie, looked at me as I lifted my coffee cup for my first sip of the day and said, “Daddy, I totally understand evolution. But where did the first of any species come from?” I placed my coffee cup on the table, walked over to the playroom wall, and added what became our most frequently invoked rule, rule four: “No ontology until after breakfast.”
What there is
When Ellie asked me what ontology was, I explained it was the study of where things came from — the beginnings of things.
You can consult the Stanford Encyclopedia of Philosophy for a precise definition. It says, “as a first approximation, ontology is the study of what there is.” Seems simple enough, but the entry almost immediately undermines this straightforward beginning: “One of the troubles with ontology is that it not only isn’t clear what there is, it also isn’t so clear how to settle questions about what there is.…it also isn’t so clear what an ontological question really is, and thus what it is that ontology is supposed to accomplish.” As the study of what exists, then, ontology includes the question of whether ontology itself exists.
My own definition of ontology was not particularly accurate — I was probably confusing it with “ontogeny” — but it was useful as a way to categorize one of the most common, and most difficult, types of questions a four-year-old asks. And when I look at my own life it turns out that what I’ve always been most interested in is this kind of ontology: finding out where things come from.
When I was younger I used to have minor panic attacks that were triggered by looking around and thinking that everything I could see had been made by someone and put exactly where it was on purpose. Once my thoughts started down this path, it was difficult to find any place for them to end.
Look at a window, for example. The frame is made of wood. Someone cut down a tree to get that wood, using a chainsaw. The chainsaw was made of metal parts, the metal for which had to be mined, refined (using coal probably, which also had to be mined), and forged (using yet more machinery). Harvesting lumber also involved log skidders, trucks, lumber mills, and workers in hard hats and clothes and boots who drive cars and live in houses, and all of those things had to be made as well. In The Toaster Project, Thomas Thwaites traces the ontology of manufactured objects in a much more productive way, attempting to build a cheap commodity toaster from scratch, starting by mining ore and working his way all the way up to a working product.
I wasn’t as creative or industrious as Thwaites. Instead, I would have to turn off all the lights and lie on my bed and breathe very slowly sometimes to stop my mind racing. It was all I could do to stave off the feeling of being crushed by the weight of an inconceivable number of tiny actions and choices that had led to everything around me being exactly what it was. I now recognize that this was essentially an ontological panic, and with time I learned to stop thinking about it.
Programming as applied ontology
Today, I work as a computer programmer. One of the fundamental habits of a programmer is determining the general features of a problem and finding a way to solve every instance of that type of problem, instead of just the problem at hand.
For example, if a programmer needs to know what the date was 136 days ago, she rarely just answers that question. She instead writes some code that takes as input a date representing “today,” and a second value representing a “number of days,” and then outputs the answer. Once she’s done that, she probably goes on to make it capable of adding days instead of subtracting them, or determining the number of days in between two arbitrary dates, and so on.
Actually, unless she’s using a very new programming language, it’s more likely that she finds the standard library of date functions, which some other programmer has already written to carry out exactly these operations. Just as they love using their existing tools to solve a general class of problems, programmers also love making new tools to solve whole new classes of problems, or to solve the same old problems in whole new ways.
Near the end of every year in my high school, the senior physics class built model rockets and launched them on the soccer field. The goal was to come as close as possible to landing your rocket in the soccer net on the opposite end of the field. Rocket Day was a longstanding school tradition, and I’d watched several Rocket Days.
For my junior year science fair project, I thought I would try to solve the general class of problem posed by Rocket Day: given a rocket of a certain cross-sectional area, with a certain fin shape and nose cone shape, and a motor with a given thrust profile, at what angle should it be launched in order to hit a target a given number of meters downrange? I thought that it ought to be possible to program a computer to answer this question.
For reasons that remain murky, my high school felt that developing a ballistic missile targeting system was an entirely appropriate eleventh-grade science fair project. They even allowed me to recruit a fellow student who was better than I was at math to help me integrate the rocket motor thrust curves, which are discontinuous and awkward to calculate. A third student, who was a more experienced programmer, helped me write the actual code, which was BASIC running on an IBM 386 clone.
I sent away by mail for the Estes Model Rocket Corporation’s Model Rocket Technical Report TR-11: Aerodynamic Drag of Model Rockets, by Dr. Gerald M. Gregorek, which you can still download today. It was derived from wind-tunnel tests and provided the equations I needed to determine drag coefficients for all of the common rocket nose cone and fin shapes, as well as data on the variation of air density with altitude, temperature, and relative humidity. My program would use these equations to calculate the position and velocity of the rocket at intervals of perhaps a tenth of a second and, in theory, tell me exactly what launch angle would make the rocket hit the soccer net.
The program allowed a user to select the fin shape, nose cone shape, rocket tube radius, total mass, engine type, launch angle, and air temperature. It worked very well, up to a certain point, and then the altitude numbers would just go off into the millions of meters and the whole program would crash. We could never quite quash the bug that caused this error, and then the science fair arrived.
I suspect BASIC was not a very good choice for the programming language. Still, we received second place. The kid who won first place went on to be a doctor, and he now heads a major department of a large hospital in California, so I don’t feel too badly about it.
That science project taught me that it is possible to approach a problem by returning to the very beginning of things — in this case, the basic physical laws that govern ballistic flight. Looking for the beginnings of things is a habit that has stayed with me ever since, including in my current large garden, which investigates the question of where food comes from. I have a flock of chickens who lay eggs for us, the ontological overtones of which should be obvious. I enjoy (slowly) renovating our old house, and there is nothing better for learning about beginnings than taking down a wall in a house built around the turn of the last century.
I have always thought my career as a programmer traced back to that science fair project about rockets. It felt satisfying that an effort to get to the beginning of one thing, while it didn’t really succeed, ended up being a whole different beginning for me.
A few months ago, my parents were cleaning out their attic and gave me a pile of my elementary school work they had saved. The papers sat on my desk for weeks, but I finally looked through them and discovered a sheet of paper from second grade.
“I think my special job should be a computer programmer,” I had written. “I could program the school computers.” The thing about ontology is, you never know where the actual beginning of anything is. Existence, it turns out, is tricky.
Rule four redux
A few months after her question about evolution, again at breakfast, Ellie looked at me and said, “I have a question, but I think I need an exception to rule four.” I told her to go ahead, mostly to see if she actually understood what an ontological question was. She continued, “Well, I was just wondering how people started making up words.” Yeah, she got it.
She’s a smart kid, and nothing gives me more joy than explaining some feature of the world to her at excruciating length, but I do prefer to have a cup of coffee first.
Rusty Foster is a writer and programmer who lives in Maine.