- source
- Link
- tags
- Artificial Intelligence, Coding
- author
- Marvin Minsky
What can computers do?
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.
It is generally believed that computer programs cannot be more than a set of rules and instructions for what to do in a given computer state. While this is true, it falls into the common pitfall of thinking of the whole as the sum of its parts
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.”
Minsky discusses three ways to see a computer program
A program as a sequence of instruction to be obeyed
The most common and simple-minded view is that a computer program is a sequence of clear-cut operations to be performed on some data.
A program as a court of law
The author now gives an example program that can accumulate facts from user input. A disambiguation “part” of the program acts as a court, weighing different facts against previously accumulated knowledge and adding it to its database.
In large programs with many such subprograms, it is clear that the whole isn’t behaving like a sequence anymore. The programmer only constructs the laws and rules that will guide those courts but usually cannot predict or understand the details of operations.
For try as we may, we rarely can fully envision, in advance, all the details of [the subprograms’] interactions. For that, after all, is why we need computers.
A program as a collection of statements of advice
The great illusion shared not only by all terrified humanists but also by most computer “experts,” that programming is an inherently precise and rigid medium of expression, is based on an elementary confusion between form and content. If poets were required to write in units of fourteen lines, it wouldn’t make them more precise; if composers had to use all twelve tones, it wouldn’t constrain the overall forms; if designers had to use only fourth order surfaces no ‑one would notice it much! It is humorous, then, to find such unanimity about how the rather stiff grammar of (the older) programming language makes for precision in describing processes.
It is interesting to note that it seems that in Minsky’s mind, programming would have more flexible syntax in the future approaching natural language more accurately.
I think the following quote, referring to a “missionaries and cannibal” solving program, is impressive. The program tries several solutions and prefers those making progress towards moving people to the other side of the river. An outsider can tell the program if its making progress or not. This sounds to me like machine learning, which was in its early days at the time.
Some other function may have been modified so that, in certain situations, “progress” won’t get to evaluate the situation at all, and someone might get eaten anyway. If that happened, the outsider would try to guess why.
He would have the options (1) of thoroughly understanding the existing program and “really fixing” the trouble, or (2) of entering anew advice statement describing what he imagines to be the defective situation and telling the program not to move the missionary into the position of being eaten. When a program grows in power by an evolution of partially‑understood patches and fixes, the programmer begins to lose track of internal details and can no longer predict what will happen—and begins to hope instead of know, watching the program as though it were an individual of unpredictable behavior.
Programming is more than a bunch of instructions
In each domain of uncertainty I am at liberty to specify (instead of particular procedures) procedure‑generators, selection rules, courts of advice concerning choices, etc. So the behavior can have wide ranges‑it need never twice follow the same lines, it can be made to cover roughly the same latitude of tolerance that lies in the author’s mind.
A programmer, by giving instructions, is specifying a frame in which a program will develop. I believe most very interesting programs are actually creating something new that can be of interest to the programmer itself.
Data analysis is a simple form of this phenomenon. A programmer writes some code to extract word frequency from a piece of text, and get some insights he could not have got before. 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 take advantage of the unsurpassed flexibility of this medium requires tremendous skill‑technical, intellectual, and esthetic. 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. Computer programs are good, they say, for particular purposes, but they aren’t flexible. Neither is a violin, or a typewriter, until you learn how to use it.