On 19 December 2014 at 18:56, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 12/17/2014 12:30 AM, Manu via Digitalmars-d wrote: >> >> If vibe.d didn't crash, *or* if the debugger actually worked (such >> that we could have debugged the crash), then we would have surely >> stuck with that. >> But we couldn't get behind a solution that was impossible to debug. > > > I've debugged a lot of D code with no debugger at all (how else could I port > it to various platforms like Win64?). > > I've actually not found debuggers to be of much use other than telling me > where the seg fault was and giving a stack trace.
Perhaps this is habit, retained from a time where the tooling was unreliable? You probably haven't spent the majority of your career in an environment where you could reliably rely on them, and then as a result, never came to rely on them? Debuggers are for quickly verifying code flows as expected, and inspecting the broader state at a point of failure. Stepping through code and watching as it goes, quickly and easily validating that all the variables are in their appropriate states, etc, is invaluable. Surely you can't argue that halting at point of crash, then immediately being able to comprehensively inspect the surrounding context, identifying things that were outside of the expected state, etc, is going to be faster and easier than crashing, making some guesses as to what the problem may have been, inserting a bunch of logs to print out the values of stuff (rather than just inspecting them in-situ), and running again, hoping that the crash is reliably reproducible, and that you instrumented the right stuff. It might be too that realtime software devs come to rely on debuggers more than others? Execution is completely non-deterministic. Bugs are often not reliably reproducible, tend not to manifest in the same places at the same times. It could be too that leading the program into the state where the crash occurs takes a great deal of time, such that killing the program, adding logs, hoping you catch the right stuff, then spending the time to run around and try and invoke the bug again burns a lot more time than actually finding and fixing it. It's also a very common issue that the problem details that you need to inspect are of a very high frequency nature. Logging may produce 100,000 lines of output per frame. This will interfere with the framerate, and there are many forms of bugs that are temporally invoked. Running at low framerate may cause the bug to disappear... Perhaps you suggest filtering the output, or triggering it at certain times... but how do you know what parameters to base that on? You could spend hours just trying to understand in what situation a bug manifests such that you are able to instrument the build to produce the information you need. I would never work professionally in an environment without a quality debugger. I'm not unique.