Yes, I think so. In fact Haskell "effect systems" are a lot like "capability languages" in the sense that the restrict in a fine-grained way which parts of your codebase can perform which sorts of actions. My library Bluefin[1] takes this a step further and represents capabilities as value-level entities which you pass around to whoever needs the capability (and correspondingly, not to whoever doesn't need it). Bluefin calls capabilities "handles" (though I have wondered about renaming).

In fact, this passage from the article describes very closely what it is like to use Bluefin, yet I bet the author doesn't even know of Bluefin's existence! That makes me think I am on the right lines with my design.

> The first is that if you want the entire application to be written in an object-capability style then its main() method must be given a “god object” exposing all the ambient authorities the app begins with. You then have to write proxy objects that restrict access to this god object whilst implementing standard interfaces.

This part is too pessimistic, however:

> No language has such an object or such interfaces in its standard library, and in fact “god objects” are viewed as violating good object oriented design.

As you correctly point out, cryptonector, Haskell's IO is the "god object". It allows you to do roughly anything. And indeed Bluefin's runEff[2] gives you access to the god object (which is IO wrapped up in an effect (or "capability") called IOE). The rest of the program runs by "peeling parts off" this god object so it only uses the parts that it needs.

I have found this a very satisfactory way to program.

[1] https://hackage.haskell.org/package/bluefin

[2] https://hackage-content.haskell.org/package/bluefin-0.0.15.0...