www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Vision 2016 H1

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
In case you missed it from the announce forum: 
http://wiki.dlang.org/Vision/2016H1 -- Andrei
Jan 24
next sibling parent tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:
 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei
Is there a list or a proper place to put the list of desired/asked/necessary tools together with their purpose?
Jan 24
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:
 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei
Some comments: - I'm not sure number of PRs is worth measuring, maybe a better metric would be number of devs submitting a PR, especially given your goal of raising participation. If it's just a core group of devs submitting most of those PRs, does it matter much that they had more time to work on D a year ago? - I don't think the language of military hierarchy, ie general/lieutenant/soldier, applies towards D. It's more like a guerrilla army, think the US revolution and the Swamp Fox (https://en.wikipedia.org/wiki/Francis_Marion#Guerrilla_war). Since everybody is a volunteer, this is how it will be organized anyway, just pointing out that almost nobody wants to be called a lieutenant! :) - It sounds like there's a fair amount of minutiae that's only handled by the core team right now. I agree that formalizing that work into an official title or group would help get more people to do it, as has been done with the release manager role. On the other hand, every OSS project has this problem, as few will volunteer to take out the garbage. ;) - Don't discount the debate on the newsgroup. I lurked in the newsgroup for years before I got involved, to see what kinds of decisions were being made and how the process worked. Yes, everybody would rather debate than chip in, but talking is usually a precursor for doing. - I don't understand this section: "This needs to be balanced with the false notion that any contribution must receive attention in proportion to the effort expended on it. 'I wrote a DIP therefore it must be worked on' quickly becomes 'There's no purpose in trying a DIP, nobody will look at it'." Are you saying DIP and PR authors should not expect anybody to care about their efforts? That would seem contrary to the goal of raising participation. Perhaps a way to avoid this situation and formalize it would be to provide some sort of pre-approval process that is guaranteed to be checked by the core team (enhancement requests in bugzilla don't work, it's just too overstuffed with issues), so that contributors can be told _before_ they work on something whether it's likely to get serious consideration. Maybe a wiki page that's monitored by the core team? Swift also has the converse, a list of issues that are unlikely to be accepted: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md - There's a couple mentions of tooling, but I don't get the impression that source formatters and parsers are what people have in mind. I think they're talking about bugs or holes in the core tools, ie compilers, linkers, and debuggers. This is a problem for any OSS project that doesn't have a commercial model, to fund such quality of implementation issues that volunteers don't want to take up.
Jan 24
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-01-25 06:19, Joakim wrote:

 - I don't understand this section:

 "This needs to be balanced with the false notion that any contribution
 must receive attention in proportion to the effort expended on it. 'I
 wrote a DIP therefore it must be worked on' quickly becomes 'There's no
 purpose in trying a DIP, nobody will look at it'."

 Are you saying DIP and PR authors should not expect anybody to care
 about their efforts?  That would seem contrary to the goal of raising
 participation.
Just because you get more pull request (more participation) doesn't mean someone needs to look at them ;) -- /Jacob Carlborg
Jan 25
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 05:19:41 UTC, Joakim wrote:
 - Don't discount the debate on the newsgroup.  I lurked in the 
 newsgroup for years before I got involved, to see what kinds of 
 decisions were being made and how the process worked.  Yes, 
 everybody would rather debate than chip in, but talking is 
 usually a precursor for doing.
Yup, debates are important for creating shared understanding and consensus. Moving without consensus means a lot less will be done. Good leaders create processes where consensus emerge AND a good shared understanding of why and how.
Jan 25
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 January 2016 at 05:19:41 UTC, Joakim wrote:
 Since everybody is a volunteer, this is how it will be 
 organized anyway, just pointing out that almost nobody wants to 
 be called a lieutenant! :)
The name isn't that bad, but the authority question is... lieutenants would need enough documentation to make decisions on their own that they can be confident are correct and accepted by the leadership. We don't have that, so appointing someone to the title would be meaningless, regardless of what it is called. General is a bit different because there's more autonomy there and such an individual may be ok making up their own rules.
 - There's a couple mentions of tooling, but I don't get the 
 impression that source formatters and parsers are what people 
 have in mind.
