Frankston, Bob. Beyond Limits. Chapter 3, pp. 43-57 in Denning, Peter J., Metcalfe, Robert M. (eds.) Beyond Calculation: The Next Fifty Years of Computing. Copernicus Springer-Verlag (New York: 1997).
Last updated 2002-10-13-12:15 -0700 (pdt)
"Bob Frankston has long been interested in the possibilities of computers and the assumption that there must be something useful about them. He is best known for implementing VisiCalc (along with Dan Bricklin), the first electronic spreadsheet and the first program to make the personal computer a required business tool." - From the summary about the contributors.
Corbató's law is introduced (p.45):
- The number of lines of code is the same independent of the language used.
[This is an observation about the human grasp of complexity, suggesting that we are limited by the size of the program. As programming languages improve and increase the level of expressions, we can make more powerful programs in the same number of lines. We can attack more difficult problems because their programs are now within our grasp. -- dh:]
The term "a pride of programmers" is introduced (p.45):
"Projects that required innovation in too many areas at once were unlikely to succeed. The IBM 360 and the Multics project were notable exceptions and both experienced long delays in delivering on their promises. The lessons of why these programs were so difficult are still relevant today. Fred Brook's The Mythical Man Month applies to any complex system, not just a large pride of programmers."
Frankston points out a defect of the 1798 Malthusean Law on the limits to population growth (p.45):
- We are doomed to starve because population increases exponentially and food supply increases only linearly.
The defect is a failure to take into account the nature of change and innovation. In addition (p.46),
"With computers we have an additional element -- the computers themselves are direct agents in the process of innovation."
On the evolution of programming, Frankston makes frequent reference to the transition to descriptive programming. He makes an observation that I can certainly support (p.47):
"The challenge has shifted from providing the professional programmer with tools to providing the 'users' with the tools to interact directly with the computer. The original users of FORTRAN saw themselves as, and they were, scientists and engineers solving their own problems. ..."
Frankston echoes a theme that is consistent with Computer Programming for Everyone (CP4E), though with a particular solution in mind (p.47):
"As we've expanded the set of 'programmers' to include, potentially, anyone using a computer, we've also changed the nature of programming. Rather than specify a series of steps, one can give examples or a description of what should be done rather than the detailed steps of how to do it."
There is another statement that appeals to the direction programming must take (p.48):
"It is this ability to use the computer as an agent by 'programming' it with behavior that is central to the power of computing. It is important to realize that we have converted the user into a programmer, just as the phone dial converted people (users?) into phone operators. ...
"Just as there weren't going to be enough phone operators, there aren't going to be enough programmers to add the little bits of intelligent behavior we are going to expect of the infrastructure. And it is this limitation imposed by the need to specify behavior that is part of the upcoming challenge."
Frankston talks about moving from programming to problem solving. There are some juxtapositions I have not fathomed (p.49):
"At best, one can prove that two representations of an algorithm are equivalent, but that doesn't address the question of whether the program meets a vague requirement. The question is whether the program works properly in service of some larger goal. There may, in fact, be multiple conflicting goals.
"Rather than proving programs correct, we must make them simple enough to understand."
I don't see how this follows, lest it is meant to suggest that the correctness of a program should be evident a priori as a consequence of its understandability.
In discussing Occam's razor, Frankton argues that "simplification is our goal."
Then he says this approach won't work (p.49):
"But this begs the question since it just shifts the problem to finding the right representation, which is unsolvable in the general case, both because it reminds us that the nature of the solution is a function of the context in which the problem is being solved (ambiguity) and simply because it is a restatement of general problem solving."
So Frankston is led to the idea of iterating and improving a solution. He ends with this (p.49):
"When we have independent, interacting systems we don't necessarily have the option of recomposing them. This places a premium on getting an effective representation the first time, but inevitably, the initial solution will need to be adjusted as the situation changes. To the extent we can, we must be prepared for such change."
There is more here, building toward the notion of system resiliency, not system correctness, as the appropriate goal.
To be continued ...
created 2000-07-18-14:00 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 02-10-13 12:18 $
$$Revision: 6 $