On Friday, 19 December 2014 at 12:53:32 UTC, Tobias Pankrath wrote:
> On Friday, 19 December 2014 at 12:44:26 UTC, Kiith-Sa wrote:
>> On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright wrote:
>>> On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:
>>>> Docs need to have examples which are plain and obvious, and the
>>>> language will be absorbed by osmosis.
>>>
>>> I agree. Can you point to specific cases that need an example?
>>
>> If it doesn't have an example, it needs an example, no matter how trivial it is. That's a good place to start. Of course, then there are lazy examples that don't really help in real use. These need to be identified and rewritten.
>
> • If you look up how to do $x in the documentation and it is takes you time to figure that out, consider to add an example for $x to the documentation.
>
> • If you answer/ask a question in D.learn on how to do $x, consider to add an example for $x to the documentation.
>
> This way we should build up exactly those examples that are useful.

+1

No different to adding unit tests where possible for each reported bug.

On Friday, 19 December 2014 at 12:53:32 UTC, Tobias Pankrath wrote:
> On Friday, 19 December 2014 at 12:44:26 UTC, Kiith-Sa wrote:
>> On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright wrote:
>>> On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:
>>>> Docs need to have examples which are plain and obvious, and the
>>>> language will be absorbed by osmosis.
>>>
>>> I agree. Can you point to specific cases that need an example?
>>
>> If it doesn't have an example, it needs an example, no matter how trivial it is. That's a good place to start. Of course, then there are lazy examples that don't really help in real use. These need to be identified and rewritten.
>
> • If you look up how to do $x in the documentation and it is takes you time to figure that out, consider to add an example for $x to the documentation.
>
> • If you answer/ask a question in D.learn on how to do $x, consider to add an example for $x to the documentation.
>
> This way we should build up exactly those examples that are useful.

Turned into an issue (not really a traditional issue since it's never "solved", but to hopefully remind people). Also mentioned in the wiki(Get involved):

https://issues.dlang.org/show_bug.cgi?id=13876
http://wiki.dlang.org/Get_involved

On Friday, 19 December 2014 at 09:15:18 UTC, Walter Bright 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.

Are you _quite_ sure about that?  Because all my experience agrees with Manu.  If any of us (I think we have about 400 developers here?) have need of a book, we're skimming it and cherry-picking the important bits to what needs done _right now_.  This is part of why I really appreciate that Andrei had a proper index written for TDPL; it makes it fit into "real world" workflows (as I know them) much better.

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.

-Wyatt

On Friday, 19 December 2014 at 13:33:08 UTC, Wyatt wrote:
> On Friday, 19 December 2014 at 09:15:18 UTC, Walter Bright 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.
>
> Are you _quite_ sure about that?  Because all my experience agrees with Manu.  If any of us (I think we have about 400 developers here?) have need of a book, we're skimming it and cherry-picking the important bits to what needs done _right now_.
>  This is part of why I really appreciate that Andrei had a proper index written for TDPL; it makes it fit into "real world" workflows (as I know them) much better.
>
> 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.

New D developers at Sociomantic are given "Learn Tango with D" book and time to investigate it in details before starting any real work. Job I had before was crappy enterprise mess but there still was time reserved for books in a developer schedule. I'd expect it from any half-decent job.

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.

On Friday, 19 December 2014 at 08:31:12 UTC, John Colvin wrote:
>
> "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"?

While I'm not unsympathetic to your point, try to see things from Manu's position.  Every time I've seen him bring up an issue that he has experienced in reality, he's been told, variously:
a) You're doing it wrong
b) Your problem isn't real
c) Your use case doesn't exist
d) We don't need theoretical solutions
e) The things you want are niche and pointless

...and so on.

Despite this, he's persisted in trying to raise awareness and support for close-to-the-metal performance and control for _years_.  And then this thread happens after he was burned (yet again!) by the tooling and the "foolish" expectation that things would work as advertised in a situation where he lost face with his peers.

