Has D failed? ( unpopular opinion but I think yes )

[Nierjerson]

On Sunday, 14 April 2019 at 00:00:46 UTC, Walter Bright wrote:
> 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.

I realize this, and this is why it is even more prudent to do 
things as best as possible. For example, if you have a yugo and 
you are racing F1's you better optimize all variables in all ways 
to stand a chance.

What you have stated is an excuse. Money helps but you don't have 
it, so do you just give up? Because that is what you are saying 
whether you realize it or not.

I'm not blaming you or D's management in any way. I know it is an 
uphill battle. What I'm trying to do here is make you realize 
that the way your climbing the mounting is a hard route. You need 
other people that you trust and will commit and bring in to your 
inner sanctum. Only you can make that decision.

I've noticed H. S. Teoh mention wanting to fork D. I believe he 
is quite an intelligent person and seems to have alternative 
views that could provide more of a balance for you guys. You NEED 
someone that thinks differently. You might need other people. But 
ultimately you have to realize it would be beneficial to broaden 
your group(is it just you and Andre?) and that you have to find 
the right people.

You have to also realize you have to make changes yourself. You 
must adapt with the times. If you still manage D with the same 
mindset you did 10 years ago then something is wrong. This is why 
you need other people to help you. It is IMPOSSIBLE for you to do 
what is needed by yourself or even you and Andre! If you think it 
is then you have already failed.

