(no title)
Verdex_3 | 7 years ago
Personally, I want a mathematical structure of "problems" such that we can track when we're actually making things more complex or less complex. In the article, removing boilerplate was a problem because internal domain models were being exposed publicly. But what I really want to know is "what are we actually gaining by removing the boiler plate and what are we losing by exposing domain models". In like a general mathematical sense such that if everyone about programming changes (maybe suddenly we switch to APL or something), the lessons we learned are still valid.
So far the best I've managed is [1]. I've done a bunch of refinement in the last year and a half, but the general structure is about the same. I'm not suggesting that what I have is complete or even necessarily the right direction to go for this sort of thing. But what I am saying is that in order to make definite statements about how the problem and/or code you're dealing with is complex (that don't rely on appeals to authority) then you probably need to have done at least as much "work" as I have (if that makes any sense).
[1] - https://www.sep.com/sep-blog/2017/04/25/objective-code-quali...
skohan|7 years ago