3 ms·
> 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
by sradman 6y ago
> 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 6y agoYeah, 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 6y agoI 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.
- sradman 6y agoNaming 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 6y ago“Component” might fit the bill.
- pjmlp 6y agoIn 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.