I like this article -- its accurate and describes real pain points in the existing debugger experience which _do_ have technical causes that might ultimately de

I like this article -- its accurate and describes real pain points in the existing debugger experience which _do_ have technical causes that might ultimately derive from language/ecosystem design flaws. I'm curious to see what the author's team is building. I'm quite excited to see language-level adoption of debugger features. It's unfortunate to me that debugger's are mainly bolted onto the side of language's with (at best) convention-based 'semantics' baked into the compiler/interpreter implementation. With the interface to 'debugger semantics' completely outside the code and with at most a language-level 'debugger' statement that is basically equivalent to adding a non-conditional breakpoint. How about a language with a debugger() {} block so that the full logic for logpoints, breakpoints, conditional breakpoints can be persisted in the source rather than in inherently non-scalable ide gui -- and specified as part of the language design? How about something like debugger() { setRewindTarget("point1") } -- for capturing a particular program state in a returnable way -- with perhaps some semantics/heuristics around the behavior of common abstractions which interface with out-of-process contexts (sockets and files) -- and/or the ability to specify what you want to happen to those kinds of resources inside the debugger {} block so that you can quickly create exactly the rewind behavior you want for a particular task. How about more dynamic and easily queryable debugger contexts: 'break on first execution of each line in each function in project (for reading a new codebase)', 'break on first execution of code changed in last n commits', 'break on code written by author according to git blame' ... How about features for augmenting print() based debugging. Baked the semantics needed to support a value-history inspector into the language implementation. A program should be able to describe 'debuglog(matrix as image)', 'debuglog(object as tree view)' and the _language_ should ensure the program is compatible with a debugger protocol able to communicate with an appropriate rendering context capable of displaying these in a useful way ...