Internal consistency and interfaces

We can think that our development effort hinges on single language implementations, lack of context switching, etc. But what really allows us to be effective is when the modules that we use, as well as those we create, have a deterministic, internal consistency and provide reliable interfaces with adherence to a standard interface policy.

That is, if I am utilizing a module that makes use of a simple npm install for managing its dependencies, I may therefore make the assumption that I may make use of that module as a dependency which itself can be utilized within my module/app with a similar level of consistency. This is not always the case.

If you followed the link above, know that I have lasting admiration for the developers on that project, and I am humbled by all they have accomplished. But touting the library as a module within the npmjs registry was a source of confusion for me.

It takes much effort to ensure that every function that composes our module, and the module itself, is internally consistent. But the point at which our module must interface with another, is the point at which we should not have to worry about the internal implementation specifics of the other, but should be able to bank on its internal consistency and provision of standard interfaces.

So in the end does it matter whether our architecture is written all in one language, or is it the interface points which deserve our attention? Mixed architectures may well be perfectly viable. And we may begin to see this sooner rather than later as WASM becomes implemented in browsers. It seems perfectly likely that modules written in C++, Python, etc. will compile to the target and may be expected to interface in standard ways to reduce friction.