www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Effective D book?

reply "Szymon Gatner" <noemail gmail.com> writes:
Any plans on that now that language is stable enough? Andrei 
authoring maybe?
Jun 14 2013
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?

The language is fairly stable, but still far from complete. There's still several unimplemented and undesigned big features that could significantly affects what the best practices are (scope parameters and lack of copy constructors comes to mind). Also, I think it's still a bit too early to put out a book on best practices in D. Not many people have lots of experience writing production D code.
Jun 14 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:56 AM, Peter Alexander wrote:
 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei authoring maybe?

The language is fairly stable, but still far from complete. There's still several unimplemented and undesigned big features that could significantly affects what the best practices are (scope parameters and lack of copy constructors comes to mind). Also, I think it's still a bit too early to put out a book on best practices in D. Not many people have lots of experience writing production D code.

It's true that "best practices" in D are still evolving. That's not a bad thing - best practices in C++ have changed a lot over the years.
Jun 14 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?

Who would write it? It seems to me that D is still new and not widespread, which means that everybody has their own styles and interpretation of how to use the language. I could see someone writing a "Programming with Phobos" book(let) though, for example. But a full blown best practice for the entire language itself seems excessive to me. In particular, while *stable*, it *is* still "evolving", which means that while the old code still works, the patterns are still shifting.
Jun 14 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 11:29 AM, monarch_dodra wrote:
 Who would write it?

Anyone who wants to!
 It seems to me that D is still new and not widespread, which means that
 everybody has their own styles and interpretation of how to use the language.

 I could see someone writing a "Programming with Phobos" book(let) though, for
 example. But a full blown best practice for the entire language itself seems
 excessive to me. In particular, while *stable*, it *is* still "evolving", which
 means that while the old code still works, the patterns are still shifting.

Although you are right, the best practices are still evolving, I don't think that automatically precludes writing a book on the current state of thought on the matter.
Jun 14 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 11:29 AM, monarch_dodra wrote:
 In particular, while *stable*, it *is* still "evolving", which
 means that while the old code still works, the patterns are still shifting.

One example of that is Andrei and I have been discussing the idea of moving import declarations from their traditional place at the top of the file to being in the most nested scope in which they are referenced.
Jun 14 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 03:02 AM, Walter Bright wrote:
 On 6/14/2013 11:29 AM, monarch_dodra wrote:
 In particular, while *stable*, it *is* still "evolving", which
 means that while the old code still works, the patterns are still
 shifting.

One example of that is Andrei and I have been discussing the idea of moving import declarations from their traditional place at the top of the file to being in the most nested scope in which they are referenced.

One issue with local imports is that they hide local symbols.
Jun 15 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 05:09 PM, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
 One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar".

So does this: void main(){ void writeln(string) {} writeln("foo"); { import std.stdio; writeln("bar"); } }
Jun 15 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 11:03 AM, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote:
 So does this:

 void main(){
     void writeln(string) {}
     writeln("foo");
     {
         import std.stdio;
         writeln("bar");
     }
 }

Still not seeing any issue. The first writeln cannot know about the import because it is at a deeper scope, so only the second writeln will print anything.

The local import therefore hides a local symbol.
Jun 16 2013
next sibling parent reply "Tyro[17]" <ridimz yahoo.com> writes:
On 6/16/13 5:34 AM, Timon Gehr wrote:
 void main(){
      void writeln(string) {}
      writeln("foo");
      {
          import std.stdio;
          writeln("bar");
      }
 }

void main(){ void writeln(string) {} writeln("foo"); { import io = std.stdio; writeln("bar"); io.writeln("baz"); } } I see your point... but somehow I don't think it's that big of a problem. Should be fixed for those not willing to use the mechanism currently available to resolve the issue, but I wouldn't loose any sleep if it weren't. -- Andrew Edwards -------------------- http://www.akeron.co auto getAddress() { string location = " ", period = "."; return ("info" ~ location ~ "afidem" ~ period ~ "org"); }
Jun 16 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 11:50 AM, Tyro[17] wrote:
 On 6/16/13 5:34 AM, Timon Gehr wrote:
 void main(){
      void writeln(string) {}
      writeln("foo");
      {
          import std.stdio;
          writeln("bar");
      }
 }

void main(){ void writeln(string) {} writeln("foo"); { import io = std.stdio; writeln("bar"); io.writeln("baz"); } } I see your point... but somehow I don't think it's that big of a problem.

Well, it does not have to be in order to get fixed. The D module system otherwise avoids this kind of issue.
 Should be fixed for those not willing to use the mechanism
 currently available to resolve the issue, but I wouldn't loose any sleep
 if it weren't.

