![](https://csdnimg.cn/release/download_crawler_static/10856692/bg12.jpg)
Prologue xvii
was automata theory concerned with the study of highly abstract, mathematical
models of computation.
For some computer scientists, automata theory was the “science” in “computer
science.” is suggested, indeed assumed, that computer science was a mathematical
science. Research papers, monographs, and textbooks devoted to automata theory
were full of axioms, denitions, theorems, corollaries, and proofs in the traditions of
mathematics and mathematical logic. e problem was that not all computer scientists
were convinced that automata theory had any direct inuence on, or relevance in,
the design, implementation, and understanding of real computational artifacts. As
Maurice Wilkes, one of the pioneers of automatic computing, put it in an informal
talk delivered in , one did not need to know automata theory to build physical
computers, algorithms, or software. is can be contrasted, he remarked, to the re-
lationship between Maxwell’s equations in electromagnetic theory and radio engi-
neering. If one wanted to design a radio antenna, Wilkes said, one had better know
something about Maxwell’s equations. Automata theory had no such linkages with
much of the rest of computer science (including numerical analysis).
Moreover, there were substantial parts of the computational paradigm that at the
end of the ’s did not seem “scientic” at all. For example, a substantial part of com-
puter architecture, the branch of computer science concerned with the functional
structure and design of computers, was essentially a heuristic, craft- like discipline
having little theoretical content atall.
So also in the realm of programming:Even though there was recognition that this
entailed a whole new kind of artifact (liminal in the sense Ihave used here), deserving a
name of its own— ”software,” coined in the mid- s— there was a perceptible sense of
inadequacy about the way programs and software were being designed and implemented.
In , the term “software engineering” was invented to indicate that software had
evolved to a level of complexity that demanded the same kind of intellectual respect
that was accorded to the artifacts civil, mechanical, and other contemporary branches
of engineering dealt with. Yet it was far from clear what shape this respect shouldtake.
Programming languages— abstract artifacts— had reached a more scientically re-
spectable state by the beginning of the second age. In particular, the ’s decade was
rich in its advancement of a theory of the syntax of programming languages, con-
cerned with the rules governing grammatically correct forms of programs expressed
in programming languages. But semantic considerations— what the elements of a pro-
gramming language meant and how to characterize their meanings, how language
implementers could unambiguously and correctly translate programs in a given lan-
guage into machine- executable code, how programmers could objectively interpret the
meanings of language elements in the course of writing programs— were a dierent
matter. eories of the semantics of programming had indeed emerged in the late ’s,
but very little of these theories had been adopted by the designers and implementers
of “real- world” languages and industrial- grade software. Instead, these designers and
implementers resorted to natural language and informality in dening the semantics
of their programming languages.