I'm not so sure... those do form the groundwork for a lot of requested things like refactoring tools too which are somewhat common requests.
  I think they're talking about bugs or holes in the core tools, 
 ie compilers, linkers, and debuggers.
And this too, of course.
Jan 25
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 14:37:36 UTC, Adam D. Ruppe wrote:
 The name isn't that bad, but the authority question is... 
 lieutenants would need enough documentation to make decisions 
 on their own that they can be confident are correct and 
 accepted by the leadership. We don't have that, so appointing 
 someone to the title would be meaningless, regardless of what 
 it is called.

 General is a bit different because there's more autonomy there 
 and such an individual may be ok making up their own rules.
Well, as a former soldier serving at a national military HQ the terminology comes through as extremely childish and pushing all the wrong buttons. The military is a rigid blind bureaucracy per excellence with absolutely no other purpose than being able to execute fast and predictable in a future crisis moving thousands of units. Outside that crisis it is slow, expensive, inefficient and the activities are pointless and non-negotiable. :-/
Jan 25
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 January 2016 at 15:02:37 UTC, Ola Fosheim Grøstad 
wrote:
 The military is a rigid blind bureaucracy
That's kinda my point though, we can't even do bureaucracy because the rules aren't there so "lieutenants" would be completely lost, and we can't do autonomy because nobody is clear on who owns what.
Jan 25
prev sibling parent reply kldjlkd <kldjlkd kldsjf.kd> writes:
On Monday, 25 January 2016 at 15:02:37 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 25 January 2016 at 14:37:36 UTC, Adam D. Ruppe wrote:
 The name isn't that bad, but the authority question is... 
 lieutenants would need enough documentation to make decisions 
 on their own that they can be confident are correct and 
 accepted by the leadership. We don't have that, so appointing 
 someone to the title would be meaningless, regardless of what 
 it is called.

 General is a bit different because there's more autonomy there 
 and such an individual may be ok making up their own rules.
Well, as a former soldier serving at a national military HQ the terminology comes through as extremely childish and pushing all the wrong buttons. The military is a rigid blind bureaucracy per excellence with absolutely no other purpose than being able to execute fast and predictable in a future crisis moving thousands of units. Outside that crisis it is slow, expensive, inefficient and the activities are pointless and non-negotiable. :-/
You deny the whole modern history with such a speech. The current state of human being, with all its history and experience, is that so far we haven't found any better solution than being organized and prioritized (or specialized). In the past, people tried to adopt a more horizontal system but it didn't work.
Jan 25
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 15:28:47 UTC, kldjlkd wrote:
 You deny the whole modern history with such a speech.
That's a bold statement with no argument to back it up.
 The current state of human being, with all its history and 
 experience, is that so far we haven't found any better solution 
 than being organized and prioritized (or specialized).

 In the past, people tried to adopt a more horizontal system but 
 it didn't work.
Of course we have horizontal and organic ways of organizing civil society. The military is just a very very special case where no failure is accepted in very chaotic situations. That means everything is routine. It is far more bureaucratic than even the most bureaucratic civil organization. The legal system is organic in comparison. People who have romantic ideas about the army probably have their ideas of what it is like from movies or games. That does not reflect the incredibly dull day-to-day army life. The overarching principle in the army is that nobody should need to be so skilled in their task that they cannot easily be replaced on the spot. Basically an ant colony.
Jan 25
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
wrote:
 That does not reflect the incredibly dull day-to-day army life.
I don't think we should read *too* much into the words. Whether we call them collaborators or middle managers or lieutenants or what isn't as important as actually just defining what we actually want to do. In a few threads over the last few weeks, I've said that I don't want to be part of Phobos because it destroys my development flow and I've even gone so far as to fork Phobos itself and write a whole new generator to fix its documentation. The main reason is in my own projects, I know exactly what is expected of me to get stuff done and there's very little process overhead. This way, I can make the most of my limited time. Middle managers in Phobos need an environment where they won't feel the same way, they need some degree of ownership too.
Jan 25
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:
 I don't think we should read *too* much into the words.