There is no mechanism in place that reliably avoids silent breakage.
Jun 16 2013
parent "Tyro[17]" <ridimz yahoo.com> writes:
On 6/16/13 6:07 AM, Timon Gehr wrote:
 On 06/16/2013 11:50 AM, Tyro[17] wrote:
 On 6/16/13 5:34 AM, Timon Gehr wrote:


 Should be fixed for those not willing to use the mechanism
 currently available to resolve the issue, but I wouldn't loose any sleep
 if it weren't.

There is no mechanism in place that reliably avoids silent breakage.

A very valid point. For this particular case though, I would move to suggest that an apt resolution would be to documentation the behavior and suggest that if such behavior is not desired, the use of renamed imports or static imports is recommended for scoped imports. import s = std.stdio; import std.stdio: print = writeln; static import std.stdio; any of these options is a valid solution this particular issue while documentation takes care of the rest. Having just said that, I took a quick look at the documentation and this is what it had to say: "In function scopes, imported symbols only become visible after the import declaration lexically appears in the function body. In other words, imported symbols at function scope cannot be forward referenced. " Even the example given there clearly tells you this will happen: void main() { void writeln(string) {} void foo() { writeln("bar"); // calls main.writeln import std.stdio; writeln("bar"); // calls std.stdio.writeln void writeln(string) {} writeln("bar"); // calls main.foo.writeln } writeln("bar"); // calls main.writeln std.stdio.writeln("bar"); // error, std is undefined } I don't see the problem. -- Andrew Edwards -------------------- http://www.akeron.co auto getAddress() { string location = " ", period = "."; return ("info" ~ location ~ "afidem" ~ period ~ "org"); }
Jun 16 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/16/13 5:34 AM, Timon Gehr wrote:
 On 06/16/2013 11:03 AM, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote:
 So does this:

 void main(){
 void writeln(string) {}
 writeln("foo");
 {
 import std.stdio;
 writeln("bar");
 }
 }

Still not seeing any issue. The first writeln cannot know about the import because it is at a deeper scope, so only the second writeln will print anything.

The local import therefore hides a local symbol.

Yah that's a bug. Has anyone filed it yet? Andrei
Jun 16 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 06:06 PM, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote:
 On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
 One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar".

void writeln(string) {} void main() { import std.stdio; writeln("foo"); std.stdio.writeln("bar"); }

Oh, but that's not a local symbol, that's a module level symbol. The import is more local that the module level writeln, so that works as you would expect. It also isn't a problem at all, ...

It sure is, the module system is supposed to provide hijacking protection.
Jun 15 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2013 2:34 PM, Timon Gehr wrote:
 It sure is, the module system is supposed to provide hijacking protection.

Inner scopes override outer scopes. That isn't what hijacking is.
Jun 15 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 01:36 AM, Walter Bright wrote:
 On 6/15/2013 2:34 PM, Timon Gehr wrote:
 It sure is, the module system is supposed to provide hijacking
 protection.

Inner scopes override outer scopes. That isn't what hijacking is.

A module can introduce a new symbol and silently change what some identifier lookup refers to, where the previous symbol referred to resides in a different module.
Jun 15 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2013 2:06 AM, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote:
 On 6/15/2013 2:34 PM, Timon Gehr wrote:
 It sure is, the module system is supposed to provide hijacking protection.

Inner scopes override outer scopes. That isn't what hijacking is.

I think this is an issue Walter, consider: void main() { import std.stdio; string message = "Hello, world!"; writeln(message); } It std.stdio contains a symbol called "message" then this will not print "Hello, world".

Yes, it will. Current scope overrides imported scope.
Jun 16 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 05:09 PM, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
 One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar".

More peculiar example: void main(){ import std.stdio; void writefx(string s){writeln(s);} { import std.stdio; writefx("bar"); // error: writefx is private } } 'writefx' happens to be a private symbol in std.stdio.
Jun 15 2013
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 15.06.2013 17:09, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
 One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro.

Here is another example I recently stumbled upon: ///////// module a; class A { import std.stdio; } ///////// module b; void writeln(string){} class B : A { void foo() { writeln("Hi"); } } Guess which function is called in foo! There are conflicting rule sets at work here, the symbol lookup rules for base classes vs the lookup rules for (private) imports. Walter seems to be fine as is but I'm not sure (http://forum.dlang.org/post/5197E695.10807 digitalmars.com - the issue is not a regression as reported, there seems to be some change to it in 2.063 that I couldn't isolate). At least the symbols imported into the base class should be private by default (though that won't change anything in the same module). OT: This points to another slight non-orthogonality as declarations and imports have different visibility defaults, which is modified by the same "public:"/"private:".
Jun 16 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 7:17 PM, Jonathan M Davis wrote:
 I'm a bit reticent to bring it up given that I won't be done anytime soon, but
 I actually started writing such a book following DConf. After Andrew brought
 up the possibility of Effective D in his talk and all of the talk that occurred
 at DConf about doing more with tutorials and publishing best practices, I
 decided that I'd give it shot.

Awesome!
 And while I'm sure that there's plenty more best practices that we'll figure
 out over time, and some of what we do know has been shifting as we learn, I
 think that we do know enough at this point about best practices in D to fill
 such a book.

Keep us posted.
 Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc
 so that it can easily be converted into latex, html, and e-book formats rather
 than being tied to any particular format (I was going to use latex, but Andrei
 thought that a macro language would be better as latex is very tied to physical
 print and fixed layouts). It'll probably be the first book ever to be written
 entirely in ddoc.

This is just being a win all around!
Jun 14 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:15 PM, Jonathan M Davis wrote:
 My one major complaint about using ddoc is the need for the $(P ) macro
 everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should
 probably create an enhancement request for that (and maybe even try and
 implement it), but I have enough to do right now that I decided that I'd just
 put up with it for now. But aside from the need for $(P ) macros, it's
 actually quite pleasant to work with.

 I do have to process the ddoc before giving it to the compiler in order to
 generate the table of contents and index macros (since you can't generate
 those with just macros), but since I'm using a D script to do the build,
 that was actually pretty easy.

 So, I'm writing a book on D which is written in D's documentation macro
 language and using D to actually drive the build. It's all very D. :)

I'd write it first without bothering with any formatting commands. Add them in at the end. (This is how I do all my articles.)
Jun 14 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/13 11:55 AM, H. S. Teoh wrote:
 I'm curious about how you manage to factor out / abstract away the
 niggling details of LaTeX, like the use of ".\ " after an abbreviation
 (to make it produce only an inter-word space, as opposed to the extra
 space at the end of a sentence),

ABBRDOT = .\$(SPACE)
 m-dash

MDASH = ---
 vs. n-dash

NDASH = --
, etc., some of which
 are quite specific to LaTeX but are quite necessary if you're going for
 print-quality typesetting. And what about embedded \footnote's?

FOOTNOTE = \footnote{$0}
 Section
 references?

SECREF = \ref{sec:$0}
 Do you have macros for all of them?

Yah. All of the above would go into a latex.ddoc macros file. Then the html.ddoc file would contain things like ABBRDOT = .$(SPACE) MDASH = &mdash; etc.
 Does it make it a bit
 cumbersome to type?

Most likely, but this is the price to pay for supporting multiple formats. Then, LaTeX wasn't exactly designed for ease of typing, so the marginal cumbersomeness shouldn't be high.
 I do have to process the ddoc before giving it to the compiler in
 order to generate the table of contents and index macros (since you
 can't generate those with just macros), but since I'm using a D script
 to do the build, that was actually pretty easy.

Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output?

Yah, all outputs should have TOCs and such. Andrei
Jun 16 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:43 PM, Szymon Gatner wrote:
 Btw: Not sure if "effective" series isn't somehow propertiary and linked to
Herb
 Sutter. I know he is not only responsible for c++ but also for c# version

I would refrain from naming it "Effective D". Scott Meyers is the author of several "Effective C++" books, and it would be disrespectful to try to trade off of that, even though there is an "Effective Java" by Bloch and an "Effective C#" by Wagner, etc. Heck, to throw something out there, why not "D Best Practices"?
Jun 14 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Jun-2013 12:07, SomeDude пишет:
 On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:
 Heck, to throw something out there, why not "D Best Practices"?

Or "D Patterns and Practices" ? With some David Simcha content in it (if he agrees with that of course).

IMHO D Cookbook sounds about right. -- Dmitry Olshansky
Jun 15 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/13 6:19 PM, Jonathan M Davis wrote:
 For the book that I'm working on, I'm really not going to worry about the
 title at this point. I'm just going to write it, and I'll worry about stuff
 like the title and who might publish it or anything along those lines once
 it's much closer to completion.

Awesome approach. Andrei
Jun 16 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2013 3:19 PM, Jonathan M Davis wrote:
 For the book that I'm working on, I'm really not going to worry about the
 title at this point. I'm just going to write it, and I'll worry about stuff
 like the title and who might publish it or anything along those lines once
 it's much closer to completion.

+1 Also, I wouldn't worry about formatting until it's near completion, either.
Jun 16 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/16/13 12:53 PM, Walter Bright wrote:
 On 6/15/2013 3:19 PM, Jonathan M Davis wrote:
 For the book that I'm working on, I'm really not going to worry about the
 title at this point. I'm just going to write it, and I'll worry about
 stuff
 like the title and who might publish it or anything along those lines
 once
 it's much closer to completion.

+1 Also, I wouldn't worry about formatting until it's near completion, either.

I think people's styles differ here. I've spent time upfront on TDPL's page design and then I've enjoyed seeing parts of the finished product growing as I worked on it. Andrei
Jun 16 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2013 1:36 PM, Jonathan M Davis wrote:
 I tend to worry about things like how paragraphs are separated and which words
 get emphasized as I go along (the same sorts of things that I'd worry about in
 a simple forum post), but I'm not going to worry about minute formatting
 details like mdash or ndash or anything like that. And I won't worry about the
 font style or page layout or anything along those lines until much later.
 Without having a bunch of text, I don't know how you'd be able to sort that
 out very well anyway, since you wouldn't be able to see what your tweaks did.
 But I _am_ doing enough formatting to care about whether I need $(P ) or not -
 just not a whole lot beyond that.

Sure, whatever works best for you! Me, I'm definitely the kind of person who can only think about one thing at a time, and when I'm writing text, I just let it flow in one uninterrupted stream. Interestingly enough, most of the grammatical errors in my text come about because of editing it later.
Jun 16 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/13 5:43 AM, Szymon Gatner wrote:
 Btw: Not sure if "effective" series isn't somehow propertiary and linked
 to Herb Sutter. I know he is not only responsible for c++ but also for
 c# version

The "Effective" series at AWL is directed by Scott Meyers and would not preclude one from using the title elsewhere. That being said, I mentioned the book last night to Scott and he said if the author wants to publish it in that series, he'd be glad to look into it. Andrei
Jun 14 2013
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/14/2013 07:17 PM, Jonathan M Davis wrote:

 It'll probably be the first book ever to be written entirely in ddoc.

The first ddoc book was a D book as well: ;) http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/foreach_opapply.d Ali
Jun 15 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote:
 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?

Who would write it?

Did you read what you quoted? :-)
Jun 14 2013
prev sibling next sibling parent "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote:
 On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote:
 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?

Who would write it?

Did you read what you quoted? :-)

That was just a suggestion of course ;) And I am asking this after watching David Simcha's talk. There are language idioms clarifying already even if just while writing Phobos. And there can always be new editions with newly discovered idioms / patterns and good practices. But I do see your point on proper battlefield testing first.
Jun 14 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote:
 On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote:
 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?

Who would write it?

Did you read what you quoted? :-)

