On Saturday, 13 April 2019 at 20:38:04 UTC, Walter Bright wrote:
> On 4/13/2019 6:08 AM, Nierjerson wrote:
>> I do not think think anyone is criticizing you or Walter personally or your capabilities in what you do. EXCEPT: You guys have to figure out how to take D to the next stage of growth. You guys are the leaders and so only you can do it. No one else can step in and say "This is how we are going to make it happen".
>
> Actually, yes they can. There's a lot that goes on that I have no involvement in, people just stepped up and did it. For example,
>
> gdc
> ldc
> bugzilla
> autotester
> dub
> VisualD
> Dfeed (the forum software)
> the website server
>
> What doesn't work is giving Andrei & I long lists of action items. I get them every day.


The problem is you don't understand and you think you do:

1. We are not talking about individuals doing things. We are talking about those things being done in a consistent and meaningful way rather than ad hock. What happens when Rainer Schultz gives up on D? You realize he took over Visual D himself from someone that gave up.

What happens when those people decide to move on, die, get preoccupied, have less time, etc?

You are always expecting people to do work yet and some do, but to pretend that it has any longevity is being naive. Visual D development has somewhat stalled. RS still works on it here and there but it is pretty much what it is. It has limitations and issues. It is not commercial and to pretend that it is the solution for the IDE platform on windows is nonsense. It is the only one that is usable to any useful degree. It works, surprisingly well, but not well enough for most businesses to invest in D.

I'm not saying to downplay these things, I'm simply saying 1. They are not enough. and 2. They are not coherent enough with D as a whole.

2. D needs structure in it's overall design. It's far more than just a compiler. A compiler by itself is about useless as a new born baby. The tools, libraries, the docs, the community, etc are all required for wide acceptance. But there has to be some underlying glue that binds it all together. Just having everyone create the these things on their own is not enough. It ends up with a rats nest of problems. Everyone does their things different ways, no one agree's, things don't easily connect up, etc.

It is quite amazing D has worked so well with this method, it is a testament to the people who contribute to D, not the process itself.

Imagine if all these people that have contributed to do did it in a structured in unified way. No redundancy, waste, abuse... what would D be like?

Your approach is too lackadaisical *if* your goal is wide acceptance[I realize that is a trigger word here because people think it means acceptance by the mass of moronic programmers]. It works well for some things but poorly for others.

All I am talking about is having a plan and project management.  Something like: "We have these N things we want done 100%, we will sort and prioritize these M things and work on them this way until they are accomplish. We will do them to the best of our abilities." [More than this, but trying to express an idea]


> You want something to happen, step up and take a role and make it happen.


Ok, I'm going to step up and take a role, right here right now:

1. You need to find someone who will create two things:

  a) a method for people to contribute in an easy way. A website would work, you have people who can create websites(they have done it) so task them with creating a new web sight, say dlang.org\ProjectManagement.

The site is designed to be coordinate two things:

      i. People who have a common desire for improvement on some part of D. It could be a library, a tool, a patch, etc.
      ii. The core D team's projects for D, such as rewriting phobos or D3 or an IDE, or whatever it is you guys decide is to be done. You state "We are doing this, here is how you can help".

The site is a meeting place, a way to formally work together. Not email, not forums. Sorta like bugzilla, github, forums, etc all combined. It doesn't have to be over the top but needs a unified and singular place to interact with in evolving D. What does this do? It provides a formality for people to take it serious, specially those on the outside. It says "We are serious bout getting things done around here so much that we take make it efficient to get things done". It is the difference from "work at home" and having an building where business is done. Just the environment itself makes people think differently.

You guys could talk about specifics. I'm just saying that some efficient, formal, and meaningful way to coordinate projects and people is necessary. Why? Because if it exists it will also increase the success rate of good projects. It might require you guys to spend a few weeks or months figure out the details. I think getting many peoples desires on such a site would be best.

No point in me giving too many of my thoughts because it is a task for you to do to get the ball rolling. What I am saying is that having a *place* to optimize work, scheduling, and tasking will turbo charge D, if it is done right.

I will say this: Suppose I want to contribute to a part of D that doesn't exist or up to my standards, say some library. By having a site where can go to, sorta like dub for libs, but search for the thing, say it is a graphics library, and I can see the projects, there should be just a few as these are projects sanctioned by D to eventually be official, then I can contribute to them.

