mikeg@c3.c3.lanl.gov (M. P. Gerlek) (05/02/91)
In article <9105020134.AA29577@enuxha.eas.asu.edu> hurwitz@ENUXHA.EAS.ASU.EDU (Roger A. Hurwitz) writes: > At the risk of getting char-broiled, it is my belief that the entire > idea of programming contest that puts a premium on speed rather than > quality sends the wrong message to CS noviates. [...] Why not make > these things software design contests, and judge the contestants on the > quality of their designs? As a veteran of a few years of these contests - both as organizer and competitor, high school and collegiate level - I heartily agree. The current approach is to solve n problems in time t or better -- with no regard to style of user interface (unless specified in problem), modularity of design, efficiency of code, etc. However, in organizing high school contests at Merrimack College, every year this discussion came up, and every year we got stuck on the fact that judging "good" and "clean" code is *wildly* subjective. We tried an approach where teams we be awarded "extra" points, above and beyond a time-based score, for "good" code but the judges (the department profs :-) had different ideas as to what programs were "good". Bzzzt. And in any case, a smart time would blow off the quality points and strive for raw speed to complete problems, unless the quality points were weighted heavily enough. Given that programming contests are good for business in that they create interest for high schoolers and keep college kids busy (half grin), here's the deal. Along the lines of what Roger posted, why not bag the whole n problems in time t idea and go for 1 (one) problem: Outline one largish program - to use an infamous Merrimack College example, call it "Joe's Sub Shop": the program will, say, use queues to schedule arriving customers, have an ordering scheme to create subs, have an elaborate cost-figuring scheme ("pickles $0.25 extra, unless it's a large in which case pickles are free if it's not whole wheat bread"), keep statistics as to how many of each type sub ordered, etc etc. Give them the problem by outlining the required tasks, and let 'em go to. This will encourage all team members to work together on one problem - something not much done now - as well as make them write modular code (n terminals for n team members might be nice). We can't be too advanced - these are high school kids - but you get the idea. The teams will have to design and implement the program in one day. At the end, the programs are reviewed - this will take some time - by several judges independently on modularity, user interface, data structure usage, etc. The opinions are tabulated, and the winner is declared. Side thought: drum up outside interest by getting a local company to underwrite cost of refreshments & let 'em provide one of their programmers to code up a solution and present it to the teams while the judging is going on at the end of the day. This idea has some inherent difficulties, admittedly, but I think the concept is much more sound and more in keeping with modern CS thinking than current contests. I'd be interested in other opinions - email or posted. -[mpg] mikeg@lanl.gov former Merrimack College ACM Chapter Chief Techo-Geek, now humble grad student
pa_scott@merrimack.edu (qwerty?) (05/03/91)
This whole idea of a 1 program contest is GREAT !
The complexity of the problem is VASTLY different when talking about
college-level contestants and high school level contestants. A lot of
time highschoolers don't get to work in a team environment to produce
one system. One learns alot from doing a group project/program, and I
think any high school students that have this type of exposure will
have a GREAT advantage in their college/post high school years.
Highschol students should, IMHO, be able to solve problems that involve :
a. arrays
b. character/string manipulation
c. high school math (trig, algebra, geometry)
So your kind-a limited to what you can do with the high schoolers but
"Joe's Sub Shop" is a good thing to have them attempt. Could be like
a cash register/reciept system.
Where as college level students should be able to solve probelms that involve :
a. data structures (stacks, queues, link lists,...)
b. Calculus
c. file i/o (maybe)
d. pointers
e. etc.,etc.
The scope of "Joe's Sub Shop" for college students would be a lot
greater. They SHOULD have some back gropund in group projects, and
their computer porgramming skills are a lot greater.
This idea of group programming contest is a GREAT idea for both the
high school and college levels.
Too bad I'm graduating from Merrimack this year, cause I'd like to try this
in our high school contest next year.
Greener
p.s. 17 days till graduation :-) YOW !
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Scott Green "EMACS" = "Escape-Meta-Alt-Control-Shift" Class of 1991
pa_scott@merrimack.edu or uunet!samsung!hubdub!pa_scott
Merrimack College - North Andover, Massachusetts
"qwerty ? dnim fo etats A...srekcah nexalf k'neat!"
night@jec308.its.rpi.edu (Trip Martin) (05/10/91)
mikeg@c3.c3.lanl.gov (M. P. Gerlek) writes: >Given that programming contests are good for business in that they >create interest for high schoolers and keep college kids busy (half >grin), here's the deal. Along the lines of what Roger posted, why not >bag the whole n problems in time t idea and go for 1 (one) problem: >Outline one largish program - to use an infamous Merrimack College >example, call it "Joe's Sub Shop": the program will, say, use queues >to schedule arriving customers, have an ordering scheme to create >subs, have an elaborate cost-figuring scheme ("pickles $0.25 extra, >unless it's a large in which case pickles are free if it's not whole >wheat bread"), keep statistics as to how many of each type sub >ordered, etc etc. Give them the problem by outlining the required >tasks, and let 'em go to. >This will encourage all team members to work together on one problem - >something not much done now - as well as make them write modular code >(n terminals for n team members might be nice). We can't be too >advanced - these are high school kids - but you get the idea. >The teams will have to design and implement the program in one day. >At the end, the programs are reviewed - this will take some time - by >several judges independently on modularity, user interface, data >structure usage, etc. The opinions are tabulated, and the winner is >declared. One variant we've talked about here at RPI is to have a single project that has a list of independent features to be incorporated. The contest itself is divided into 2 parts. The first part, each team works on getting a minimally functional system running. At the end of the first part, the programs are all submitted and copies are made for each team. Each team then has say, a half hour to sort through the programs and choose one (which can't be their own) program which they will then try to add as many features as they can to for the second half. Teams will get points for features that they've implemented correctly, and also for other teams choosing their program for the second half. The idea is there the contest is divided into a "development phase", where each team writes a program from scratch, and a "maintenance phase", where they have to try to modify code that someone else has written. -- Trip Martin night@rpi.edu -- Trip Martin night@rpi.edu
daryl@unix.cis.pitt.edu (Daryl P. Sawders) (05/10/91)
I like the idea of using a two-phase approach to the programming problem. Incorporating "implementation" and then "maintenance" is exactly what kids need to see of the "real" world.
steve@nuchat.sccsi.com (Steve Nuchia) (05/12/91)
In article <ct9g_2m@rpi.edu> night@acm.rpi.edu writes: >contest itself is divided into 2 parts. The first part, each team >works on getting a minimally functional system running. At the >end of the first part, the programs are all submitted and copies >are made for each team. Each team then has say, a half hour to >sort through the programs and choose one (which can't be their own) >program which they will then try to add as many features as they can Sounds like a good idea, but I think there is a trap here. In particular, there is a disincentive to making the initial program easy to modify, easy to understand, etc. I would seriously consider having solutions done up beforehand: just one or a selection using different approaches/styles, so that the playing field is level for round two and there is no temptation to booby-trap one's submission for round one. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "Innocence is a splendid thing, only it has the misfortune not to keep very well and to be easily misled." --- Immanuel Kant, Groundwork of the Metaphysic of Morals -- Steve Nuchia South Coast Computing Services (713) 964-2462 "Innocence is a splendid thing, only it has the misfortune not to keep very well and to be easily misled." --- Immanuel Kant, Groundwork of the Metaphysic of Morals
peter@ficc.ferranti.com (Peter da Silva) (05/13/91)
In article <1991May11.185651.20462@nuchat.sccsi.com> steve@nuchat.sccsi.com (Steve Nuchia) writes: > Sounds like a good idea, but I think there is a trap here. In particular, > there is a disincentive to making the initial program easy to modify, > easy to understand, etc. Not at all. Doing that would lose you points in the selection phase. In fact the point system could be arranged that the authors of the first-half program get some fractional points from the people who chose their code for the second half, and with enough teams the overall winning strategy could become simply to blow off the second half altogether and get as many second-half winners using your first-half code. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"