I guess it does look silly like that :) But the point I wanted to make came in the next sentence, is that I think that currently, no single person could write said book, because everyone has their own interpretation of best practices, or different types of use. Not even Andrei. We all have our own interpretation right now of how to use D. If the book was released by a single author, it would just be that person's interpretation of "Effective". I would love to be proven wrong of course. Another interesting project, given D's state, could be a collaborative "D idioms and patterns", for example?
Jun 14 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 14, 2013 at 11:22:14PM +0200, monarch_dodra wrote:
 On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote:
On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote:
On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
Any plans on that now that language is stable enough? Andrei
authoring maybe?

Who would write it?

Did you read what you quoted? :-)

I guess it does look silly like that :) But the point I wanted to make came in the next sentence, is that I think that currently, no single person could write said book, because everyone has their own interpretation of best practices, or different types of use. Not even Andrei. We all have our own interpretation right now of how to use D. If the book was released by a single author, it would just be that person's interpretation of "Effective". I would love to be proven wrong of course.

What about collecting the most common D practices among us and seeing if some common trends show up?
 Another interesting project, given D's state, could be a
 collaborative "D idioms and patterns", for example?

Isn't there already a section on the wiki dedicated to that? It would help if more people would contribute their experiences. T -- When solving a problem, take care that you do not become part of the problem.
Jun 14 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, June 14, 2013 20:29:09 monarch_dodra wrote:
 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei
 authoring maybe?

