www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Trip notes from Israel

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
-- Andrei
May 22 2017
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/22/2017 11:05 AM, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
 -- Andrei


Submitted to reddit as well: 
https://www.reddit.com/r/programming/comments/6cntso/from_the_d_blog_introspe
tion_introspection/ 
-- Andrei
May 22 2017
parent Suliman <evermind live.ru> writes:
On Monday, 22 May 2017 at 15:12:42 UTC, Andrei Alexandrescu wrote:

 On 05/22/2017 11:05 AM, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ --
Andrei


 Submitted to reddit as well: 
 https://www.reddit.com/r/programming/comments/6cntso/from_the_d_blog_introspe
tion_introspection/ -- Andrei


Perfect! I have been in Weka.IO in this january too! Big thanks 
guys!
May 22 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 mixin is a statement so it needs a terminator, hence
 the semicolon at the very end. In turn, mixin takes
 a string (the concatenation of variable op


That actually depends on context! The mixin statement needs 
statements, but the mixin expression takes expressions. Same 
mixin keyword, but if it is in the context of a statement it is a 
statement and in the context of an expression, it is an 
expression.

---
void main() {
	int payload;
         mixin("++payload;"); // statement, ; required
	int b = mixin("++payload"); // expression, ; would be wrong 
there and cause an error!
}
---

http://dlang.org/spec/expression.html#MixinExpression
http://dlang.org/spec/statement.html#MixinStatement
May 22 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/22/2017 11:23 AM, Adam D. Ruppe wrote:

 On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 mixin is a statement so it needs a terminator, hence
 the semicolon at the very end. In turn, mixin takes
 a string (the concatenation of variable op


 
 That actually depends on context! The mixin statement needs statements, 
 but the mixin expression takes expressions. Same mixin keyword, but if 
 it is in the context of a statement it is a statement and in the context 
 of an expression, it is an expression.
 
 ---
 void main() {
      int payload;
          mixin("++payload;"); // statement, ; required
      int b = mixin("++payload"); // expression, ; would be wrong there 
 and cause an error!
 }
 ---
 
 http://dlang.org/spec/expression.html#MixinExpression
 http://dlang.org/spec/statement.html#MixinStatement


Yah, didn't want to overload the article (or the discussion) with the 
expression/statement distinction. -- Andrei
May 22 2017
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/22/2017 11:26 AM, Andrei Alexandrescu wrote:

 On 05/22/2017 11:23 AM, Adam D. Ruppe wrote:

 On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 mixin is a statement so it needs a terminator, hence
 the semicolon at the very end. In turn, mixin takes
 a string (the concatenation of variable op


 That actually depends on context! The mixin statement needs 
 statements, but the mixin expression takes expressions. Same mixin 
 keyword, but if it is in the context of a statement it is a statement 
 and in the context of an expression, it is an expression.

 ---
 void main() {
      int payload;
          mixin("++payload;"); // statement, ; required
      int b = mixin("++payload"); // expression, ; would be wrong there 
 and cause an error!
 }
 ---

 http://dlang.org/spec/expression.html#MixinExpression
 http://dlang.org/spec/statement.html#MixinStatement


 
 Yah, didn't want to overload the article (or the discussion) with the 
 expression/statement distinction. -- Andrei


Updated the post, it's an interesting point after all. Thanks! -- Andrei
May 22 2017
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 22 May 2017 at 15:26:26 UTC, Andrei Alexandrescu wrote:

 Yah, didn't want to overload the article (or the discussion) 
 with the expression/statement distinction. -- Andrei


Yeah, the details might be too much for a general audience (and I 
realize you know this, I'm commenting more for other readers who 
might be interested), but I do think this illustrates an 
important point for anyone who wants to use mixin: it is similar 
to, but not exactly like copy/pasting code into the source.

mixin parses a piece of code, then pastes the *AST node*, not the 
source code, into the tree where the mixin is found. That's why 
the semicolon is required in the statement context - it needs a 
complete branch that actually fits the AST at the moment, not 
just a string that is pasted into the source code at the location.

So similar enough to copy/paste to get someone quickly started 
playing with code generation, but this key difference is needed 
to really understand it.
May 22 2017
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 22.05.2017 17:38, Adam D. Ruppe wrote:

 On Monday, 22 May 2017 at 15:26:26 UTC, Andrei Alexandrescu wrote:

 Yah, didn't want to overload the article (or the discussion) with the
 expression/statement distinction. -- Andrei


 Yeah, the details might be too much for a general audience (and I
 realize you know this, I'm commenting more for other readers who might
 be interested), but I do think this illustrates an important point for
 anyone who wants to use mixin: it is similar to, but not exactly like
 copy/pasting code into the source.

 mixin parses a piece of code, then pastes the *AST node*, not the source
 code, into the tree where the mixin is found. That's why the semicolon
 is required in the statement context - it needs a complete branch that
 actually fits the AST at the moment, not just a string that is pasted
 into the source code at the location.

 So similar enough to copy/paste to get someone quickly started playing
 with code generation, but this key difference is needed to really
 understand it.


The grammar has:

expression;

as a statement.

mixin(...)

as an expression

and

mixin(...);

as a statement

Hence,

mixin(...);

is actually grammatically ambiguous and the behaviour of the compiler is 
somewhat arbitrary.

The compiler could easily compensate for the ambiguity during semantic 
and not require the terminating semicolon when parsing the string of a 
mixin statement.
May 22 2017
prev sibling next sibling parent Quentin Ladeveze <ladeveze.quentin openmailbox.org> writes:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ --
Andrei


It was really an entertaining and interesting post, thank you.
May 22 2017
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ --
Andrei


Wow, that was really good. Love to read more of your trip notes.
May 22 2017
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ --
Andrei


A fun read!

"(Late at night, I double checked. Mozilla’s CheckedInt is just 
as bad as I remembered. They do a division to test for 
multiplication overflow. Come on, put a line of assembler in 
there! Portability is worth a price, just not any price.)"

Shocked: do you use assembly in Checked and cripple the 
optimizer?!?!
Luckily, no. But LDC and GDC do create the `seto` instruction I 
think you were hinting at:
https://godbolt.org/g/0jUhgs

(LDC doesn't do as good as it could, 
https://github.com/ldc-developers/ldc/issues/2131)

cheers,
   Johan
May 22 2017
next sibling parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 22 May 2017 at 22:51, Johan Engelen via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/
 -- Andrei



 A fun read!

 "(Late at night, I double checked. Mozilla’s CheckedInt is just as bad as I
 remembered. They do a division to test for multiplication overflow. Come on,
 put a line of assembler in there! Portability is worth a price, just not any
 price.)"

 Shocked: do you use assembly in Checked and cripple the optimizer?!?!
 Luckily, no. But LDC and GDC do create the `seto` instruction I think you
 were hinting at:
 https://godbolt.org/g/0jUhgs


So for LDC to be as good as GDC, you need to need to compile with
-enable-ldc-amazing-feature-cross-module-inlining?


 (LDC doesn't do as good as it could,
 https://github.com/ldc-developers/ldc/issues/2131)


If you want a hint (though it's not my place to say), LLVM I'm told is
a reasonably OK compiler, and any reasonably OK compiler should come
with overflow intrinsics - try using them directly.

(Turning off mild morning sarcasm).

Iain.
May 23 2017
next sibling parent kinke <kinke gmx.net> writes:
On Tuesday, 23 May 2017 at 08:18:26 UTC, Iain Buclaw wrote:

 If you want a hint (though it's not my place to say), LLVM I'm 
 told is a reasonably OK compiler, and any reasonably OK 
 compiler should come with overflow intrinsics - try using them 
 directly.


The intrinsics are exposed by LDC's druntime, they just need to 
be made use of:
https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/intrinsics.di#L446-L468
May 23 2017
prev sibling parent Johan Engelen <j j.nl> writes:
On Tuesday, 23 May 2017 at 08:18:26 UTC, Iain Buclaw wrote:

 So for LDC to be as good as GDC, you need to need to compile 
 with -enable-ldc-amazing-feature-cross-module-inlining?


In this case, yep.


 If you want a hint (though it's not my place to say), LLVM I'm 
 told is a reasonably OK compiler, and any reasonably OK 
 compiler should come with overflow intrinsics - try using them 
 directly.


Pleasantly surprised that you think so highly of LDC and LLVM 
that you assume we are able to get the `seto` instruction in this 
case without using an overflow intrinsic.

- Johan
May 23 2017
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/22/17 4:51 PM, Johan Engelen wrote:

 On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
 -- Andrei


 
 A fun read!
 
 "(Late at night, I double checked. Mozilla’s CheckedInt is just as bad 
 as I remembered. They do a division to test for multiplication overflow. 
 Come on, put a line of assembler in there! Portability is worth a price, 
 just not any price.)"
 
 Shocked: do you use assembly in Checked and cripple the optimizer?!?!
 Luckily, no. But LDC and GDC do create the `seto` instruction I think 
 you were hinting at:
 https://godbolt.org/g/0jUhgs
 
 (LDC doesn't do as good as it could, 
 https://github.com/ldc-developers/ldc/issues/2131)


Thanks! Yes, seto is what I thought of - one way or another, it gets 
down to using a bit of machine-specific code to get there. I'll note 
that dmd does not generate seto (why?): https://goo.gl/nRjNMy. -- Andrei
May 23 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 23 May 2017 at 13:27:42 UTC, Andrei Alexandrescu 
wrote:

 On 5/22/17 4:51 PM, Johan Engelen wrote:

 On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu 
 wrote:

 [...]


 
 A fun read!
 
 "(Late at night, I double checked. Mozilla’s CheckedInt is 
 just as bad as I remembered. They do a division to test for 
 multiplication overflow. Come on, put a line of assembler in 
 there! Portability is worth a price, just not any price.)"
 
 Shocked: do you use assembly in Checked and cripple the 
 optimizer?!?!
 Luckily, no. But LDC and GDC do create the `seto` instruction 
 I think you were hinting at:
 https://godbolt.org/g/0jUhgs
 
 (LDC doesn't do as good as it could, 
 https://github.com/ldc-developers/ldc/issues/2131)


 Thanks! Yes, seto is what I thought of - one way or another, it 
 gets down to using a bit of machine-specific code to get there. 
 I'll note that dmd does not generate seto (why?): 
 https://goo.gl/nRjNMy. -- Andrei


it does this
overflow_flag = 0
op
if (overflowed)
{
   overflow_flag = 1;
}

this can in some circumstances be faster then using seto!
If the inliner does a good enough job :)
May 23 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/23/2017 09:42 AM, Stefan Koch wrote:

 On Tuesday, 23 May 2017 at 13:27:42 UTC, Andrei Alexandrescu wrote:

 On 5/22/17 4:51 PM, Johan Engelen wrote:

 On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 [...]


 A fun read!

 "(Late at night, I double checked. Mozilla’s CheckedInt is just as 
 bad as I remembered. They do a division to test for multiplication 
 overflow. Come on, put a line of assembler in there! Portability is 
 worth a price, just not any price.)"

 Shocked: do you use assembly in Checked and cripple the optimizer?!?!
 Luckily, no. But LDC and GDC do create the `seto` instruction I think 
 you were hinting at:
 https://godbolt.org/g/0jUhgs

 (LDC doesn't do as good as it could, 
 https://github.com/ldc-developers/ldc/issues/2131)


 Thanks! Yes, seto is what I thought of - one way or another, it gets 
 down to using a bit of machine-specific code to get there. I'll note 
 that dmd does not generate seto (why?): https://goo.gl/nRjNMy. -- Andrei


 
 it does this
 overflow_flag = 0
 op
 if (overflowed)
 {
    overflow_flag = 1;
 }


Where did you see this pattern? Couldn't find it anywhere in 
core.checkedint. And how is "overflowed" tested?


 this can in some circumstances be faster then using seto!
 If the inliner does a good enough job :)


The code in core.checkedint is conservative:

pragma(inline, true)
ulong mulu(ulong x, ulong y, ref bool overflow)
{
     ulong r = x * y;
     if (x && (r / x) != y)
         overflow = true;
     return r;
}

The compiler is supposed to detect the pattern and generate optimal code.


Andrei
May 23 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 23 May 2017 at 15:19:39 UTC, Andrei Alexandrescu 
wrote:

 On 05/23/2017 09:42 AM, Stefan Koch wrote:

 On Tuesday, 23 May 2017 at 13:27:42 UTC, Andrei Alexandrescu 
 wrote:

 On 5/22/17 4:51 PM, Johan Engelen wrote:

 [...]


 Thanks! Yes, seto is what I thought of - one way or another, 
 it gets down to using a bit of machine-specific code to get 
 there. I'll note that dmd does not generate seto (why?): 
 https://goo.gl/nRjNMy. -- Andrei


 
 it does this
 overflow_flag = 0
 op
 if (overflowed)
 {
    overflow_flag = 1;
 }


 Where did you see this pattern? Couldn't find it anywhere in 
 core.checkedint. And how is "overflowed" tested?


 this can in some circumstances be faster then using seto!
 If the inliner does a good enough job :)


 The code in core.checkedint is conservative:

 pragma(inline, true)
 ulong mulu(ulong x, ulong y, ref bool overflow)
 {
     ulong r = x * y;
     if (x && (r / x) != y)
         overflow = true;
     return r;
 }

 The compiler is supposed to detect the pattern and generate 
 optimal code.


 Andrei


That code is written nowhere.
It was my hand translation of the asm.
(And it was wrong)

The compiler does indeed seem to optimize the code somewhat.
Although the generated asm still looks wired.
http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3
May 23 2017
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/23/2017 11:37 AM, Stefan Koch wrote:

 
 The compiler does indeed seem to optimize the code somewhat.
 Although the generated asm still looks wired.
 http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t
intel:!t),version:3 


That call enters a different overload:

pragma(inline, true)
uint mulu(uint x, uint y, ref bool overflow)
{
     ulong r = ulong(x) * ulong(y);
     if (r > uint.max)
         overflow = true;
     return cast(uint)r;
}

which is of efficiency comparable with code using seto. I'm not too 
worried about that. https://goo.gl/eRXUpr is of interest.


Andrei
May 23 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 23 May 2017 at 15:43:24 UTC, Andrei Alexandrescu 
wrote:

 On 05/23/2017 11:37 AM, Stefan Koch wrote:

 
 The compiler does indeed seem to optimize the code somewhat.
 Although the generated asm still looks wired.
 http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3


 That call enters a different overload:

 pragma(inline, true)
 uint mulu(uint x, uint y, ref bool overflow)
 {
     ulong r = ulong(x) * ulong(y);
     if (r > uint.max)
         overflow = true;
     return cast(uint)r;
 }

 which is of efficiency comparable with code using seto. I'm not 
 too worried about that. https://goo.gl/eRXUpr is of interest.


 Andrei


Well ....
Since core.checkedint is in druntime, we _could_ detected the 
checking operations and generate better code for them.
But right now, I am convinced it is worth the effort.
May 23 2017
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 23 May 2017 at 15:54:42 UTC, Stefan Koch wrote:

 Well ....
 Since core.checkedint is in druntime, we _could_ detected the 
 checking operations and generate better code for them.
 But right now, I am [NOT] convinced it is worth the effort.
May 23 2017
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 23 May 2017 at 15:37:39 UTC, Stefan Koch wrote:

 The compiler does indeed seem to optimize the code somewhat.
 Although the generated asm still looks wired.
 http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3


The jbe (jump-below-equal)
does check the overflow flag (and redundantly the zero-flag) here
and sets the bool which represents overflow to one.
May 23 2017
prev sibling next sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ --
Andrei


Now that you are back and could take some time to think this 
over, would you say your trip will influence how you see D's and 
the D community evolution? In what way?
May 22 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/22/17 6:53 PM, cym13 wrote:

 On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
 -- Andrei


 
 Now that you are back and could take some time to think this over, would 
 you say your trip will influence how you see D's and the D community 
 evolution? In what way?


In several ways. To an extent it was a confirmation of things already 
known: We do well on things we focus on (language core, standard 
library, quality of implementation), and less so on things we focus less 
on (soft skills, community building, leadership). I got a clearer notion 
that the latter is an important ingredient.

One thing that several of those people emphasized is we need to improve 
leadership and decision. "You are trying to do democracy and democracy 
doesn't work here" (by a successful serial entrepreneur). Walter and I 
have implicitly fostered a kind of meritocracy whereby it's the 
point/argument that matters. It should be meritocracy of the person - 
good proven contributors have more weight and new people must prove 
themselves before aspiring to influence. Historically, anyone with any 
level of involvement with D could hop on the forum and engage the 
community and its leadership in debate. Subsequently, they'd be 
frustrated with the ensuing disagreement and also get a sense of 
cheapness - if I got to carry this unsatisfactory debate with the 
language creator himself, what kind of an operation is this?

Since anything can be debated by anyone, everything gets debated by 
everyone. Anyone can question any decision at any time and expect a 
response. It's the moral equivalent of everyone in a 5000-person company 
building can expect to stop the CEO on the way to his/her office and 
engage them in a conversation of any length. The net consequence is 
slower progress.

Where we need to be is fostering strong contributions and contributors. 
The strength of one's say is multiplied by his/her contributions (and 
that simply means pulled PRs, successful DIPs - not "won" debates). Many 
successful OSS projects have been quoted as implementing this policy 
successfully.

Every person in the room took a significant fraction of the meeting time 
to tear me a new one about dub and http://code.dlang.org. Each in a 
different place :o). I got to the point where I consider every day spent 
with code.lang.org just sitting there with no ranking, no statistics, no 
voting, no notion of what are the good projects to look at - every such 
day is a liability for us. We really need to improve on that, it is of 
utmost importance and urgency. Martin said he'll be on that in June, but 
we could really use more hands on deck there.