Yeah, it's interesting. I recall thinking as I was drafting the document: "One word... ONE word that doesn't sit well and it will be all about that word." And now here we are. It's like those presidential or Fed chairman press conferences... :o). I changed http://wiki.dlang.org/Vision/2016H1. Andrei
Jan 25
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu 
wrote:
 On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:
 I don't think we should read *too* much into the words.
Yeah, it's interesting. I recall thinking as I was drafting the document: "One word... ONE word that doesn't sit well and it will be all about that word." And now here we are. It's like those presidential or Fed chairman press conferences... :o). I changed http://wiki.dlang.org/Vision/2016H1.
It was just a suggestion for better naming, and it's hardly all I talked about. I haven't liked that military terminology since a couple DConfs ago, but I felt it might turn off those coming across the language now who read the Vision document, so I finally mentioned it. The last thing you'd want potential OSS contributors thinking is that we have some military-style bureaucracy here. ;) Dicebot's suggestion, which you use now, is much better. btw, is there really an opening in "top leadership?" I thought that door was shut. :)
Jan 25
prev sibling next sibling parent reply Andrew Edwards <edwards.ac gmail.com> writes:
On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu 
wrote:
 On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:
 I don't think we should read *too* much into the words.
Yeah, it's interesting. I recall thinking as I was drafting the document: "One word... ONE word that doesn't sit well and it will be all about that word." And now here we are. It's like those presidential or Fed chairman press conferences... :o). I changed http://wiki.dlang.org/Vision/2016H1. Andrei
The bikeshed is now translucent... However, the community still lacks focus/direction. Pick a destination, establish To-dos and Milestones, empower the community to make it happen, then supervise to ensure everyone stays on task. State the priority or at a least list of priorities. Everything under the sun cannot be THE priority. e.g. 1. Improve Module System -- To-dos -- Milestones 2. Improve Memory Management 2.1 Garbage Collector -- To-dos -- Milestones 2.2 Manual Memory Management -- To-dos -- Milestones 3. Tools 3.1 Adapt dfmt -- To-dos -- Milestones 3.1 Adapt dfix -- To-dos -- Milestones After stating the priority, identify the most capable resources to head each initiative, empower them with a bit of autonomy and encourage the larger community to organize in support of these initiatives. Finally, supervise!!!
Jan 25
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 25 January 2016 at 22:12:06 UTC, Andrew Edwards wrote:
 On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu 
 wrote:
 On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:
 I don't think we should read *too* much into the words.
Yeah, it's interesting. I recall thinking as I was drafting the document: "One word... ONE word that doesn't sit well and it will be all about that word." And now here we are. It's like those presidential or Fed chairman press conferences... :o). I changed http://wiki.dlang.org/Vision/2016H1. Andrei
The bikeshed is now translucent... However, the community still lacks focus/direction. Pick a destination, establish To-dos and Milestones, empower the community to make it happen, then supervise to ensure everyone stays on task. State the priority or at a least list of priorities. Everything under the sun cannot be THE priority. e.g. 1. Improve Module System -- To-dos -- Milestones 2. Improve Memory Management 2.1 Garbage Collector -- To-dos -- Milestones 2.2 Manual Memory Management -- To-dos -- Milestones 3. Tools 3.1 Adapt dfmt -- To-dos -- Milestones 3.1 Adapt dfix -- To-dos -- Milestones
I've been asking for this list for sometime now. It is actually what I wanted from the Vision document, but that ended up too broad and vague. I've since repeatedly pointed out that it should be more specific, more like a roadmap, as you lay out.
 After stating the priority, identify the most capable resources 
 to head each initiative, empower them with a bit of autonomy 
 and encourage the larger community to organize in support of 
 these initiatives.
These people will tend to be self-selected, but they could always be given some leeway in a named role.
 Finally, supervise!!!
