On 2/10/14, 3:15 PM, Andrei Alexandrescu wrote:
> 2. A few months ago a prominent member of the community made (privately
> to Walter and myself) a strong argument along the same lines as yours: D
> could move much faster if some good management could be used with it,
> and offered to ask as a manager of the project.

s/ask/act/

On Monday, 10 February 2014 at 23:15:35 UTC, Andrei Alexandrescu wrote:
> Taking a look at https://www.bountysource.com/trackers/383571-d-programming-language, however, reveals that there's little attention to those bugs, in SPITE of the fact that contributions on HARDER problems on the SAME project continued as furiously as ever, if not more.

Interesting, I had directly the opposite impression when went through the bountysource list. Lot of issues have pull requests provided but are stalled because of slow feedback cycle.

Am 11.02.2014 00:11, schrieb deadalnix:
> On Monday, 10 February 2014 at 21:57:42 UTC, Paulo Pinto wrote:
>> A bit off topic, but can you still get new single core chips?
>
> Sure you can. But that is far from common, unless you have really strict
> constraints.

I know, I was just big a bit sarcastic about not using threads in this day and age.

On Monday, 10 February 2014 at 21:57:42 UTC, Paulo Pinto wrote:
> A bit off topic, but can you still get new single core chips?

Yes you can!
http://en.wikipedia.org/wiki/Intel_Edison
will be made available in 2014, single core.
And since it will have very limited resources, C# and Java are probably off limits. I must say D would be a perfect language for it!
:D

On Monday, 10 February 2014 at 23:13:56 UTC, deadalnix wrote:
> You seems to knows everything in and out. You tell me. If you
> aren't sure, please start parsing D to clang AST. After all, that sound like a great idea.

No, I don't know everything, but I said "modified subset of D", that would be a different language. Suitable for my needs (I don't need RTTI or exceptions etc).

I know I can do it, because source-2-source compilation is not that difficult and could be the first step. And (slow) parsers are not so difficult to write with the tools we have today.

After looking at the SVN repositories for clang I am becoming a bit more familiar with the source code which looked chaotic the first time I looked at it.

The AST looks ok from skimming through the repository, I assume I can get it through a visualization tool and generate visual graphs of the hierarchies.

Le 11/02/2014 00:12, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" a écrit :
> On Monday, 10 February 2014 at 23:06:56 UTC, Xavier Bigand wrote:
>> ????
>> So in these case I will forget D, and cry all the tears of my body. It
>> will just a shame for a system language.
>> And it's certainly kind of applications actually miss for D, to
>> improve his visibility.
>
> Yes, but nobody that are in the "decision making body" of D has shown
> any resemblance of understanding or priority for real time applications.
> Seriously, the language is close to ten years in the making.
>
>> Just take a look around you all applications are interactive, with
>> more animations,...
>
> Yeah, but at some point you just have to accept that people who don't
> have a need to write real time will avoid putting it on the road map.

Boostrapping D, will certainly reveal some issue with GC? I don't know much about compilers, but certainly the parser may see some performance gains with GC and the other parts? Maybe some major loose?

I am curious to see that as a benchmark comparator.

It's not real-time but it's a serious system application challenge.

> I would like to see a roadmap that says "real time" and "no gc" and
> "whole program optimization", "owned pointers", "shared pointers"++
>
> I see no road map.

On Monday, 10 February 2014 at 23:20:50 UTC, Andrei Alexandrescu wrote:
> Terrific. The challenge here is to adapt project management theory to the realities of a volunteer project.

Yes, I understand that. I guess it often means that key people have to do the "unfun" stuff and let the more intermittent volunteers do the "fun" stuff…

But I believe that "democratic design" requires very strong communication of vision if you want to create something new (otherwise you tend to end up with bastardized copies of what exist, since people will navigate towards the safe common ground).

> that. I'm all ears on advice on how to do better. I just have difficulty seeing how more management would help.

Just a suggestion of some possibilities:

Externally (front of web page):
- More clear communication of the boundaries of the project.
- Stating clearly what ground you do not cover.
- Defining short term/long term goals on your front page.
- Make it visible when they are met or changed.

Internally (you probably do this already in some form):
- Map out a list of dependencies between long term goals and use it for planning so that people who are more inclined to do proof-of-concept stuff can help out.
- Some sort of social reward mechanism (borrow from MMOs?). I like the bounty stuff, but social rewards are much stronger.
- Make commitments in key areas. Like stating how the project will change if you cannot meet deadlines. Like a priori stating what you will do with the GC if benchmark X is not met by date N. That could make those wanting GC push harder and those not wanting GC more complacent. Ok, maybe the wrong thing to do for the GC, but you get the idea, get the direction set.