Documentation of vibe.d was also mentioned as an important problem. More 
precisely, it's the contrast between the quality of the project and that 
of the documentation - someone said his team ended up with a different 
(and arguably inferior) product that was better documented. Literally 
they had the same engineer try each for a day. Reportedly it was very 
difficult to even figure whether vibe.d does some specific thing, let 
alone tutorials and examples of how to do it.

Back to community: Successful OSS projects have a hierarchy and follow 
formalized paths and processes for communicating up and down. People are 
willing to work/wait for months on a proposal because they have a sense 
of process and a confidence their proposal, if properly done, will get a 
fair shake. These are good ideas to follow (and indeed I got more 
confirmation that investing in our new DIP process is a good thing to do).

We need to improve the collaboration and tone in the forums and github. 
(I was amazed at how well these business and community leaders knew 
who's who in our community.) We can only assume in the future people 
will peruse our forums/github to decide whether to use D in their 
enterprise. We need to improve on the current disposition toward 
fruitless debate not concluding in decision making. What hurts us the 
most and stands like a sore thumb is the occasional use of abusive 
language. We need to stop that.

Many of these things I had a good sense of before entering the meeting, 
and was on the way toward improving on them. The meeting provided a 
strong confirmation of the importance of these matters, and good ideas 
toward doing better.


Andrei
May 26 2017
next sibling parent Meta <jared771 gmail.com> writes:
On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:

 What hurts us the most and stands like a sore thumb is the 
 occasional use of abusive language. We need to stop that.


Interesting. Are there any examples you're willing to provide? It 
seems to me that stuff like this is immediately condemned, but 
only if it comes from somebody who is new or doesn't post here 
often. There's been a few cases I can think of where a regular 
contributor/frequent poster said something that I'd consider 
"abusive language" and it's allowed to slide without (public) 
reprimand or apology, but again it's not completely clear what 
you have in mind when you say "abusive language".
May 26 2017
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:

 One thing that several of those people emphasized is we need to 
 improve leadership and decision. "You are trying to do 
 democracy and democracy doesn't work here" (by a successful 
 serial entrepreneur).


