It's entirely possible that the assignment was given to force the students to work with OO. But in that case, pick a problem that matches to an OO implementation and don't force busy work on a student just because that's what the lesson plan says.

Now, I'm not saying that there aren't equally silly constraints out in The Real World™. However, those tend to be a different set of silly constraints from school. For example, it's entirely possible (in TRW) to be told that you have to use a particular language or environment because that's what the entire organization is using (or whatever). But "Do it in OO" is rarely one of the real-world constraints. "Make it reusable" may be, but OO-ness, in and of itself, rarely is.

I'd be curious to hear back from the teacher in this instance as to why they put that set of contraints on the student / developer. That may be more instructive than anything else.

I have certainly seen "use OO" be a real-world constraint. That part was not what I thought was stupid. I can accept that an example to teach people how to use the OO mechanics had better be a problem they can understand easily with or without it. Particularly since a bit of blind flailing with OO can turn the simplest of problems into a mess.

No, that wasn't what put me off. What put me off was restrictions like the ones described at Re: Re: OO 2 death?. A series of restrictions that struck me as seriously counter-productive. Is advice like, "Modules no more than 1.5 pages" or advice like, "Days of the week need to be separated for maintainability" any good? Not as far as I can see...

That said, were I this highschool student, dealing with those restrictions, I would have chosen to program in Ruby. Why? Because Ruby's OO has fewer "moving parts" than Perl's does, making it somewhat more compact. Also the syntax looks cleaner to the uninitiated, which probably will go over better with a teacher who doesn't know the language...