Who would write it?

I'm a bit reticent to bring it up given that I won't be done anytime soon, but I actually started writing such a book following DConf. After Andrew brought up the possibility of Effective D in his talk and all of the talk that occurred at DConf about doing more with tutorials and publishing best practices, I decided that I'd give it shot. And while I'm sure that there's plenty more best practices that we'll figure out over time, and some of what we do know has been shifting as we learn, I think that we do know enough at this point about best practices in D to fill such a book. Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. - Jonathan M Davis
Jun 14 2013
prev sibling next sibling parent "Elvis" <nospam pureworld.com> writes:
On Saturday, 15 June 2013 at 02:17:59 UTC, Jonathan M Davis wrote:
 On Friday, June 14, 2013 20:29:09 monarch_dodra wrote:
 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei
 authoring maybe?

Who would write it?

I'm a bit reticent to bring it up given that I won't be done anytime soon, but I actually started writing such a book following DConf. After Andrew brought up the possibility of Effective D in his talk and all of the talk that occurred at DConf about doing more with tutorials and publishing best practices, I decided that I'd give it shot. And while I'm sure that there's plenty more best practices that we'll figure out over time, and some of what we do know has been shifting as we learn, I think that we do know enough at this point about best practices in D to fill such a book. Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. - Jonathan M Davis

