3 ms·

So 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 nee

by veddox 7y ago

So 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? I have to admit I don‘t have a whole lot of experience with large codebases, but this seems a bit like premature optimisation. (After all, this is just pushing the work of really understanding the code base away from the initial reading phase and on to the actual debugging/extending - which is the phase most work is done in.) Also, how do you deal with unexpected interactions between layers, especially when you don‘t see all the layers as you implement a new one?

akkartik 7y ago
> 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)

by veddox 7y ago

akkartik 7y ago

> 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)