Peter is chair of the graduate computer-science department at Rivier College in New Hampshire. He can be contacted at varholp@alpha.acast.nova.edu.
I recently came across a new printing of Why Computers Still Can't Think, by Hubert Dreyfus, which explores the technical limitations of computers before leaping to the ambitious (and dubious) conclusion that trying to make computers appear intelligent is a waste of time and money. Since I'm more used to extending my imagination than limiting it, I turned to two books whose purpose was to guide and direct intelligence, whether human or machine. Between the two books, I found a much more positive perspective on the future interactions between people and computers.
I confess to losing respect for "psychologists in computing" after being one of them. For the most part, the psychologists in computing I knew could not be bothered with learning about the technical limitations and opportunities afforded by hardware and software (they were, however, more than happy to collect paychecks equivalent to those of their engineering counterparts). That's not to say that there isn't a role for specialists who can bridge the gap between the human mind and the computer processor. While software moves closer to the human way of perceiving the world, software developers continue to lack a good conceptual model of human thought that can assist us in making design decisions.
Donald Norman, once professor of cognitive science at the University of California at San Diego and now an Apple Fellow, doesn't pretend to have just such a conceptual model in Things That Make Us Smart: Defending Human Attributes in the Age of the Machine. However, Norman does point out some rather remarkable things about the way humans think and work, and how computers can be used to complement rather than detract from our natural traits.
Norman begins with a simple distinction between experiential and reflective modes of thinking. Experiential thinking concerns the lessons we learn from experiences--lessons which are usually learned and applied with little or no delay, and no conscious thought behind them. Reflective thinking, on the other hand, involves reasoning out a situation that may not have been encountered before, and making an evaluation and a decision based on that evaluation.
This distinction affects people's use of software if the software requires them to reflect when they should be experiencing and experience when they should be reflecting. Desktop publishing, for example, didn't become popular until we could immediately see on the page the impact of a design change, rather than trying to picture the result of a change in our minds as we typed in the formatting characters.
The way we represent information determines how the user makes use of technology. Different designs can force users into specific ways of working that rarely get noticed. For example, while Windows can be used without a mouse, very few bother without some kind of pointing device. The graphical display almost demands a way of moving the pointer in ways other than those defined by the cursor keys. A spreadsheet, on the other hand, has a basic design that's so flexible it can be used for a wide variety of activities for which it was never intended.
What lessons does Norman provide for software developers? The answer is in his last chapter, which distinguishes between hard technologies--those that are inflexible and require the user to adapt to their way of working, and soft technologies--those that adapt to and complement the way people work and think about things.
How important is it to distinguish between hard and soft technologies when designing and building software? It may make the difference between a successful product and a failure, and it may not always be possible for the developer to consciously distinguish between the two types of technologies. How many times have we felt that we have "conquered" or "mastered" a particular software package, when in fact it should have eased its way into our style of working, while we were unconsciously adapting to its perspective on our problem?
Unlike Norman, I don't blame the technologists, or anyone else for that matter, for producing computers and software that are difficult to use. In the beginning of the computer era, computers were impossible to use for just about everyone. They had little power to spare from their number-crunching activities, and most knowledgeable people believed that they would always be run by specialists for very specific purposes. There was little understanding of or need for the distinction of hard and soft technologies. They were all hard because of the limitations of the technology and how we thought about it.
As computers became more powerful and less expensive and gained a foothold on the desktop, software developers responded with products that became easier for individual, nonspecialist users. Today, software has to be graphical to survive, while the very best software is making a few tentative efforts at working in a way that makes it appear less of a tool and more of a semi-intelligent assistant.
All this means that people like Donald Norman have important lessons to impart that software developers are not always aware of. In software development, we rarely design with the idea of a sensible division of labor between the human and the computer. Norman points out that we can learn valuable lessons from looking at why people do certain activities the way they do, and try to support it with computers, rather than try to replace it with something better.
Like usability engineering, fuzzy logic is a field that has not achieved widespread acceptance, despite the cheerleading efforts of Lotfi Zadeh and Bart Kosko. The problem is that it sounds too much like yet another theory of probability, and its proponents are terribly defensive as they try to explain how the two differ. Nevertheless, there is a certain appeal to being able to program a computer using a type of logic that seems to map directly into the imprecise notions of how people think and communicate.
I began reading The Fuzzy Systems Handbook fully expecting a nuts and bolts account of assembling fuzzy constructs. The book did contain a C++ disk, after all, and had code examples of just about every type of fuzzy concept. I was pleasantly surprised to find a lucid, engaging discussion on just why fuzzy sets were good at representing human reasoning processes.
In one sense, The Fuzzy Systems Handbook is a true how-to book on constructing fuzzy systems from scratch. Each concept, from the mathematical constructs of fuzzy sets to the fuzzy-membership function, is described, illustrated, and coded into a working example. The code is presented in the text and on disk, so you can examine it as it runs. Even better, the code is of high enough quality to be integrated into your own programs, letting you quickly build fuzzy models into new and existing applications. Several months ago, for instance, I began writing a set of fuzzy-operator libraries for my visual simulation language. I simply substituted Cox's code for mine and ended up with more capable and robust functions.
However, the book goes well beyond the code to give you a sense of how fuzzy logic emulates human thought. There is no preaching, as is Bart Kosko's tendency when describing fuzzy thinking as the "universal truth," but rather a practical discussion of why it can be a useful computational model for imprecision. As I read the text and ran the examples, it became clear that fuzzy systems are an attempt to adapt the Boolean nature of computers and computer programming to the imprecise nature of many human activities.
The word "warm," for example, has different meanings to different people and under different circumstances. Yet people understand well enough the concept of warm so that it need not be more precisely defined. Fuzzy systems also understand the concept of warm by defining a membership function across the possible range of temperatures that connotes the degree of "warmness." By using ordinary set operators such as union and intersection (with their own fuzzy definitions), fuzzy systems can manipulate these concepts to produce evaluations and decisions that might not be normally possible with software.
Cox starts with some of the simpler concepts, such as fuzzy-set operators and membership functions, and uses these as a foundation to progress into fuzzy reasoning, fuzzy models, and the fuzzy-system life cycle. Several example projects are included that enable the reader to assemble working models of integrated fuzzy systems. At every step, Cox describes the concept, relates it to previous concepts, and shows you the code. He works with Borland C++, but does not make use of any object constructs, so it may be possible to work with any ANSI C compiler.
The Fuzzy Systems Handbook is best read beside your computer. The disk is full of C++ examples and demos, and examining, compiling, and running them while you're reading about them is just about the best way of learning. Possibly the best thing about it is that, unlike most how-to books on new or esoteric subjects, The Handbook of Fuzzy Systems does not require you to buy yet another book to understand the background behind what you've just done.
Hubert Dreyfus bases many of his arguments for the limitations of computers on a dichotomy between things that people do well and things that computers do well. Norman recognizes a dichotomy too, but instead of adhering slavishly to it, he uses the dichotomy as the starting point for weaving together the strengths of people and software to get more than is possible from either one individually. For their part, fuzzy systems question the very existence of such a dichotomy, or at least demonstrate that it may not be where we think it is. In any case, both Norman and Cox provide fitting responses to Why Computers Still Can't Think.
Copyright © 1994, Dr. Dobb's Journal