Good jobs, I'm very much looking forward to reading it!
Jun 14 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, June 14, 2013 19:57:52 Walter Bright wrote:
 Interestingly enough, based on Andrei's suggestions, I'm writing it using
 ddoc so that it can easily be converted into latex, html, and e-book
 formats rather than being tied to any particular format (I was going to
 use latex, but Andrei thought that a macro language would be better as
 latex is very tied to physical print and fixed layouts). It'll probably
 be the first book ever to be written entirely in ddoc.

This is just being a win all around!

My one major complaint about using ddoc is the need for the $(P ) macro everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should probably create an enhancement request for that (and maybe even try and implement it), but I have enough to do right now that I decided that I'd just put up with it for now. But aside from the need for $(P ) macros, it's actually quite pleasant to work with. I do have to process the ddoc before giving it to the compiler in order to generate the table of contents and index macros (since you can't generate those with just macros), but since I'm using a D script to do the build, that was actually pretty easy. So, I'm writing a book on D which is written in D's documentation macro language and using D to actually drive the build. It's all very D. :) - Jonathan M Davis
Jun 14 2013
prev sibling next sibling parent "Szymon Gatner" <noemail gmail.com> writes:
On Saturday, 15 June 2013 at 02:17:59 UTC, Jonathan M Davis wrote:
 On Friday, June 14, 2013 20:29:09 monarch_dodra wrote:
 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:
 Any plans on that now that language is stable enough? Andrei
 authoring maybe?

Who would write it?

I'm a bit reticent to bring it up given that I won't be done anytime soon, but I actually started writing such a book following DConf. After Andrew brought up the possibility of Effective D in his talk and all of the talk that occurred at DConf about doing more with tutorials and publishing best practices, I decided that I'd give it shot. And while I'm sure that there's plenty more best practices that we'll figure out over time, and some of what we do know has been shifting as we learn, I think that we do know enough at this point about best practices in D to fill such a book. Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. - Jonathan M Davis

Would love to proof read it. Btw: Not sure if "effective" series isn't somehow propertiary and linked to Herb Sutter. I know he is not only responsible for c++ but also for c# version
Jun 14 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, June 15, 2013 05:43:11 Szymon Gatner wrote:
 Btw: Not sure if "effective" series isn't somehow propertiary and
 linked to Herb Sutter. I know he is not only responsible for c++
 but also for c# version

Scott Meyers wrote the C++ one, Bill Wagner wrote the C# one, and Joshua Bloch wrote the Javae one. I'm not aware of Herb Sutter having anything to do with any of them. And Effective Java was published via a different publisher from the other two, so my guess is that there would be no problem with the name Effective D. But I'm not married to the name "Effective D." It's simply the name that's been suggested and which would have recognition thanks to books with similar names in other languages. The important thing is the content of the book. If it ends up with a different name, then it ends up with a different name. - Jonathan M Davis
Jun 14 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, June 15, 2013 00:26:55 Ali =C3=87ehreli wrote:
 On 06/14/2013 07:17 PM, Jonathan M Davis wrote:
  > It'll probably be the first book ever to be written entirely in dd=

=20
 The first ddoc book was a D book as well: ;)
=20
=20
 http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/fore=

 pply.d

So, you wrote your book with ddoc? I didn't know that. That's cool. It'= s a lot=20 more versatile than you'd initially think. - Jonathan M Davis
Jun 15 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:
 Heck, to throw something out there, why not "D Best Practices"?

Or "D Patterns and Practices" ? With some David Simcha content in it (if he agrees with that of course).
Jun 15 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
 One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar".