I doubt this would ever happen: Walter and Andrei are not managers, and I doubt OSS contributors would want it. The best one can do is define a roadmap and hope it's heeded. I wanted to say this earlier but forgot: what D is trying to do is impossible. You cannot have a successful OSS project that has a high technical standard and no commercial backing. OSS projects tend to be more like ruby and rails, where most anything goes. Projects with a high technical standard have to be more selective, so they go against the OSS grain. When that happens in OSS, it's usually because of commercial backing. It is amazing that D has gotten so far as an OSS project without commercial backing, a credit to the engineering sense of Walter and the core team. But I don't think you can organize your way around that fundamental obstacle. Of course, I'd likely have said OSS being so widespread would be impossible a couple decades ago, but OSS has certainly garnered a niche, once it was coupled with commercial models.
Jan 25
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 04:57:11 UTC, Joakim wrote:
 It is amazing that D has gotten so far as an OSS project 
 without commercial backing, a credit to the engineering sense 
 of Walter and the core team.  But I don't think you can 
 organize your way around that fundamental obstacle.
I don't think that is accurate at all. But paid work will make it easier to get the boring or difficult parts done. Hobby programmers will gravitate towards the fun parts and copying the design of others (e.g. Linux copying Unix). For D, the difficult part is completing the language on paper. It is human nature to push difficult parts are into the future, but one should actually say "no more work on easy parts, we have to do the difficult parts first". And that takes decisive leadership. Implementing is the easy part.
Jan 25
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 26 January 2016 at 07:18:43 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 04:57:11 UTC, Joakim wrote:
 It is amazing that D has gotten so far as an OSS project 
 without commercial backing, a credit to the engineering sense 
 of Walter and the core team.  But I don't think you can 
 organize your way around that fundamental obstacle.
I don't think that is accurate at all.
Which part? There's at least three statements there, one largely factual, one opinion, then a prediction. It's unclear what you think is inaccurate, since you don't say.
 But paid work will make it easier to get the boring or 
 difficult parts done. Hobby programmers will gravitate towards 
 the fun parts and copying the design of others (e.g. Linux 
 copying Unix).

 For D, the difficult part is completing the language on paper. 
 It is human nature to push difficult parts are into the future, 
 but one should actually say "no more work on easy parts, we 
 have to do the difficult parts first". And that takes decisive 
 leadership.

 Implementing is the easy part.
I wouldn't say D has pushed the difficult parts, and often implementing takes a lot of work too. Obviously, the design is usually more important in the long-term, but the design "on paper" won't matter if nobody wants to implement it.
Jan 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 14:24:57 UTC, Joakim wrote:
 On Tuesday, 26 January 2016 at 07:18:43 UTC, Ola Fosheim 
 Grøstad wrote:
 On Tuesday, 26 January 2016 at 04:57:11 UTC, Joakim wrote:
 It is amazing that D has gotten so far as an OSS project 
 without commercial backing, a credit to the engineering sense 
 of Walter and the core team.  But I don't think you can 
 organize your way around that fundamental obstacle.
I don't think that is accurate at all.
Which part? There's at least three statements there, one largely factual, one opinion, then a prediction. It's unclear what you think is inaccurate, since you don't say.
I don't think OSS needs commercial backing to reach high technical levels. I do think that many OSS projects spend too little time on design and process, and well, design and coordination is more challenging when you aren't co-located in the same place. I also think that often implementors take leading roles in OSS, when that role should have been taken by a designer/coordinator that would spend more time on leadership. If you spend 10% leading and 90% coding then the leading part suffers... But there are tools we can use, if the issue was recognized.
 I wouldn't say D has pushed the difficult parts, and often
Memory management. Performant garbage collection. Coherent semantics.
 implementing takes a lot of work too.  Obviously, the design is 
 usually more important in the long-term, but the design "on 
 paper" won't matter if nobody wants to implement it.
They probably would if there was consensus behind it, it was solid, important and had a seal of approval.
Jan 26
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 26 January 2016 at 14:35:53 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 14:24:57 UTC, Joakim wrote:
 On Tuesday, 26 January 2016 at 07:18:43 UTC, Ola Fosheim 
 Grøstad wrote:
 On Tuesday, 26 January 2016 at 04:57:11 UTC, Joakim wrote:
 It is amazing that D has gotten so far as an OSS project 
 without commercial backing, a credit to the engineering 
 sense of Walter and the core team.  But I don't think you 
 can organize your way around that fundamental obstacle.
