Forum

I agree with Chenglie Hu’s "Viewpoint" "Just Say ‘A Class Defines a Data Type’" (Mar. 2008) that data types are of central importance in computer science and should be emphasized throughout the curriculum. In CS 2, I always dedicate a good number of lectures to abstract data types and their (algebraic) specification. Some students are initially resistant, but eventually most recognize that an "interface" in Java’s sense is not enough to explain what, say, a priority queue is, whereas an "implementation" (or "class") provides too much detail.

Motivating ADTs by examining "basic types" in a more abstract light, separated from their (accidental) properties in a given language or machine, seems to work well. One of the few advantages of C++ over Java is that "user-defined types" can be made to look exactly like "basic types," thus allowing for continuity.

A word of caution: Despite the educational and practical value of ADTs, an emphasis on them may be seen as "too theoretical" by some. If you indeed consider this route, be prepared for the inevitable discussions.

Finally, I offer three minor disagreements with Hu: Algorithms and data types are a "holistic whole," so there’s no need to separate them; variables are instances of an ADT; and just say "a class implements a data type."

Peter H. Froehlich
Baltimore, MD

Chenglie Hu’s point about "toy" objects in his "Viewpoint" (Mar. 2008) resonated with me. At the time I graduated from the U.S. Navy’s Nuclear Power Program in 1983, the classroom part of the course was a six-month cram session of 76-hour (or more) weeks. We spent the first three learning or reviewing a classic high school science and math curriculum, then moved into the physics, thermodynamics, chemistry, and mechanical engineering needed for us to understand and operate the systems comprising a nuclear-reactor propulsion environment. The only way to coherently tie all these topics together while moving this quickly was to use real data and real examples from working reactors. From beginning to end, we were exposed to real-world examples in our studies.

Even with real data, 75% of the people entering the program did not complete it. I can’t imagine even trying if we had only toy data and examples. I encourage all programmers and educators to weigh the benefits of using real-world examples in their courses in the interests of allowing a quicker and more complete understanding of the material.

Jack Cain
Santa Cruz, CA

I want to express my appreciation to Chenglie Hu for his "Viewpoint" (Mar. 2008). My experience trying to switch from the "pure-OOP" approach in CS1 has been an uphill battle. For example, my department still uses Byron Weber Becker’s Java: Learning to Program with Robots as the textbook for our CS1 students; while its value is recognized, it blurs most of the important elements for understanding how computers actually work. For example, how can these students be expected to "understand" a constructor with parameters before finally getting around to variables and eventually to methods in Chapter 6? One result is that we must find another way to teach them in CS2. I don’t mind having to use object-oriented programming in CS1, but we should not pretend that the algorithmic side of the road doesn’t also lead to solutions to real problems. As it is, even after a good part of the semester, the students might have learned only to play a poorly designed video game.

Chung-Chih Li
Bloomington, IL

I am an adult learner (age 57) just starting a Java programming course at the University of Phoenix, online. The first assignment was "Describe the difference between an object and a class." As you can imagine, the answers and examples were all over the place. After reading Chenglie Hu’s "Viewpoint" (Mar. 2008), I understand why he would not start students out with a discussion about objects and classes.

Of special interest to me was the approach he suggested for teaching programming. Has he used such an approach with his own students? Is it still too early to think about using it for teaching a class? Maybe Hu can write his own textbook to spell it out in detail.

Although I’m likely to have graduated before any changes are made that would help me learn programming, I want to know how this idea plays out so I could make appropriate suggestions to my university. The online discussions among students who have finished the Java courses there suggest they were taught in the best way possible.

I also checked out Hu’s Web pages at cscserver.cc.edu/chu/ and was amused to find that some of his students "might not have happily learned." I wish I could afford the luxury of attending classes in person instead of fitting them in online around a full-time job and family. I’m always happy to learn. The biggest lesson is that although the amount of knowledge I never will possess is enormous, I will never be deterred from trying to learn more.

Mark Hanna
Banks, OR

Author’s Response:

In their comments, Froehlich (while I respect his objections) and Li shared what has worked and what hasn’t in their respective classes. Cain shared an instance of how important real-world examples are to the learning process. And Hanna, as a novice, was still wondering about the best way for him to learn programming. The common thread is that educators must find ways to give their programming students a coherent learning experience. At the very least, they, along with textbook authors, must provide examples they are most likely to benefit from in their software-engineering classes.

