In case anyone's unaware of what the parent is referring to... http://www.zdnet.com/blog/btl/rest-in-peace-roland-piquepaille/11430

Yes, I would like to live somewhere in the Atlantic.

I agree with doing things natively. I'm leading a small team currently developing a native game for Android and iOS, (written in C++, using the NDK and Java as a thin Android wrapper and Objective-C for the iOS wrapper).
Since our lowest common denominator is OpenGL ES 1.1 (it's a sprite-based game), we've not really had any cross-platform hiccups so far.
However, it's much easier for us than with non-game apps, since we are not using the native widgets.

It's not a typo, it's talking about rotations of a single microcrystal.
The previous article that is referenced records rates of 500 rotations per second - which is 30,000rpm.

I'm not sure which I dislike more.
Blackberry OS is horrible, inconsistent and not forwards- or backwards-compatible. XCode code-signing is a dark art, its SVN integration flaky and I (personally) just don't like Obj-C - at least it allows pure C.
Android is kind of awkward to get into, with their odd resource system and intents, as well as various bugs in their Eclipse integration, but at least has the JNI bridge and is free / open.
I never thought I'd say this, but Flash / Flex / Actionscript 3 actually feels quite nice to get into, from a 2D graphics point of view, with only minor oddities.

Basically, I hate everything :-)

I'm writing this from a crater in the ground below.

If the course will involve teaching 3D graphics programming, I highly recommend you look at RenderMonkey
I've found it to be really useful for prototyping shaders. One of its most useful features is that it allows developers to mark variables as "artist variables", which are then mapped onto sliders / colour-pickers etc. This allows a user to tweak parameters in the shader and view the results immediately, without having to recode it.
Assuming the engine you ultimately decide upon supports loading custom HLSL / GLSL shaders, your students could potentially apply their own shaders to assets in the games they create, allowing them full creative control over things such as lighting and blending.

This is true. I often wish some of the designers and artists I've worked with had more of a grasp of this sort of stuff, especially things like interface programming. Most of the time, just giving them specific information about limitations and preferences of implementing the design on the target platform gets the job done, but it'd be nice if they intuitively knew these kinds of things.
With that in mind, my main concern about this course is that the students will walk away with a firm grasp of programming basics, but not how game code directly relates to the work they will be doing - why things like polygon budgets, texture formats matter, for instance, or how the interactions of multiple finite state machines are affected by adding or removing states.

If the course is going to include 3D graphics, I highly recommend looking at RenderMonkey.
I've found it very useful for prototyping shaders, and it allows developers to define 'artist variables' that are mapped to sliders, colour-pickers etc., allowing users to change various shader parameters and see the effects instantly without needing to recode.
This also helps open up the possibility of allowing your students to add their own shaders to games they create, assuming the engine / framework you eventually choose supports this.

So as long as I do not gain financially, infringe copies of works woth more than $1000 per 6 months or make my infringing copy available to others, it's not illegal?
For instance, watching videos of copyrighted TV shows on YouTube is legal? (whereas uploading, of course, is not)

As someone who has dabbled with raytracing before, I would have to agree. It's an interesting tech demo of something that's possible, but not really of practical use. For instance, they showed the chandelier with a million polys - that's all well and good, but it's on the ceiling! If the game was actually being played, the player would never get close enough to see those clever refractions. (And even if they did, the demo shows the frame rate would drop to around 17-20 FPS).

A guy at my company made this for touch-screen Android phones a few months back.