by John Lees
The Madness Known as Programming Contests by John Lees University of Missouri-Rolla Programming contests are a rather new form of competitive sport. I don't know when the first programming contest was held, but it can not have been too long ago; the necessary technology has been in existence no more than fifteen years. Such contests are probably a phenomenon of this decade, since the primary ingredient – crazy students of computer science – has been available in quantity only for the past few years. Just what is a programming contest? That is still open to definition at this time. I am going to describe my experiences as a co-chairman of the second Annual North Central Regional Programming Contest which was held at the University of Missouri-Rolla on April 17, 1976. The preceding year I was a contestant in the first North Central Regional, so I have now seen programming contests from both sides. If pressed on the question of whether I prefer being a contestant or being a co-chairman, I will reply, "Next time I think I'll just watch." The contests held at Rolla drew from twenty to twenty-five participants from the ACM's (Association for Computing Machinery) North Central Region, an area which includes about 400 Colleges, Universities and Junior Colleges, all of which were invited to participate. Each institution could send one team consisting of up to four student team members and a team sponsor to the contest. Teams had to pay their own transportation and lodging, but there were no fees associated with the contest itself. Facilities and time were donated by the UMR Computer Center, students, faculty and staff, with financial assistance from the ACM North Central Region. The UMR student chapter of the ACM was responsible for organizing and running the second annual contest. The exact form of a contest is dictated by the facilities available and by the need for a standard language. One of the most difficult requirements of a programming contest is that everyone must be programming in the same language, everyone must be aware of the language standard used, and the language must be popular enough that the contestants don't have to learn it on the fly. Taking all three points into consideration there was no choice but to adopt ANSI FORTRAN IV as the contest language. No one in their right mind would think of a contest using COBOL, and there are no other widely used programming languages. (Ed. note: BASIC?) The facilities at UMR are punchcard oriented, so teams were distributed around the building in such a way that each team had a keypunch, a table and blackboard space. To ensure essentially instant turnaround, we detached ourselves from the University Network and ran WATFIV, a fast, in-core student FORTRAN compiler, on our own 360/50. Contestants could read in their decks on a cardreader in the hall; another cardreader in the machine room was used to run decks which had been handed in for judging. Output was printed on an 1100 line-per-minute printer and handed back immediately after the run had been logged. Following an explanation of the contest rules and time to look over the facilities and locate their assigned rooms, the four contest problems were handed out and the contest began at 10:30 a.m., closing at 4:00 p.m. The teams could work the entire five and a half hours (most did), but program distribution was closed during a one and one-half hour lunch period: decks could be read in during that period, but no output was handed back and decks could not be handed in for judging. Each team had to solve the same four problems. They could approach the task in any way they wished; all that counted was getting a program written in ANSI FORTRAN that would give the correct output when run with the official data. Most teams seemed to assign one member to each problem and work more or less independently, although it is not at all clear that this is the best of all possible strategies. As many runs as needed to debug a program (at 10 points penalty per run) could be made through the hall cardreader with any test data dreamed up by the contestants allowed. Once a team felt that they had a problem correctly programmed, such that it would work to spacification with any possible input data, the deck was handed in at program distribution to be run with official data and judged. Submitting a deck for judging incurred a 15 point penalty plus a real-time penalty in that ten minutes or so were required for the deck to be run with official data and the source and output judged. If the judges found an incorrect answer or an ANSI violation, the source listing was marked as such and handed back to the team for them to correct the problem and try again. The output of judged runs was not handed back, i.e., the contestants could not find out what the official data was. When a run was judged to be totally correct, the time of the run was put on the scoreboard and that team could forget about that problem. The problems were far from easy. This year only one team, University of Nebraska-Lincoln, completed all four problems to finish in first place. One team completed three problems and quite a few teams did not complete any of the four problems. The problems ranged from playing BINGO to a loading dock problem involving moving crates through a hall and around a corner (the program had to determine if the dimensions of a crate allowed it to be moved without tipping it on a corner). The winning team made seven judged and twelve non-judged runs. One team gave up before the contest was over and ran a job which printed the message "WE GIVE UP. WE ARE SLASHING OUR WRISTS IN THE RESTROOM," 2000 times. We felt that this was in rather poor taste and canceled the job. We feel that the First and Second Annual North Central Regional Programming Contests have been successful. The participants have all seemed to have fun and everything has run more smoothly than we have hoped for. (Note: 100 dozen homemade cookies are too much for eighteen teams and assorted contest personnel to eat in one day. The same comment applies to 60 gallons of soda pop. 30 dozen donuts is about right.) One thing that bothers me is that programming contests seem to encourage anything but "good programming." The only thing that counts in a contest is
