There's a book I like called "Design Rules: The Power of Modularity"; it was written by some business professors in 2000 and is loosely about the industrial organization and the history of IBM's System/360 (the first "modular computer family") and more generally about how modularity enables innovation and growth.

They enumerate what they call "modular operators" which are basic ways components can be broken down:

* "splitting" a design into modules

* "substituting" one module design for another

* "augmenting" adding a new module to the system

* "excluding" a module from the system

* "inverting" to create new design rules

* "porting" a module to another system

It doesn't matter here whether the modules are computer programs, hardware components, business units, or companies in an industry (Intel, AMD, RAM manufacturers...).

Modularity is a core part of the Unix philosophy. Unix itself is an operating system and involves some particular concepts (pipes, files, processes).

It seems obvious that the concepts for an operating system (pipes, files) will be less relevant in a different domain (say, web programming).

(I don't mean to reopen the entire microservices vs. monoliths debate, but it's of course relevant.)

While I agree that maybe the Unix abstractions aren't appropriate for new problems in different domains, I think some parts of the Unix philosophy (i.e. modularity and compositionality) still deserve consideration.

Thanks for the reference to that book. I need to check it out now.

Have you ever used a mainframe OS like MVS, or the z/OS or earlier versions of it?

> “purity” is holding us back and closing our mind to new solutions.

Maybe. But consider shebang. It means that any program (/script) written in any language known by the system can call any other program written in any other language. That keeps open the option of which laguage should we use for our next module. Right?

That's an constrained example of the general concept of a file-association (having a file plus the info of what application executes that file).

As such, it predates UNIX, exist in other OSes as well, and can be even more dynamic (as shebangs are hardcoded into the file, where file + executable associations could be external).

Linux offers another way anyway: linux_binfmt

If I'm not mistaken that's also how jar files can be executed by themselves without calling java on them.

It is nifty and mind-blowing. It basically means there is a way to "call" a program-file and let it decide who should interpret the program.

It is not too different from the way in which html-pages can declare what is the character-set that should be used to interpret the binary contents of the file. The deep thing to me is that programs can not only encode instructions for the computer, they can also encode how to do the decoding. Obviously you then need some common convention (like shebang) to say how you can interpret the part that tells how to interpret the content.

There would be a step anyway between the user selecting even a regular binary executable (via pressing enter after writing its name on the shell, by double-clicking on it in a desktop file manager, by running a shell script which on some line invokes it, etc) and it starting to execute (the shell or GUI would have to interpret the action and tell the OS to execute the binary).

So adding an intermediary to do a choice of executor and/or handover in between (whereas at the shell/file-manager level, or at the OS call level), but still before execution, is quite easy.