letters to the editor
DOI: 10.1145/1610252.1610255
in CS Education, Educate the Educators First

In their Point/CounterPoint “CS Education in the U.S.: Heading in the Wrong Direc- tion?” (July 2009), Robert Dew- ar wrote that the CS curriculum

lacks important fundamentals, mostly

of a mathematical nature, and Owen

Astrachan wrote that “Studying more

mathematics will not make software

bugs disappear, although both [Edsger

W.] Dijkstra and Dewar seem to think

so,” concluding implicitly that more

mathematics in the CS curriculum is

not necessary.

Astrachan apparently overlooked the distinction between necessary and sufficient conditions, a routine distinction in mathematics. As far as I know, neither Dijkstra nor Dewar ever claimed that mathematics is a “silver bullet” guaranteeing reliable design, and both would likely agree with Fred Brooks that indeed there is no silver bullet.

Dijkstra’s and Dewar’s argument that mathematics is an essential aspect of a proper CS education mirrors the fact that education in all engineering disciplines involves a solid mathematical foundation from the start, then used in all (other) courses; see my article “Teaching and Practicing Computer Science at the University Level” in Inroads, SIGCSE Bulletin 41, 2 (June 2009), 24–30.

As long as CS educators cannot agree about the fundamentals, practice will remain below the professional standards common in classical engineering; see Allen Tucker et al.’s “Our Curriculum Has Become Math-Phobic” in SIGCSE Bulletin 33, 1 (Mar. 2001), 243–247. This could be the result of declining CS student enrollment, possibly leading to the replacement of mathematics with, say, trendy topics apparently more appealing to freshmen. However, even trendy topics can be combined with a solid mathematical foundation, with the trendy topics included as illustrations. In any case, the emphasis in teaching such topics must be mathematical modeling, not mere description.

Unfortunately, teachers are divided, so combining theoretical CS expertise and practical experience in the same person is rare, unlike in other engineering disciplines. Educating the educators may well be a first priority.

Raymond Boute, Ghent, belgium

modular Programming
Still a Challenge

In Leah Hoffmann’s interview “Liskov on Liskov” (July 2009) Barbara Liskov recalled research being conducted at the time she was beginning her career (1970). “When I started,” she said, “the main way people thought about modu-larization was in terms of subroutines… But they didn’t have any way of linking a bunch of procedures together.” She also said (in Karen A. Frenkel’s news item “Liskov’s Creative Joy,” also July 2009) “…the major challenge still is how to build large software systems.”

The definition of “module” inevitably affects the building of large software systems, prompting our own recollections and connections. For example, a counterexample to the use of subroutines as the basic module existed in the form of a project that began in 1965 at Argonne National Laboratory (ANL) and was reported at the Spring Joint Computer Conference (May 1969) to develop the Argonne Reactor Computation System (ARC) from linked computational modules running on IBM System 360 computers and OS/360. The modules were FORTRAN IV main programs where the output of one program was analyzed to become the input for other programs. Reactor designers wanted three main features:

Superprograms. To link programs into superprograms directed by another FORTRAN IV main program while the original programs could still run on their own. They wanted all Assembler code and any direct communication with the manufacturer’s software to be isolated for porting to other hardware. Initially, the most important Assembler code was for LINKing and LOADing modules for coordinating the I/O

stream and communicating with JCL;

New algorithms. To improve the modules through new-algorithm rewrites wherever possible; and

New modules. To make it possible to build modules as required.

ARC programmers each had five to 10 years of experience (rare in 1965) and advanced degrees in mathematics, science, and engineering. They coded in Absolute and Assembler on ANL-built hardware (AVIDAC and GEORGE) and in FORTRAN on the IBM 704 and the CDC 3600. Because OS/360 was so unstable (as shipped in 1965), they needed to be able to decipher dumps. Completion of the project would have been delayed without programmers capable of working close to the hardware and operating system.

The ARC system later became the platform for ANL reactor calculations and was studied and used by other laboratories worldwide, though not before it was shown to be portable.

On the first Earth Day (Apr. 22, 1970), a joint project with the Control Data Corporation aimed to port the ARC system to CDC hardware. We were aided in this effort by Richard Lee of CDC and Larry Atkins, a Northwestern University engineering student also known for writing Chess 3.6, the winner of several ACM North America Computer Chess Championships in the 1960s and 1970s. Once the modular environment was ported, the computational modules were easily ported. In fact, after one computational module was ported, the remaining work was almost automatic.

Louis C. Just, Lakewood, CO Gary K. Leaf, Argonne, IL Bert J. toppel, Argonne, IL

 

a Quart of nFE Solution for a Pint CPu Problem In his article “Network Front-End Processors, Yet Again” (June 2009), Mike O’Dell seemed to be arguing what I say to colleagues in simpler terms, namely, that using a network front-end (NFE) processor is (and always has been) a