&gt; OOP approach means that my process needs to know how to communicate with other processes via very specific protocols, which aren&#x27;t very well defined (any process could describe its type of object).<p>That&#x27;s why we have IDL -- interface description language for RPC calls. An IDL-to-X (usually C) compiler generates the necessary glue so that anybody can talk to the program in question. IDL is also the basis of MS COM, which I quite like from the design standpoint.<p>&gt; The usefullness of tools like grep or sed would drop drastically, and we would fall back to big blobs of software.<p>So you teach grep to take an IDL file, invoke an IDL compiler and dynamically load the parser for the protocol in question.  Also, if the broker were a standardized, perhaps in-kernel component (dbus, kdbus), you could attach &quot;idlgrep&quot; to <i>any</i> process to trace its calls. You wouldn&#x27;t be restricted to pipes.<p>&gt; Since I&#x27;m just passing data, do I really need the behavior attached to it? How would state persistence be handled?<p>The parent&#x27;s wording was a bit unfortunate. You can have interfaces and interface inheritance and versioning (the &quot;OOP&quot; part), but there&#x27;s no behavior send between processes.<p>&gt; With object how many &quot;translator&quot; (C in the example) would you need to acheive the same result?<p>Exactly one: the IDL compiler.