5 ms·

Because you cannot predict the future of your program. Coupled logic that seems correct now may need to be uncoupled in the future. By having every sector of l

Because you cannot predict the future of your program. Coupled logic that seems correct now may need to be uncoupled in the future. By having every sector of logic be ungrouped it leads to maximum reusability for the future. Technical debt is at the lowest possible level in projects where every piece of logic is uncoupled. In fact the very phenomenon of Technical debt arises from logic that's hard to uncouple. By having every sector of your program be a lego brick you are preparing your program for an inevitable future where the structure must be reconfigured. Grouping logic together is like super gluing lego bricks together because it seems like they belong together. There's a term for this style of coding that's actually negative. It's called ravioli code. But the negativity mostly applies to when this style of coding is used in OOP.

AnimalMuppet 6y ago
Very, very wrong. > In fact the very phenomenon of Technical debt arises from logic that's hard to uncouple. No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see what's actually going on. > By having every sector of your program be a lego brick you are preparing your program for an inevitable future where the structure must be reconfigured. This is like economists, who have correctly predicted nine of the last two recessions. Sure, you're prepared for when the change comes (if you can find where to make it - see above). You've also prepared for all the changes that never come. That's rather wasteful. > Because you cannot predict the future of your program. Coupled logic that seems correct now may need to be uncoupled in the future. Sure, it may. And when that happens, we'll decouple it. And in the meantime, we'll enjoy the coupling that, at the moment, is the correct thing. See, this is all in the context of SOLID, the very first piece of which is "Single Responsibility". We don't couple things on a whim.
- lerptime 6y ago
  No you're very wrong. >No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see what's actually going on. All this logic must exist regardless of whether it's coupled or uncoupled. You do not alleviate the logical burden by coupling logic together or uncoupling the logic. If you call this "technical debt" then you cannot get rid of it. Why even call it debt then as logic is intrinsic to application. In fact decoupling logic can improve readability as it marks each piece of logic with a contextual function name. Either way you do not alleviate complexity by coupling logic. You alleviate this complexity problem by providing logical layers, using namespaces, and using good function naming. Coupling logic into Objects does nothing objectively as it does not eliminate complexity it only makes sure that the complexity is LESS modular. Let's be clear though. I am saying that the lower levels of your application should be ALL uncoupled logic. Then you build logical layers on top of your primitives that consists of compositions of your logic that build higher and higher. So a person on layer 5 only needs to go to layer 4 to understand it, and does not need to go to layer 1 to understand every primitive. >This is like economists, who have correctly predicted nine of the last two recessions. Sure, you're prepared for when the change comes (if you can find where to make it - see above). You've also prepared for all the changes that never come. That's rather wasteful. Analogies don't offer proof of an argument. Additionally it's not a good analogy. Economists don't completely understand what causes recessions and how to prevent them. We do, however, completely understand the difference between uncoupled logic and coupled logic. >Sure, it may. And when that happens, we'll decouple it. And in the meantime, we'll enjoy the coupling that, at the moment, is the correct thing. This is the main point of tech debt. It is hard to decouple. You can have all logic decoupled at the lowest layer and still have everything be readable. I think the previous sentence is just a type of programming you haven't dealt with. You've never wrote a program with decoupled logic that was readable. Think deeper. There is no reason why coupled logic should be more readable then decoupled logic. The Logic still exists either way, you either compose two modules and give it a name or you don't even use modules shove all your logic into a module with a single name. >See, this is all in the context of SOLID, the very first piece of which is "Single Responsibility". We don't couple things on a whim. The problem is OOP does this all the time. It couples state with logic. These two things should be uncoupled.
jdmichal 6y ago
I think you're basically describing the idea of having pure computations on pure data objects as much as possible? In which case, I believe that's fairly idiomatic in functional languages. And it's becoming more common in languages like C# and Java that started out OOP but have introduced enough functional niceties to make that style more idiomatic. I've been doing it in Java for at least three years. Here's a comment I wrote about it from then: https://news.ycombinator.com/item?id=14687947 https://news.ycombinator.com/item?id=14687947

AnimalMuppet 6y ago

Very, very wrong. > In fact the very phenomenon of Technical debt arises from logic that's hard to uncouple. No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see what's actually going on. > By having every sector of your program be a lego brick you are preparing your program for an inevitable future where the structure must be reconfigured. This is like economists, who have correctly predicted nine of the last two recessions. Sure, you're prepared for when the change comes (if you can find where to make it - see above). You've also prepared for all the changes that never come. That's rather wasteful. > Because you cannot predict the future of your program. Coupled logic that seems correct now may need to be uncoupled in the future. Sure, it may. And when that happens, we'll decouple it. And in the meantime, we'll enjoy the coupling that, at the moment, is the correct thing. See, this is all in the context of SOLID, the very first piece of which is "Single Responsibility". We don't couple things on a whim.

lerptime 6y ago
No you're very wrong. >No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see what's actually going on. All this logic must exist regardless of whether it's coupled or uncoupled. You do not alleviate the logical burden by coupling logic together or uncoupling the logic. If you call this "technical debt" then you cannot get rid of it. Why even call it debt then as logic is intrinsic to application. In fact decoupling logic can improve readability as it marks each piece of logic with a contextual function name. Either way you do not alleviate complexity by coupling logic. You alleviate this complexity problem by providing logical layers, using namespaces, and using good function naming. Coupling logic into Objects does nothing objectively as it does not eliminate complexity it only makes sure that the complexity is LESS modular. Let's be clear though. I am saying that the lower levels of your application should be ALL uncoupled logic. Then you build logical layers on top of your primitives that consists of compositions of your logic that build higher and higher. So a person on layer 5 only needs to go to layer 4 to understand it, and does not need to go to layer 1 to understand every primitive. >This is like economists, who have correctly predicted nine of the last two recessions. Sure, you're prepared for when the change comes (if you can find where to make it - see above). You've also prepared for all the changes that never come. That's rather wasteful. Analogies don't offer proof of an argument. Additionally it's not a good analogy. Economists don't completely understand what causes recessions and how to prevent them. We do, however, completely understand the difference between uncoupled logic and coupled logic. >Sure, it may. And when that happens, we'll decouple it. And in the meantime, we'll enjoy the coupling that, at the moment, is the correct thing. This is the main point of tech debt. It is hard to decouple. You can have all logic decoupled at the lowest layer and still have everything be readable. I think the previous sentence is just a type of programming you haven't dealt with. You've never wrote a program with decoupled logic that was readable. Think deeper. There is no reason why coupled logic should be more readable then decoupled logic. The Logic still exists either way, you either compose two modules and give it a name or you don't even use modules shove all your logic into a module with a single name. >See, this is all in the context of SOLID, the very first piece of which is "Single Responsibility". We don't couple things on a whim. The problem is OOP does this all the time. It couples state with logic. These two things should be uncoupled.

jdmichal 6y ago

I think you're basically describing the idea of having pure computations on pure data objects as much as possible? In which case, I believe that's fairly idiomatic in functional languages. And it's becoming more common in languages like C# and Java that started out OOP but have introduced enough functional niceties to make that style more idiomatic. I've been doing it in Java for at least three years. Here's a comment I wrote about it from then: https://news.ycombinator.com/item?id=14687947 https://news.ycombinator.com/item?id=14687947