>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 don't lose anything from a hard structural standpoint. Readability and being harder to understand is an opinionated based metric. It can be influenced by how you even name a function. It is a soft metric therefore weaker than the hard one. Additionally I DO mention the qualitative opinionated cost of modularity several times in this thread. So I address it but it is definitively weaker because anyone can have an opposite opinion and say that "in my opinion modular code is more readable"
>You mention "pure functional context", and yet this whole thread exists under a post about OOP,
Did you read the article? The author of the article was not convinced by OOP, he never supported OOP and generally the entire article is critical of OOP. I would say my reply is highly relevant and that you didn't read the article.
>it's no good trying to create toy examples that are side effect free to try and dismiss the points being made.
The examples serve a purpose to illustrate my point not to illustrate a real world example. If you want a real world example look at the react + redux architecture. The gold standard model for all web UIs exactly do what I mention with state management. They completely separate State away from pure functions. The entire web generally follows this model abstracting state management away from even code. Web apps are stateless with the database handling the entire job of state management. Examples of this pattern are EVERYWHERE, the example I gave is a toy example to help you understand not to say "hey this is a real world application." I thought that was obvious, my fault for not being clear on that.
>yeah, that's the point. Splitting code doesn't by definition make it more modular.
The definition from above says: "Broadly speaking, modularity is the degree to which a system's components may be separated and recombined, often with the benefit of flexibility and variety in use"
If you are "splitting" code then by definition you are separating code which was previously combined. By Definition it is more modular. You really can't argue this point. More likely what's going on here is you have your own personal fuzzy definition of modularity which you are unconciously combining with your opinionated view on what constitutes good code. I am using the english definition not some fuzzy notion of good code so I am definitively right.
Be more exact and formal with your terminology it will lead to much less misunderstandings.
From the Wikipedia link you provide - "modularity is the degree to which a system's components may be separated and recombined"
Lines of code != system's components.
It's why we don't split a 20 line function into twenty 2 line functions (where the first line is one of the original, and the second is the call to the next function), and no one would say that doing so has made the code more modular.
This is itself backed by the wikipedia link, 'In software design, modularity refers to a logical partitioning of the "software design" that allows complex software to be manageable for the purpose of implementation and maintenance. The logic of partitioning may be based on related functions, implementation considerations, data links, or other criteria'; what we have done by splitting up the code this way has not helped it be more manageable.
So no, by the definitions you yourself cited, splitting up the code does not translate to more modular code.
Did I say this? No. Does this have anything to do with the conversation? No.
>It's why we don't split a 20 line function into twenty 2 line functions (where the first line is one of the original, and the second is the call to the next function), and no one would say that doing so has made the code more modular.
You think of logic as procedural lines of instructions. Procedural lines of instructions are not modular. If you think like this, none of your code is ever truly really modular. All code should be writable in one line. You split into several lines ONLY for readability, but your core logic should easily be isomorphic to one line code.
If your code doesn't share this isomorphism then none of your code is modular.
Inevitably you have to eventually address the procedural nature of the world in your code. When this case arises you have to abstract this all away to the smallest section of your code as possible.
>what we have done by splitting up the code this way has not helped it be more manageable.
Modularity and Manageability ARE TWO different words with two different definitions.
Wikipedia in this case is just being dumb and fuzzy with it's definitions. Right above your cited link it has an alternative definition that is in direct conflict with the one you stated. Modularity in modular programming is different from modularity in software? Come on. This is stupid.
Let's not play pedantic games here. Modularity and Managability are different. We know this. No need to play games. Combining the two into one thing is a lack of coherence. Be coherent.
When you take one thing and split it into two things. The two things are modules and thus more modular than the one thing. That is simple intuitive and clear.
You don't lose anything from a hard structural standpoint. Readability and being harder to understand is an opinionated based metric. It can be influenced by how you even name a function. It is a soft metric therefore weaker than the hard one. Additionally I DO mention the qualitative opinionated cost of modularity several times in this thread. So I address it but it is definitively weaker because anyone can have an opposite opinion and say that "in my opinion modular code is more readable"
>You mention "pure functional context", and yet this whole thread exists under a post about OOP,
Did you read the article? The author of the article was not convinced by OOP, he never supported OOP and generally the entire article is critical of OOP. I would say my reply is highly relevant and that you didn't read the article.
>it's no good trying to create toy examples that are side effect free to try and dismiss the points being made.
The examples serve a purpose to illustrate my point not to illustrate a real world example. If you want a real world example look at the react + redux architecture. The gold standard model for all web UIs exactly do what I mention with state management. They completely separate State away from pure functions. The entire web generally follows this model abstracting state management away from even code. Web apps are stateless with the database handling the entire job of state management. Examples of this pattern are EVERYWHERE, the example I gave is a toy example to help you understand not to say "hey this is a real world application." I thought that was obvious, my fault for not being clear on that.
>yeah, that's the point. Splitting code doesn't by definition make it more modular.
Completely and utterly wrong. Splitting code by definition makes it more modular. See: https://en.wikipedia.org/wiki/Modularity
The definition from above says: "Broadly speaking, modularity is the degree to which a system's components may be separated and recombined, often with the benefit of flexibility and variety in use"
If you are "splitting" code then by definition you are separating code which was previously combined. By Definition it is more modular. You really can't argue this point. More likely what's going on here is you have your own personal fuzzy definition of modularity which you are unconciously combining with your opinionated view on what constitutes good code. I am using the english definition not some fuzzy notion of good code so I am definitively right.
Be more exact and formal with your terminology it will lead to much less misunderstandings.