I'm pretty sure nobody actually involved with D would call it a 
democracy.  We may get to say our piece, but ultimately the core 
team decides.


 Walter and I have implicitly fostered a kind of meritocracy 
 whereby it's the point/argument that matters.


That's because that's all that matters.  It is what almost every 
worthwhile organization aspires to, though very few get there.  
Doing anything else would be a mistake.


 It should be meritocracy of the person - good proven 
 contributors have more weight and new people must prove 
 themselves before aspiring to influence.


Certainly you can weight their opinion more because they know the 
code better, but otherwise it is precisely this personal 
influence taking precedence over the particular argument that 
sinks most organizations.


 Historically, anyone with any level of involvement with D could 
 hop on
 the forum and engage the community and its leadership in 
 debate. Subsequently, they'd be frustrated with the ensuing 
 disagreement and also get a sense of cheapness - if I got to 
 carry this unsatisfactory debate with the language creator 
 himself, what kind of an operation is this?


Or they were inspired that their feedback was taken into account, 
if not followed, and decide to pitch in.


 Since anything can be debated by anyone, everything gets 
 debated by everyone. Anyone can question any decision at any 
 time and expect a response. It's the moral equivalent of 
 everyone in a 5000-person company building can expect to stop 
 the CEO on the way to his/her office and engage them in a 
 conversation of any length. The net consequence is slower 
 progress.


