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.