Can you really blame him for being frustrated?

-Wyatt

On Friday, 19 December 2014 at 14:50:48 UTC, Wyatt wrote:
> On Friday, 19 December 2014 at 08:31:12 UTC, John Colvin wrote:
>>
>> "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"?
>
> While I'm not unsympathetic to your point, try to see things from Manu's position.  Every time I've seen him bring up an

I'm not sympathetic to it, as Manu obviously wasn't talking about John but about the couple people he was frustrated with.  I realize everyone wants to start a flame war, but it's silly to take the most expansive possible meaning of every barb and then take haughty offense at it.

On Friday, 19 December 2014 at 12:52:32 UTC, uri wrote:
> This is true. The first week for a new developer where I work is developing a better boot loader. The debugger is not allowed during this induction week and as a result our devs learn how to write better code first time through careful planning and understanding of what's going on at the machine level.
>
As you beat your chest over your boot loader - consider both this example and in general Walter's lack of need for a debugger. Could this lack of need be attributable to understanding of the entire code base being used? 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. 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. Isn't one of the best ways to learn a new codebase to step through it in the debugger?

Maybe your devs learn how to write better code the first time through. But what happens when they are thrown new requirements on dependencies that are challenging to deal with?

On Fri, 19 Dec 2014 15:38:27 +0000
Daniel Davidson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Friday, 19 December 2014 at 12:52:32 UTC, uri wrote:
> > This is true. The first week for a new developer where I work is developing a better boot loader. The debugger is not allowed during this induction week and as a result our devs learn how to write better code first time through careful planning and understanding of what's going on at the machine level.
> >
> As you beat your chest over your boot loader - consider both this example and in general Walter's lack of need for a debugger. Could this lack of need be attributable to understanding of the entire code base being used? 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. 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. Isn't one of the best ways to learn a new codebase to step through it in the debugger?
> 
> Maybe your devs learn how to write better code the first time through. But what happens when they are thrown new requirements on dependencies that are challenging to deal with?

one of the worst things one can do to understand some big codebase is start it under debugger.

if that codebase is so shitty that you can't see the modules and interfaces without tracing them in the debugger... well, in this case debugger will not help, the codebase is crap.

if that codebase is well-documented and well-decoupled, you can get a picture in your head by learning what each part of the system do and then descend into various parts, learning APIs.

what "stepping through it in the debugger" does is effectively simulates the work. and gives you a simulated understanding. i was thrown into huge codebases with alot of dependencies for past decades and "stepping through it in the debugger" was always just a waste of time.

it's not the best way to understand how to use some engine by watching how it's gears turning. it may be fun, but not very productive. first you grok what that engine was designed for, and only then you may want to see the gears. but it's often not necessary.

On Fri, Dec 19, 2014 at 03:38:27PM +0000, Daniel Davidson via Digitalmars-d wrote:
> On Friday, 19 December 2014 at 12:52:32 UTC, uri wrote:
> >This is true. The first week for a new developer where I work is developing a better boot loader. The debugger is not allowed during this induction week and as a result our devs learn how to write better code first time through careful planning and understanding of what's going on at the machine level.
> >
> As you beat your chest over your boot loader - consider both this example and in general Walter's lack of need for a debugger. 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.

With printf (well, fprintf to a debug log, to be precise), I can get a trace of strategic points in the code in text format that I can peruse at my leisure, rather than being stuck inside a debugger where rewinding isn't possible. (Yes, I know gdb has recently acquired rewinding capability, but that's no help in a tightly-controlled embedded environment where every tool is locked to a specific version and upgrading is not an option.)

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. (though even the latter can be manually done by inserting an infinite loop into a suspected target and then using `top` to see if the CPU usage is 100% -- a `kill -11` afterwards usually also generates a stacktrace that confirms where it ended up). It's just that debuggers aren't as universally useful as proponents tend to make it out to be.


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


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


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

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


T

-- 
Famous last words: I wonder what will happen if I do *this*...