[chhickman]

The original promise of separation of concerns wasn't simply a code organization scheme, it was that we would be able to write composable software where components could be added or replaced with minimal systemic impact. We were going to be able to drop in new UIs without touching the BL or fix a bug in a component in one place and have it fixed everywhere, etc. The problem was that SoC, and the other various concepts from SOLID and design patterns didn't quite accomplish that - inter-dependencies remained and only became more difficult to reason about. Chasing this fantasy led object oriented programming down a path of increasingly complicated frameworks to try to manage and hide these dependencies until one would find themself thinking more about program structure and writing more plumbing code than doing actual work. Worse, now you have all the bits of logic necessary to understand how something works spread across multiple files so you have to have a system-wide understanding of a systems organization and understand the workings and vagaries of the half dozen or so different frameworks that were used to make it all seem magically loose-coupled. I'm sure there's some <insert name>'s Law somewhere that states it better, but it boils down to the fact that for any given set of tasks you can only reduce the complexity so much and anything else is just moving the complexity around, not eliminating it. I think there's something to be said for having all the logic you need to understand an interface in one or two files and focusing on making that as clean as possible, which is exactly what (at least some) of the 4GLs in the past seemed to do well, or at least made possible.