5 ms·

If you can move your code and spread it around it is Modular by definition. This is never a bad thing from a design perspective. It is only a bad thing from a c

If you can move your code and spread it around it is Modular by definition. This is never a bad thing from a design perspective. It is only a bad thing from a complexity and readability perspective. More likely you think it's a bad thing because your code isn't actually modular. Likely you need one piece of logic but that logic isn't modular so to move it to another location you need to drag a bunch of extra baggage around with it. You wanted a banana but instead you got the gorilla holding the banana and the entire jungle. Sound familiar? The smallest primitive that is modular is a pure immutable function. If the modules you are moving around are not pure functions then likely your code isn't actually modular.

sam0x17 5y ago
> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do this merely to get the linter to pass, instead of for the actual purpose of modularization.
- Jtsummers 5y ago
  Right. If A and B are coupled so tightly that one cannot exist without the other, you don't really have two modules. You have one, AB. This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). The latter is particularly pernicious in languages which don't have a clear separation between classes and modules (Java, for instance, or historically I think this has changed). The reality is that there are two (at least) kinds of modularity. "Syntactic" (I need a better name for this) modularity like Java classes, or C's translation units (why I need a better name). These act as modules, but don't necessarily define a real, proper module. And then there are your real modules which are comprised of the things that must exist together (like in the earlier example), regardless of the project structure or language's notion of a module. I had a team try to convince me their code was "modular" but their GUI portion was directly tied to the DB portion and other logic. Nothing could be instantiated separately, so it wasn't really modular, it was just using the language and build system's notions of modules to create the illusion of modularity (C++ and VS in their case). In contrast, another team had developed a collection of libraries (C# and VS again) that were used in multiple applications. That was real modularity.
  - deltasixeight 5y ago
    > This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). Exactly! The class is not the smallest unit of modularity. You unionize several pieces of mutable state with several functions (aka methods) in class based programming and if your unionization was a design flaw you're pretty much screwed. To make your code truly modular you need to break it down further. Separate state and function. To go even deeper make the function pure and make state immutable. Abstract mutability to a small unsafe portion of your code. >The reality is that there are two (at least) kinds of modularity. "Syntactic" (I need a better name for this) modularity like Java classes, or C's translation units (why I need a better name). These act as modules, but don't necessarily define a real, proper module. And then there are your real modules which are comprised of the things that must exist together (like in the earlier example), regardless of the project structure or language's notion of a module. The only true logic module is a stateless function that is independent of all context. Think on that, that is literally the smallest unit of logic that can be moved around anywhere. The problem here is how do you program in a way such that even for these functions are easily de-composable and rearranged without necessitating a rewrite in the case where you find the logic needs massive changes? Use point free programming with pure non-procedural functions solves this. The problem is mutability must happen somewhere and usually this is abstracted to a very small section of your code. >I had a team try to convince me their code was "modular" but their GUI portion was directly tied to the DB portion and other logic. Nothing could be instantiated separately, so it wasn't really modular, it was just using the language and build system's notions of modules to create the illusion of modularity (C++ and VS in their case). In contrast, another team had developed a collection of libraries (C# and VS again) that were used in multiple applications. That was real modularity. GUI programming is inherently hard as the state of the GUI is by nature muteable and it's hard to write modular code as a result. However modern programming frameworks generally get around this using the technique I outlined above, see React redux and MVU. https://guide.elm-lang.org/architecture/ https://guide.elm-lang.org/architecture/
  - josephg 5y ago
    Yes this. With I often think about questions like: - Is this code useful in other contexts? Are there other contexts where I might want this? (Or someone else might want this?) - Modules have a clear API boundary - Modules can be described independently of the code which uses them - Modules can (and should) have their own testing suite, independent of the test suite of the containing module There's lots of examples; but you can kind of spot code like this in your projects. It has a property of being disentangled. "This just solves this one specific problem I have with strings / event emitters / random numbers / my database, separate from anything else I'm trying to do". "I kinda want to just document this code separate from the documentation of everything else". "I don't want to pull that whole library in, but can I just steal these 3 functions for this other project?"
- deltasixeight 5y ago
  Read the 2nd paragraph of my post you replied to. You talk about true modularity and it is addressed in my second paragraph. If you find these problems with your code then the code was Never modular in the first place. Modular code involves writing code independent of context. One way of doing this is to wrap every expression in a pure functional context. Another way is to make every variable immutable. > I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. Doing this doesn't hurt. There's nothing stupid about it unless you coded everything in a way where it's NOT modular. Procedural programming is usually not modular because the results of a computation depend on the Order of the procedures. Immutable state is isomorphic to an expression so procedural code with immutable state solves the issue. Let's say I need a function to add 3 numbers. I impliment it like this: addThree = func(x, y, z){ return addTwo(x, y) + z} addTwo = func(x, y) {return x + y} You're saying addTwo is unecessary and pointless if it's not reused. I'm saying you can't predict the future, there may be a time where you need addTwo, but if you never need it, it doesn't really matter, you don't lose anything here. Modularity doesn't hurt the structure and organization of the code. It only effects qualitative aspects like how easy is it to interpret understand or read.
  - lostcolony 5y ago
    "it doesn't really matter, you don't lose anything here" Except you do. It's harder to understand and less readable; and in a real life rather than made up example, addTwo is in some other module entirely and has side effects that are completely invisible (in most languages) when just looking at addThree, making debugging and understanding WTF is going on far harder. You mention "pure functional context", and yet this whole thread exists under a post about OOP, which is all about state management; it's no good trying to create toy examples that are side effect free to try and dismiss the points being made. Yes, of course pure code is fairly trivial to slice and dice, and the cost of doing so tends to be low (not zero, but low), but that's not really what is being talked about. Otherwise you're kind of "no true Scotsman"ing this; "if you find these problems with your code than the code was never modular in the first place" - yeah, that's the point. Splitting code doesn't by definition make it more modular.

sam0x17 5y ago

> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do this merely to get the linter to pass, instead of for the actual purpose of modularization.

Jtsummers 5y ago
Right. If A and B are coupled so tightly that one cannot exist without the other, you don't really have two modules. You have one, AB. This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). The latter is particularly pernicious in languages which don't have a clear separation between classes and modules (Java, for instance, or historically I think this has changed). The reality is that there are two (at least) kinds of modularity. "Syntactic" (I need a better name for this) modularity like Java classes, or C's translation units (why I need a better name). These act as modules, but don't necessarily define a real, proper module. And then there are your real modules which are comprised of the things that must exist together (like in the earlier example), regardless of the project structure or language's notion of a module. I had a team try to convince me their code was "modular" but their GUI portion was directly tied to the DB portion and other logic. Nothing could be instantiated separately, so it wasn't really modular, it was just using the language and build system's notions of modules to create the illusion of modularity (C++ and VS in their case). In contrast, another team had developed a collection of libraries (C# and VS again) that were used in multiple applications. That was real modularity.
- deltasixeight 5y ago
  > This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). Exactly! The class is not the smallest unit of modularity. You unionize several pieces of mutable state with several functions (aka methods) in class based programming and if your unionization was a design flaw you're pretty much screwed. To make your code truly modular you need to break it down further. Separate state and function. To go even deeper make the function pure and make state immutable. Abstract mutability to a small unsafe portion of your code. >The reality is that there are two (at least) kinds of modularity. "Syntactic" (I need a better name for this) modularity like Java classes, or C's translation units (why I need a better name). These act as modules, but don't necessarily define a real, proper module. And then there are your real modules which are comprised of the things that must exist together (like in the earlier example), regardless of the project structure or language's notion of a module. The only true logic module is a stateless function that is independent of all context. Think on that, that is literally the smallest unit of logic that can be moved around anywhere. The problem here is how do you program in a way such that even for these functions are easily de-composable and rearranged without necessitating a rewrite in the case where you find the logic needs massive changes? Use point free programming with pure non-procedural functions solves this. The problem is mutability must happen somewhere and usually this is abstracted to a very small section of your code. >I had a team try to convince me their code was "modular" but their GUI portion was directly tied to the DB portion and other logic. Nothing could be instantiated separately, so it wasn't really modular, it was just using the language and build system's notions of modules to create the illusion of modularity (C++ and VS in their case). In contrast, another team had developed a collection of libraries (C# and VS again) that were used in multiple applications. That was real modularity. GUI programming is inherently hard as the state of the GUI is by nature muteable and it's hard to write modular code as a result. However modern programming frameworks generally get around this using the technique I outlined above, see React redux and MVU. https://guide.elm-lang.org/architecture/ https://guide.elm-lang.org/architecture/
- josephg 5y ago
  Yes this. With I often think about questions like: - Is this code useful in other contexts? Are there other contexts where I might want this? (Or someone else might want this?) - Modules have a clear API boundary - Modules can be described independently of the code which uses them - Modules can (and should) have their own testing suite, independent of the test suite of the containing module There's lots of examples; but you can kind of spot code like this in your projects. It has a property of being disentangled. "This just solves this one specific problem I have with strings / event emitters / random numbers / my database, separate from anything else I'm trying to do". "I kinda want to just document this code separate from the documentation of everything else". "I don't want to pull that whole library in, but can I just steal these 3 functions for this other project?"
deltasixeight 5y ago
Read the 2nd paragraph of my post you replied to. You talk about true modularity and it is addressed in my second paragraph. If you find these problems with your code then the code was Never modular in the first place. Modular code involves writing code independent of context. One way of doing this is to wrap every expression in a pure functional context. Another way is to make every variable immutable. > I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. Doing this doesn't hurt. There's nothing stupid about it unless you coded everything in a way where it's NOT modular. Procedural programming is usually not modular because the results of a computation depend on the Order of the procedures. Immutable state is isomorphic to an expression so procedural code with immutable state solves the issue. Let's say I need a function to add 3 numbers. I impliment it like this: addThree = func(x, y, z){ return addTwo(x, y) + z} addTwo = func(x, y) {return x + y} You're saying addTwo is unecessary and pointless if it's not reused. I'm saying you can't predict the future, there may be a time where you need addTwo, but if you never need it, it doesn't really matter, you don't lose anything here. Modularity doesn't hurt the structure and organization of the code. It only effects qualitative aspects like how easy is it to interpret understand or read.
- lostcolony 5y ago
  "it doesn't really matter, you don't lose anything here" Except you do. It's harder to understand and less readable; and in a real life rather than made up example, addTwo is in some other module entirely and has side effects that are completely invisible (in most languages) when just looking at addThree, making debugging and understanding WTF is going on far harder. You mention "pure functional context", and yet this whole thread exists under a post about OOP, which is all about state management; it's no good trying to create toy examples that are side effect free to try and dismiss the points being made. Yes, of course pure code is fairly trivial to slice and dice, and the cost of doing so tends to be low (not zero, but low), but that's not really what is being talked about. Otherwise you're kind of "no true Scotsman"ing this; "if you find these problems with your code than the code was never modular in the first place" - yeah, that's the point. Splitting code doesn't by definition make it more modular.