On 19 December 2014 at 20:47, 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 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.
>
>
> I think the most valuable point Manu made is that there are "excellent" and "good" programmers. The difference is not so much in the actual skills, but in the willing to spend time on programming.
>
> "Excellent programmers" spend a great amount of time learning things. It takes a huge part of their free time and it really takes a lot of passion and diligence. But most of the professional programmers are simply "good". They code at work and that's it. They don't spend any time beyond that on programming and, especially, learning new things.
>
> If we're speaking about "excellent programmers" category, then almost everything about D is already good enough for these people. You can tell it by a number of truly fascinating D projects.
>
> And it looks like the guys who work on D are mostly "excellent programmers", which speak pretty different language compared to the "good programmers". Probably, this is the main cause of misunderstanding.
>
> 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. And the uselessness is so obvious, that there's nothing even to talk about. At the same time, "good programmers" use it extensively, especially on Windows. It is so useful to them, that there's nothing even to talk about!
>
> So, Manu speaks from the "good programmer" position, and Walter speaks from the "excellent programmer" position, implying "if you'd become a better programmer, you wouldn't have no problems using D".
>
> This implication is mostly true. But it's orthogonal to Manu's point - "good programmers" have troubles using D.
>
> The probable solution to this is to attract some "good" programmers to point out and work on the aforementioned issues - site, documentation, tooling, etc. But I'm not sure it's possible to do this for D with volunteer efforts.

Thank you.

I get so frustrated by the apparent majority in this forum who seem to
think 'most' programmers are the type who would even read or post on a
forum like this. Or read a programming book! They must surely be the
overwhelming minority.
In my experience, that is, large companies, probably somewhere around
500 colleagues in almost 15 years, is that 90% of them are 'good' at
best. Nothing will be successful unless that silent majority can get
on board... and they will NOT exert any particular effort to do so,
unless it clearly advantages them somehow and/or the friction is
minimal.

D is a great language for enthusiasts, obviously. Andrei often talks
about a 7 digit userbase; he's presented on this in lectures. I don't
think think that number is even remotely possible unless we are able
to attract an overwhelming majority of 'average' to 'good'
programmers. I doubt there are that many 'excellent' programmers in
the world!
In my experience to date (presenting D to corporate colleagues, of
which is quite extensive), the main barrier remaining is
presentation... and for my particular user-base, rough edges in the
Windows experience; an ecosystem where the standard of tooling and
presentation is otherwise very high.
People call my industry niche, but I reckon gamedev's are among (if
not) the largest remaining community of native developers who embark
on new developments frequently (ie, annually). I see it as one of D's
most promising targets, but that will depend on getting the Windows
tooling across the line. Gamedev may have a larger number of 'average'
programmers than other industries (I can't say), but whatever, that's
just how it is.

That said, I'm not working in games at the moment. But I don't see any difference in expectation in my new company than I did in games. If anything, it's even more windows-centric, since the cross-platform expectation (present in games), is not really with me now.

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

On 19 December 2014 at 19:15, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:
>>
>> People aren't allocated work time to read books.
>
>
> This can't be generally true. Most people who attend programming conferences, for example, are attending on their employer's dime.

In my experience, only a select few highly privileged developers tend
to have the opportunity to attend conferences, and such opportunities
may be years apart. I don't think that's the 'general' case.
The general case from my perspective, is people who go to work to get
paid to pay their bills and enjoy their lives in whatever way they
prefer to do that. They may or may not be good at their job, but the
point is about their life's priorities.

They're not necessarily 'bad' programmers; they may be perfectly
capable of learning any new material they require to do their job on
the fly... but if there's a significantly greater degree of friction
than they expect (a precedent defined by competitors which we have no
real control over), they will complain, and probably won't look again
in the future.
It takes a special kind of programmer who will continue to contribute
substantial time to their skillset in their own time after they have
already been reliably employed for a decent number of years.

Those people are already here. Andrei's 'million users' are not, and those people are will largely be the people I describe, and most of them will learn on the fly, while on the job.

On Saturday, 20 December 2014 at 07:26:30 UTC, Manu via Digitalmars-d wrote:
> Thank you.
>
> I get so frustrated by the apparent majority in this forum who seem to
> think 'most' programmers are the type who would even read or post on a
> forum like this. Or read a programming book! They must surely be the
> overwhelming minority.

I am well-aware that people who actually have a passion for programming are tiny minority. Though many still read programming books because that adds some weight for career advancement requests.

But you call to support interests of those programmers at cost of interests of existing users - something absolutely impractical at current language development stage. Trying to explain why this expectation is not reasonable and not just is the least hostile reaction I can give.

Whatever Andrei says, there is no benefit in blindly pumping user base if you don't have resources to support it. I also remember him saying "want million users, build as if you had million users". Well, currently we don't truly build even for thousand users.

You have been stressing those cases for several years now. Have you actually contributed anything to DMD to improve debug symbol generation seeing how this is important to you?

I keep asking you simple question you avoid answering - who personally should work to address your concerns? Those are all legit concerns and I doubt anyone would willingly prefer to keep things as they are. But who will do it if apparently you are the person who needs it most and you don't want to do it?

On Friday, 19 December 2014 at 10:47:28 UTC, Sergei Nosov wrote:
> I think the most valuable point Manu made is that there are "excellent" and "good" programmers. The difference is not so much in the actual skills, but in the willing to spend time on programming.

I would avoid calling those groups "good" and "excellent". This sounds dangerously elitist with no actual data to back it up - it is not uncommon to find better programmers in group you call "good" then some of those you call "excellent".

Calling them "not nerds" and "nerds" is better way to get straight to the fundamentals :) And yes, I believe currently any effective usage of D requires at least one nerd in a team to act as a proxy for the rest.

