Communications of the ACM
Forum
Forum
Chenglie Hu's Technical Opinion "Dataless Objects Considered Harmful" (Feb. 2005) is a breath of fresh air in a world gone overboard with the notion that only one toolthe objectcan be used for every programming task.
Objects are indeed extremely valuable in certain situations. I was taken by Simula in its heyday and do not recall a software project since then that did not benefit from the OO paradigm, or would have, had it been available.
But just as a hammer is not the right tool for every job, neither is an object. Hu rightly pointed out that when an object contains no data, its use only confuses things. Procedures are even more fundamental to programming than objects and methods. Even if every problem were coded using sometimes dataless objects, the fact is every method is procedural to its core. No object "knows how" to do anything until a programmer writes the procedural code of its methods. Each invocation of these methods is procedural, too.
Between procedure-oriented and OO lies the forgotten paradigm of "module-oriented," introduced by D.L. Parnas more than 30 years ago in his article "On the Criteria to Be Used in Decomposing Systems into Modules" in Communications (Dec. 1972). A collection of procedures, types, and anything else you care to declare are grouped together, along with an information-hiding facility. Most examples allegedly showing the superiority of OO are in fact MO.
Think about Modula-2 and Ada 83. No OO proponent would call them OO languages, and rightly so; they lack inheritance, polymorphic variables, and dynamically dispatched method calls. Yet their modules handle most of the examples with all the benefits attributed to OO. Like dataless objects, objects that are really only modules further confuse the issue.
Moreover, even degenerate objects serving as pseudo-modules are frequently inferior to true modules, because the object insists on having (or being) exactly one type. Sometimes no type (such as a library of pure functions) is needed. Occasionally, several types (such as a graph package with nodes, arcs, and graphs) are needed.
Programming is a complex task that must overcome a variety of problems. It calls for more than one tool. We should be teaching students to use the right tool for the right job, not a hammer for everything.
Rodney M. Bates
Wichita, KS
Chenglie Hu's Technical Opinion (Feb. 2005) made several excellent points. For example, his statement that "teaching dataless objects fundamentally defeats the notion of teaching objects-first" can be generalized as "teaching dataless objects fundamentally defeats the notion of teaching objects."
In addition to the four reasons Hu cited for teaching procedural programming, the most fundamental, and obvious, is that OO programming is impossible without procedural programming.
Finally, his advocacy of teaching multiple programming paradigms is entirely correct. Too often, harmful religious wars erupt because zealots take extreme positions at the expense of proper balance.
Alex Simonelis
Montreal
Chenglie Hu's Technical Opinion (Feb. 2005) was very helpful. I'm teaching Java at the high school level for the first time this semester, to students who have had a semester of Visual Basic.
Our Java textbook's "Hello, World" program seemed unsatisfactory to me, but I couldn't figure out how to improve it. Then along comes Hu's column, two days before the first class. Its excellent "Hello, World" stimulated a great discussion on OO programming.
David Armstrong
Stoneham, MA
Computing Is Mathematical Engineering
Like me, Jon Crowcroft's Viewpoint "On the Nature of Computing" (Feb. 2005) ponders the nature of computing. I began my career as a mathematician, straying into computing almost by accident. I never considered math a science and haven't felt that computing is either. My favorite aspects of computingprogramming language semantics and user interface designlink rather with linguistics and psychology.
I came to my own conclusion when my daughter began a degree program in mathematical engineering. Although she was studying the math behind civil and mechanical engineering, I felt "mathematical engineering" described the true nature of computing. Chemical engineers build things from chemical components, and electrical engineers build things from electrical components. What we do in computing is surely mathematical engineering, in that we build things from mathematical components (call them "virtual" if you like).
Most of us in computing have little understanding of math, but the things we build obey the laws of mathematics rather than any other set of laws.
Robin Evans
Reading, U.K.
Software is essentially thought put down in a particular format dictated by both the machine and language. It is therefore "virtual," as Jon Crowcroft pointed out in his Viewpoint (Feb. 2005), but there are levels to that virtualness. For example, software controlling a guided missile contains analogues of the missile and its environment, or what might be called the empirical knowledge of the factors governing the missile's physical behavior (such as gravity and wind resistance). It also contains application-related knowledge defined by the missile's construction (such as how it moves when its control surfaces are adjusted). Finally, there is discretionary knowledge (such as how one part of the missile's software communicates with another part of its software). This knowledge representation is not arbitrary, though no particular representation is "correct."
The VM systems Crowcroft cited are the application of frameworks to this discretionary knowledge. But, like programming languages, these frameworks can themselves be discretionary. The lack of an empirical basis has led to problems rationalizing the use of one approach over another. All software abstractions, discretionary or not, can arguably be traced back to analogues of real-world attributes. While they may be arbitrary in design, they exist for a purpose that is identifiably outside of themselves, though still traceable back to the external attributes.
Psychologically, there are quite recognizable limitations on software forms that are not external at all; they are driven by constraints on our intellectual processes. Our written languages are linear strings because this is how a certain part of our brains works. Most programming languages work in a similar way. Even the linear digital architecture credited to John von Neumann also, arguably, recapitulates the brain's function.
We experience problems when our chosen representational form contradicts the needs of the system. Our languages are significantly limited as understanding mechanisms; using a small, sequential, single-tasking mechanism inhibits or even prevents our understanding of anything other than small, sequential, single-tasking things.
Problems arise when the way the language works doesn't fit the way the system works. But our language formats are a function of limitations in our own cognitive processing.
Perhaps we are looking in the wrong place to understand the principles of software engineering? Besides looking around us for guidance on how to build software, we must also look inside ourselvesat our understanding of mechanisms. We must divide software into objects and classes, not because that is how the world is arranged but because that is how we interpret how the world is arranged.
The primary forces driving software engineering may be internal, not external.
Phillip G. Armour
Deer Park, IL
The age-old art vs. science vs. engineering debate is still not settled. The Viewpoint by Jon Crowcroft (Feb. 2005), along with an article by Alan M. Davis, "Art or Engineering, One More Time" in IEEE Software (Nov. 1996, comparing software development to custom home design/construction), help address it very nicely.
Boundary setting is indeed critical. Since anything is potentially possible in software, people expect anything to be possible. Limits in tools, technology, and human comprehension become difficult to justify or accept (and deal with). Someone always seems to be saying, "If you can't do it, I'll find someone who can." And someone always says "I can," because the boundaries seem to have no (lasting) reality to them.
This affects the quality of results, given that, when a boundary is approached, failure to go beyond it is often simply a matter of will. That is, if one cannot exceed (or ignore) the boundary and produce a result in spite of it, it is because one did not try hard enough or do his or her best. This puts a moral overtone on what ought to be a matter of professional (engineering) judgment.
Scott Duncan
Ellerslie, GA
Blog on Blog
The blogs described in "Why We Blog?" by Bonnie A. Nardi et al. (Dec. 2004) demonstrate why the Internet represents a revolution in human communication. The network is a great place to inform and to be informed, and the presence of multiple voices and points of view is a central aspect of objective thinking.
Blogs allow us to be in touch with the people who care to read the things we care the most about, and whose posts we're just as eager to read, sharing their joy and pain.
Bloggers write whatever comes to mind yet have no idea who will read it, a sense of freedom many of us find liberating. Although bloggers are their own editors, their personal freedom online also involves some amount of responsibility. Bloggers make commitments not only to post and update regularly but to read other people's blogs, send comments, and respond to comments.
Improving the quality of blogspace will help make it both a means of expression and of scholarship.
Hong-Lok Li
Vancouver, BC, Canada
©2005 ACM 0001-0782/05/0400 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2005 ACM, Inc.
No entries found