On 16/12/2014 6:48 p.m., Rikki Cattermole wrote:
> On 16/12/2014 5:11 p.m., MattCoder wrote:
>> On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole wrote:
>>> I started writing a small booklet on this, if you got an email if
>>> you're interested or some way to send you. Please let me know.
>>
>> Do you mind to share with us all? :)
>>
>> Matheus.
>
> https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
>
> No guarantees of how long it'll stay up there.
>
> And to reiterate, its only just a start. And I don't know if I ever
> complete it. There isn't really enough material for an actual book.
> Maybe booklet but meh.

Update, had a look into offerings for publishing, going with lulu.
It'll be a pocket book. Although won't publish to book format for a while (ebook only). Around 50 pages.
It won't be centered purely on D, more this is what could be available and this is how to deal with it in e.g. D.
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.

On 12/19/2014 2:47 AM, Sergei Nosov wrote:
> 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.

Sure it's possible - but the issues have to be specific. "Need more examples", for example (!), is nice but not helpful to anyone trying to improve the documentation. Saying "I need an example for std.foo.bar()" is an actionable item.

On Fri, 19 Dec 2014 10:47:27 +0000
Sergei Nosov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

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

one of the things one can do if he is in corresponding position is to ban debuggers. i found that after month or two people start producing better code with better documentation and "control knobs". and surprisingly faster. debugger is just a kind of bad habit, and when people faced the fact that they will not be payed for work simulation (and why should we?), they either go or becomes more productive.

On Friday, 19 December 2014 at 11:16:41 UTC, Walter Bright wrote:
> On 12/19/2014 2:47 AM, Sergei Nosov wrote:
>> 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.
>
> Sure it's possible - but the issues have to be specific. "Need more examples", for example (!), is nice but not helpful to anyone trying to improve the documentation. Saying "I need an example for std.foo.bar()" is an actionable item.

I'm afraid, the answer to this specific question is - "Every function needs an example". Consider, e.g. http://en.cppreference.com/w/ or http://www.cplusplus.com/reference/ It's hard to find a function that doesn't have a usage example.

Granted, the mentioned references are most likely volunteer effort (are they?). But it took C++ something like 20 years and a wide corporate adoption for that to happen.

I guess, it took less time for other languages, like Python or Ruby, but that's, probably, because those languages looked really interesting and fun at their times. So they attracted a lot of "good" programmers.

D poses itself as a more serious language (at least it's how it looks like). And, probably, nobody will say that it's bad. But, as a consequence, it makes it less attractive to "good" programmers. Especially now, when there's lot of successful "toy" languages. D is not "flashy" enough these days.

On Friday, 19 December 2014 at 11:54:42 UTC, ketmar via Digitalmars-d wrote:
> On Fri, 19 Dec 2014 10:47:27 +0000
> Sergei Nosov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> 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!
>
> one of the things one can do if he is in corresponding position is to
> ban debuggers. i found that after month or two people start producing
> better code with better documentation and "control knobs". and
> surprisingly faster. debugger is just a kind of bad habit, and when
> people faced the fact that they will not be payed for work simulation
> (and why should we?), they either go or becomes more productive.

Exactly. But you also imply something like "it would be great if every good programmer became excellent", which is not very realistic.

The example is a little abstract, but smoking is also a bad habit. However, there's no way you can fight it and win for the observable future.

On Thursday, 18 December 2014 at 14:55:19 UTC, Chris 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.

This is out of line.  It doesn't help anyone to throw around this kind of aggressive, blame-laden criticism, especially not towards someone who is trying to expand the professional developer uptake of D.

It's important that we all try and be constructive, sympathetic and helpful when offering advice, even (actually, especially) when suggesting to someone that they might have done things differently.

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.

On Friday, 19 December 2014 at 11:54:42 UTC, ketmar via Digitalmars-d wrote:
> On Fri, 19 Dec 2014 10:47:27 +0000
> Sergei Nosov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> 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!
>
> one of the things one can do if he is in corresponding position is to
> ban debuggers. i found that after month or two people start producing
> better code with better documentation and "control knobs". and
> surprisingly faster. debugger is just a kind of bad habit, and when
> people faced the fact that they will not be payed for work simulation
> (and why should we?), they either go or becomes more productive.

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.


Cheers,
uri

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.

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