4 ms·

Why Small Modules Matter

2 points by fagnerbrack 11y ago

Someone 11y ago
"Conclusion By separating the concerns and trying to create more efficient abstractions, we can build a small amount of functions that are perfectly decoupled and reusable. This way we don't need to think too much when making changes to the domain." For me, that is the case for small _functions_, not small -modules_. The problem with small modules is that they run the risk of being slightly incompatible with each other. You create some object of type T with module X, pass it to module Y, but the modules disagree about 'minor' details of type T. Proponents will argue that both should build on a module defining T, but before you know it you are handing with types T, T', T'', etc. all being almost the same thing. Even if you don't, the modules will disagree about how to return errors, do logging, etc. That problem can be solved when one party packages a set of potentially well-interacting modules, removes redundant functionality, tweaks them to interact really well, and ships the result as a larger module. Now, that still can lead to many modules shipping overlapping coherent functionality. In that case, I think competition should drive competition from the market. It also can help if a large party uses his power in the market, as happened with Microsoft and .Net. Compared to Java, there's way less chance that you will find that you need two XML parsers or two different concurrent set implementations in your project (yes, in some cases that is 'solved' by making XML parsers or logging libraries pluggable, but I think that overcomplicates things. Because of that, I think there is some kind of "seven plus or minus two" equivalent for modules: they should form a tree that has a limited branching factor, so that both the top level module and all submodules build on not too many other modules (value of 'not too many' TBD) You don't see a C program do #include <strlen.h> ... #include <strcat.h> it just includes a single header that brings in a set of related functions, and lets the linker ignore unused ones. Of course, in the JavaScript world, there is no linker yet (or at least, proponents of tiny modules haven't (fully) realized that their minifier could/should strip out unused functions) so people waste time manually specifying exactly what to include. Also, the JavaScript world still lives in the Wild West, and it will be a while before larger libraries will start making sense. That JavaScript is so loosely typed doesn't help, but I expect that the move to Web Assembly (or whatever the idea is called nowadays) will see this change rapidly. That certainly will happen if/when entities start shipping web assembly binary blobs.
- fagnerbrack 11y ago
  Sorry to take so long to respond. Your arguments applies to modules that are external, not internal ones. The article specifically talks about internal abstractions, not abstractions that should be all exposed for external consumption (multiple projects). That is definitely up to the requirements. There is no difference between using a single module with many functions than using many functions inside a feature directory. I would argue the last one make the intent clear while not having to think about another searation (the module file).

2 points by fagnerbrack 11y ago

"Conclusion By separating the concerns and trying to create more efficient abstractions, we can build a small amount of functions that are perfectly decoupled and reusable. This way we don't need to think too much when making changes to the domain." For me, that is the case for small _functions_, not small -modules_. The problem with small modules is that they run the risk of being slightly incompatible with each other. You create some object of type T with module X, pass it to module Y, but the modules disagree about 'minor' details of type T. Proponents will argue that both should build on a module defining T, but before you know it you are handing with types T, T', T'', etc. all being almost the same thing. Even if you don't, the modules will disagree about how to return errors, do logging, etc. That problem can be solved when one party packages a set of potentially well-interacting modules, removes redundant functionality, tweaks them to interact really well, and ships the result as a larger module. Now, that still can lead to many modules shipping overlapping coherent functionality. In that case, I think competition should drive competition from the market. It also can help if a large party uses his power in the market, as happened with Microsoft and .Net. Compared to Java, there's way less chance that you will find that you need two XML parsers or two different concurrent set implementations in your project (yes, in some cases that is 'solved' by making XML parsers or logging libraries pluggable, but I think that overcomplicates things. Because of that, I think there is some kind of "seven plus or minus two" equivalent for modules: they should form a tree that has a limited branching factor, so that both the top level module and all submodules build on not too many other modules (value of 'not too many' TBD) You don't see a C program do #include <strlen.h> ... #include <strcat.h> it just includes a single header that brings in a set of related functions, and lets the linker ignore unused ones. Of course, in the JavaScript world, there is no linker yet (or at least, proponents of tiny modules haven't (fully) realized that their minifier could/should strip out unused functions) so people waste time manually specifying exactly what to include. Also, the JavaScript world still lives in the Wild West, and it will be a while before larger libraries will start making sense. That JavaScript is so loosely typed doesn't help, but I expect that the move to Web Assembly (or whatever the idea is called nowadays) will see this change rapidly. That certainly will happen if/when entities start shipping web assembly binary blobs.

fagnerbrack 11y ago
Sorry to take so long to respond. Your arguments applies to modules that are external, not internal ones. The article specifically talks about internal abstractions, not abstractions that should be all exposed for external consumption (multiple projects). That is definitely up to the requirements. There is no difference between using a single module with many functions than using many functions inside a feature directory. I would argue the last one make the intent clear while not having to think about another searation (the module file).