On Friday, 19 December 2014 at 16:27:03 UTC, H. S. Teoh via
Digitalmars-d wrote:
Could
this lack of need be attributable to understanding of the
entire code
base being used?
Nope.
FWIW, I work with a large enterprise project that is far too
large for
anyone to grasp in its entirety, yet I don't find debuggers
that helpful
either. Well, they *are* helpful in some cases, just not as
many as
people often claim, as least not for me. The oft-maligned
printf-debugging, when wisely used in a targeted way, is often
better
IME because I'm dealing with an embedded environment, where
it's a pain
to setup a debugger. Well, it *can't* run a full debugger; the
best it
can so is to run gdbserver which I then have to connect to
remotely.
Once that's setup, I run into the frustrating problem of gdb
being
unable to find the requisite symbols, needing to be in the same
directory as the executable, being unable to locate the source
file(s),
being unable to resolve library symbols, ad nauseaum.
I think that "at least not for me" is important there.
Personally, I did not malign the printf debugging approach.
However nothing is more painful than sitting through a printf
debugging session with someone new to code who is using the
printf to learn the code, when a perfectly good debugger is
available. Is the embedded environment you describe the typical
case?
I'm not advocating, not reading or attempting to understand the
code. But, assume you have your best understanding at hand and
still have questions and/or bugs; you drop a breakpoint in code
that is new to you. What you get is much more than the
documentation: you get the callstack allowing you to navigate the
code, you get the data allowing you to see the structures and
their content. Problems with gdb does not take away from the
benefit debugging in general. Remember this thread was started
with someone having bugs in a windows environment.
Not many advocate ignorance. Programmers do advocate laziness
with good cause. In theory, if a person can successfully use code
without understanding all details of its implementation then that
person has made a mental cost savings. Maybe not so important to
the set of coders here - but there is value in not being required
to understand all details. One benefit of the separation of
concerns between interfaces and implementation is the level of
understanding required for the former might be significantly less
than the latter.
I imagine you don't have many outside dependencies for your
boot
loader. I imagine most of what Walter works on involves an
entire
stack that he has either written from ground up or when pulling
outside dependencies in has much less surface area to deal
with that
is new to him.
Unfortunately, your imagination isn't quite accurate in this
case.
How so? Is the bootloader using vibed or websockets? Does dmd use
vibed or websockets? Of course your next reply can be all the
complex libraries dmd uses internally to which I'll reply that
all of those are code that Walter is likely intimately familiar
with making it easy for him with his vast experience to not use a
debugger. No one has to use a debugger, but I'm in the camp that
they can make life easier especially when getting familiar with
new code. Maybe here I'm in the minority.
Contrast that with someone wanting to tie into a framework
(vibed) or
use a sophisticated library (websockets). Yes, you can stick
with the
"real men don't use debuggers" line, but that is much easier to
stomach when your outside dependencies are small in scope.
That is a false assumption, based on my experience as described
above.
How does your unfortunate situation of being "with a large
enterprise project that is far too large for anyone to grasp in
its entirety, yet I don't find debuggers that helpful" relate to
the extent of dependencies and their impact on utility of a
debugger? I get that in general you don't find debuggers useful,
which is fine. When trying to understand a tangled mess of code
that you did not write your preferred method is read the code and
printf. Those are valuable. Maybe someone who rarely or never
uses a debugger is not the best to gauge the benefit differential
of a debugger on systems with few outside dependencies versus
systems with heavy outside dependencies.
Isn't one of the best ways to learn a new codebase to step
through it
in the debugger?
[...]
Absolutely not. You'd get lost in the forest *really* quickly
and lose
sight of the forest for the trees, especially in a large
codebase where
each logical operation may involve a dozen layers of
abstraction, and
lower-level code is all generic so you won't easily understand
how it
concretely fits into the big picture. For this, I recommend
reading the
source code instead(!). That's what the source code is for!!
More chest beating. I don't see how the *addition* of a debugger
causes one to get lost. I'm in emacs trying to learn a new code
base. Everything I could do before I can still do (including
reading the source code) and I can look at real live data,
examine structures with contents, quickly navigate the stack,
etc. It only adds value IMO as it is not an either/or.
Of course, none of this implies that we shouldn't work on
making D work
better with debuggers; quite on the contrary, I found it very
frustrating sometimes when I *do* need to use the debugger but
D support
for that is rather anemic. Fortunately, being a
printf-debugging veteran
does help work around such limitations. :-P
I guess that makes D's fast compile times all the more important
to you.
T
