Some thoughts

Mon Nov 25 16:53:43 UTC 2019

Last week I forgot to take my vitamin D pill and got into a deep 
depression where I decided to end my help on D. I used the whole 
saturday morning to write a bye-bye-message. Meanwhile I realised 
my mistake with the pill and I'm up again (and I won't leave). 
But I think, part of the thoughts I wrote down might still be of 
some interest. Therefore I want to share them with you.

Berni

----------------------------------------------------

 From time to time there are threads in this forum with hundreds 
of responses. Most of the time, after having read the first few 
answers, there is nothing more in the rest of them, but one 
repeating theme (often burrowed beneath the surface): Why is D 
not the programming language no. 1?

 From my perspecive, D is currently like a racing car with rusty 
axis, flat tyre and hardly working breaks. But people discuss 
about adding a rear spoiler, whether a new turbo gear will help 
and maybe sometimes even the color of the car. And then they 
wonder, why the car still is not no. 1.

For getting D up in those lists, which compare programming 
languages, I think getting back to the fundamentals is most 
important. I see two of them:

a) Remove bugs
b) Improve documentation

Let me get a little bit more into those two:

a) Remove bugs

About 20 years ago, I had a strange experience. In a team we 
where programming a server in java and after running that server 
for some time it slowed down and eventually crashed. This 
repeated several times. After long research we found out, that 
the bug was to be found inside java.utils.vector. It was the 
first time, that a bug was not in my own code, but in the 
language itself. At that time we discussed to switch to an other 
language but having no usefull alternative we decided to rewrite 
the vector class instead.

The next time, when I had this experience again, was a few years 
ago with D. And when I wanted to report the bug, I found out that 
it's been reported allready years ago. And this repeated several 
times since. If allready one bug is enought to make people 
discuss moving to an other language, what do dozens of them do?

According to bugzilla [1] there are currently 406 bugreports 
concerning phobos. Probably half of them are allready fixed or 
clearly of wontfix type or invalid. But it's important to remove 
all others. And from what I've seen in the source code, I'm 
pretty sure, there are much more bugs hidden in there, some of 
them as deep as in the underlaying C functions. Get rid of all of 
them.

I think, a good idea would be something similar to the freeze 
cycles Debian uses. Maybe D 2.100 (call it D 2.1) could be used 
here for good. At some time, maybe D 2.095, start a freeze, which 
means, no new features are allowed from that time on (put new 
features in a separate branch for the time being). Increase the 
freeze with every version: Only fix bugs of severity normal or 
higher from D 2.096 on, Only major from D.2097, and so on. Add 
charts like the one on [2], so everyone can see the advance.

How to do that with too few people who contribute? Well 
gamification could be an answer: Allow people giving plus points 
to others who did a good job (or call them kudos if you like) and 
add sort of an alltime highscore table. Add some promotion system 
where one can get up the ladder when some criteria is fullfilled, 
getting a new title like "bug hunter" or "bug expert" or 
whatever. Make these criteria easy to fullfil in the beginning 
and more difficult later on. Add some bonusses (a star next to 
the name in the forum, some additional feature to use, ..., being 
listed on the front page as top bug hunter or what ever). I hope 
you get the picture.

b) Improve documentation

An important step would be to replace the current phobos 
documentation by the ddox version or by dpldocs (from Adam 
Ruppe). That would allready be a great improvement. But there are 
also so many functions, where the description is a oneliner that 
hardly tells, what the function's doing. And the public example 
just giving a special case. From this, beginners may not 
understand how to use the function, especially when it's a 
template. (I had to peek into the source code in the last weeks 
from time to time, to find out, what a certain function really 
does or how it is supposed to be used.)

There are hidden features (like %r in formattedWrite, or %*d in 
formattedRead) or even wrong documentation (again std.format, for 
example, which tells, that the format string for formattedRead 
behaves the same like formattedWrite, which isn't true). Get that 
right.

And every place, where the code does not behave like the 
documentation tells, it's a bug that needs to be fixed. Don't 
preserve the bug. All bug fixes are breaking changes. And they 
are always necessary. For example: "%s" behaves somewhat strange, 
when arrays of strings are printed. They are quoted: ["aaa", 
"bbb"] instead of [aaa, bbb]. To fix that, a minus flag has been 
introduced (which now makes it hard to fix "%50s" as a side 
note). This did not break code, but in the longrun this attitude 
is part of the answer why D isn't no 1.

I would also recommend to reduce the amount of "red" on the whole 
homepage. Red is associated with "danger" and that works 
subconciously. As D is percieved as the "red" language, that 
cannot be removed completely, and that's not necessary, but for 
example a red line between the main menu and the content is 
sufficent. Replace the main menu by something from white over 
gray to black. Or use #3931b0 as a secondary color.

[1] 
https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&component=phobos&list_id=228741&product=D&query_format=advanced&resolution=---&version=D2

[2] https://bugs.debian.org/release-critical/