Jun 15 2013
prev sibling next sibling parent "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
 One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar".

void writeln(string) {} void main() { import std.stdio; writeln("foo"); std.stdio.writeln("bar"); } ?
Jun 15 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 14, 2013 at 11:15:14PM -0400, Jonathan M Davis wrote:
 On Friday, June 14, 2013 19:57:52 Walter Bright wrote:
 Interestingly enough, based on Andrei's suggestions, I'm writing
 it using ddoc so that it can easily be converted into latex, html,
 and e-book formats rather than being tied to any particular format
 (I was going to use latex, but Andrei thought that a macro
 language would be better as latex is very tied to physical print
 and fixed layouts). It'll probably be the first book ever to be
 written entirely in ddoc.

This is just being a win all around!

My one major complaint about using ddoc is the need for the $(P ) macro everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should probably create an enhancement request for that (and maybe even try and implement it), but I have enough to do right now that I decided that I'd just put up with it for now. But aside from the need for $(P ) macros, it's actually quite pleasant to work with.

I'm curious about how you manage to factor out / abstract away the niggling details of LaTeX, like the use of ".\ " after an abbreviation (to make it produce only an inter-word space, as opposed to the extra space at the end of a sentence), m-dash vs. n-dash, etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? Section references? Do you have macros for all of them? Does it make it a bit cumbersome to type?
 I do have to process the ddoc before giving it to the compiler in
 order to generate the table of contents and index macros (since you
 can't generate those with just macros), but since I'm using a D script
 to do the build, that was actually pretty easy.

Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output? T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius
Jun 15 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote:
 On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander 
 wrote:
 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
 One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar".

void writeln(string) {} void main() { import std.stdio; writeln("foo"); std.stdio.writeln("bar"); }

Oh, but that's not a local symbol, that's a module level symbol. The import is more local that the module level writeln, so that works as you would expect. It also isn't a problem at all, because you can easily refer to the module level symbol by fully qualifying it. module thismodule; void writeln(string) {} void main() { import std.stdio; thismodule.writeln("foo"); std.stdio.writeln("bar"); } In any case, I'd recommend explicitly choosing which symbols to import in the local import to avoid name clashes.
Jun 15 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, June 15, 2013 08:55:11 H. S. Teoh wrote:
 I'm curious about how you manage to factor out / abstract away the
 niggling details of LaTeX, like the use of ".\ " after an abbreviation
 (to make it produce only an inter-word space, as opposed to the extra
 space at the end of a sentence), m-dash vs. n-dash, etc., some of which
 are quite specific to LaTeX but are quite necessary if you're going for
 print-quality typesetting. And what about embedded \footnote's? Section
 references? Do you have macros for all of them? Does it make it a bit
 cumbersome to type?

I'm early enough in the process that I haven't done much with those yet, and I'm likely to have to go back and fix that sort of thing up later (especially since about all I've done with LaTeX previously is write papers for college, and I didn't necessarily have to get everything as nice and exact as you would for a published book, so I'd likely be screwing some of that up even if I were writing directly in LaTeX). I expect to be using macros for them, but since you have to mark them up when writing in LaTeX anyway, it's not like I lose much using ddoc instead. It's just that the syntax changed. But it may be that if some of those can be automated, I'll end up doing something in the build script to manipulate the text to add that markup for me rather than using macros directly. I'll worry about that level of typesetting later. I wouldn't be worrying about that now even if I were writing directly in LaTeX. And ddoc macros will easily allow me to add it all later. It's just that the ddoc files for stuff like html and epub will ignore them. I don't really need to create something which is completely target-agnostic. I just need to create something that easily converts to all of the target formats that I need. And ddoc will do that just fine.
 I do have to process the ddoc before giving it to the compiler in
 order to generate the table of contents and index macros (since you
 can't generate those with just macros), but since I'm using a D script
 to do the build, that was actually pretty easy.

[...] Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output?

LaTeX will autogenerate the table of contents and the index, but html won't (and I don't think that something like epub will either, but I haven't gotten around to generating that yet). So, I have to generate the whole thing as macros, which the latex.ddoc file mostly gets rid of, and the html.ddoc file replaces with the appopriate text and links. - Jonathan M Davis
Jun 15 2013
prev sibling next sibling parent "matovitch" <camille.brugel laposte.net> writes:
I am referring to the beginning of this thread, but definitly 
wating for such a book to come out I have open a SO question 
(interactive media for a yet evolving langage) about effective 
design patterns and best practice in D. So if you have some 
clever methods you want to share, I am waiting for your answers. 
:-)
Jun 15 2013
prev sibling next sibling parent "matovitch" <camille.brugel laposte.net> writes:
On Saturday, 15 June 2013 at 19:52:45 UTC, matovitch wrote:
 I am referring to the beginning of this thread, but definitly 
 wating for such a book to come out I have open a SO question 
 (interactive media for a yet evolving langage) about effective 
 design patterns and best practice in D. So if you have some 
 clever methods you want to share, I am waiting for your 
 answers. :-)

