This false belief is based on a confusion between form and content. A rigid grammar need not make for precision in describing processes. The programmer must be very precise in following the computer grammar, but the content he wants to be expressed remains free. The grammar is rigid because of the programmer who uses it, not because of the computer.
The programmer does not have to fixate the computer with particular processes. In a range of uncertainty he may ask the computer to generate new procedures, or he may recommend rules of selection and give the computer advice about which choices to make.
Thus, computers do not have to be programmed with extremely clear and precise formulations of what is to be executed, or how to do it. The argument presented here is not specifically about "design," but about the general question of what we can get computers to help us do.
For a number of reasons, it is customary to underestimate the possibilities. To begin, I want to warn against the pitfall of accepting the apparently "moderate" positions taken by many people who believe they understand the situation. It is easy to understand why a humanist will want to rhapsodize about the obscurity of thought processes, for there is an easy non sequitur between that obscurity and the desired an anthropomorphic uniqueness.
But this isn't the non sequitur important here. The fallacy under discussion is the widespread superstition that we can't write a computer program to do something unless one has an extremely clear, precise formulation of what is to be done, and exactly how to do it. This superstition is propagated at least as much by scientists—and even by "computer scientists"—as by humanists.
What we are told, about the limitations of computers, usually takes this general form: "A computer cannot create. It can do only exactly what it is told. Unless a process is formulated with perfect precision, you cannot make a computer do it.
In the September issue of Scientific American , I discussed three programs: one is the checkers program of Samuel, which plays at the master level. Mary is twice as old as Ann was when Mary was as old as Ann is now. If Mary is 24 years old, how old is Ann? In that article I was concerned with problems of going further, to extend such work in the direction of more versatile general intelligence.
But for my purpose here, they can serve as adequate examples even in their present state, for while limited in what they can handle, they already do enough to confound the old comfortable superstitions. The old view is that a program is "nothing but" a set of rigid rules for exactly what to do in each situation. This is indeed a useful point of view for reassuring beginners at programming, or for analyzing the programs written by beginners. However, for more advanced processes, while "perfectly" true in one sense, it would be as correct to say that "houses are nothing but arrangements of construction materials" or "books are merely long strings of words.
Let me begin by discussing one of the skeptical attitudes that is derived from some statements of good logicians and bad philosophers. But this is not a logical consequence, for it is based on a careless technical oversight. People are not this consistent, and there is no reason whatever why we should feel constrained to build our machines along such lines. Instead we can, and already do, build machines that can tolerate contradictory factual assertions. To do this, we have to add selection rules for resolving contradictions, priority hierarchies for choosing between incompatible statements, and the like.
Here is an example of a dialog with that program:. When they are on the same level, the program simply rejects the later statement, as seen here:. But of course Raphael could have written some other priority rule. Incidentally, the program's statement, "The above sentence is ambiguous I will describe this later in more detail.
Programming provides us with new tools to express ourselves. We now have intellectual tools to describe "how to" as well as "what is. For example, one often… Expand. View on ACM. Save to Library Save.
Create Alert Alert. Share This Paper. Topics from this paper. Electrical engineering Debugging Universal quantification. Executable Programmer Marvin robot. Computer language. Citation Type. I believe that open-ended evolution would be the ultimate form of a program impressing the programmer.
Though only evolving within the frame imposed by the programmer, such a program would create endless and more complex novelty. To constrain the behavior of a program precisely to a range may be very hard, just as a writer will need some skill to express just a certain degree of ambiguity. A computer is like a violin.
You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists.
Neither is a violin, or a typewriter, until you learn how to use it.
0コメント