I don't think that is accurate at all.
Which part? There's at least three statements there, one largely factual, one opinion, then a prediction. It's unclear what you think is inaccurate, since you don't say.
I don't think OSS needs commercial backing to reach high technical levels. I do think that many OSS projects spend too little time on design and process, and well, design and coordination is more challenging when you aren't co-located in the same place. I also think that often implementors take leading roles in OSS, when that role should have been taken by a designer/coordinator that would spend more time on leadership. If you spend 10% leading and 90% coding then the leading part suffers...
OK, I finally know what you disagree with. The fundamental problem is that without commercial funding, all OSS contributions are voluntary, usually done during their spare time, while focused design takes time, a lot of it. Without commercial backing to fund that time, it is difficult for most to work towards that high level of technical design. Perhaps that's why OSS devs spend most of their time coding, they want to focus what little time they have on getting some code out. Now, every once in a while, some lone coder like Walter has the time to buck those odds. But then the problem becomes scaling the OSS project, especially without a commercial model. We're lucky that Walter and Andrei are financially independent enough to work on D full-time, but that's still only two people. D certainly is going a lot slower than it would with commercial backing. Now, corporate support is no panacea, it has its own pitfalls. And maybe if someone stuck a whole bunch of money behind D, Walter and Andrei wouldn't even know how to spend all of it well, ie torrid growth simply may not be possible at this point in the language growth curve. But I think D would certainly have grown faster to this point if it had a commercial model, and that such funding generally allows time for the design and coordination you say most OSS projects don't do.
 But there are tools we can use, if the issue was recognized.
Such as?
 I wouldn't say D has pushed the difficult parts, and often
Memory management. Performant garbage collection. Coherent semantics.
It doesn't sound like Walter has much interest in the first two, and either nobody has picked those up or bothered to integrate PRs like Sociomantic's concurrent GC from D1. As for the last, I'm sure he either disagrees or doesn't care.
 implementing takes a lot of work too.  Obviously, the design 
 is usually more important in the long-term, but the design "on 
 paper" won't matter if nobody wants to implement it.
They probably would if there was consensus behind it, it was solid, important and had a seal of approval.
I don't think consensus has been the issue as much as time, which is the killer for any OSS or voluntary project.
Jan 26
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 15:02:51 UTC, Joakim wrote:
 OK, I finally know what you disagree with.  The fundamental 
 problem is that without commercial funding, all OSS 
 contributions are voluntary, usually done during their spare 
 time, while focused design takes time, a lot of it.  Without 
 commercial backing to fund that time, it is difficult for most 
 to work towards that high level of technical design.  Perhaps 
 that's why OSS devs spend most of their time coding, they want 
 to focus what little time they have on getting some code out.
It is true that it is easier to jump in and out of "evolutionary coding" than focused design, but that's more of a convenience issue... You can achieve a lot by cutting down the scope and use a divide and conquer strategy. So I don't think it is the most limiting factor, unless you try to implement an existing bloated standard like C++ or HTML5.
 I don't think consensus has been the issue as much as time, 
 which is the killer for any OSS or voluntary project.
I think one generally can get more done by having a design that is ready and that is partitioned into "implementable units". Design the APIs for a standard library up front, provide minimal proof-of-concept implementation, let other people replace it with production quality code.
Jan 26
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu 
wrote:
 Yeah, it's interesting. I recall thinking as I was drafting the 
 document: "One word... ONE word that doesn't sit well and it 
 will be all about that word." And now here we are. It's like 
 those presidential or Fed chairman press conferences... :o).

 I changed http://wiki.dlang.org/Vision/2016H1.
Yea, let's paint that non-pacifistic bikeshed ;-) In seriousness: I think the vision in terms of improving engagement is fine, but what I would suggest in practice is to focus carefully on the decision-making structure that is needed in order for D to flourish. That's going to involve some serious thought about, for example, what sort of decisions Walter and yourself are happy delegating, what circumstances you might reserve a veto or override, and how to arrange things (and provide structured guidance) so that the chances of you needing to pull those powers out are minimal. It would also involve considering who gets a say about who sits in various decision-making roles (for example, how to mix top-down and bottom-up selection of people who will hold positions of responsibility). I think that getting that basic structure right may do a lot in terms of making it possible to obtain, productively use, and retain contributors on every possible level.
Jan 25
prev sibling next sibling parent reply JohnCK <j j.com> writes:
On Monday, 25 January 2016 at 16:02:09 UTC, Adam D. Ruppe wrote:
 On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
 wrote:
 That does not reflect the incredibly dull day-to-day army life.
