Right. My point is that you have to make your operations fit within that language. As opposed to the object metaphor, where you get to define the language however you want.

Very similar to the REST versus SOAP/whatever paradigm. Neither one should be more capable than the other. In fact, REST should be the more restrictive choice. Right?

Now try to do real time 3D graphics with those operations.

Plan9 window manager is not an example of performance.

Depending on how it's implemented, there's no real reason why it couldn't be done. For example, I could create SceneGraph_fs, which exposed the scene graph of objects as a directory hierarchy. The filesystem's toplevel directory would be organized with a /scenegraph/ directory for the scenegraph, /lights/ for the light models, and /tmp/ for a scratch space for constructing objects and staging them to be added. Each node in the scene graph would be represented by a directory under /scenegraph/ which contained one file for each distinct chunk of data the graphics engine would need to know (like a position matrix, an orientation matrix, a mesh model, a texture map, etc., depending on whether or not the directory represented a model or a transformation).

For data in /scenegraph/, SceneGraph_fs would accept well-formatted writes to a node's files as a means to update the node in the scene--for example, to translate the node, you would write a new matrix to the object's positional matrix file (the write() would return EPERM if the matrix was malformatted). To create or modify an object atomically, you could describe it under /tmp/ in SceneGraph_fs, and rename() it into place. You could manage lights and lighting data in the same way.

Of course, the graphics card interfacing happens in filesystem implementation. But, the application interacts with the scenegraph as a filesystem, not as an object.