the link : http://stackoverflow.com/questions/tagged/d (forget the obvious)
Jun 15 2013
prev sibling next sibling parent "matovitch" <camille.brugel laposte.net> writes:
the 'true' link : 
http://stackoverflow.com/questions/17127251/effective-d-best-practices-and-design-patterns
Jun 15 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Saturday, 15 June 2013 at 21:35:20 UTC, Timon Gehr wrote:
 On 06/15/2013 05:09 PM, Peter Alexander wrote:
 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
 One issue with local imports is that they hide local symbols.

Can you give an example? I can't repro. void main() { import std.stdio; void writeln(string) {} writeln("foo"); std.stdio.writeln("bar"); } This writes only "bar".

More peculiar example: void main(){ import std.stdio; void writefx(string s){writeln(s);} { import std.stdio; writefx("bar"); // error: writefx is private } } 'writefx' happens to be a private symbol in std.stdio.

You might want to open a bug report for this. David
Jun 15 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 16, 2013 01:55:35 Dmitry Olshansky wrote:
 15-Jun-2013 12:07, SomeDude =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:
 Heck, to throw something out there, why not "D Best Practices"?

Or "D Patterns and Practices" ? With some David Simcha content in it (if he agrees with that of cou=


=20
 IMHO D Cookbook sounds about right.

Cookbook is in a similar situation with Effective, if not worse, as O'R= eilly=20 has a whole line of programming books with that name, and AFAIK, every=20= programming book with Cookbook in its name has been published though th= em. So,=20 an author who wanted to use that title would probably have to publish=20= specifically through O'Reilly to get it into that series. However, from the looks of how the Cookbook books are supposed to be la= id out,=20 they really aren't intended for discussing best practices. They're for = giving=20 solutions to specific programming problems, with the idea that they con= tain a=20 list of such "recipes" that you can look up to figure out how to solve = common=20 programming problems in the language or domain that the book covers. It= would=20 certainly be useful to have that sort of book for D, but I believe that= it=20 would be fundamentally different from what a book which might be publis= hed in=20 the "Effective" series would contain. For the book that I'm working on, I'm really not going to worry about t= he=20 title at this point. I'm just going to write it, and I'll worry about s= tuff=20 like the title and who might publish it or anything along those lines o= nce=20 it's much closer to completion. - Jonathan M Davis
Jun 15 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 15 June 2013 at 08:07:23 UTC, SomeDude wrote:
 On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:
 Heck, to throw something out there, why not "D Best Practices"?

Or "D Patterns and Practices" ?

+1
Jun 15 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 16 June 2013 at 00:42:15 UTC, Timon Gehr wrote:
 On 06/16/2013 01:36 AM, Walter Bright wrote:
 On 6/15/2013 2:34 PM, Timon Gehr wrote:
 It sure is, the module system is supposed to provide hijacking
 protection.

Inner scopes override outer scopes. That isn't what hijacking is.

A module can introduce a new symbol and silently change what some identifier lookup refers to, where the previous symbol referred to resides in a different module.

It happen to me recently; the bug was very puzzling. I do think that identifier lookup should turtle down in the module before looking at imports.
Jun 15 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote:
 So does this:

 void main(){
     void writeln(string) {}
     writeln("foo");
     {
         import std.stdio;
         writeln("bar");
     }
 }

Still not seeing any issue. The first writeln cannot know about the import because it is at a deeper scope, so only the second writeln will print anything.
 It also isn't a problem at all, ...

It sure is, the module system is supposed to provide hijacking protection.

Hmm good point.
 More peculiar example:
 ...
 'writefx' happens to be a private symbol in std.stdio.

I think this is just the separate bug where private symbols are visible through imports. Should be solved by DIP22 IIRC.
Jun 16 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote:
 On 6/15/2013 2:34 PM, Timon Gehr wrote:
 It sure is, the module system is supposed to provide hijacking 
 protection.

Inner scopes override outer scopes. That isn't what hijacking is.

I think this is an issue Walter, consider: void main() { import std.stdio; string message = "Hello, world!"; writeln(message); } It std.stdio contains a symbol called "message" then this will not print "Hello, world". Updates to libraries that introduce symbols could subtly break working code. Whether or not this is what hijacking is, I think this is a problem.
Jun 16 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 16, 2013 11:06:18 Peter Alexander wrote:
 On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote:
 On 6/15/2013 2:34 PM, Timon Gehr wrote:
 It sure is, the module system is supposed to provide hijacking
 protection.

Inner scopes override outer scopes. That isn't what hijacking is.

I think this is an issue Walter, consider: void main() { import std.stdio; string message = "Hello, world!"; writeln(message); } It std.stdio contains a symbol called "message" then this will not print "Hello, world". Updates to libraries that introduce symbols could subtly break working code. Whether or not this is what hijacking is, I think this is a problem.

I concur. It may be that it's reasonable for local imports to shadow declarations from outside the function rather than creating conflicts, but they definitely shouldn't shadow symbols inside the function - _especially_ when the local symbol is declared after the local import. The current behavior is just going to create bugs. - Jonathan M Davis
Jun 16 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 16 June 2013 at 12:52:52 UTC, Andrei Alexandrescu 
wrote:
 On 6/16/13 5:34 AM, Timon Gehr wrote:
 The local import therefore hides a local symbol.

Yah that's a bug. Has anyone filed it yet?

Timon has filed that the behaviour is underspecified: http://d.puremagic.com/issues/show_bug.cgi?id=7329 I have now filed it as a bug: http://d.puremagic.com/issues/show_bug.cgi?id=10378
Jun 16 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 16 June 2013 at 16:48:46 UTC, Walter Bright wrote:
 On 6/16/2013 2:06 AM, Peter Alexander wrote:
 It std.stdio contains a symbol called "message" then this will 
 not print "Hello,
 world".

Yes, it will. Current scope overrides imported scope.

Sorry, bad example: string message = "Hello, world!"; void main() { import std.stdio; writeln(message); }
Jun 16 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 16, 2013 09:53:55 Walter Bright wrote:
 On 6/15/2013 3:19 PM, Jonathan M Davis wrote:
 For the book that I'm working on, I'm really not going to worry about the
 title at this point. I'm just going to write it, and I'll worry about
 stuff
 like the title and who might publish it or anything along those lines once
 it's much closer to completion.

+1 Also, I wouldn't worry about formatting until it's near completion, either.

I tend to worry about things like how paragraphs are separated and which words get emphasized as I go along (the same sorts of things that I'd worry about in a simple forum post), but I'm not going to worry about minute formatting details like mdash or ndash or anything like that. And I won't worry about the font style or page layout or anything along those lines until much later. Without having a bunch of text, I don't know how you'd be able to sort that out very well anyway, since you wouldn't be able to see what your tweaks did. But I _am_ doing enough formatting to care about whether I need $(P ) or not - just not a whole lot beyond that. - Jonathan M Davis
Jun 16 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jun 16, 2013 at 07:58:20AM -0400, Andrei Alexandrescu wrote:
 On 6/15/13 11:55 AM, H. S. Teoh wrote:
I'm curious about how you manage to factor out / abstract away the
niggling details of LaTeX, like the use of ".\ " after an
abbreviation (to make it produce only an inter-word space, as opposed
to the extra space at the end of a sentence),

ABBRDOT = .\$(SPACE)
m-dash

MDASH = ---
vs. n-dash

NDASH = --
, etc., some of which are quite specific to LaTeX but are quite
necessary if you're going for print-quality typesetting. And what
about embedded \footnote's?

FOOTNOTE = \footnote{$0}

But it doesn't address the problem of how to make $(FOOTNOTE ...) work correctly with HTML output. Is it suppressed completely? Post-processed to appear in a footnote DIV? Something else?
Section references?

SECREF = \ref{sec:$0}
Do you have macros for all of them?

Yah. All of the above would go into a latex.ddoc macros file. Then the html.ddoc file would contain things like ABBRDOT = .$(SPACE) MDASH = &mdash; etc.
Does it make it a bit cumbersome to type?

Most likely, but this is the price to pay for supporting multiple formats. Then, LaTeX wasn't exactly designed for ease of typing, so the marginal cumbersomeness shouldn't be high.

Or rather, LaTeX *was* designed for ease of typing, but not for ease of auto-generation / parsing. Many of the quirks of LaTeX syntax is to make it easy to type certain formatting elements, but it comes at the expense of consistency of syntax, which is what makes it tricky for systems like DDoc to generate output for (and rather hard for external programs to parse correctly). T -- This is a tpyo.
Jun 16 2013