Lost a new commercial user this week :(

[Manu via Digitalmars-d]

On 19 December 2014 at 18:56, Walter Bright via Digitalmars-d
<digitalmars-d at 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.