Is computer science just modeling?

The recent discussion of abstraction has been very interesting for me. I seem to have talked myself into the position that what we are (or should be) teaching when we teach computer science is modeling — where modeling refers to both structure and behavior. Almost all software is either (a) a model of something (Turing conceptualized a Turing Machine as a model of human computation, hence even software that implements an algorithm is a model) or (b) a tool (or other framework) to help build models. Abstraction is the process of stepping back from the act of modeling and building tools that capture the processes and structures we use to build models. That seems both right and too simple.

I have claimed that computation is really externalized thought. (See section 5 of "Putting Complex Systems to Work" as well as "If a Tree Casts a Shadow is it Telling the Time?" A revised edition will appear in an upcoming issue of the International Journal of Unconventional Computation.) Thought in some reasonable sense can be said to be the development of (mental) models. So if software is externalized thought it makes sense to say that computer science is really about modeling and the abstractions that underlie and enable it.

If as suggested earlier, modeling is the representation of something in a well-defined language, then software is the representation of the subject matter of a mental model in a particular computer language. Even an algorithm expressed as a program fits this definition. A program that implements an algorithm is the representation of the algorithm in the programming language. As noted in the earlier entry, this perspective implies a three-fold division: the thing being modeled, the conceptualization of the thing, i.e., the conceptual model, and the externalization or representation of the conceptual model in a well-defined language.

The difference between this position (and the one taken in "If a tree …") and that taken by most science and engineering education is that this position takes our conceptual (mental) models seriously. Most of science attempts to avoid talking about mental models. Even though all of science is about ideas — how are we to understand the world — we don't like to talk about ideas because we can't hold on to them. Thus we talk about representations, typically mathematical representations, of ideas. That's fine — except when we lose track of the fact that the point of it all is to understand the world — and then perhaps to use that understanding to add new things to the world. (See "turning dreams into reality" below.)

This position also argues for teaching computer science students as many (mental) modeling techniques as we know — including mathematical techniques. As noted earlier, the point is not to teach mathematics as mathematics but to teach mathematics as a language for expressing models. The same argument could be made about many other disciplines. Most disciplines develop models of their domains. It would be useful for computer science students to learn as many ways as possible to conceptualize the world. The challenge then would be to find ways to make models developed in other disciplines expressible in an executable form, i.e., as software.

Of course most software does not attempt to model something that exists in the world prior to the software. Most software is the development of something new. But consider how our intellectual abilities work. We evolved the ability to conceptualize the world presumably because it was a useful survival capability. But once we developed that ability, we used it to invent new worlds — to write fiction — as well as to conceptualize the world as it is. The same is true for software. Most of the software we write involves developing models of things that don't exist elsewhere. But the ability to build software that models anything is grounded on the ability to write software that implements models in general — of both existing and imaginary elements. So it makes sense to argue that computer science is the study of building models and that anything that helps develop that ability will contribute to one's ability to write better software. Abstraction, then is the factoring out common elements in model building and understanding those common elements as conceptualizations on their own.

My department is in the School of Engineering, Computer Science, and Technology. We recently had a school-wide open house in which we wore T-shirts that said "Turning dreams into reality." Although I don't for the most part think of Computer Science as an engineering discipline, I agree that we have that in common. We are both creative disciplines in which we create visions, which we then transform into something that exists in the material world. (Even software and the cyberspaces that it creates exist in the material world.)

Engineering is said to be the application of science to practical ends. If one thinks of engineering as transforming dreams to reality, it is far more than that. But science is what underlies engineering. It provides the understanding that allows the engineer to transform a dream into reality.

Perhaps in the same way, modeling serves as the "science" of computer science. It's the understanding of models and how models work that allows software developers to transform their dreams into software reality.