RE: Open Perl Exercises, anyone ?

On Tue, 25 Jun 2002, Stephen Collyer wrote:
> See my response to Tom Phoenix that covers this point. In brief:
>
> 1. Lots of exercises (maybe with multiple solutions).
> 2. Trainer chooses the right set for the course.
> 3. Problem solved.

There should be some schema (XML, SQL inserts or something) for exchanging
exercises.  From what has been talked about so far I would think there
should be a variety of meta-information available too:

	- The question itself
	- The primary topic of the question (hashes, references, etc.)
	- Topics required to complete the question (regex, DBI, etc.)
	- theme (none, chess, cartoons, etc.)
	- difficulty (like Knuth used in Art of Programming)
	- A variety of answers with associated topics used
	- The contributors to this question

Having a defined Perl Topic Hierarchy would obviously be required.  But if
the idea is to have a large body of questions (something which I think
would be absolutely wonderful for the perl training community) then you're
going to need some way to sift through them effectively.  If we have the
questions stored in such a way that the trainer can say I want questions
on sort that don't require hashes then we're getting somewhere.

I like the idea of having a variety of answers to some questions.  Some
questions could be asked several times in the period of a course with
progressively shorter/simpler answers being shown as things moved on.
That's why associating topics with answers is important.  Answer 1 may be
based on arrays and answer 2 may require hashes.

Someone was talking about how easy questions don't necessarily seem
interesting to the instructor.  I've had that problem, but there's a real
and opposite problem as well.  In several classes I've ended up with
students that know C or Java or who have "maintained CGI scripts for a few
years" that move much faster than the rest of the class.  Having exercises
to keep them entertained while the slower folks try to get their quotes
balanced would be nice.  And if the challenging questions are labeled as
such it would avoid scaring off the newbies.

-- 
</chris>

There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. And the other way
is to make it so complicated that there are no obvious deficiencies.
                                                        - - C.A.R. Hoare