Given that: There are two types of code: Code that implements the “domain logic,” and code that implements various abstractions used by the do an logic. I sug

Given that: There are two types of code: Code that implements the “domain logic,” and code that implements various abstractions used by the do an logic. I suggest that: We need to be able to both debug the domain logic and the abstractions implementation independently of each other. ——- In simpler days, the above was accomplished with feature like “step over,” or, “run until.” We simply skipped over the lines of code in functions that were “beneath” the level of abstraction that interested us. Today, there are many deep layers of abstractions, and sometimes important things happen within them. Similarly, our data itself is wrapped up in bundles of abstractions, and sometimes we need a way to view that data as an abstraction, at other times we need to “drill down.” We have sophisticated tools for building abstractions in code, and we have a way of bolting some of that onto the debugger by means of source code mapping. But that is not enough. We need more sophisticated ways of stepping through our domain code that understands the abstractions it is hiding. We need to be able to write a framework or library, and write debugger extensions to go with it, just as we write extensions for our compiler toolchain. That way, we can build abstractions that can be “stepped over” in the debugger as easily as we can write our code in abstractions in the editor. ——- I think everyone realizes this and is rushing to implement point solutions here and there, like special cases for async stack traces when you use JS’ built-in async/await. And the author is hinting at an important “special case” for React. I suspect that we need a more general facility for meta-debugging, much as macros are a more general facility for meta-programming.