You can say this is what dub and git hub provide... and in some way they do. But it's not the same. It's too fractured and too independent/individual. The site could link to github but it has to coordinate people(the energy/work) and harness it.

It also lets you guys organize it. If, say some group of guys want to write an audio library then you will have to take a look at it. This also requires a standardization of coding style which is done well. Ideally there would be the top programmers who monitor the code to make suggestions about issues such as longevity, style, generality, optimizations, etc.

You guys to to control the overall process while the worker bee's do the grunt work of writing code. With such a site you should be able to see an overall digraph of all the relationships and also dig in to the project management side, such as conflicts, time spent, who's doing what, etc.

One could could think of this as a sort of D forum on steroids(it could have a forum component that is integrated).

Wish such a site too, one could create fiat currency... you know how people love their fake gold coins. [I'm not suggesting that specifically but there could be a sort of reward system for contributing to projects or competitions, etc]


b) An overarching plan for D, say, for the next 10 years. This plan is then filled in with details. It should be rather exhaustive. It should cover ALL things anyone could want out of D. No expense should be spared, meaning there should be no worries about going overboard. All the fat can be trimmed. The idea here is to provide long term goals that definitely will make D better. It doesn't matter if you think it is worthless, it is just if magically it existed for D it would be better then it is added.

For example,

Let's imagine D should have it's own OS written in D. This is a feasible thing, it could potentially be better than any other OS out there. Of course, this is not something practical for D to focus on, but it is something that if one could magically have would be good for D. This is sort of brainstorming for things that will help D take over the world.

One then sorts, rehashes, prioritizes, and creates a smaller list of things. One builds a hierarchy. All things are relevant but it is narrowing down things to a manageable scheme. With the project management site, though, if some people want to build an OS for D then they could add it to the site, and move in that direction. They are busy building such a thing and so, eventually, in theory, it will get done. But it's officially part of D and that alone provides some cohesion.

Regardless of the specifics, these two options are meant to provide two things: An overall plan that people can understand and a place where the plan turns in to a reality.

2. You and your team need to sit down and rather than just gab about things seriously figure out what needs to be done, not for specific D things(e.g., some code, library, language feature, etc) but the management side. Each of you needs to have an honest conversation with yourself and each other to figure out where everyone stands, everyones desires, everyones intentions, and what each one is willing to do. If certain gaps in capabilities are missing then you need to seek out those people that will fill those gaps and fit all together correctly. There has to be balance to such a team. If everyone thinks the same then there is no dissenting views and this causes problems.

