ity by establishing new languages for describing a design, each of which emphasizes particular aspects of the design and deemphasizes others. Underlying our approach to this subject is our conviction that “com- puter science” is not a science and that its significance has lile to do with computers. e computer revolution is a revolution in the way we think and in the way we express what we think. e essence of this change is the emergence of what might best be called procedural epis- temology—the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of “what is.” Computation provides a framework for dealing precisely with notions of “how to.” In teaching our material we use a dialect of the programming lan- guage Lisp. We never formally teach the language, because we don’t have to. We just use it, and students pick it up in a few days. is is one great advantage of Lisp-like languages: ey have very few ways of forming compound expressions, and almost no syntactic structure. All of the formal properties can be covered in an hour, like the rules of chess. Aer a short time we forget about syntactic details of the lan- guage (because there are none) and get on with the real issues—figuring out what we want to compute, how we will decompose problems into manageable parts, and how we will work on the parts. Another advan- tage of Lisp is that it supports (but does not enforce) more of the large- scale strategies for modular decomposition of programs than any other language we know. We can make procedural and data abstractions, we can use higher-order functions to capture common paerns of usage, we can model local state using assignment and data mutation, we can link parts of a program with streams and delayed evaluation, and we can easily implement embedded languages. All of this is embedded in an in- xxiii