I don't think we should read *too* much into the words. Whether we call them collaborators or middle managers or lieutenants or what isn't as important as actually just defining what we actually want to do.
I agree 100%! Please guys don't get stuck on small things like this. I'm seeing this behavior growing up in here. Maybe it's time to create a new group called: Drama. :) And please don't waste your time answering this. JohnCK.
Jan 25
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 16:31:50 UTC, JohnCK wrote:
 On Monday, 25 January 2016 at 16:02:09 UTC, Adam D. Ruppe wrote:
 On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim 
 Grøstad wrote:
Please guys don't get stuck on small things like this. I'm seeing this behavior growing up in here.
It is not a small thing in the sense that it affects D's ability to complete features before adding more features. Let's follow the metaphores: - Andrei is the general. - Walter is the general/special forces. The special forces are highly skilled, but don't bring common soldiers along. They don't exercise leadership, but swiftly implement features on direct orders from the generals: like C++ exceptions, UDAs etc. Here's the problem: features are added before the existing features are completed without any documentation/rationale for why the new features are of the highest priority. This goes on while the population is suffering from traffic jam caused by a lack of basic infrastructure like non-GC memory-management. Is the lack of memory management a small thing? Hell no. So why isn't it of the highest priority? Because it is difficult to design? Well, then you need to replace the generals with a process that can bring in more viewpoints. Now, in defense of Andrei, I'll say that he has become much less of a general in the past two years, and more of an enabler, and that he also created a forum to allow more viewpoints to be presented. But the generals aren't nurturing the process! And the implementation of D still depends on Walter operating as the special forces rather than bringing other people up closer to his level... Not a small problem. Establishing a better process with better yield is a challenging problem. It won't happen by itself.
 And please don't waste your time answering this.
So you are basically in favour of censorship? Which is an authoritarian mode of leadership. Thus you don't mind having generals as a metaphor. Don't you think that people can decide for themselves which debates they want to engage in? Which is a more democratic way of organizing decision making processes.
Jan 25
parent reply JohnCK <j j.com> writes:
On Monday, 25 January 2016 at 18:37:44 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 25 January 2016 at 16:31:50 UTC, JohnCK wrote:
 ...
 And please don't waste your time answering this.
So you are basically in favour of censorship? Which is an authoritarian mode of leadership. Thus you don't mind having generals as a metaphor. Don't you think that people can decide for themselves which debates they want to engage in? Which is a more democratic way of organizing decision making processes.
Please, you've exposed your opinion and Andrei already changed the document using "contributors". Engaging on this matter will be just a waste of time. Let's focus on D itself. JohnCK.
Jan 25
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 18:45:43 UTC, JohnCK wrote:
 Please, you've exposed your opinion and Andrei already changed 
 the document using "contributors". Engaging on this matter will 
 be just a waste of time. Let's focus on D itself.
Again you make an authoritarian statement "Engaging on this matter will be just a waste of time.". Nobody has to waste their time, they don't have to read. There is no way _you_ can know what leads to a change that will bring the necessary changes that makes D competitive. D added nogc YEARS ago, because I pushed the point that the GC would never be a viable option for real time programmers. But we still have no competitive memory management on paper. That's two years too late. We should have been implementing it now. D needs a competitive solution to Rust and C++ before C++ compilers implement the next generation C++ features. That might be next year? I would love to get rid of C++, but I increasingly believe that this will not be a rational option. That's sad, because C++ is a nuisance. You cannot focus on D without changing the process. Meaning: give critical features higher priority than "low hanging fruit".
Jan 25
parent reply Meta <jared771 gmail.com> writes:
On Monday, 25 January 2016 at 20:34:40 UTC, Ola Fosheim Grøstad 
wrote:
 D added  nogc YEARS ago, because I pushed the point that the GC 
 would never be a viable option for real time programmers.
