![](bg4.png)
3.2 Competition–based Learning
In programming courses, most assignments are pro-
grams: students are asked to write programs to solve
particular problems or to perform certain tasks.
When the work is done, students hand in the pro-
grams they wrote, together with a written report.
This is the standard procedure, but, to use the pro-
gramming jargon, it does not scale, if done by hand:
it is acceptable if you have a few students and a few
small programs, but it becomes impossible if you
have 200 students, and want them to hand in new
assignments every week. The solution is to use an
automatic judging system such as Mooshak (Leal
and Silva, 2003).
Mooshak was designed to manage programming
competitions such as the ACM International Colle-
giate Programming Contest (http://icpc.baylor.edu
/icpc/). Originally it was not a pedagogical tool.
However, the facilities it provides can be very useful
in programming courses.
Within Mooshak, a contest is a set of program-
ming problems or tasks, to be solved by the contest-
ants before a given deadline. Contestants submit
their source files using a browser. Mooshak recom-
piles and links them with the appropriate libraries,
and runs them with a set of secret test files. The re-
sulting output files are compared with the “official”
ones and if they all match exactly the task is “ac-
cepted”. If one of the tests fails, the reply is “wrong
answer”. In this case, no indication is given of the
nature of the discrepancy. It’s up to the contestants
to figure out, using their wit, the causes of the fail-
ure, and then correct it.
The great novelty of this system is that students
obtain immediate feedback, and this has great peda-
gogical value. Most of the times, students are 100%
sure that their programs fully satisfy the stated re-
quirements and they are surprised and disappointed
when they get “wrong answer”. In the past, their
wrong solution would be submitted to the teaching
assistant, and it might be falsely be taken as correct,
if the assistant was not rigorous or did not have time
to experiment all the interesting cases. In any case,
the assistant would typically return the assignment a
few days after, and if corrections were necessary,
they would be more painful because the assignment
was over in the student’s mind.
All programming assignments – exercises, prob-
lems and scripts are carried to be judged automati-
cally. When we started this approach, we used
scripts only, in place of the so-called “projects” that
were, at the time, the only meaningful programs the
students would write, typically at the end of the se-
mester. The observation at the time was that the
quality of those projects was very unsatisfactory,
because the students were only novice programmers.
That was understandable, but it left everybody, stu-
dents and teacher, unhappy. With scripts, students
could be guided to program interesting systems,
which would be beyond there current capabilities, if
they were left on their own.
With time, students became quite good at fol-
lowing scripts. We were surprised that when they
were given a problem without guidance, they would
feel uneasy. Many would simply give up instantly,
knowing that the grade points they had got with the
scripts were sufficient for passing.
To counter this attitude, we increased the num-
ber of problems and gave them more weight in the
final grade.
Still, Mooshak it was difficult to use Mooshak
early in the course, because Mooshak was designed
to handle input-output programs, i.e., programs that
read their input from the console and write their out-
put to the console too. This means that students must
know how to read data, not a trivial thing in many
programming languages. Furthermore, output must
conform exactly to what was specified, not a charac-
ter more, not a character less. Again, this is not an
issue after a while, but it discourages students on
their first rounds with Mooshak.
In order to solve this issue, and get more success
earlier (meaning, from the first lab), we introduced
exercises. With exercises, students merely write a
function with a specified interface, and submit it,
Input and output is performed by a “framework” in
which the students function is inserted, thus freeing
the students from those worries. This involved some
hacking with Mooshak, but proved very effective,
and helped raising the morale in the class.
With Mooshak, the results of all the submissions
are public: if my task is “accepted”, all my col-
leagues will know that immediately; is it gets
“wrong answer”, likewise. This is very instructive:
one might think that publicizing failures is counter-
productive, but in the end, everybody knows that
doing things wrong when you are learning is normal.
You don’t have to feel ashamed or anxious for not
getting the program right immediately: nobody does.
And you don’t have to be surprised that it is so hard
to finalize all the tasks, even the simpler ones: you
can watch that everybody else is going through the
same troubles, and eventually succeeding. So will
you, by working well, calmly and cautiously. All the
above instils group spirit which according to Rovai
(2002) allows learners to challenge and to nurture
each other which in turn affects positively their abil-
ity to cope and to learn. On the contrary, what is
strange and becomes suspicious is someone who
always gets things right at the first attempt. Actually,
although the teachers do not take any explicit meas-
ures against cheating, some situations like those
have arisen and were checked. On the other hand,
TEACHING PROGRAMMING WITH A COMPETITIVE ATTITUDE TO FOSTER GROUP SPIRIT
417