Things I learned the hard way

[Jonathan M Davis]

On Tuesday, June 18, 2019 8:41:31 PM MDT Exil via Digitalmars-d wrote:
> On Wednesday, 19 June 2019 at 01:15:33 UTC, Walter Bright wrote:
> > https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
> >
> > Debuggers are over-rated
> > I heard a lot of people complaining that code editors that
> > don't come with debugging are terrible, exactly because they
> > don't come with debugging.
> >
> > But when your code is in production, you can't run your
> > favorite debugger. Heck, you can't even run your favourite IDE.
> > But logging... Logging runs everywhere. You may not have the
> > information you want at the time of the crash (different
> > logging levels, for example) but you can enable logging to
> > figure out something later.
> >
> > (Not saying debuggers are bad, they just not as helpful as most
> > people would think.)
>
> This I don't agree with. Maybe specifically for his job it might
> not have been. If you are more of a tech support and you need to
> remote into a customer's computer and use whatever they have
> available on their computer, sure. But I doubt that's the case
> for a large majority of programmers. Also you can debug a crash
> that happened on a customer's computer for a native production
> application with a stack trace. You might be missing some
> variables because it is a production build that were optimized
> away but you still get a lot of relevant information.

If anything, it's becoming more and more the case that the programs being
run are services where you can't simply rerun them to reproduce problems,
and in such situations, logging can be critical. Depending on the problem
and how the machine is set up, core dumps can certainly help, and a debugger
is helpful with those, but the whole idea that most programs can be simply
debugged in an IDE is arguably becoming less and less the case as more and
more stuff is a service running in the cloud.

Now, there's no question that many programs will continue to be run on a
local machine or on a customer's machine in a manner that they can be
debugged in-place, and plenty of bugs are quite reproducible, but a _lot_ of
code that is written and run these days is not in such a situation. I have
no idea whether more programmers operate in an environment where they can
easily run what they're working on in their IDE, or whether more programmers
are dealing with cloud services which can't easily be run in a debugger, but
many, many programmers are dealing with cloud services, and for better or
worse, the trend in computing seems to be heading more and more in that
direction for many domains.

So, really, how important or useful logging is vs a debugger is very
dependent on the kind of programs that you work on. For instance, on
multiple occassions, Walter has expressed the viewpoint that if there's a
problem, you simply rerun the program in the debugger, because he's used to
working with batch programs like compilers where you give them some input,
and they always do the same thing with the same input. As such, things like
hitting a segfault for a null pointer don't tend to be a big deal to him.
They're usually easy to reproduce, debug, and fix. On the other hand, in
those same discussions, other people have had a very different point of view
on things like how bad null pointers are, because they're used to working
with programs where you can't simply rerun them to reproduce the problem.

Personally, I've actually worked on several programs where even though
everything is local and could easily be run in a debugger, a log is far more
useful than the debugger, because the nature of the program is such that
once you stop it, you can't continue and have the program function properly
(e.g. because the program has a watchdog that kills stuff if it doesn't
respond quickly enough).

- Jonathan M Davis