Chenglie Hu
Waukesha, WI

Back to Top

Enforce User Compliance as a First Line of Defense

The article "The Myths and Truths of Wireless Security" by Alfred Loo (Feb. 2008) put too much emphasis on passwords. End users are known for their inability to use decent-strength passwords. Even expecting them to care about passwords aims too high. The IT staff must be reminded over and over of such user attitudes and behavior.

When my end users request changes in their passwords, they always want to know the minimum password length and whether they must include nonalphabetic characters. I tell them to use whatever password they want as long as it doesn’t have to be written down. I also tell them to use at least one element that changes between servers. The reason for not having to write it down is that most intrusions involving password guessing come from colleagues in the same organization, not from "professional" attackers. Meanwhile, they resist even basic schemes that go beyond the old (flawed) login+password schemes.

Confronted by security challenges, time-based tokens, one-time passwords, and the like, they politely listen to administrators’ security-minded arguments, then dismiss them as not feasible, imagining we don’t know the real situation or the true nature of an attacker’s motivation.

They think they simply don’t need a stronger identification scheme. In Mexico, banks are required to have such a scheme, though when money is not directly involved, users have been known to throw tantrums so they can keep using their everyday passwords.

Seeking to access a certain user’s data, an attacker might try to find vulnerabilities in the host system, revealing data about every user in the system, rather than guess probable passwords based on a particular user’s public profile.

Gunnar Wolf
Mexico City, Mexico

Author’s Response:

User resistance to doing more to secure a computer system is common. Ways to overcome it and enforce the organization’s security policies depend on support from top management, including the CEO.

Malicious hacking takes multiple forms, each involving its own level of technical skill and preferences for attack methods. However, none can ever be ignored. A single security breach might be fatal to an organization, as I described in my article.

Alfred Loo
Hong Kong

Back to Top

Clarify Object Identity in Object Schizophrenia

The article "Patterns, Symmetry, and Symmetry Breaking" by Liping Zhao (Mar. 2008) led me to explore the relationship between the object schizophrenia problem (OSP) and the symmetry-breaking concept it described. OSP in classical object-oriented modeling can be understood as broken semantics for method execution, contracts, and other concerns. (For more on OSP, especially in the context of subject-oriented programming, see www.research.ibm.com/sop/sopcpats.htm.)

The notion of object identity is central to OSP, as the semantics become clearer only when we consider object identity. An object has a set of operations and a state that remembers the state. OSP emerges mainly as a result of message-forwarding mechanisms (such as consultation and delegation), leading to "memory loss," or broken semantics. In delegation, the inability to associate "self" with the appropriate object (method holder or originator) results in broken delegation and (consequently) in OSP.

In the context of the article, OSP can also be understood as symmetry breaking, especially in terms of object identity. Moreover, the notion of object identity—crucial to OSP—might lead to a clearer understanding (and possibly a formal approach) when applied to design patterns and symmetry breaking.

Agneeswaran Vijay Srinivas
Lausanne, Switzerland

Back to Top

Keep Faith in Ambient Intelligence

Ambient intelligence (AmI) is often promoted as a breakthrough despite its potential drawbacks. The article "The Illusion of Security" by David Wright et al. (Mar. 2008) analyzed ways to prevent the fictional threat scenario it presented and if indeed the scenario did occur ways its consequences might be addressed. That scenario—three fraudulent insider data administrators working in concert and senior executives trying to conceal their attack—is not AmI-related. Real-world scenarios with more disastrous consequences could occur on any given day in any given bank or critical-infrastructure-related governmental office.

A malicious insider group operating inside such an organization is highly improbable, as its conspirators would be expected to be well-screened, highly paid, and backed up by trusted endorsers.

Meanwhile, the type of attack described in the article is a force majeure for any organization—practically impossible to prevent once the conspirators have agreed to cooperate.

The three administrators and the company president described in the article fled to an undeveloped country with no AmI infrastructure. Our hope for a secure society with less of a chance of AmI-related disasters shouldn’t depend on downgrading our interest in developing vibrant AmI technology wherever we are.

Jaak Tepandi
Tallinn, Estonia

Back to Top

Back to Top