Re: Language Challenge 2000 - Update

[David Emery <emery@grebyn.com>]

At an IEEE Ada conference back in the late '80s, they held a programming
contest.  What made this unique was that it had two parts.  The first
part was to implement the given set of requirements.  The second part
consisted of some "maintenance" to apply to the system, i.e. to 
implement a revised set of requirements.  Thus the emphasis in this
contest was on how flexible the software was and how rapidly it could
adjust to new requirements.  

There were 3 teams, if I remember right.  My team had the most 
interesting solution :-), but we couldn't get it to compile.  The
problem was compiler internal errors, rather than issues with our own
code.  (We were simulating OO inheritance using generics, and vendor V's
compiler choked on one particularly complex generic.)  It's too bad, as
our design would have allowed us to make the changes very quickly.

The problem, as I remember, was to produce a system for selling
theatre tickets.  You had to support multiple ticket agencies, so
concurrency was an issue.  THe initial theatre was a "classic box",
but we anticipated alternate theatre shapes, including theatre-in-the-
round.

As I recall, one of the other 2 teams also hit some compiler problems.
The winning team had probably the least elegant design, but they got 
their software to work, which the other teams didn't :-(

Another idea that was discussed, but not adopted, was a contest whereby
the teams swapped designs/software, so in phase 2 you had to modify
someone else's software.  The scoring for that approach was based on
both correctness of the initial design, and also how well another
team could learn your design.  But the "game mechanics" of such a
contest could be touchy.  After all, you spend a lot of effort learning
someone else's software to make it easier for them to win!

         dave