December 19, 2014
On Fri, 19 Dec 2014 08:24:49 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> This doesn't mean that debuggers are *useless*, which is a completely different statement (and is patently false). Sometimes they can be useful, e.g., for obtaining a stacktrace from a segfault, or to ascertain exactly where a function pointer ends up when it's a generic object that could in theory point anywhere, etc.
yes, debugger is *very* useful for inspecting core dumps. that is why i still have gdb installed. ;-)


December 19, 2014
On Fri, 19 Dec 2014 08:24:49 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

p.s. and D support for generating extensive debug information is important, 'cause we need it to do core dump inspection.


December 19, 2014
On 20/12/2014 2:54 a.m., MattCoder wrote:
> On Friday, 19 December 2014 at 11:12:04 UTC, Rikki Cattermole wrote:
>> ...
>> I have about 10 pages to go. Uses cases, 1 design pattern, bunch of
>> exploring of language support (LISP) and some misc stuff. So maybe
>> sooner rather then later there will be an announcement.
>
> Please let us know!
>
> Matheus.

Its hard to find your email!

Email me? alphaglosined // gmail // com
December 19, 2014
On 20/12/2014 2:03 a.m., Wyatt wrote:
> On Friday, 19 December 2014 at 11:12:04 UTC, Rikki Cattermole wrote:
>>
>> Basically, I know there is very little resources on CTFE in any form
>> published. So my goal is to get this authoritative as possible on the
>> subject.
>> So with any luck, 50 years from now people will still be asking
>> questions about what D was, and its state when it was written.
>>
>> I have about 10 pages to go. Uses cases, 1 design pattern, bunch of
>> exploring of language support (LISP) and some misc stuff. So maybe
>> sooner rather then later there will be an announcement.
>
> Do you have a repo for the work-in-progress, or some way to take
> patches?  (e.g. grammar fixes)
>
> -Wyatt

Assuming your email that is appearing in Thunderbird is correct, I'll email you when MattCoder emails me (don't have his email).
That way, one email chain.
December 19, 2014
On Friday, 19 December 2014 at 17:00:56 UTC, Rikki Cattermole wrote:
> Its hard to find your email!
>
> Email me? alphaglosined // gmail // com

Done! :)

Matheus.
December 19, 2014
On 2014-12-19, 5:33 AM, Wyatt wrote:
> On Friday, 19 December 2014 at 09:15:18 UTC, Walter Bright wrote:

> The class of people who attend programming conferences is an extreme
> minority of our field.  They're about as representative of our industry
> as you believe the posters on these newsgroups are of the D userbase.

Yay, I'm in the minority!  My CEO was somewhat disappointed that I didn't ask to go to the most recent DConf, even though we so far have _no_ D development in house yet.  (I do get sent to C++ and Beyond...)

December 19, 2014
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

December 19, 2014
On 12/19/2014 7:38 AM, Daniel Davidson wrote:
>  Could this lack of need be
> attributable to understanding of the entire code base being used?

No. It's attributable to I use different methods of debugging.

The dmd source code is littered with debugging aids I've written. The classic example is having a pretty-printer for each data structure. I don't find the typical debugger pretty-printer to be adequate at all - they never dump the type in the way that I think about the type.

December 19, 2014
On Fri, Dec 19, 2014 at 2:47 AM, Sergei Nosov via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
> On Friday, 19 December 2014 at 08:57:56 UTC, Walter Bright wrote:
>
>> 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.
>>
>
> I think the most valuable point Manu made is that there are "excellent" and "good" programmers.
>

This distinction may be valid in some instances, but I believe it is wrong to use when talking about debuggers.


> In the "debugger" case, Manu's point is that it's unusable. And Walter's implied point is "debuggers aren't that useful anyway, so why it was a showstopper?".
>
> My personal observation is that "excellent programmers" share the Walter's point on debuggers - they practically don't use it.


Hyperbole follows: This is bullshit.

Yes, 'excellent' programmers write excellent software that can be debugged without a debugger.  But 'excellent' programmers also have to debug code written by others (or themselves in the past), in which case a debugger is _incredibly_ useful.  Using a debugger can save hours or days in diagnosing/solving a problem.


> And the uselessness is so obvious, that there's nothing even to talk about.


More hyperbole:  if a debugger is useless to you, you are not working on very complex systems.


> It is so useful to them, that there's nothing even to talk about!
>

Yup, nothing to talk about.

Some/many people value a debugger as an essential development tool.  And not having a usable debugger in D is a showstopper for them.


Kudos to Manu for trying to use D at work.  But the issues he identified are essentially the same keeping me from pushing use of D professionally - tooling is lacking.  And this is coming from someone on the opposite side environment wise... I find Visual Studio atrocious, and believe those using it suffer from stockholm syndrome.

And yes, I understand nothing will get better without volunteers working on it... but it would be nice if we could talk about the problems without mudslinging everywhere.  Acknowledging where work is needed is the first step in getting said work done.


December 20, 2014
On 19 December 2014 at 18:31, John Colvin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 19 December 2014 at 06:47:31 UTC, Manu via Digitalmars-d wrote:
>>
>> On 19 December 2014 at 00:55, Chris via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via Digitalmars-d wrote:
>>>
>>> So to sum things up
>>>
>>> 1. you blindly walked into something you had no real experience with,
>>> apart
>>> from some vague memory that some parts of vibed worked for you a while
>>> ago.
>>>
>>> 2. you knew the debugger might be an issue, if not _the_ issue, but chose not to test it beforehand, or couldn't test it beforehand, because
>>>
>>> 3. you were working on a foreign framework (and simply hoped things would work out fine, fingers crossed!).
>>>
>>> These are crucial bits of information that were missing from your first report.
>>>
>>> Please try to be more accurate the next time. Holding back crucial
>>> information gets us nowhere. It only leaves the (false) impression that D
>>> is
>>> completely unusable.
>>
>>
>> Fuck you guys.
>> I'm done here.
>
>
> "You guys"? Don't lump the rest of us in with one guy's ranting. What have the rest of us done to deserve a "fuck you"?

Sorry, there were 3 guys in particular who were ripping into me for whatever reason. Sorry for the blanket statement, it was directed at them. I don't really feel I need to be ripped apart for trying to encourage D use in the office, and then reporting on our experience. You were personally supportive, so to yourself (and others), thanks.