If you're going in the wrong direction, slower progress is to be 
lauded.

I think you're overly critical of the culture of debate that is a 
part of open source and especially this project.  I know I 
decided to pitch in after years of lurking in the newsgroup, I 
doubt I'm the only one.

Of course, like anything, debate can be overdone and you're 
probably right that it has been at times here.  But an open 
source project is a fundamentally different thing than a startup, 
it requires much more community involvement and deliberation.  I 
recommend reading this chapter from this book on open source 
development:

"Public discussion generally takes longer to make a decision than 
a proprietary development group does, but because the diversity 
of the viewpoints is greater for an open-source effort the 
resulting decision is likely to be of higher quality. This can 
translate into a shorter overall development cycle, because 
subsequent work will probably not need to be discarded because 
the real issues came up after, rather than during, the discussion 
period."
http://dreamsongs.com/IHE/IHE-54.html#pgfId-956812


 Where we need to be is fostering strong contributions and 
 contributors. The strength of one's say is multiplied by 
 his/her contributions (and that simply means pulled PRs, 
 successful DIPs - not "won" debates). Many successful OSS 
 projects have been quoted as implementing this policy 
 successfully.


There are different ways to contribute.  One may not have time to 
work on a bunch of PRs/DIPs or may be better suited to discussion 
of the technical design.

