I used to work at Google.

I can personally vouch for the fact that not all gay employees joined the "Gayglers" (I did, but I know quite a few who didn't.) I don't see why "Greyglers" should be any different.

And for those of you making comments about how people over 40 are incapable of being creative or good programmers, I have to say that my experience speaks differently. Some of the best programmers I've ever met (and worked with) were the older ones. Then again, I've seen some superstar young programmers too, so I'm not ready to say that you have to be old to program well. That said, even many of the great young programmers I've worked with were less productive simply because they had to take time to learn how to work on a large project and maintain someone else's code.

This is a student's programming contest, right? Why are you even concerned about compile time or "startup" time?

As far as compile time goes, if any sort of program you can write to solve a toy problem that's one of the problems in a competition like this actually takes a long time to compile (remember, you're not actually allowed to include that much code, according to the rules) you're doing something weird.

As far as "startup" time, I'm assuming how much time you mean the interpreter takes to start, which seems like even less of an issue, because the rules explicitly state that the time limit might be increased, at the judges' discretion, for interpreted languages.

Your classification of speeds might be relevant for some sort of question other than "what language should I use for this programming contest?" but given the rules of this particular contest, I think a better characterization of what is "slow" and "not slow" depends on whether the student can manage to code an efficient solution.

These days I would probably choose python for something like this, even though Pascal was my first language. Python's used a bit more extensively than Pascal, so you might as well teach something that will have applicability outside of the bounds of a contest (it also happens to be a fairly easy language to learn, and for people used to developing in interpreted environments, allows for quicker development time because of the lack of a compile phase in the testing cycle.)