Dr. Dobb's Journal June, 2004
E-Voting
Dear DDJ,
E-voting is a subject touched upon by both Jonathan Erickson ("Editorial," DDJ, February 2004) and Michael Swaine ("Programming Paradigms, DDJ, January 2004). The software for the Diebold voting machines is allegedly written in C++. To your knowledge, has anyone in the C++ universe examined the software to see what it does besides presenting screen images and "tallying votes"? Supposedly the software runs to almost a million lines of code, which to this nonexpert seems excessive, for what amounts to a "display" and "book keeping" program.
David Laning
amos.buffverizon.net
Jonathan responds: Dave, to the best of my knowledge, the code is proprietary and hasn't been examined by the public. I'm assuming it has been examined to some degree by the government agencies, but none that have ever said anything about it. Maybe fellow readers have a better take on this.
How Do You Spell...
Dear DDJ,
This e-mail has nothing to do with computers. The problem is that I can't remember how to spell "Pyric" as in a "Pyric victory." I have asked many people and I can't find it in the dictionary. You being editors and all, I thought you might know. There was a Greek battle where the price of victory was so high that it was almost not worth fighting at all (almost everybody died). Such victories are called "Pyric Victories." Unfortunately, I can't for the life of me remember how to spell it properly ("Pyric")—and the Microsoft Word spellchecker is no help. Secondly, I am a subscriber to DDJ, so you will be helping a customer if you have an answer for this.
Thomas Zammikiel
tomzamoptonline.net
Jonathan responds: Thomas, it is spelled "Pyrrhic" after King Pyrrhus of Epirus. In 281 B.C., King Pyrrhus of Epirus landed on the Italian shore with 20 elephants and 30,000 soldiers to defend the Greeks against the Romans. Pyrrhus won the first battle, but lost half his army, and ultimately the war. The term "Pyrrhic Victory" comes from this battle. We're here to serve.
Professional Programmers
Dear DDJ,
Andrew Todd's letter in the April 2004 issue of DDJ reminded me of a prediction I made to a colleague about 20 years ago, probably after reading James Martin's book on user-written programs. I predicted that foreign language options for American school children would soon include Basic and Cobol as well as Spanish and French. My colleague disagreed, saying that it wouldn't be necessary because programming languages would become so English-like.
We were both partly right. Students are learning to program at an earlier age, and there are tools that let end-users accomplish what used to require programmers. But I don't think the distinction between users and programmers will disappear, nor should it. Having everyone who can learn a programming language call themselves programmers is just as dangerous as having everyone who can learn anatomy call themselves surgeons.
To see what I mean, read the following excerpts from Can Software Kill? by Debbie Gage and John McCormick (http://www.eweek.com/article2/0,1759,1543652,00 .asp?kc=EWNWS030804DTX1K0000599).
Victor Garcia considers himself lucky to be alive. Three years ago, a combination of cancer and miscalculation almost killed him.
In November of 2000, Garcia and 27 other patients at the National Cancer Institute in Panama were jolted with massive overdoses of gamma rays partly due to limitations of the computer program that guided use of a radiation-therapy machine. The three Panamanian medical physicists who used the software to figure out just how much radiation to apply to patients are scheduled to be tried on May 18 in Panama City on charges of second-degree murder.
In 1993, 1995, and 1998, FDA inspectors found the same deficiencies in Multidata's software-development process coming up time and again: a lack of good software specification and documentation procedures to guide and control the software-development and change process; insufficient documentation to show that the software had been properly tested to see if it worked; and inadequate investigation into customer complaints.
Software engineer [Jack] Ganssle, notes that programmers don't need any form of certification or license to work on commercial software, including life-critical medical device software. Yet, he says, "In Maryland, where I live, if you want to cut hair, you need to be licensed."
The potential for misbehaving software to kill us is not just in hospitals. It's in cars, airplanes, and probably places I don't even know about. Eventually, I think the public will insist on more dependable software, which means programmers as well as doctors will need "special expertise," and will be expected to "uphold a trust in employing this expertise," to quote Mr. Todd.
Although programming languages are becoming easier to learn and use, acquiring this special expertise will never be easy. Just as not everyone has what it takes to become a doctor, not everyone has the patience to analyze a problem before designing a solution, or to create a model before writing any code. In addition to having patience, expert programmers must be willing to tolerate the imprecise way in which their clients view the world, while being intolerant of any imprecision in their own work. Most importantly, those who pay for software must expect programmers to be professionals, and trust them to take as long as needed to do the right thing.
In the short run, software will be more expensive. In the long run, it will be worth it.
Jim Wiggins
jwigginsifbf.org
Column Idea
Dear DDJ,
As a long time reader of DDJ, I've enjoyed the articles that show different features of languages. All programmers at one time or another, have cursed a language for some difficulty with syntax. Like others, I've always thought I could design a better language syntax. With the wide range of experiences of the DDJ readership, you could have a monthly column that develops a "DDJ Language" based on input from readers. The column would evolve over time from general design goals to specific language syntax. Each month would present a topic that readers would respond to with e-mail comments. The column author, or team, would compile the best comments into a language spec posted on the web site. Some topics could require a survey or vote of readers. If the column becomes popular, continued development could be modeled after the Linux development community.
Dan Laughlin
laughlindirecway.com
Jonathan responds: Dan, that's a great idea. If anyone would like to follow up on this, please drop me a note at jericksonddj.com.
DDJ