I agree that we need more people contributing rather than just 
talking, but I don't think this is the way to do it.


 Every person in the room took a significant fraction of the 
 meeting time to tear me a new one about dub and 
 http://code.dlang.org. Each in a different place :o). I got to 
 the point where I consider every day spent with code.lang.org 
 just sitting there with no ranking, no statistics, no voting, 
 no notion of what are the good projects to look at - every such 
 day is a liability for us. We really need to improve on that, 
 it is of utmost importance and urgency. Martin said he'll be on 
 that in June, but we could really use more hands on deck there.


Yeah, I mentioned this need before too.


 Documentation of vibe.d was also mentioned as an important 
 problem. More precisely, it's the contrast between the quality 
 of the project and that of the documentation - someone said his 
 team ended up with a different (and arguably inferior) product 
 that was better documented. Literally they had the same 
 engineer try each for a day. Reportedly it was very difficult 
 to even figure whether vibe.d does some specific thing, let 
 alone tutorials and examples of how to do it.


Eh, documentation is going to be sparse for a non-corporate OSS 
project.  If they're building products with vibe.d, presumably 
they can throw some consulting dollars Sonke's way and get him to 
help.


 Back to community: Successful OSS projects have a hierarchy and 
 follow formalized paths and processes for communicating up and 
 down. People are willing to work/wait for months on a proposal 
 because they have a sense of process and a confidence their 
 proposal, if properly done, will get a fair shake. These are 
 good ideas to follow (and indeed I got more confirmation that 
 investing in our new DIP process is a good thing to do).


