Pages: pp. 6-7
In "Teaching the Intangible" (Forward Slash, May 2012, p. 116), David Alan Grier wrote, "In a distant time, higher education was founded on the idea of developing the whole person—the spiritual, moral, athletic, social, and intellectual aspects of character." However, I think he longs for a past that never existed.
Universities were originally founded to train clergy. The medieval church had discovered that many of its clergy were ill-prepared to debate theology with heretics, and universities were established to provide this training. One such graduate was Isaac Newton, who was trained as an Anglican clergyman.
The tradition of founding colleges to train clergy was carried over into the Americas with Harvard and Yale. This continued even after the US was established. The "Union" in Union College (founded in Schenectady, New York, in 1795) refers to its purpose to train clergy for many different Protestant sects.
With the supply of clergy assured, colleges were then founded to train military officers (West Point, 1802) and engineers (Rensselaer Polytechnic Institute, 1824). Later, land grant colleges were established to train specialists in agriculture, and teachers' colleges were created to supply educators. All of these institutions would be considered trade schools by today's academic standards.
In general, I suspect that, prior to the 1950s, most adults got their guidance for spiritual, moral, athletic, and social development some place other than at a college or university. Prior to that time, most adults did not attend a college or university. There were also plenty of alternatives for receiving this guidance, such as churches and social organizations.
So it would seem that the function of colleges and universities from their earliest times was not to develop the whole person but to teach useful skills.
Rarely have I seen the blame game promulgated in the pages of Computer so blatantly as in the May 2012 issue.
The Forward Slash column ("Teaching the Intangible," p. 116) offers David Alan Grier's complaint that "educators" are at fault for the apparent decline in educational quality. His comments are not true for any teacher of whom I am aware. Nor do his comments comport with the historical record of warnings of the negative impact by educational experts of all stripes when faced with legislated budget cuts.
Let's also be serious about the acting profession being to blame for electronic crime. If the answer is so simple as Hal Berghel suggests in the Out of Band column ("Breaking the Fourth Wall of Electronic Crime: Blame It on the Thespians," pp. 86-88), the Spanish Prisoner confidence trick would not have survived to enter the popular lexicon, and social interactions between human beings would hardly have allowed us to become the dominant species on Earth.
The best pages of Computer report effective research and analysis, both current and historical. I believe the columnists whose work appears in this Computer Society publication should adhere to this standard.
Larry L. Gadeken
Hal Berghel's response:
I'll give Mr. Gadeken both an OMG and LOL for "The Blame Game." In response, let me say that absent backplane processing, reading is nothing more than coordinated eye movement.
To forestall further rants, I'll take this opportunity to confess that Los Angeles isn't really a suburb of Las Vegas, and James Garner wasn't actually responsible for the HP pretexting scandal. Relevant search terms: "literary license," "irony," and "humor."
I enjoyed reading "Software Development for Infrastructure" by Bjarne Stroustrup (Jan. 2012, pp. 47-58). It highlights a field that is often neglected—although being most critical for our society—namely, embedded computing.
Given the wide usage of such systems in daily life, the article should have stressed that, especially in embedded software, cost and quality must be carefully designed in parallel. For example, 5-nines availability is not related to reliability alone but also includes diagnosis, self-repair, and robustness. Building reliability bottom-up is not always necessary if lower-cost intelligent architectures are used.
While it was interesting to read about the reasoning on program language performance, an article that covered such a wide spectrum should have covered topics such as security, usability, or maintainability.
With the rapid evolution of infrastructure software in traffic, living, and automation together with wireless sensor networks, security is of growing concern. Due to heterogeneous users, usability is highly relevant in such systems. For example, in medical applications, the highest software defect rates stem from the UI. Infrastructure maintainability is critical because of the long lifetime of embedded software. With service cycles extending over several decades, as in aerospace and other industries, the software often is enhanced in dozens of hardware generations. It would have been helpful discussing how these concerns could be addressed at the code level and how, for example, static analysis and coding guidelines could enhance code quality.
With all such code-level guidance, careful code reviews are still necessary. The author cited the Mars Climate Orbiter as an example in which the incorrect usage of units terminated its entire mission, thus losing US$654 million. Such incorrect usage of units even happens in the article where it states that "Google used 2.26 million MW to run its servers" rather than using the correct unit MW hours.
To err is human, thus we need a variety of cost-effective techniques to make the code of our infrastructures safe, secure, usable, and maintainable.
Bjarne Stroustrup's response:
Thanks! I spotted that embarrassing mistake, but not in time to correct it before publication. Thus, I inadvertently illustrated one of the main points in my article: informal formulation of ideas is error prone. "Being careful," experienced, and having friends look over the work is not sufficient; we need all the help we can get from formalisms and tools. Had I been able to apply my recommended techniques and tools to English text, my mistake would have been caught by the first compilation.
The letter correctly points out that quality, usability, dependability, and so on require a look at the complete system, including its users and its maintenance, as well as a range of skills and techniques. However, I was writing an article rather than a thick book, and I wanted to highlight just one aspect that is often overlooked.