I'm not saying that progress won't be made, I'm saying that it 
won't be enough[I could be wrong, but I'm 99.99% likely too be 
right]. I don't want to see D go down the tubes and I don't want 
to see D stagnate. It is really the language I enjoy programming 
in the most, but it is also the language I get frustrated with 
the most. I like to work on weaknesses, not strength. Anyone can 
work on their strengths, that's the easy job, but we are held 
down by our weaknesses and weaknesses actually are most 
beneficial to build(because of diminishing returns and the way 
knowledge and experience work together(it's O(n!)).


>
> 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.

I know, but it is a double edge sword. There has to be a balance!

Remember, if a volunteer wants to do something on his own he can. 
You shouldn't stop that, it is tyrannical. But some people need 
and want structure. The best way is to provide both paths. If 
someone wants to climb the steep cliff they can, others who want 
the guided tour need that. If you limit any path then you are 
selecting only those people who will take it.

D suffers from a lack organized structure. If it had too much 
structure I would be saying the opposite of what I am saying. I'd 
be "You guys are too dictatorial, you guys need to chill and 
relax!".



>
> 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.

D works well in many ways, I'm not saying it is a total mess... 
not in the least. What I'm saying is simply this:

The D community almost only works on it's strengths... specific 
feature sets that the most dedicated want to work on and they 
neglect those things they are not interested in.

This is great for them because, guess what, they are happy. They 
say things like "Well, D works for me" or "These businesses use D 
quite successfully". I've used D successfully... if I only judge 
it on those things that it is successfully used at.

The problem with that is that the things D does poorly in are 
never developed to any high level and so it never attracts other 
people who need those things.

You have to realize because of the way D has been run in the past 
has setup what it is today. Basically it is self-motivated people 
who are willing to work on their own for their own cause. This 
has build up a hodge podge of disorganized libraries, all kinds 
of problems... Over time it gets worse and requires more effort 
to maintain. For example, if D depreciates certain features then 
those libraries general bit rot and all that effort is ultimately 
wasted. Of course, the strengths of D are not so much effected.



> 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.

Yes, and it is quite amazing that people dedicate their precious 
time... but it is still not the way to go. You are relying on 
people to build D for you... what happens when they stop? Even if 
they trickle in over time you have a certain rate of progression 
of growth that you think will continue building D:

In your mind you see D's growth as

D(t) = m*t

where m is the rate of growth which depends on volunteers 
contributing to D(which may change over time but we will use 
averages).

But you fail to take in to account other variables:

D(t) = m*t - d*t - e*t

d is decay rate. It is a measure of bit rot that occurs that 
hurts D. e is an environmental cost. Such as other compilers that 
compete with d(such as taking volunteers).

In fact the equation is far more complicated but you are only 
looking at the positive side(the things that D was well and keeps 
it going).

Eventually the costs will outweigh the benefits and D will then 
end bit rotting itself(it will just end up another compiler in 
the compiler grave yard, where eventually all compilers end up, 
even C++ will be there one day, but who wants to die young?).


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

I'm not disputing anything like this. But you are only looking at 
the positives. Your view is warped. You MUST look at the 
negatives, no matter how painful it is. Without looking at the 
negatives they will eventually overtake the positives and then 
you will be forced to look at them(well, you might die before 
they come in too play but they will occur none the less).

> 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.

No one is trying to knock anything bad about D, what you have 
done, your intelligence, anyone else's intelligence, anyones 
contributions, all the hard work, all the dedication, or anything 
else that has made D what it is.

This discussion ultimately has nothing to do with D's 
achievements. They HAVE to be ignored, at least on some level, so 
one can see the negatives. And without seeing the negatives there 
is no balanced view and D will eventually reach it's limits.

You have to realize that what is being said is not a specific 
statement about D, it is a general statement about all 
things(e.g., you are thinking in terms of functions and I'm 
thinking in terms of templates, so to speak, meaning my 
statements are more applicable to a wider class of things). I can 
say what I have said about C++ too, or anything else. You might 
say then what is the point? The point is that the better one 
understands these things the better one can control the various 
factors for specific outcomes.

1.  You agree that all things reach diminishing returns? 
Eventually whatever grows as has a growth curve and it must(in 
practical sense, or maybe just average) end up diminishing? Why? 
Because growth requires resources and all resources are 
limited(even if astronomical, they are still limited = finite).

2. All things have other factors that control their growth, so 
many that they are effectively uncountable.

D's progress, like all things, is some N dimensional function 
that depends on t and many other things. [meaning that if we know 
all the data we could model it using an N dimensional function 
rather precisely]

Such functions have orders of growth and decay. Big O notation 
takes such things in to account. You know sorting routines have 
such measures of growth. But you realize that D is just some big 
sort routine that is very complicated? It takes bits and sorts 
them in to a new array giving some complex function(the grammar, 
the machine language specification, etc). It's so complex that 
you have probably even never tried to simplify it in such a 
way... but make no mistake, it is still just an abstract machine 
that has the same types of mathematical abstractions in it.

The point is then that there are negative components and if you 
ignore them then they will catch up and then take over. You are 
ignoring most of those components. You should try to find the 
largest ones and reduce their effect.

See, if we were talking about an optimization problem, say a cpu 
task scheduler, you would have no problem understanding what I'm 
talking about. You'd say agree and say "Yes, if we want to 
maximize throughput we need to minimize task switching(it is 
costly) so we should run the most important tasks first... but we 
can't starve the smaller tasks completely." and we would come up 
with some code that would try to optimize the scheduling of the 
tasks[which is project management too].

You know all about that kinda stuff but you fail to realize it 
also exists(in a disguised form) in D's own management, which 
again, is just a program(all things in life are programs... it's 
no coincidence that transistors and neurons both are switches or 
that people use the same term for many disparate things. It's 
because there is a much deeper connection between all things).

Since you, I believe, do understand Big O/Little O notation and 
theory, I'll simplify the whole discussion to this:

D = o(t) - O(t)

o(t) is the lower bound of D's growth, it can't do any worse than 
this.

O(t) is the upper bound on D's decay, it can't do any better than 
this.

You are only looking at o(t), I'm trying to get you to look at 
O(t) because you are effectively ignoring it(seems to be what 
most humans do). You are looking at the positive side(o(t)) and 
ignoring the negative side(O(t)).


But since O(t) is not 0, there is the risk that D's growth will 
end up "negative" dead. (The universe seems too dictate that O(t) 
always overtakes o(t) due to finite resources/diminishing 
returns/bit rot/etc).

Now, if we want to maximize D's growth, we can't just look at 
o(t), we must also try to deal with O(t).

You have focused so much on o(t) and ignored almost all O(t) that 
O(t) is the "low hanging fruit". It's got so many terms in it 
that are large and can be rather easily dealt with(diminishing 
returns haven't kicked in) that if you realized this and decided 
to deal with them(as unpleasant as they seem) that you could give 
a huge boost to the overall growth of D.

But you keep focusing on o(t).

If this was an algorithm, which it is ultimately, your algorithm 
will be doomed in the long run. Not because of what you have done 
with o(t) but because of what you haven't done with O(t).

I'm in no way criticizing you for you and others accomplishments 
on o(t) but I am criticizing you on your neglect of O(t). My 
statements are purely based in logic, mathematics and reality. 
Meaning they are mathematical models(simplifications of reality) 
that are applicable to all things that can be modeled 
mathematically(which seems to be almost everything in the 
universe). It's just like how much things can be represented by a 
differential equation, or how most things can use computers to 
solve their problems(which is why compilers are so important 
since they let us more effectively write programs that solve 
problems).

The balance is to look at both o(t) and O(t). Most people look at 
only one and ignore the other as if it didn't exist[It might be a 
left/right brain thing].


If you spent the next month or two just hard core analyzing O(t) 
you'd probably do more for D than in the last 5 years. You'll see 
things you never thought existed(because they didn't in your mind 
since you never saw them). You just have to drop you preconceived 
notions and biases that have formed. You have conditioned 
yourself to look at o(t).

You are, in fact, the best person to do this because you know far 
more about D overall and generally there is actually some type of 
interdependence between o and O. Of course, having others to help 
you break out of the mental box you exist in will speed up the 
process(it's not an attack, we all exist in our own mental boxes, 
but expanding our boxes almost always is a good thing).


I'll give you a quick example that may or may not mean anything 
too you. I've always been right handed and have heavily used it 
for all things so much so that certain things that require the 
left hand usually slow me down considerably. Such as typing. I am 
very fast with my right hand, and my left faster than most 
peoples right hand... but my left hand is not at all at the same 
level as my right. I decided to try to balance this by forcing 
myself to use my left hand for things. I now can use it for many 
different things such as for a mouse and various 
tooling(soldering iron, etc) and it feels comfortable(not quite 
at the same level as the right but it's no longer a determent and 
if I ever lost my right hand it would be quite easy for me to 
adapt). This thing though is much deeper because our brains are 
wired in specific ways to our body. By forcing myself to use my 
left hand I have actually rewired my brain to some degree in a 
positive way(more balanced).

I even use two mice because sometimes it's much quicker to grab 
one with the left hand(which I think is because computer input is 
rather poorly understood. Imagine having a brain harness where 
you just think of what you want and it happens... keyboards and 
mice are just middle men that slow this process down).

Now, 5 years ago I would have never thought about such things 
because I was rather myopic. Thinking that how I thought about 
things was the way they existed. I have learned through that, 
that my thinking is limited by me and has little congruence with 
the real world. The left hand/right hand is just an example. One 
must always try too find the other side to things, it actually 
benefits everything. It's hard to understand this until you have 
done it enough to see how it works(like all things it is 
experiential). But it is very powerful. I'm trying to get you to 
at least take a leap of faith here you should do the same type of 
thing with D[ultimately in everything you do]. At worst you would 
have wasted some of your time, at best you might completely 
change your existence or D's progression. I can't tell you 
specifics in much of a meaningful way since, if you remember, I'm 
talking more in general terms. You have to fill in those specific 
details and then analyze the patterns objectively(taking in to 
account both sides).