The Best of Creative Computing Volume 2 (published 1977)

Page 86 << PREVIOUS >> NEXT Jump to page:
Go to contents Go to thumbnails
This book is also available for the Kindle

The Madness Known as Programming Contests (Association for Computing Machinery, University of Missouri-Rolla, First and Second Annual North Central Regional Programming Contests)
by John Lees

graphic of page

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

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
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

Page 86 << PREVIOUS >> NEXT Jump to page:
Go to contents Go to thumbnails
This book is also available for the Kindle