As a veteran software developer and recent (obviously) PlayBook developer, I've enjoyed some of your observations, so please take the criticism that follows in stride.

Talking about PlayBook development, "ActionScript (Life without threads)" is certainly apropos. I programmed in ActionScript for Flex 1.0 (one of The Few, I suppose) and Flex 2.0. Developing now for the PlayBook, I often found myself wishing that I could employ a logically consistent, efficient and - in regard to both syntax and semantics - non-abortion-on-toast, non-repeatedly-papered-over programming language and, certainly, a programming language expressive enough to provide multi-threading functionality. Say Java or C#, to reference a couple of mainstream stalwarts. (BTW, does anyone seriously doubt that we shall, before too long, see multithreading added to Flash programming platforms? It'll be added, alas, as one glues on another layer of mache.)

One should not conflate the (welcome) presence of Events with the unfortunate (indeed untenable, just as concurrent programming, on multicore processors enters a golden age) absence of multi-threading.

Further, some of your statements in the blog entry are simply false. Do a quick google, for example, and you'll find any number of examples of the Flash/Flex UI brought to complete halt by required "business logic" computation.

Flash/ActionScript/Flex
- resorts to providing special-case kludges,
arbitrarily providing implicit background threading
just for particular tasks, such as gfx filtering
and several varieties of RPC.
- makes the programmer jump through hoops
to role his own solutions to try to implement
reasonable facsimilies of design patterns taken
for granted in real programming systems.
- I could go on...

And what of the noble Timer class you favour?
It's wonderful, if your idea of superior involves concepts such as "non-deterministic" (while, ironically, the very concept "Timer" stands for determinism) and "low-resolution".

Citing the Timer class as representing a "more efficient" and "cleaner" option than the by-contrast complete, well-designed, performant and correct threading semantics of Java, C#, et al., is absurd. Good grief, the Timer is second-order inadequate: it depends upon frame rate that depends upon the content rendered.

I suppose I've just sketched out some of what I'd like to say on this topic, but I'll have to leave it at that for the time being.