Lost a new commercial user this week :(

[Daniel Davidson via Digitalmars-d]

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