The Limitations of Conventionaal Computer Techniques

The Limitations of Existing Computers Techniques
Selected Quotations
by C. F. Reynolds
English Electric Computers – Internal Report

The attached selected quotations emphasise some of the limitations of existing computer techniques and their cost. They also point to the areas in which it is believed that DORIS [CODIL] will be of greatest value.

“Machines can't think,” said he, “because stupid humans don't know how to teach them to think. We try and teach them as we think machines should be taught, and it doesn't work.”

He stressed the fact that humans use knowledge acquired from literally millions of sources .to do what we call thinking, but that we do not yet understand the relative values; of tradeoffs between logic and knowledge. Until we have investigated that a bit further, our machines will not 'think' we1l.

Dr. Seymour Papert, M.I.T., Speaking at the 1st Annual Symposium of the American Society for Cybernetics, 26th October 1967. Quoted. in Computers and Automation, December 1967, page 18.
 “Although in a great many places information is still being stored. on ordinary filing cards. ... the development of the computer has presented an attractive but deceptive means of handling information. I use 'deceptive' quite deliberately, because the power of the computer has 1ed many to assume that the machine will somehow undertake for us the intellectual tasks of understanding, analysing, and piecing together required information from a mass of other information. ... ... Because all these intellectual processes are to a large extent carried out without clearly specified conscious procedures, they have received little detailed examination and have indeed been largely overlooked. With the increasing use of machines, this necessity of intellectual operations has again been overlooked, perhaps because their role in manual methods was insufficiently appreciated, perhaps because the difficulties of improving intellectual methods seemed too formidable, or perhaps because too naive a view was taken of the capabilities of the machine.”

"If the computer is indeed the appropriate machine for our purposes (and it is, of course, the only available machine with sufficient power at present), then  new techniques would appear to be needed ... ... Is it possible that a special purpose machine of a different type will eventually have to be devised for information storage and retrieval? For my part, I can only hope to make clear the semantic features of information handling. The rest I leave to the electronic engineers.”

J. Farradane, City University, London, “The Problems of Input and their Inplications in Mechanization”, in Information Storage and Retrieval, Volume 4,t page 251, 1968.

The Systems Dilemma
“The ultimate success or failure of computer systems at present is overdependent on the problem definition and system design stage, The desire to simplify systems leads to a conflict between the needs of people and the computer specialist's interest in containing the project within present methodology. It is at this stage that the weight of Scientific Methodology and Management Theory is thrown at users to intimidate then quite unreasonably and with disastrous effects into a definition of their needs and function. It is at this point that so often the die is cast in favour of assumptions which lead to irrelevant systems. The flaw which underlies this approach is to treat the design of information systems as an engineering project with fixed design parameters. This is the last way it should be treated, however, for its purpose is to make a company responsive, flexible, and aware of its commercial situation. It is unlikely to do this without these characteristics being implicit in its design. This requires development to be carried out at a higher level than “application systems”, indeed at a level which can accommodate changes without extensive restrurcturing.”

Wesley M. Davies, Systems Technology Department, The Steel Company of  Wales Ltd.  The Conceptional Stage in Planning a Company Information System.”. Read at I.F.I.P. 1968, page F.1.
“We are pushing against the limits of complexity that we know how to handle. Never before have programming projects of such a degree of complexity been seriously attempted. as those that occur today in software development and in a few specific applications.”

“Computing has many frontiers; the one of speed was emphasised earlier. But many programs that tax the speed of our fastest computers can be programmed with a moderate effort. They are of the same kind of problems as those for which computers were originally designed: 1ogically simple but computationally hard. However, we also run into problems that are commputationally light but also so complex that we do not know how to design, document, and debug them. This kind of problem is relatively new. But since we also face these difficulties when we are trying to expand the use of the traditional scientific computation type (short code, long run) - problems that are potentially among the most challenging applications of computers – this complexity barrier may well be the most important limitation that the computer field will be subject to in the immediate future.”

