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.)

If you're interested in one of the sorts of things that Google has done with MapReduce, look no further than Sawzall.

http://research.google.com/archive/sawzall.html

Sawzall is essentially designed around the mapreduce framework. It's impossible to *not* write a mapreduction in Sawzall. The way it works:

Your program is written to process a single record. The magic part happens when you output: you have to output to special tables. Each of these table types has a different way that it combines data emitted to it.

So, during the map phase, your program is run in parallel on each input record. During the reduce phase, the reduction happens according to the way the output tables do whatever operation was specified.

There was some work to be done having enough different output tables to do everything that was useful, especially since you might want to take the output and plug it in as the input to another phase of mapreduction.

One of the biggest reasons this was a major innovation for Google was that it let some of the people who weren't really programmers still come up with useful programs, because the Sawzall language was pretty simple (especially when combined with some of the library functions that had been implemented to do common sorts of computations.) There were also some interesting ways in which the security model was implemented, but as far as I know they haven't been published yet.

There certainly are plenty of other technical things that can be done to improve a system like MapReduce (and I know that many of them were in various forms of experimentation when I left the company) but at least some of them are highly dependent on Google's infrastructure, and not really relevant to a general discussion. (I suspect that the papers linked above might have some hints, but it has been a while since I looked at them.)