> So, we should just "agree to disagree" and stop trying to demonstrate how one approach might be much better over another? How can anything ever get better?
No, we should try to make things better. But framing these choices as "complexity" doesn't seem to be helpful. The choices are tradeoffs but they're not a deliberate choice of complexity for the sake of some other value; at most they're choices between different kinds of complexity, and maybe not even that much.
> It also dedicates an entire section to defining "complexity" as used throughout, so there's no ambiguity there.
And yet I used that same definition but came to opposite conclusions when applying it to the original author's examples.
I also don't see anything in The Complexity Trap that accuses anyone of that. I think that's a misreading.
Rather, I think The Complexity Trap argues that many developers have a poor understanding of what "complexity" means, so they end up increasing it even when they think they are decreasing it. Specifically, I think the point it tries to make is that complexity doesn't equate to verbosity, and simplicity doesn't equate to terseness. That's why it starts by defining complexity in terms of coupling.
Your article seems to agree that DTOs are more decoupled because you refer to it as "cargo cult decoupling", yet you still argue it's more complex. So you aren't using the same definition.
Having said that, I do agree with you that blind "decoupling" is definitely not always the answer, and some things should be coupled. When a change in one thing should always cause a change in the other, purposely coupling those things in code can decrease complexity.
But I wouldn't say coupling your public API to your internal model by generating the former from the latter is one of those cases. It's something that's done for convenience and terseness, at the expense of complexity. (It's more complex because changes that would otherwise be simple refactorings could cause breaking changes for consumers of your public API in ways you would not expect. For example, you won't be able to use automated refactoring tools safely without carefully thinking through the consequences in your head.)
Depending on the project, trading complexity for terseness/less boilerplate might be the right decision. But it should be done consciously.
> Your article seems to agree that DTOs are more decoupled because you refer to it as "cargo cult decoupling", yet you still argue it's more complex. So you aren't using the same definition.
Well I'm using the same definition as the second section of The Complexity Trap, where it considers introducing an effect algebra to be increasing complexity.
Whatever tradeoff is made by introducing DTOs is in some sense the same as the one that's being made by introducing a free monad or tagless final - more verbosity and less coupling. But The Complexity Trap seems to think that verbosity is more complex than coupling half the time, and coupling is more complex than verbosity the other half of the time. So framing either as "trading complexity for ..." is unhelpful.
No, we should try to make things better. But framing these choices as "complexity" doesn't seem to be helpful. The choices are tradeoffs but they're not a deliberate choice of complexity for the sake of some other value; at most they're choices between different kinds of complexity, and maybe not even that much.
> It also dedicates an entire section to defining "complexity" as used throughout, so there's no ambiguity there.
And yet I used that same definition but came to opposite conclusions when applying it to the original author's examples.