American Scientist

To the Editors:

Brian Hayes's Computing Science column is always a favorite of mine, but I would like to present a different slant on three distinct issues in "The Post-OOP Paradigm" (March–April).

He cites the proof of Corrado Böhm and Giuseppe Jacopini as showing that the idioms of structured programming are "sufficient to express essentially all programs." What they proved is quite different: that structured programs could express essentially all algorithms. A workaday program, especially when involving human-machine interfaces, often does not represent an algorithm and is not equivalent to any Turing machine or recursive function. This has interesting implications about the set of problems that are solvable by computers—and by human minds insofar as they are biological computers. For example, if a computer were merely a Turing machine, then it would represent a formal system, and would be limited in what it could in principle prove in accord with Gödel's famous theorem.

Hayes found much to admire in object-oriented programming (OOP) languages in that they express "interactive software with a graphical user interface." Unfortunately, current OOP languages and operating systems enforce a particular and narrow style of graphical user interface that is far from optimal. To do better requires stepping outside their paradigm. Also, the inherent elegance and simplicity of OOP is undone by having to learn the myriad classes that arise in practical applications. Then, too, some simple tasks just cannot be done with OOP, forcing the supplemental use of more "primitive" languages.

Lastly, Hayes suggested, "Surely the most obvious place to look for help with programming a computer is the computer itself." Surely not. The first discipline to look toward in designing a programming language is not computer science but cognetics (applied cognitive psychology). A new class of better programming languages will arise when cognetics is applied from the first.

Jef Raskin
Pacifica, California

To the Editors:

I was a little disappointed with "The Post-OOP Paradigm." Although the article presents an admirable summary of the object-oriented programming paradigm and its precursor, the procedural paradigm, it did not present the promised "next big idea." Instead, Hayes reviews technologies which only, to use his words, "refine," "improve" or "reinvigorate" OOP. In my view, none of the technologies described in the article represent a new paradigm, in the way that OOP supplanted the procedural paradigm.

It could be argued that generic programming, a technology not mentioned in the article, is a possible candidate for a new paradigm. Generic programming can be defined as programming with concepts, a "concept" here being "a set of requirements on datatypes."

I also take issue with Hayes's assertion that "OOP is not just a different solution; it also solves a different problem." In my view, it is more correct to say that OOP solves more problems. While interactive graphical user interfaces were important initial applications of OOP, the fact is that OOP has been exploited far more widely, and is used regularly in almost every realm of software development.

William B. Rubin
Quality Object Software, Inc.
Poughkeepsie, New York

To the Editors:

Like Brian Hayes, I grew up with machine-level programming, assembly language, and so forth, until I retired. I have a very strong feeling for what programming should do, even though I can now hardly keep up with all the advances and what programmers should do.

In regard to the former, it should do the job as quickly and efficiently as possible. That may mean that it can't do all jobs, either quickly, efficiently or both. As Mr. Hayes showed with his elegant polygon example, all-purpose programming can easily grow out of hand. In contrast to that, a very small, special-purpose program, no more than some 400 bytes, such as the recent Slammer worm, can very swiftly involve most of the world's Internet capacity.

In regard to programmers, it is paramount that the programmer know exactly what the job is. We used to start with flow diagrams and other directions. I was taught to write the program in English first, knowing that if I couldn't do that, I couldn't write in PL1 or cobol. When the programmer knows the requirements with precision, the programmer must convince management of the best route.

The requirement of knowing the exact job leads naturally to extreme programming. As I and others see it, a customer and a programmer sit down at the keyboard, then review the trial runs, as one being with two minds. Each should know exactly what each module does and how it does it, the programmer in C++, Java or whatever, the customer in English. That way you avoid a lot of "oops."

Bernard W. Joseph
Clinton Township, Michigan