Ok, new vision: like Smalltalk and LISP debugging with support for single-threaded, multicore, and distributed applications. Different modes for different situations. Can run locally or remotely on a server. If distributed, on multiple servers in the cloud of your choosing. Just brainstorming here. We do want the baseline for 2018 at least as good as 1970’s-1980’s platforms, though.
Something like debugging in Inferno (and probably Plan 9). Mount the remote CPU and debug. Unfortunately Limbo didn’t have the power of Smalltalk with regards to “programming in a soup of live objects” feel.
Firstly, I don’t think debugging is treated as not a first-class activity:
Python 3.7 has just added the breakpoint() command, which can be specified to launch the developers preferred debugger.
In Javascript debugging via the browser developer tools is constantly improving. Pretty much every release of Chrome ships with an improvement or new feature. Performance tracing, memory profiling, async debugging, network condition simulation - I think non-JS developers might be surprised to find how powerful the developer tools have become.
VSCode introduced (I think) language servers to the mainstream, which has allowed languages that previously didn’t have IDE-based debugging to get it through VSCode.
Secondly, I’m not sure why Gitlab would be the platform that should support debugging? I think the author is complaining that debugging isn’t visible in places where I wouldn’t expect to see it anyway: An engineering workflow description, and a list of source control, CI, and code review features.
I think the author is complaining that debugging isn’t visible in places where I wouldn’t expect to see it anyway: An engineering workflow description, and a list of source control, CI, and code review features.
If not in an engineering workflow description, a CI solution, and a list of code review features; then where would you expect to see debugging next?
Well, interestingly, the workflow the author quotes doesn’t have a section about actually writing any code! It pretty much covers all the other stuff. But if “write the code” was there I would just expect debugging to be rolled into that, really. I wouldn’t expect a bullet point for “write the code” and another for “debug the code” - they’re both intrinsically part of the goal, which in terms of that workflow would probably be expressed something like “develop the feature” or “fix the bug”.
For Gitlab, I just don’t really see how debugging has got anything to do with it. If I’m working on debugging some code in my IDE I don’t see how my experience could be improved by anything in Gitlab. I’d love to head some ideas, though.
Now, I’m not saying debugging (and editing) code couldn’t be much better - I sure think it could be - but I just don’t think the two targets identified make much sense.
Because debugging is a necessary evil that should be minimized as much as possible. Ideally, debugger must be the last resort in preventing and fixing bugs.
On the one hand, no specification/implementation is perfect, bugs happen (especially in low-level and archaic languages). One of the signs of a novice programmer is thinking only about the happy path and writing code in the “I want to get it done” manner, without thinking about later readers who might want to understand the code. I find debug logging a great help in understanding other’s source code.
On the other hand, it is always better to prevent bugs than to fix them. The need to chase a specific run-time logic/spec violation should ideally be a lost cause already. There are expressive type systems, static analysis, borrow checking, immutability, high-level constructs, assertions, unit/integration testing that should prevent whole classes of bugs.
It is very easy to fall into “tunnel vision” in a large/legacy codebase, i.e. investigate a specific bug on a specific execution path only to fix this specific execution path, disregarding the big picture and architecture, not asking oneself “how come that this state is even possible?”. This usually leads to patchwork of small fixes that makes the code base even less coherent with time and produces even more bugs. Tools with focus on easy debugging usually encourage this style of programming.
P.S. I see a reference to a similar comment in the post and objection that not all debugging is interactive. I am happy with “we need more/better tools to understand the runtime behavior of a program” (e.g. valgrind, ThreadSanitizer, etc), but the word “debugging” already has a specific meaning and a bad reputation.
Ok, new vision: like Smalltalk and LISP debugging with support for single-threaded, multicore, and distributed applications. Different modes for different situations. Can run locally or remotely on a server. If distributed, on multiple servers in the cloud of your choosing. Just brainstorming here. We do want the baseline for 2018 at least as good as 1970’s-1980’s platforms, though.
Something like debugging in Inferno (and probably Plan 9). Mount the remote CPU and debug. Unfortunately Limbo didn’t have the power of Smalltalk with regards to “programming in a soup of live objects” feel.
Firstly, I don’t think debugging is treated as not a first-class activity:
Python 3.7 has just added the
breakpoint()command, which can be specified to launch the developers preferred debugger.In Javascript debugging via the browser developer tools is constantly improving. Pretty much every release of Chrome ships with an improvement or new feature. Performance tracing, memory profiling, async debugging, network condition simulation - I think non-JS developers might be surprised to find how powerful the developer tools have become.
VSCode introduced (I think) language servers to the mainstream, which has allowed languages that previously didn’t have IDE-based debugging to get it through VSCode.
Secondly, I’m not sure why Gitlab would be the platform that should support debugging? I think the author is complaining that debugging isn’t visible in places where I wouldn’t expect to see it anyway: An engineering workflow description, and a list of source control, CI, and code review features.
If not in an engineering workflow description, a CI solution, and a list of code review features; then where would you expect to see debugging next?
Well, interestingly, the workflow the author quotes doesn’t have a section about actually writing any code! It pretty much covers all the other stuff. But if “write the code” was there I would just expect debugging to be rolled into that, really. I wouldn’t expect a bullet point for “write the code” and another for “debug the code” - they’re both intrinsically part of the goal, which in terms of that workflow would probably be expressed something like “develop the feature” or “fix the bug”.
For Gitlab, I just don’t really see how debugging has got anything to do with it. If I’m working on debugging some code in my IDE I don’t see how my experience could be improved by anything in Gitlab. I’d love to head some ideas, though.
Now, I’m not saying debugging (and editing) code couldn’t be much better - I sure think it could be - but I just don’t think the two targets identified make much sense.
Because debugging is a necessary evil that should be minimized as much as possible. Ideally, debugger must be the last resort in preventing and fixing bugs.
On the one hand, no specification/implementation is perfect, bugs happen (especially in low-level and archaic languages). One of the signs of a novice programmer is thinking only about the happy path and writing code in the “I want to get it done” manner, without thinking about later readers who might want to understand the code. I find debug logging a great help in understanding other’s source code.
On the other hand, it is always better to prevent bugs than to fix them. The need to chase a specific run-time logic/spec violation should ideally be a lost cause already. There are expressive type systems, static analysis, borrow checking, immutability, high-level constructs, assertions, unit/integration testing that should prevent whole classes of bugs.
It is very easy to fall into “tunnel vision” in a large/legacy codebase, i.e. investigate a specific bug on a specific execution path only to fix this specific execution path, disregarding the big picture and architecture, not asking oneself “how come that this state is even possible?”. This usually leads to patchwork of small fixes that makes the code base even less coherent with time and produces even more bugs. Tools with focus on easy debugging usually encourage this style of programming.
P.S. I see a reference to a similar comment in the post and objection that not all debugging is interactive. I am happy with “we need more/better tools to understand the runtime behavior of a program” (e.g. valgrind, ThreadSanitizer, etc), but the word “debugging” already has a specific meaning and a bad reputation.
This is the first time I heard that debugging has a “bad reputation”. There must be a culture gap here.