On 2014-12-19 20:20, Walter Bright wrote:

> 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.

It can still be handy with a debugger. If you have written a custom pretty-printer you can still call that one from the debugger.

In LLDB it's possible to write custom formatters/pretty-printer for your own types.

-- 
/Jacob Carlborg

On 2014-12-20 08:46, Manu via Digitalmars-d wrote:

> 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?

I have tried debugging DMD using Xcode. Very often when I inspect variables the debugger thinks they're null when they're not. Quite often I don't have access to all variables I thought I would have access to.

I don't know if it's something special about the DMD code base, I have always thought of it as quite simple, no templates or use of the C++ standard library. Perhaps the Visual Studio debugger would work better.

But when it do work it can be very handy.

At work I have used a debugger, although this is for Ruby, which is a lot more reliable and a real pleasure to use. I can navigate inside objects, inspect their private state, call private methods and other more fancy stuff. Very handy.

-- 
/Jacob Carlborg

On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:
> Well... when? I've been here 6 years. When can I start to use D for my work?
> Other languages seem to have a higher velocity. Are we fighting a losing battle?

Other languages do much less than D which is a full-blown C++ replacement.
We've made huge progress in the past few years, look at the number of bugfixes and enhancements http://dlang.org/changelog.html and we introduced or finished several language features, that make D even more powerful (e.g. UFCS, UDA, alias this...). Still only very few people actually work on the compiler and we're also pretty bad in coordinating contributions.

On 12/20/2014 06:12 PM, Martin Nowak wrote:
> On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:
> Other languages do much less than D which is a full-blown C++ replacement.
> We've made huge progress in the past few years

Most important, we started to grow an ecosystem.
http://code.dlang.org/

On Saturday, 20 December 2014 at 17:13:04 UTC, Martin Nowak wrote:
> On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:
>> Well... when? I've been here 6 years. When can I start to use D for my work?
>> Other languages seem to have a higher velocity. Are we fighting a losing battle?
>
> Other languages do much less than D which is a full-blown C++ replacement.
> We've made huge progress in the past few years, look at the number of bugfixes and enhancements http://dlang.org/changelog.html and we introduced or finished several language features, that make D even more powerful (e.g. UFCS, UDA, alias this...). Still only very few people actually work on the compiler and we're also pretty bad in coordinating contributions.

One move that might work is providing help to those who want to get started on compiler hacking, by letting them know who those knowledgeable about dmd are and providing a venue for them to ask questions when getting started, ie some sort of mentoring into dmd hacking.  It's a bit alarming how few people dominate dmd development, especially compared to phobos:

https://github.com/D-Programming-Language/dmd/graphs/contributors

The dmd project needs to do a better job of growing more contributors, this is one good way to do it.  The alternative is to just let people jump in and sink or swim on their own, which might be a good filter to weed out the truly committed and capable from the rest, but also risks losing those who are capable but need some initial guidance.

For example, there could be a note on the README that says you should contact Kenji, Walter, Dan, or Martin if you need some help getting started with contributing to dmd, along with contact info (I assume Don and Brad might not be as interested).  You may say that all those people are reachable now, but without explicit permission like that, some people get intimidated about bothering someone like Walter.

Another suggestion is to actually write some docs for dmd, perhaps starting with frontend source layout and organization, similar to the brief list for the backend:

https://github.com/D-Programming-Language/dmd/blob/master/src/backend/backend.txt

Of course, writing docs is always a tall order, but if it leads to more contributors, it can pay off in spades.