> am I understanding you correctly that the big advantage of this technique is that it makes the initial reading of the codebase easier? But as soon as you need

> am I understanding you correctly that the big advantage of this technique is that it makes the initial reading of the codebase easier? But as soon as you need to do the „real work“ (a.k.a. debugging) you revert to the full source code anyway? No, I've seldom tended to look at the generated C++. It's an escape hatch of last resort. Mostly I live in layers. > how do you deal with unexpected interactions between layers, especially when you don‘t see all the layers as you implement a new one? If you're constantly having to think about interactions between layers, you probably are trying to over-use layers. Did you ever find yourself creating git commits that tend to change one line in some place and add a function someplace else? That's a sort of classic use case for layers. But I'm not sure I can convey this any more clearly through prose. Perhaps what would work is for you to try to read a codebase built in this way, to get a feel for what I use layers for. Candidate codebases: https://github.com/akkartik/mu#readme https://github.com/akkartik/mu#readme https://github.com/akkartik/mu1#readme https://github.com/akkartik/mu1#readme (an earlier prototype that uses very different mechanisms, and entirely different code)