For example, if you have N people and they all think exactly the same way(identical copies) then there really is only 1 person. If that 1 person can't solve a problem then N of these people can't solve the problem no matter how large N is. And this is mathematical fact that proves similarity of thinking is not effective for difficult problems(it's great for problems that they all know how to solve).

Basically you guys need to find some people that fit your team but balance it out. Someone  you can trust and will listen to but doesn't think just like you do. You have to be able to argue about stuff and see who's right or to get a little frustrated. It makes everyone grow... but it doesn't have to be hateful. If everyone has the same desire then it will actually be effective and sort itself out.

3. The overall plan has to have a singular unified purpose. It is the focal point of what this is all about. It is something clear that everyone has in their mind. If you look at a great painting there is almost always a singular concept that presents to ones mind the moment one see's it. This concept says "This is what the painting is about"(it is true that people will interpret it different, but there is always a concept, it may be "ambiguous" in some sense but not in the persons mind). It's ultimately what ties everything together in a nice package and fills in the cracks when they form. Without it one is relying on luck and/or passion/determination. These work for small things but rarely for large projects involving many people(since most people won't have much luck or passion to make it happen and they will also destroy that of others).

---

So, you and your team need to sit down and hash these things out. You don't have to listen to what I said, maybe when you sit down and try to figure all this out you'll find a better solution.  It is not about programming, but about management. No real programming topics are involved. You might figure out a way to make it worth while, could take a vacation for it, or after it. Might setup something special to make it happen. I don't know the specifics. But what I do know is that if you guys continue your approach the same way it is, the same results will occur almost surely and it is easily predictable the long term outcome.

Also, keep in mind that it doesn't mean you have to do a lot of hard work. It means that you simply have to structure things to get other people to do the hard work for you. (this is what all business is and it is a form of slavery in that it leverages other people's ability to supply energy in to the system for the purpose of a cause they generally are not ultimately interested in. You are luck that there are so many people willing to contribute to D, you might as well maximize their efforts and leverage it as much as you can).

I do hope you can figure this out. I do like D and think you did a great job in many ways. The thing that is going to make D fail though is not the great things you did but the poor things you did(= the great things you didn't do).  D is like a candle flame in the world and many of us want to see it was a volcano. That may not be your desire though but remember, Even though D is your child, many others helped raise it.

On 4/13/2019 3:12 PM, Nierjerson wrote:
> Ok, I'm going to step up and take a role, right here right now:
>
> 1. You need to find someone who will create two things:

> No point in me giving too many of my thoughts because it is a task for you to do

> 2. You and your team need to

> Basically you guys need to

> So, you and your team need to

> It means that you simply have to structure things

> I do hope you can figure this out.

This is not stepping up, it's giving me a list of action items. I have an action item for you:

* Find something great on your list of action items and do it!

---

Allow me to explain a couple things.

This is not a business. There's some paid work going on, but not a whole lot because there isn't a lot of funding. A good compiler engineer would get $500,000/yr. We just don't have a lot of money.

This means relying on volunteers. The fun thing about volunteers is you can't tell them what to do. A normal occurrence is people ask me what to work on. I present a list A, B, C, D, and the person then does H. Why? Because H interests them.

You might think, what a mess. In many ways that's true. On the other hand, working on D is a MARVELOUS opportunity for anyone who wants to jumpstart their career.

For example, take Iain Buclaw. He single-handedly, doggedly, and indefatigably improved GDC (which had been abandoned) to the point where it was accepted by and officially incorporated into the Gnu Compiler Collection. This is a monumental, career-making achievement. It's the only thing he ever needs to write on his resume. He's a made man.

Many D contributors have leveraged their work on D into high paying jobs that were otherwise closed to them.

I'm very proud of these fellows and their achievements. I'm honored that D was the route to their success. The opportunity is here with D for anyone else who wants to learn and show the world what they can do.

On 4/13/2019 2:35 PM, Mike Franklin wrote:
> Lately, I find the things that Walter is doing in DMD to be a very low priority compared to all of the bugs in bugzilla for which only he is qualified to fix.  I wish he'd stop refactoring code and start fixing bugs, but, maybe his refactorings of late are laying some groundwork for more important stuff.

I gave a list a couple times on technical debt in DMD, and nobody picked up the flag. So I've been doing it.

If this is let go for too long, the code becomes unmaintainable.

On Sunday, 14 April 2019 at 04:48:00 UTC, Walter Bright wrote:

i think there are some other things you don't understand yet.
go back in this thread and read what people think about D and why they think it should be forked.
you guys made lab experiment of it instead of finding out what the real world programming needs. why are people dissatisfied?
stop finding all those mediocre things/solutions like help here or do that. i admire the gdc project but i would not use it.
my experience is, that programmers (at work) look at D and are afraid of using it. to large, to many features that are nice but nobody needs, web like syntax, the GC and after reading in the forum, they are even more afraid to use an unstructured experiment.
then there no tools, libraries etc., just visuald and that is the only reason why some try D for a short time.
well now will tell us again - write the tools/libraries, but in a business you don't have the time to do that. all those things come with c++, c# or java. why should i invest time and money into D?
no time to experiment.
i like D, followed it for a long, long time, but it turned into a moloch. some of us still use D1 for little tasks. i hope somebody takes D1, strips the gc, adds templates, cleans up this mess and forgets about the rest of the bloat.

On Sunday, 14 April 2019 at 04:48:00 UTC, Walter Bright wrote:
> On 4/13/2019 2:35 PM, Mike Franklin wrote:
>> Lately, I find the things that Walter is doing in DMD to be a very low priority compared to all of the bugs in bugzilla for which only he is qualified to fix.  I wish he'd stop refactoring code and start fixing bugs, but, maybe his refactorings of late are laying some groundwork for more important stuff.
>
> I gave a list a couple times on technical debt in DMD, and nobody picked up the flag. So I've been doing it.

Uh, yes we have, and you response was not far from get stuffed (maybe that was Andrei's, don't remember).

> If this is let go for too long, the code becomes unmaintainable.

You don't say.

On Sunday, 14 April 2019 at 04:48:00 UTC, Walter Bright wrote:
> On 4/13/2019 2:35 PM, Mike Franklin wrote:
>> Lately, I find the things that Walter is doing in DMD to be a very low priority compared to all of the bugs in bugzilla for which only he is qualified to fix.  I wish he'd stop refactoring code and start fixing bugs, but, maybe his refactorings of late are laying some groundwork for more important stuff.
>
> I gave a list a couple times on technical debt in DMD, and nobody picked up the flag. So I've been doing it.
>
> If this is let go for too long, the code becomes unmaintainable.

you need to stop whining and start to organize something.
stop the development, stabilize and eradicate the experiments.
find out what people need and implement that first - treat this like a business.

stop whining - do something

On Sunday, 14 April 2019 at 05:35:41 UTC, silentwatcher wrote:
> On Sunday, 14 April 2019 at 04:48:00 UTC, Walter Bright wrote:
>
> i think there are some other things you don't understand yet.
> go back in this thread and read what people think about D and why they think it should be forked.
> you guys made lab experiment of it instead of finding out what the real world programming needs. why are people dissatisfied?
> stop finding all those mediocre things/solutions like help here or do that. i admire the gdc project but i would not use it.
> my experience is, that programmers (at work) look at D and are afraid of using it. to large, to many features that are nice but nobody needs, web like syntax, the GC and after reading in the forum, they are even more afraid to use an unstructured experiment.
> then there no tools, libraries etc., just visuald and that is the only reason why some try D for a short time.
> well now will tell us again - write the tools/libraries, but in a business you don't have the time to do that. all those things come with c++, c# or java. why should i invest time and money into D?
> no time to experiment.
> i like D, followed it for a long, long time, but it turned into a moloch. some of us still use D1 for little tasks. i hope somebody takes D1, strips the gc, adds templates, cleans up this mess and forgets about the rest of the bloat.

I am working in the "business" 9 to 5 and I can say 90% of what you write is just wrong. It seems you had a look 5 years ago at D and all the improvements and community effort since then you haven't noticed.
The D Language is used at companies and the tooling, libraries have greatly improved. I enjoy every day I can write D coding at work because it works so much better than other languages.

Please take the time to validate what you say.

Kind regards
Andre

On Sunday, 14 April 2019 at 04:48:00 UTC, Walter Bright wrote:

> I gave a list a couple times on technical debt in DMD, and nobody picked up the flag. So I've been doing it.
>
> If this is let go for too long, the code becomes unmaintainable.

I understand.  I'll give the list another look and maybe make a few PRs in passing.

You could make things a lot easier on everyone and just adopt The D Style for DMD:  https://dlang.org/dstyle.html#phobos_documentation

For those who don't know and want to help Walter out, the list is here:  https://forum.dlang.org/post/p6oibo$1lmi$1@digitalmars.com

Mike

On Sunday, 14 April 2019 at 08:00:16 UTC, Andre Pany wrote:
> On Sunday, 14 April 2019 at 05:35:41 UTC, silentwatcher wrote:
>> [...]
>
> I am working in the "business" 9 to 5 and I can say 90% of what you write is just wrong. It seems you had a look 5 years ago at D and all the improvements and community effort since then you haven't noticed.
> The D Language is used at companies and the tooling, libraries have greatly improved. I enjoy every day I can write D coding at work because it works so much better than other languages.
>
> Please take the time to validate what you say.
>
> Kind regards
> Andre

in your setting it might be wrong - not in mine.
i love disciples - but maybe you are right, i will shut up and hope something will change.
good luck in your endeavors.

On Sunday, 14 April 2019 at 08:00:16 UTC, Andre Pany wrote:
> On Sunday, 14 April 2019 at 05:35:41 UTC, silentwatcher wrote:
>> [...]
>
> I am working in the "business" 9 to 5 and I can say 90% of what you write is just wrong. It seems you had a look 5 years ago at D and all the improvements and community effort since then you haven't noticed.
> The D Language is used at companies and the tooling, libraries have greatly improved. I enjoy every day I can write D coding at work because it works so much better than other languages.
>
> Please take the time to validate what you say.
>
> Kind regards
> Andre

in your setting it might be my observations could be wrong - not in mine.
i love disciples/evangelists - but maybe you are right, i will shut up and hope something will change.
good luck in your endeavors.