[adamjernst]

For webapps, I agree. There is no progression of state in a webapp's "controller" object: it's one shot and done.

For native apps in frameworks like Cocoa Touch of course it's an entirely different ballgame. A view controller has quite a bit of state, usually some different modes, maybe some enforced state transitions. So the controller pattern makes a lot of sense there.

The author is spot on about how some architectural oddities like one-method-classes come from Java's lack of functions as first class objects.

[eevee]

Oh, sure. I don't mean "controller" necessarily in the sense of MVC; just the idea of using a class as a bag of unrelated functions. Web frameworks trying to be MVC happen to be the most egregious offenders.[1] I'd actually forgotten that I made up the name "controller pattern". :)

[1] I blame this on MVC not making sense for Web backends; the controller is supposed to make sense of a stream of realtime user actions, but that doesn't apply so well to the discrete request/response model of HTTP. Your URL layout itself is, in effect, already doing most of the work of a GUI controller, and what's left is a relatively small bit of glue between the model and view. (Pyramid even bills itself as an MV framework; it refers to request handlers as "views", rather than reserving the name only for templates.)