No. The only part you may have had in ushering in nogc is putting the idea out there (although I'm pretty sure Manu and Bearophile were advocating it long before that). nogc was brought about because Johannes Pfau had the initiative to implement the framework for it and push it through. Otherwise we would still just be talking about it as a nice idea, and you would be bringing it up for the nth time with absolutely no benefit to anyone.
Jan 25
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 01:08:31 UTC, Meta wrote:
 No. The only part you may have had in ushering in  nogc is 
 putting the idea out there (although I'm pretty sure Manu and 
 Bearophile were advocating it long before that).  nogc was 
 brought about because Johannes Pfau had the initiative to 
 implement the framework for it and push it through. Otherwise 
 we would still just be talking about it as a nice idea, and you 
 would be bringing it up for the nth time with absolutely no 
 benefit to anyone.
No. This isn't about the idea of " nogc" or "better C", Walter did those on his own. It was about convincing Walter that enough people found the current situation not very useful for a particular type of programming. It was about having many viewpoints of how the GC situation was keeping D back. It was a very long and heated thread with many people commenting on what they needed to make better use of D. Changes in D come from significant _vocal_ end user pressure. That is the historical trend. And that trend is very clear.
Jan 25
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 16:02:09 UTC, Adam D. Ruppe wrote:
 On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
 wrote:
 That does not reflect the incredibly dull day-to-day army life.
I don't think we should read *too* much into the words.
For individualistic people that have been drafted to boot camp and experienced being stripped off their individuality and drilled to blindly obey pointless "humiliating" orders by young and dumb seargents the words evoke the wrong _emotions_. I was so happy to put that part of my life behind me. It was a wasted year. I don't have to read anything into the words. It is in my spine. There is no way I can pretend that military role-play in a supposedly productive environment isn't immature.
 Whether we call them collaborators or middle managers or 
 lieutenants or what isn't as important as actually just 
 defining what we actually want to do.
No, but it sends a message of what "generals" and "lieutenants" imagine to be the ideal development process. Which is something I have complained loudly about before. I think it keeps D back. I think how you organize the process can have massive influence on degree of volunteering, enthusiasm and the quality of the decision-making. If you take on the title "general" it does communicate something about your mental model of the process. It is a very pompous label that few normal adults would be comfortable with applying to themselves outside a game world.
 In a few threads over the last few weeks, I've said that I 
 don't want to be part of Phobos because it destroys my 
 development flow and I've even gone so far as to fork Phobos 
 itself and write a whole new generator to fix its documentation.

 The main reason is in my own projects, I know exactly what is 
 expected of me to get stuff done and there's very little 
 process overhead. This way, I can make the most of my limited 
 time.
And that is an interesting perspective that sends strong signals about a need to reconsider how the process can be organized so that people feel less resistance in their own productivity/satisfaction. Evolving the process and motivational factors is a key leadership role, right?
Jan 25
prev sibling parent reply kldjlkd <kldjlkd kldjlkd.fs> writes:
On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 25 January 2016 at 15:28:47 UTC, kldjlkd wrote:
 You deny the whole modern history with such a speech.
That's a bold statement with no argument to back it up.
 The current state of human being, with all its history and 
 experience, is that so far we haven't found any better 
 solution than being organized and prioritized (or specialized).

 In the past, people tried to adopt a more horizontal system 
 but it didn't work.
Of course we have horizontal and organic ways of organizing civil society.
breaking news, the civil society has a horizontal organization... What a joke.
Jan 25
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 17:18:40 UTC, kldjlkd wrote:
 On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
 wrote:
 Of course we have horizontal and organic ways of organizing 
 civil society.
breaking news, the civil society has a horizontal organization... What a joke.
Read the sentence again. It is not uncommon in highly educated organizations to have flatter structures and high levels of autonomy. I am not going to argue this point, that is my field after all.
Jan 25
prev sibling parent reply Dicebot <public dicebot.lv> writes:
On Monday, 25 January 2016 at 14:37:36 UTC, Adam D. Ruppe wrote:
 On Monday, 25 January 2016 at 05:19:41 UTC, Joakim wrote:
 Since everybody is a volunteer, this is how it will be 
 organized anyway, just pointing out that almost nobody wants 
 to be called a lieutenant! :)
