✍ Scribed by John McDermott
No coin nor oath required. For personal study only.
The R1 paper [7] claimed that the following two lessons emerged from our effort to develop a computer system configurer:
• "An expert system can perform a task simply by recognizing what to do, provided that it is possible to determine locally (i.e., at each step) whether taking some particular action is consistent with acceptable performance on the task." • "When an expert system is implemented as a production system, the job of refining and extending the system's knowledge is quite easy."
If I had the paper to write over again, I would claim that three lessons emerged from this research.
One of the three lessons is the first lesson mentioned above; the paper almost got that lesson right, but as far as I can tell, failed to convince anyone that it is important. The second lesson mentioned above is a wildly simplistic formulation of another lesson that continues to emerge as R1 grows in size and shape; a better formulation of the second lesson is that today's most commonly touted programming heuristics (also known as "good software engineering principles") must be made substantially less parochial before they can be followed to develop and maintain a system like R1. The third lesson is that if usefulness is the primary criterion of success for an application program, then R1 didn't become much of a success until several years after the R1 paper was written.
📜 SIMILAR VOLUMES