J. Nievergelt, “Computers and Computing - Past, Present and Future". I.E.E.E. Spectrum, January 1968.
“Within the last year of two the “Total Systems” philosophy, which has held sway for over half a decade, has come under heavy attack. In an article published early in 1965 it was suggested that the pressure to integrate has gone too far; that systems designers were so busy trying to produce such completely integrated systems that they were getting nowhere, and indeed. where results were being produced they were both too cumbersome and too inflexible to be of much lasting benefit. Like the leviathans of pre-history the seeds of their destruction lay in the inertia of their vast bulk”.

A.G. Barclay, C.A., “An Examination of Three Causes of Limitations in Present Computer Applications”, The Accountants Magazine, December
1967, page 593.
Reference is to: John Dearden, “How to Organise Information Systems”, Harvard Business Review, March/April 1965, page 65
“We should be positively looking for and developing programming methods that do a1low inconsistency, redundancy, ambiguity and incompleteness; we should recognise that these seem to be vices only because the error-prone techniques of procedural programming make them so.”

“But allowing that we need. no longer call them vices doesn't in itself make then virtues. It would be ludicrous to complicate our dp systems by wantonly introducing confusion ancl inconsistency into situations where none existed before; and we must recognise that some problems can only be solved by extreme rigor and precision. My theme is concerned with those situations where confusion and inconsistency are inherent elements of the problem and where we cannot hope to write successful programs unless we are able to deal properly with these factors.”

M. A.Jackson, John Hosklms and Co Ltd., "The Need for Imprecision”, Datamation, February 1968, page 143.
Ultimately all computer production is meant for human consumption in some form or another. Will it be possible to have machines working for us and having them doing things for us, then it must be simple to control them. I would almost say that sinplicity is the keynote of my talk, In many of the present day programming languages and their compilers this is not reflected. There is a seemingly natural tendency to put all features into a compiler that arise out of some pragmatic need, instead of a tendency to unify the concepts. One provides the user with a rich choice of possibilities. It is 1ike providing a machine with 16 index registers because 16 wi1l perform better than one single. But a little sophistications and generality make available all locations as index registers. I can express this in the 1aw of good numbers. There are but three good numbers: zero, one and all. Any choice in between has that arbitrary element: why just 16?"

W. L. Van Der Poe1, “The Software Crisis, Some Thoughts and Outlooks”, I.F.I.P. 1968
“McClure spoke as a programming expert and listed some of the things that we had. not done with programming languages. His list included:

Combination of simplicity and generality
Generation of efficient code
Having an influence on machine design
A deeper understanding of data
Simpler operating systems
Setter de-bugging facilities
An understanding of command languages.”

Robert M. McClure, Scientific Contro1 Corporation, Da1las, “Whither Programming Languages”, Panel Discussion at Fall Joint Computer Conference, 1967 as reported by Dr. Pinkerton in diary note dated 12.12.67.
“In terms of technical achievement, the computer revolution in U.S. business is outrunning expectations. In terms of economic payoff on new applications, it is rapidly losing momentum. Such is the evidence of a new study by McKinsey and Company of computer systems management in 36 major companies.”

“From a profit standpoint, our findings indicate, computer efforts in all but a few exceptional companies are in real, if often unacknowledged, trouble. Faster, costlier, more sophisticated. hardware; larger and increasingly costly computer staffs, increasingly complex and ingenious applications: these are in evidence everywhere. less and less in evidence, as these new applications proliferate, are profitable results. This is the familiar phenomenon of diminishing returns. But there is one crucial difference: As yet, the real profit potential of the computer has barely begun to be tapped.”

“The distribution of costs which go to make up total computer expenditures is, however, fairly consistent among the companies participating in our study. Of every $100,000 of total computer expenditures about $35,000 goes for hardware: $30,000 for computer operations staff payroll; £15,000 for maintenance programming (i.e. Keeping current systems updated); and the remaining $20,000 for development programming and other staff time devoted to new applications.”

McKinsey & Co., New York, “Unlocking the Computers Profit Potential”, 1968

No comments:

Post a Comment