Programming on an already full brain

Reviewer: Boris Beizer

This paper is based on unsupported premises and, as a result, attacks non-problems or, if not that, then certainly does not attack significant programming problems. The questionable premise is that the act of coding and getting to the stage of having a compiled unit ready for testing is a significant part of the programming task. The paper provides an approach to reducing this (small) part of the labor. After rejecting text editors, interpreters, forms-based languages, and visual programming, Fry arrives at the Emacs menu. This system allows partial parsing, syntax checking, and other analysis of code selected by the mouse. The system provides in-context help and multilevel in-context menus triggered by the kinds of objects selected. It is also integrated with debugging tools. Fry goes on to propose additional “aids,” including five-button mice, pen inputs, pointing devices for both hands, voice recognition, head trackers, eye trackers, trackballs, and foot pedals. Apparently, the author has problems with keyboards. This rich input environment is prompted, in part, by a desire to avoid repetitive strain injury (RSI), which he calls “the hacker's disease.” He gives no evidence of either the putative high labor content that this approach proposes to reduce or of the supposed high incidence of RSI among programmers. A final comment concerns “RSI of the brain. Programming environments requiring repetitive, low-level, mind-numbing operations to get anything done are a prime cause of programmer burnout.” I thought the cause was months of 80-hour weeks to get things done under an unreasonable schedule. These negative comments aside, the proposed coding aids could be helpful and might reduce effort and bugs in what is generally recognized as a small part of the programming job. Programming tool designers should read this paper to see what else might be worked into their toolkits, at what cost, and for what benefit.