(author here) I will probably write more about this, but it's not just modularity, or interfaces. Or at least those words are clouded by associations with spec

(author here) I will probably write more about this, but it's not just modularity, or interfaces. Or at least those words are clouded by associations with specific mechanisms in whatever programming languages one has used One additional distinction that's relevant is strong vs. weak modules in the sense here: https://thunderseethe.dev/posts/whats-in-a-module/#strong-vs-weak-modules https://thunderseethe.dev/posts/whats-in-a-module/#strong-vs... Some of my comments here - https://lobste.rs/s/eccv1g/what_s_module https://lobste.rs/s/eccv1g/what_s_module and here - https://lobste.rs/s/u7y4lk/modules_matter_most_for_masses https://lobste.rs/s/u7y4lk/modules_matter_most_for_masses Harper doesn't use the term "strong modularity", but he says that REAL modularity is M x N, and that's closer to what I'm getting at: https://existentialtype.wordpress.com/2011/04/16/modules-matter-most/ https://existentialtype.wordpress.com/2011/04/16/modules-mat... To be most useful, it is important that the relationship between M and A be many-to-many, and not many-to-one or one-to-one. (Although I disagree with the assertions about static types -- I think he is making a very domain specific argument, nonetheless we agree on strong modularity) It needs more analysis, but I'd claim there are at least two kinds of modularity and programming to interfaces, but the difference is not clear to most people The interior vs. exterior distinction is a big one -- is the interface "owned by" one party, or does it stand alone? Are you able to do "interior" refactorings that change the interface, or is it fixed, outside the project? This is a big difference in practice