[OT] Leverage Points

[John Carter]

On Saturday, 18 August 2018 at 22:20:57 UTC, Walter Bright wrote:
> On 8/18/2018 9:59 AM, Jonathan Marler wrote:
>> In your mind, what defines the D language's level of success?
>
> It no longer needs me or Andrei.

I think that is a pretty weak measure.

Stroustrup and Matsumoto are still actively tending their babies 
decades later.


A better measure is that "it is the language of choice for 
programming activity."

Note the fine print there.

* Choice. ie. Programmers _want_ to use it, not are constrained 
to use it.
* For programming activity, not new projects. ie. The era of vast 
tracts of green field programming is long gone. We're mostly in 
the era tinker toys and tidying.

By tinker toys I mean gluing and configuring large frameworks and 
packages together.

While the industry does a huge amount of tinker toy development, 
and has massive package and dependency management tools.... we're 
still not Good at it. There is a big difference between "Doing a 
lot of" and "Being Good at".

By tidying I mean refactoring legacy code that is way too large 
and complex to rewrite all at once. ie. A "successful" language 
of the 2020's is one that can "play nice" with the vast pile of 
legacy.

> in increasing order of effectiveness
> 12. Constants, parameters, numbers (such as subsidies, taxes, 
> standards).

The cost of starting to use D.

> 11. The sizes of buffers and other stabilizing stocks, relative 
> to their flows.

The size of pool of people who know of, and know D.

> 10. The structure of material stocks and flows (such as 
> transport networks, population age structures).

Current projects, tools and packages using D.

> 9. The lengths of delays, relative to the rate of system change.

Time to bug fix, time to answering a newbies question, time to 
handle and roll out a dip.

> 8. The strength of negative feedback loops, relative to the 
> impacts they are trying to correct against.

The effect of bad experiences with D. Bugs in compiler and 
libraries.

> 7. The gain around driving positive feedback loops.

The positive effects on productivity and programmer happiness in 
using D.

> 6. The structure of information flows (who does and does not 
> have access to information).

How well does information flow from the experts to the newbies. 
How hard is to create and get accepted new info.

> 5. The rules of the system (such as incentives, punishments, 
> constraints).

Incentives tend to be, "My change, my suggestion, my package was 
accepted or accepted up to a bunch of constructive feedback 
suggestions"

Punishments tend to be rejection, especially dismissive or 
insulting.

Constraints tend to be number of and pain due to bureaucratic 
hoops one has to jump through.

> 4. The power to add, change, evolve, or self-organize system 
> structure.

There is a strong push to lock the language standard and standard 
library down solid.

But this merely results in a language and language ecosystem 
(cough python 3) that cannot evolve.

A better goal would be to provide rewrite tools that would allow 
the language ecosystem to evolve with the language.

ie. You need a compiler that reads AND rewrites code!

> 3. The goals of the system.

If the D language evolution is directed at ever smaller and less 
relevant corners of programming activity, yes, it will die. If it 
is directed and enabling and enriching ever larger portions of 
the programming activity, it will thrive.

> 2. The mindset or paradigm out of which the system — its goals, 
> structure, rules, delays, parameters — arises.

ie. Is the mindset to create a language, or to create a language 
that is so compelling it will dominate the language landscape.


> 1. The power to transcend paradigms.

D is fairly well positioned to take on many of the current 
language paradigms.

This question is more about if a new one comes along, does D 
absorb it? Or wilt? Again I come back to that rewrite tool. How 
fast can you evolve the language, the standard library and the 
whole language ecosystem?

If the answer is like, python 3, or perl, no sorry, it takes 
years. Or like C++, we're going to dance carefully on a head of 
pin for decades to avoid obsoleting anything.

Then your rate of evolution will be the same as or slower than 
the competing languages.