Rather, it is a blend, some hierarchy on top of a wide herd of 
cats. ;) But sure, improving the process will help.


 We need to improve the collaboration and tone in the forums and 
 github. (I was amazed at how well these business and community 
 leaders knew who's who in our community.) We can only assume in 
 the future people will peruse our forums/github to decide 
 whether to use D in their enterprise. We need to improve on the 
 current disposition toward fruitless debate not concluding in 
 decision making.


As I said above, even "fruitless" debate can help, but like 
anything else, it can be overdone.


 What hurts us the most and stands like a sore thumb is the 
 occasional use of abusive language. We need to stop that.


Any large community is going to have it, tough to police.


 Many of these things I had a good sense of before entering the 
 meeting, and was on the way toward improving on them. The 
 meeting provided a strong confirmation of the importance of 
 these matters, and good ideas toward doing better.


I'm sure there was some good advice, but I'd caution that these 
entrepreneurs were not running an open source project, which 
requires a much lighter touch.
May 26 2017
next sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Friday, 26 May 2017 at 16:55:44 UTC, Joakim wrote:

 On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu 
 wrote:

 Documentation of vibe.d was also mentioned as an important 
 problem. More precisely, it's the contrast between the quality 
 of the project and that of the documentation - someone said 
 his team ended up with a different (and arguably inferior) 
 product that was better documented. Literally they had the 
 same engineer try each for a day. Reportedly it was very 
 difficult to even figure whether vibe.d does some specific 
 thing, let alone tutorials and examples of how to do it.


 Eh, documentation is going to be sparse for a non-corporate OSS 
 project.  If they're building products with vibe.d, presumably 
 they can throw some consulting dollars Sonke's way and get him 
 to help.


A reasonable presumption, but I do not know if Sonke himself has 
capacity for such as he seems quite busy.

So it might be worth thinking about alternative ways to move 
towards better docs for vibe.d (in collaboration with Sonke).
May 27 2017
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 26 May 2017 at 16:55:44 UTC, Joakim wrote:

 On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu 
 wrote:

 Walter and I have implicitly fostered a kind of meritocracy 
 whereby it's the point/argument that matters.




I don't see any evidence of this statement being true. 
Unfortunately.


 That's because that's all that matters.  It is what almost 
 every worthwhile organization aspires to, though very few get 
 there.  Doing anything else would be a mistake.


True.


 Of course, like anything, debate can be overdone and you're 
 probably right that it has been at times here.  But an open 
 source project is a fundamentally different thing than a 
 startup, it requires much more community involvement and 
 deliberation.


Right,  feedback and arguments about semantics are good, feedback 
on usability or integration problems are good.

What is not good is lifting out design-issues into small packages 
and trying to fix them one-by-one with a strong emphasis on 
implementation cost.

Democracy is great for building big things if the vision is clear 
and shared.

Democracy is great for pointing out where the systemic problems 
are.

Democracy is great for adapting something that is complete to new 
use cases.

Democracy is not great for innovation, designing new solution, 
creating good UI experiences or even engineering...

So, why-oh-why so much effort on writing DIPs on stuff like 
pre/post condition syntax? This has to be designed into a whole 
and would be better done by a small team of designers taking the 
_problems_ into account consulting experts on the specifics of 
the area. But if you want expertise you actually have to be 
interested in learning about that topic instead of defending what 
is there already.

Anyway, if people sense that semantic changes are too hard to get 
through I guess they will aim for something that is on the 
surface (like "body"). As a symbolic act to see if change is at 
all possible.

But it is rather inconsequential and rather inefficient use of 
resources. Which will happen to any project without a list of 
priorities.
May 27 2017
parent reply Meta <jared771 gmail.com> writes:
On Saturday, 27 May 2017 at 10:50:34 UTC, Ola Fosheim Grøstad 
wrote:

 Anyway, if people sense that semantic changes are too hard to 
 get through I guess they will aim for something that is on the 
 surface (like "body"). As a symbolic act to see if change is at 
 all possible.


Don't mistake my intentions. I proposed removing `body` because 
not being able to use it as a symbol name is often complained 
about on the forums, because it is a small, manageable and 
understandable change, because it is a net (admittedly tiny) 
improvement to the language, and because I wanted to write a 
"practice" DIP to familiarize myself with the process in the 
event that I decide to write a larger one in the future (such as 
fixing up and resubmitting Kenji's tuple DIP).
May 27 2017
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 27 May 2017 at 20:21:56 UTC, Meta wrote:

 On Saturday, 27 May 2017 at 10:50:34 UTC, Ola Fosheim Grøstad 
 wrote:
 Don't mistake my intentions. I proposed removing `body` because 
 not being able to use it as a symbol name is often complained 
 about on the forums, because it is a small, manageable and 
 understandable change, because it is a net (admittedly tiny) 
 improvement to the language, and because I wanted to write a


Sure, there are many small improvements that could be made, but 
this is a lot of bureaucracy for the 15 minutes it takes to turn 
it into a contextual keyword...
May 27 2017
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:

 Every person in the room took a significant fraction of the 
 meeting time to tear me a new one about dub and 
 http://code.dlang.org. Each in a different place


Just a couple days ago, people asked me if my libs were on dub... 
this was annoying because they shouldn't have to ask *me*, they 
should just ask the website, but even basic search and listing is 
broken.

I've complained about this before... 
https://github.com/dlang/dub-registry/issues/123 in Sept 2015.


I'm not a dub user, so I don't particularly care to maintain it 
myself... but does NOBODY care?

It is also embarrassingly slow to even load the code.dlang.org 
homepage.


 Documentation of vibe.d was also mentioned as an important 
 problem.


Documentation in general is a big problem.
May 26 2017
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:

 On 5/22/17 6:53 PM, cym13 wrote:

 One thing that several of those people emphasized is we need to 
 improve leadership and decision. "You are trying to do 
 democracy and democracy doesn't work here" (by a successful 
 serial entrepreneur). Walter and I have implicitly fostered a 
 kind of meritocracy whereby it's the point/argument that 
 matters. It should be meritocracy of the person - good proven 
 contributors have more weight and new people must prove 
 themselves before aspiring to influence. Historically, anyone 
 with any level of involvement with D could hop on the forum and 
 engage the community and its leadership in debate. 
 Subsequently, they'd be frustrated with the ensuing 
 disagreement and also get a sense of cheapness - if I got to 
 carry this unsatisfactory debate with the language creator 
 himself, what kind of an operation is this?

 Since anything can be debated by anyone, everything gets 
 debated by everyone. Anyone can question any decision at any 
 time and expect a response. It's the moral equivalent of 
 everyone in a 5000-person company building can expect to stop 
 the CEO on the way to his/her office and engage them in a 
 conversation of any length. The net consequence is slower 
 progress.

 Where we need to be is fostering strong contributions and 
 contributors. The strength of one's say is multiplied by 
 his/her contributions (and that simply means pulled PRs, 
 successful DIPs - not "won" debates).


I strongly suggest to have a clear and transparent procedure to 
collect impressions and  suggestion from *commercials* that are 
*actually using* the language in production, and separate those 
from other things to discuss.

Guru meditation: try not to loose talented contributors 
involved... Dicebot, Kenji, Bearofile... what's happened, and 
what can be done on this front?

Sincerely
/Paolo
May 26 2017
prev sibling next sibling parent Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ --
Andrei


Interesting read. You're my brother from another mother. :)
May 23 2017
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ --
Andrei


That was a great read, thanks!

At the end, you mention a successful serial entrepreneur who 
counsels pursuing the great rather than the good ideas being 
advanced in the D community. Did he happen to mention which ideas 
were great, and which just good?
May 23 2017
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-05-22 17:05, Andrei Alexandrescu wrote:

 http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/
 -- Andrei


About the custom attributes that are mentioned, like "has acquired a 
lock" attribute. This would be a perfect candidate for a UDA and using 
the compiler as a library to implement a domain specific checker for 
this feature. When the regular compiler sees this attribute it has no 
meaning to the compiler. But when running the custom checker it will 
perform some additional checks to verify that the code behaves according 
to the specific domain requirements.

Without knowing any details, it might be possible to implement similar 
checks today by modifying druntime and replace the RTInfo template with 
a custom implementation that performs some additional checks.

-- 
/Jacob Carlborg
May 23 2017