Forum

This letter is in response to Rachid Guerraoui and Mohamed Fayad’s "Thinking Objectively" column (Aug. 1999, p. 125). Although the discussion gives a clear, if somewhat abbreviated, description of OO design principles, there are a number of issues I have found troubling in attempting to apply these principles in practical situations.

I am somewhat in defense of the OMG approach, as well as the OO wrapping approach, which I believe is a pragmatic way to progress toward solving very complex problems.

As a physical scientist, I find the most useful models we develop have transformative potential. When we examine sand, for instance, we see silicon. When we develop a solid-state model of purified silicon, we see the potential to transform sand into machines capable of Boolean cognition. Elaborating that potential into an industry has led to the development of concepts, principles, and entities nonexistent before this potential was recognized.

Information technology has a profound influence on our social and economic institutions, redefining our private and working lives. Just as the conceptual universe of the semiconductor engineer would be largely foreign to the electrical engineer of the 1930s, we may find concepts of personal responsibility and community will be inappropriate in the world our grandchildren will know. Intelligent agents will assume a great number of our responsibilities. And collaborative virtual environments will greatly expand the scope and reach of our social activities, while limiting our kinesthetic association with our partners.

A consequence of the transformative process is that any conceptual partitioning becomes tenuous. Fortunately, as silicon makes clear, stabilizing interfaces allows components to evolve on either side of the interface, and allows an orderly migration of infrastructure to new interfaces when it becomes clear which technologies provide the greatest value.

For example, the coexistence of pulse and tone telephone dialing, or copper/fiber-optic/atmospheric transmission, with investment in switching and signaling, allow improved services and performance through an organized process of replacement.

I believe the strategy of the OMG and many of the CORBA service providers reflect this reality and vision.

Whichever approach is taken, OO theorists should address certain challenges, as they are the roadblocks implementers will eventually face. Challenges include:

• What leverage does OO technology provide for recognizing the points of engineering stability around which we can establish interfaces?
• As conceptual models change, will it be possible to refactor systems so a gradual conversion from one object model to another object model can be accomplished gracefully ? If not, are interfaces the only point of departure for analysis?

My experience as a practitioner has been that, while OO implementation is a well-considered manifestation of Parnas information hiding, OO design strategies have limited leverage in transformative problem solving. This requires representations describing programs as cause-and-effect networks that accomplish an intention. The following principles are key:

• We must distinguish clearly between subject and object (in a grammatical sense) or, alternatively, roles and context/values (in an operational sense). This distinction reflects the differentiation in design between mechanism (which is manufactured) and effect (which is a transient manifestation of the mechanism’s behavior).
• To adequately understand system behavior, we must find representations that give equal weight to data and control graphs. At all cost, we must avoid flattening the graphs in a way that encourages us to believe system behavior can be understood from a representation that exhibits only control or messaging sequence.

I apologize if I am misreading or misinterpreting the authors’ words, but in the third section of the column I am left with the impression that no organized strategy can be applied to develop the conceptual partitioning organizing our engineering activities—except to hire really bright people. Our next great step—in the theory of software and systems design—must be to overcome that paucity of alternatives.

Brian K.E. Balke
Woodland Hills, CA

Back to Top

Educational Concerns

I read the four reports on educational technology ("Log On Education," Aug. 1999, p. 21) with a mixture of pleasure and apprehension. What was striking was the difference between the first two reports and the last two. Wayne Grant and Robert Tinker each tell of steps taken to make a technology that has had a considerable influence on science education—computer-compatible physical sensing probes—easier to use. With Palm adaptation by ImagiWorks (Grant) and the SmartProbe (Tinker), the goal is to make the technology transparent and keep students focused on the job at hand—gathering and analyzing data.

What a difference from the third story, by Jeremy Roschelle and Mike Mills. The conversation among the (mercifully) fictional students seems to be concerned almost entirely with the tools they use rather than with the scientific process. It is far from clear to me what the pedagogical point is here. Students use tools that seem to require a lot of fussing to implement a technique they don’t really grasp—understanding ordinary least squares requires a knowledge of both calculus and statistics. They are learning neither math nor science.

If this example is confusing, the final report, from Mitchell Resnick, Robbie Berg, and Mike Eisenberg, is baffling. How exactly was what must have been an extremely frustrating project for Nancy (building a Rube Goldberg contraption that didn’t work), a "rich learning experience"? What did she learn from this experience? Did she at least come to understand something about animal behavior and why her approach failed?

These latter two reports betray a fascination with the use of technology for its own sake that is threatening to become a real problem in education. Computers, graphing calculators, Vernier probes, and the rest are wonderful tools in their place, but they are dangerous when the tools themselves become the objects of study.

Steve Wildstrom
Technology & You, Editor
BusinessWeek
Washington, D.C.

I was amazed that Grant and Tinker did not mention that almost exactly what they discussed—miniature, low-cost handheld devices that sense pH, voltage, acceleration, pressure, and other physical parameters, conduct data logging and analysis and that can share results with other units and communicate results and methods to and from PCs—has been available commercially and used in schools for years.

One of these products, namely, the Texas Instruments line of calculators and associated data-acquisition modules, are programmable, have bit-mapped displays at the top end, and are otherwise well suited for most of the tasks described in the articles. They are less expensive than the PalmPilots suggested as a basis for the described activities (sometimes far less expensive; we bought a top-of-the-line Texas Instruments calculator, with alphanumeric keyboard, for $70).

In the next piece, Roschelle mentions the Texas Instruments product line briefly, but only with regard to its applicability to teaching mathematics.

Another inexpensive (under $100) and available technology for hands-on, real-world interfacing, at a bit more advanced level (middle school and up), is the BASIC Stamp and its accessories from Parallax (www.parallaxinc.com). Parallax has a useful curriculum that can be downloaded free (www.stampsinclass.com); its software is for IBM-compatibles but runs on Macs with a simple emulator. Also not mentioned is that it has been possible for some years now to connect LEGO products to both Macs and IBM-compatibles, allowing many of the experiments and interactions described to be experienced immediately, without waiting for any new technology.

I am pleased with new developments and glad to see PDAs and other products sprout interfaces that interact with physical phenomena, but it does a disservice to any educator or parent in search of such products not to mention the abundance of well-designed and practical solutions at hand.

(I have no affiliation with or financial interest in any of the products I have mentioned but have used them all with kids in activities much like those described in the column.)

Jef Raskin
Pacifica, CA

Back to Top

Building LEGO Robots

I was unpersuaded by Glen Henshaw’s letter about teaching more analytic solutions to students building LEGO robots ("Forum," Oct. 1999, p. 13). The source of my disagreement lies in the different goals intended. To me, the goal is not to make better robots or even to make better robot builders but to make better engineers.

People who work on the scientific end of the spectrum need to know all the theories; they are their tools. People working on the engineering end of the spectrum need to know ad-hoc methods; these methods are their tools when the theories fail.

To criticize these courses for not teaching all the relevant theories, and for using materials that demand ad-hoc methods, is to miss the point. They’re trying to teach budding engineers how to mess around with a messy problem in order to come up with a workable solution. Robots are just a convenient subject matter, not the essence. LEGOs mess up an already messy problem space so the theories, even if taught, don’t work. That’s why they’re good, not why they’re bad.

We have plenty of courses that teach all the relevant theories to budding engineers once they’ve decided what kind of engineer they want to be. What we lack are courses that teach how to solve messy problems of any stripe.

Pat McGee
Falls Church, VA

Back to Top