After reading Ben Halpren's blog post: "What industry am I in?", I thought about giving him a link to a lecture a friend of mine showed that explained his thoughts on the "complexity management industry", and perhaps used this lecture as a starting point for actually answering Ben Halpren's question. But I decided that excerpting from the lecture would be more worthwhile and useful. Defining the industry is more important than actually naming it.
This excerpt is taken from Lecture 1A of the MIT 6.001 Structure and Interpretation of Computer Programming, 1986, by Hal Abelson.
PROFESSOR: I'd like to welcome you to this course on computer science. Actually, that's a terrible way to start. Computer science is a terrible name for this business.
First of all, it's not a science. It might be engineering or it might be art, but we'll actually see that computer so-called science actually has a lot in common with magic, and we'll see that in this course.
So it's not a science.
It's also not really very much about computers. And it's not about computers in the same sense that physics is not really about particle accelerators, and biology is not really about microscopes and petri dishes. And it's not about computers in the same sense that geometry is not really about using surveying instruments.
In fact, there's a lot of commonality between computer science and geometry.
Geometry, first of all, is another subject with a lousy name. The name comes from Gaia, meaning the Earth, and metron, meaning to measure. Geometry originally meant measuring the Earth or surveying. And the reason for that was that, thousands of years ago, the Egyptian priesthood developed the rudiments of geometry in order to figure out how to restore the boundaries of fields that were destroyed in the annual flooding of the Nile.
And to the Egyptians who did that, geometry really was the use of surveying instruments.
Now, the reason that we think computer science is about computers is pretty much the same reason that the Egyptians thought geometry was about surveying instruments. And that is, when some field is just getting started and you don't really understand it very well, it's very easy to confuse the essence of what you're doing with the tools that you use.
And indeed, on some absolute scale of things, we probably know less about the essence of computer science than the ancient Egyptians really knew about geometry.
Well, what do I mean by the essence of computer science? What do I mean by the essence of geometry?
See, it's certainly true that these Egyptians went off and used surveying instruments, but when we look back on them after a couple of thousand years, we say, gee, what they were doing, the important stuff they were doing, was to begin to formalize notions about space and time, to start a way of talking about mathematical truths formally.
That led to the axiomatic method. That led to sort of all of modern mathematics, figuring out a way to talk precisely about so-called declarative knowledge, what is true.
Well, similarly, I think in the future people will look back and say, yes, those primitives in the 20th century were fiddling around with these gadgets called computers, but really what they were doing is starting to learn how to formalize intuitions about process, how to do things, starting to develop a way to talk precisely about how-to knowledge, as opposed to geometry that talks about what is true.
... Here is a piece of mathematics that says what a square root is.
DECLARTIVE KNOWLEDGE:
The square root of X is the number Y, such that Y squared is equal to X and Y is greater than 0.
Now, that's a fine piece of mathematics, but just telling you what a square root is doesn't really say anything about how you might go out and find one.
So let's contrast that with a piece of imperative knowledge, how you might go out and find a square root. This, in fact, also comes from Egypt, not ancient, ancient Egypt. This is an algorithm due to Heron of Alexandria, called how to find a square root by successive averaging.
IMPERATIVE KNOWLEDGE:
- Make a guess (G)
- Improve the guess by averaging G and X/G
- Keep improving the guess until it is good enough
That's a method. That's how to do something as opposed to declarative knowledge that says what you're looking for. That's a process.
Well, what's a process in general? It's kind of hard to say. You can think of it as like a magical spirit that sort of lives in the computer and does something. And the thing that directs a process is a pattern of rules called a procedure.
So procedures are the spells, if you like, that control these magical spirits that are the processes. I guess you know everyone needs a magical language, and sorcerers, real sorcerers, use ancient Arcadian or Sumerian or Babylonian or whatever.
We're going to conjure our spirits in a magical language called Lisp, which is a language designed for talking about, for casting the spells that are procedures to direct the processes.
Now, it's very easy to learn Lisp. In fact, in a few minutes, I'm going to teach you, essentially, all of Lisp. I'm going to teach you, essentially, all of the rules.
And you shouldn't find that particularly surprising. That's sort of like saying it's very easy to learn the rules of chess. And indeed, in a few minutes, you can tell somebody the rules of chess.
But of course, that's very different from saying you understand the implications of those rules and how to use those rules to become a masterful chess player.
Well, Lisp is the same way. We're going to state the rules in a few minutes, and it'll be very easy to see.
But what's really hard is going to be the implications of those rules, how you exploit those rules to be a master programmer. And the implications of those rules are going to take us the, well, the whole rest of the subject and, of course, way beyond.
OK, so in computer science, we're in the business of formalizing this sort of how-to imperative knowledge, how to do stuff. And the real issues of computer science are, of course, not telling people how to do square roots. Because if that was all it was, there wouldn't be no big deal.
The real problems come when we try to build very, very large systems, computer programs that are thousands of pages long, so long that nobody can really hold them in their heads all at once.
And the only reason that that's possible is because there are techniques for controlling the complexity of these large systems. And these techniques that are controlling complexity are what this course is really about.
And in some sense, that's really what computer science is about. Now, that may seem like a very strange thing to say. Because after all, a lot of people besides computer scientists deal with controlling complexity.
A large airliner is an extremely complex system, and the aeronautical engineers who design that are dealing with immense complexity.
But there's a difference between that kind of complexity and what we deal with in computer science. And that is that computer science, in some sense, isn't real.
You see, when an engineer is designing a physical system, that's made out of real parts. The engineers who worry about that have to address problems of tolerance and approximation and noise in the system. So for example, as an electrical engineer, I can go off and easily build a one-stage amplifier or a two-stage amplifier, and I can imagine cascading a lot of them to build a million-stage amplifier. But it's ridiculous to build such a thing, because long before the millionth stage, the thermal noise in those components way at the beginning is going to get amplified and make the whole thing meaningless.
Computer science deals with idealized components. We know as much as we want about these little program and data pieces that we're fitting things together. We don't have to worry about tolerance. And that means that, in building a large program, there's not all that much difference between what I can build and what I can imagine, because the parts are these abstract entities that I know as much as I want. I know about them as precisely as I'd like.
So as opposed to other kinds of engineering, where the constraints on what you can build are the constraints of physical systems, the constraints of physics and noise and approximation, the constraints imposed in building large software systems are the limitations of our own minds.
Top comments (0)