The name isn't that bad, but the authority question is... lieutenants would need enough documentation to make decisions on their own that they can be confident are correct and accepted by the leadership. We don't have that, so appointing someone to the title would be meaningless, regardless of what it is called. General is a bit different because there's more autonomy there and such an individual may be ok making up their own rules.
I think more realistic name distinction would be "core team", "collaborators" and "contributors".
Jan 25
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 25 January 2016 at 15:05:45 UTC, Dicebot wrote:
 I think more realistic name distinction would be "core team", 
 "collaborators" and "contributors".
LOL. I was just reading the section on that in "The Design and Implementation of the FreeBSD Operating System" yesterday. What timing. - Jonathan M Davis
Jan 25
parent reply Dicebot <public dicebot.lv> writes:
On Monday, 25 January 2016 at 18:30:49 UTC, Jonathan M Davis 
wrote:
 On Monday, 25 January 2016 at 15:05:45 UTC, Dicebot wrote:
 I think more realistic name distinction would be "core team", 
 "collaborators" and "contributors".
LOL. I was just reading the section on that in "The Design and Implementation of the FreeBSD Operating System" yesterday. What timing. - Jonathan M Davis
What section? I have no idea what you refer to :)
Jan 25
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 25 January 2016 at 18:52:00 UTC, Dicebot wrote:
 On Monday, 25 January 2016 at 18:30:49 UTC, Jonathan M Davis 
 wrote:
 On Monday, 25 January 2016 at 15:05:45 UTC, Dicebot wrote:
 I think more realistic name distinction would be "core team", 
 "collaborators" and "contributors".
LOL. I was just reading the section on that in "The Design and Implementation of the FreeBSD Operating System" yesterday. What timing. - Jonathan M Davis
What section? I have no idea what you refer to :)
Section 1.4 where they go over the FreeBSD development model. http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0321968972/ref=sr_1_1?ie=UTF8&qid=1453752473&sr=8-1&keywords=freebsd+operating+system - Jonathan M Davis
Jan 25
prev sibling next sibling parent Satoshi <satoshi gshost.eu> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:
 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei
Whats about reference counting as a main memory manager? It would be nice for low level programming where I cannot use GC and want use things like ~=, etc.
Jan 25
prev sibling next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:
 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei
Maybe we should finally decide what color to paint the bikeshed?
Jan 25
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 25 January 2016 at 15:38:01 UTC, rsw0x wrote:
 On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
 wrote:
 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei
Maybe we should finally decide what color to paint the bikeshed?
Probably some shade that they can't actually make paint of for some reason. ;) - Jonathan M Davis
Jan 25
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:
 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei
We are still shorthanded with all aspects of D development: top 
leadership,
I'd be interested in seeing someone with good leadership/community skills(no offense to Andrei/Walter meant) become a "top" part of D like Andrei/Walter currently are. I can think of a few D core contributors off the top of my head that seem to possess good leadership qualities and seem to go out of their way to make sure things get done.
Jan 25
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/16 1:48 PM, rsw0x wrote:
 On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu wrote:
 In case you missed it from the announce forum:
 http://wiki.dlang.org/Vision/2016H1 -- Andrei
 We are still shorthanded with all aspects of D development: top
 leadership,
I'd be interested in seeing someone with good leadership/community skills(no offense to Andrei/Walter meant) become a "top" part of D like Andrei/Walter currently are. I can think of a few D core contributors off the top of my head that seem to possess good leadership qualities and seem to go out of their way to make sure things get done.
Yah, that aspect is less understood than it should. Say Herb Sutter would join the fray under an alias and started doing great things - I trust myself and Walter enough to think he'd be quickly recognized and "promoted". There definitely is room in the top ranks for one or more folks of that caliber. -- Andrei
Jan 25
parent Bubbasaur <bubba gmail.com> writes:
On Monday, 25 January 2016 at 19:41:53 UTC, Andrei Alexandrescu 
wrote:
 ... There definitely is room in the top ranks for one or more 
 folks of that caliber. -- Andrei
Scott Meyers!
Jan 25