[sradman]

> IMO this is a confused take on modularity.

You are restricting the scope of what we call a “module” to language runtime modules while the OP has expanded the scope to include things like network tiers and processes with an IPC interface.

I found the OP's perspective both new and useful.

[ignoramous]

Yeah, that and the author made it clear in the opening paragraph that that they are viewing "modularization" from a Systems Design point-of-view and not software engineering per se.

[kpmah]

I think what I'm trying to say is that my definition of a module as a "unit of encapsulation or understanding" is the more inclusive and general one, as it includes network and process boundaries. The OP's use of the word is the restrictive one because it excludes language-level modules. I say this because security and isolation are not typically goals of language-level modules.

This is fine to talk about, of course. It's just confusing to reconcile the article with my definition of modules, which I thought to be the common one.

[pjmlp]

In some languages, like Modula-2, modules and libraries are exactly the same unit of measure.

You just don't group multiple modules into a single library.

Well you kind of can with sub-modules, but at the end of the day the binary library is generated exactly the same way.

[sradman]

Naming things is hard. My purpose was to emphasize the need to juggle the two definitions when assessing the article. We need a better word for the deployable unit of code that the OP calls a “module".

[layer8]

“Component” might fit the bill.