Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!stanford.edu!decwrl!pa.dec.com!granite.pa.dec.com!mellon From: mellon@nigiri.pa.dec.com (Ted Lemon) Newsgroups: comp.org.acm Subject: Re: Yet another posting...:) Message-ID: Date: 3 May 91 16:40:27 GMT References: <91120.075856TAINT021@ysub.ysu.edu> <9105020134.AA29577@enuxha.eas.asu.edu> Sender: news@pa.dec.com (News) Organization: Digital Equipment Corporation Lines: 23 In-Reply-To: glenn@curie.ces.cwru.edu's message of 2 May 91 09:45:28 >Seriously, how would you have these contests judged? Have the judges >each take an enormous amount of time to thoroughly read and understand >each team's entries, then have them vote on the winner? The current >contests take quite a bit of time to judge, so you'd have to decrease >the number of problems. My point is not that you're wrong, just that >what you want may not be possible at a contest with 100+ teams.... You're probably right that judging the quality of a program in the manner you've described isn't reasonable. So, how about setting up teams, where one person writes a program that solves one problem, then a second team member modifies that program to solve a second, related problem, a third team member solves a third related problem, and so on? Naturally, in a situation like this, the team with the best programming style will have a speed advantage over the team which codes quickly but poorly. There are a lot of problems with this approach, not the least of which is coming up with a good set of related problems to solve, but I think it might be possible to make it work. _MelloN_