(Is it reasonable to limit features/production-quality to the shared common denominator of 3 backends? Can you somehow mitigate that?)

On Monday, 10 February 2014 at 23:29:25 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 10 February 2014 at 23:13:56 UTC, deadalnix wrote:
>> You seems to knows everything in and out. You tell me. If you
>> aren't sure, please start parsing D to clang AST. After all, that sound like a great idea.
>
> No, I don't know everything, but I said "modified subset of D", that would be a different language. Suitable for my needs (I don't need RTTI or exceptions etc).
>
> I know I can do it, because source-2-source compilation is not that difficult and could be the first step. And (slow) parsers are not so difficult to write with the tools we have today.
>
> After looking at the SVN repositories for clang I am becoming a bit more familiar with the source code which looked chaotic the first time I looked at it.
>
> The AST looks ok from skimming through the repository, I assume I can get it through a visualization tool and generate visual graphs of the hierarchies.

Long story short, if you want to map thing on top of clang AST, you'll have to reduce significantly the subset of D you want to use, or build a full fledged front end, at which point you'd better use LLVM directly or GCC, or whatever backend suit your desires.

For instance, static ifs, template constraints and CTFE require full understanding of language semantic by the frontend. Runtime reflection, is also out. That mean UDA could work but become useless. Type inference also require almost complete understanding of the language by the frontend.

And even with these drastic restrictions, you'll still need a significant amount of semantic analysis in the frontend before feeding clang. You'll have to instantiate templates yourself (or bye bye alias parameters, string parameters and so on). Track variables used in closures (well, on that one you can arguably allocate every stack frame on heap and pas the whole stack frame to C++ lambda, that should work, but that will excruciatingly slow and memory consuming) to allocate them on heap.

With CTFE, compile time reflection and static ifs/mixins, D wraps around itself in a way that makes it all or nothing in implementation.

On Monday, 10 February 2014 at 23:15:35 UTC, Andrei Alexandrescu wrote:
> develop themselves. But as I told Walter, for better or (sometimes definitely) worse, our character flaws make history inside the D community.

But I am also a hard core roleplayer… so you won't know when I am me, and when I am pulling your leg. I assume the same about you. ;-]

The internet is a stage. What is real, what is not real? Hard to tell. What is a person, what is a character? Difficult question.

> This is a typical problem. Reviewing contributions is hard and thankless work. I know how we solved it at Facebook for our many open-sourced projects: we created a team for it, with a manager, tracking progress, the works. This is _exactly_ the kind of thing that can't be done in a volunteer community.

Maybe you can make some parts modular after you refactor into D. Then people can take ownership of modules and social recognition will encourage more commitment.

I don't know the D social arena well enough to know if that works though.

> So I wasn't glib when I sent you to github. In a very concrete sense, you'd be helping there a ton more in a fraction of the time you spend posting.

But I don't want to do that when I am merely assessing D. I am not commited to D. Yet.

> I think D must not define itself in relation to any other language.

I respect that position.

Of course, it does not help if outsiders have been told that D is a better C++. It kinda sticks. Because people really want that.

I am very hard trying to convince myself that D is more like compiled C#, which lowers my expectations, because that original vision of a "better C++" is very firmly stuck.

Of course, the problem with C++ is that it is used very differently by different people. D is appealing more to the high-level version of C++. It probably depends on when you first used C++ or what parts of C++ you are interested in.

> done and witnessed a number of such attempts, I think you're exceedingly naive about what can be done with traditional project management approaches in this case.

There you go ad hominem again.

I have studied online virtual worlds where people volunteer for worse…

But my point was more that you need to communicate a vision that is such that the people you want to attract don't sit on the fence. I am quite certain that more skilled C++ programmers would volunteer if they saw a vision they believed in.

So maybe they don't do more, but more hands available…

> Ola, I'm sure you mean well. I trust you will find it within yourself the best way to contribute to this community.

You really need to avoid this ad hominem stuff… You see, as a hardcore roleplayer I could be tempted to switch over into a sarcastic mode. And that would not be fair to you. ;-)

On Tuesday, 11 February 2014 at 00:21:22 UTC, deadalnix wrote:
> With CTFE, compile time reflection and static ifs/mixins, D wraps around itself in a way that makes it all or nothing in implementation.

Ok, but I think I didn't communicate clearly what I am looking for. I am just looking for a "nicer" C++. I don't really need the full D semantics. I am content with the C++ subset that I can desugar into.

To me D is just that, a "nicer" C++. I don't need the high level stuff. Those are "nice to have", but not "needed".