Modules, Monoliths, and Microservices
&gt;By far the part we&#x27;re worst at is #1, isolation. If we could truly and efficiently isolate one bit of code from another, the other goals would mostly fall into place. But we simply do not know how.<p>This might sound a bit mean but the author hear lacks clarity in thinking and therefore really doesn&#x27;t know what he&#x27;s talking about.<p>We 100% know how to isolate code. In fact the primitive that guarantees this isolation is part of the name of this site: combinator. Isolated logic is literally the definition of a combinator.<p>If every line of your code was written as a combinator then all your code would be reconfigurable and modular to the maximum amount theoretically possible.<p>The hard lines drawn with physical hardware are largely irrelevant and only obscure the main point. It&#x27;s not relevant whether your code is isolated by a combinator or hardware acting like a combinator. There is no theoretical difference between using a virtual folder to group things or using a computer to group things.<p>The main issue with &#x27;isolation&#x27; then comes down to IO, because all IO related primitives cannot be part of a combinator by definition and IO is a required part of computation. (by IO I mean input&#x2F;output and shared mutable memory access)<p>The article doesn&#x27;t even mention this. The main problem with modularity is how to deal with it in the face of IO. Hence he&#x27;s not clear about what he&#x27;s talking about.<p>IO breaks modularity &amp; isolation and so does the use of anything that is not a combinator.