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/

On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:

> a) Remove bugs
> b) Improve documentation

I'd add a third:
c) improve the installer so it handles properly updating already-installed versions.

On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:
> 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.

I think I understand you, but that others might miss the point,
so to be clear, it's not that colors are never worth
discussing, or that a real spoiler wouldn't help. It is not
that these other conversations shouldn't happen but that the
*focus* on them is a violation of something like Maslow's
hierarchy of needs, but for programming languages.

Suppose dlang.org were down, the entire website, for months
or more. People wouldn't say of D, "nah you shouldn't pick
that up, the language has too many features." or "it has too
many attributes that you have to stick on functions". They
would say "it's obviously dead; nobody cares even to maintain
the website!"

But a website is a relatively mundane and boring thing. It's
not distinctive of D that it has a website--every language has
one. If a big D release came out and the changelog were all
about the website, people would not be impressed in the
slightest. I know a guy who knows a guy who could maintain a
website for you for a pittance.

It's merely a website, and yet, it is vitally important, to the
degree that almost nothing else about D would make a difference
if this one part of D were absent.

Trivial bugs and documentation are a level up the needs
hierarchy from having a website, but they're still several
levels down below most of what's discussed here.

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

Rather than obscure bugs that crop up in obscure cases only,
what I dislike most are "flat tire" bugs, to continue your car
metaphor. A flat tire is obvious and it's relatively easy to
fix, so if you see one, it just means that nobody cares, or
nobody has even tried to drive the thing.

I've had the "has anyone ever even tried to use this thing?"
thought a few times with third-party packages. Not with Phobos
as yet. Actually all the package maintainers I've reported bugs
to have been very responsive and have gotten them fixed, so I
wouldn't write a long goodbye letter over something like this,
and I don't even want to give examples because it'd be unfair
to them even though some of the bugs would make for great
examples.

The D website though has some "nobody cares" tier bugs, like
all the 404s in the library documentation:

https://issues.dlang.org/show_bug.cgi?id=19725

Or that run.dlang.io's 'shorten' button has been broken for 17
days:

https://github.com/dlang-tour/core/issues/739

On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:
> ...
> 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.
> ...

Yes that's a problem and not just that, the hurry to do something turns into a bad design, like the topic about never grow arrays (After 117 replies) and the borrow/owner, which I'm with Timon Gehr.

By the way stop these attributes-fest, people don't realize how complex the language is turning in.

> ...
> I would also recommend to reduce the amount of "red" on the whole homepage...

Well unfortunately it will be hard to help, I tried here: https://forum.dlang.org/thread/nedlktszcvbkwokltzax@forum.dlang.org

To improve this forum for mobile and I didn't get any answer to my question:

"I'd like to know if it is possible to have this to be accessed direct in your server (Maybe in a new sub-domain), since my hosting is slow."

Then people will ask why there are so few or lack of contributors around here.

Matheus.

PS: Most friends of mine complained exactly about this Forum, and even asked how I use this forum on mobile and now some are using my version, but they're still complaining about the speed (My server is slow).

On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:
> 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).

I've suggested creating a stable branch many times, but the counter argument has been that it is too much extra work. Which could be true, I don't know.

Anyway, I disagree with the complaint about working on language semantics. Dynamic arrays are basically intractable because they "randomly" split an array into two objects, how can you formally reason about code that does that? Missing memory management options has been a recurring theme for at least 15 years, and is also a selling point that competing languages make a big deal about (and also benefit from).

But compiler work and library work should be separate anyway, so I don't think that should be mixed up with Phobos. If things are missing in phobos and you don't know how to fix it, then maybe adding a unit test would be the right thing, but Phobos is really not my cup of tea so I don't know.

> I would also recommend to reduce the amount of "red" on the whole homepage.

Red is a good branding colour. Noticable and memorable. Yellow is a bit more noticable, but red is still very effective.

Very successful in marketing as well: Coca Cola, etc.

On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:

> 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

At this point, I don't think the problem is identifying work that needs to be done, but rather identifying ways to get it done.

You should, of course, file bug reports as appropriate, but that's not enough. Sticking with cars, what we have here is people seeing someone that's broke in a car with no gas by the side of the road. Telling him that he needs to put gas in to get going isn't going to accomplish much - he already knows that's why the car died, and he knows how to fix it. The only thing that will help is giving him money to buy gas, giving him a container of gas, or giving him a way to earn money needed to buy gas.

There are many comparisons with the experience provided by Go and Rust. Those languages had tremendous financial resources behind them. The greatest assistance you can give to D at this point is to come up with ideas to obtain more resources or otherwise come up with a plan to get the problems fixed. This has been discussed to death, but that doesn't accomplish anything. There is nobody that's going to read about the problems and start fixing them.

On Monday, 25 November 2019 at 18:49:15 UTC, matheus wrote:
> On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:
>> ...
>> 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.
>> ...
>
> Yes that's a problem and not just that, the hurry to do something turns into a bad design, like the topic about never grow arrays (After 117 replies) and the borrow/owner, which I'm with Timon Gehr.
>
> By the way stop these attributes-fest, people don't realize how complex the language is turning in.
>
>> ...
>> I would also recommend to reduce the amount of "red" on the whole homepage...
>
> Well unfortunately it will be hard to help, I tried here: https://forum.dlang.org/thread/nedlktszcvbkwokltzax@forum.dlang.org
>
> To improve this forum for mobile and I didn't get any answer to my question:
>
> "I'd like to know if it is possible to have this to be accessed direct in your server (Maybe in a new sub-domain), since my hosting is slow."
>
> Then people will ask why there are so few or lack of contributors around here.
>
> Matheus.
>
> PS: Most friends of mine complained exactly about this Forum, and even asked how I use this forum on mobile and now some are using my version, but they're still complaining about the speed (My server is slow).

Did you contact Vladimir? https://github.com/CyberShadow/DFeed The forum is probably not the best way to offer to help on an individual project.

On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:
> a) Remove bugs


I feel this gets brought up a bit, how pull requests sit idle for years along with bug reports. People working on D work on whatever they want, fixing bugs and handling pull requests are just chores that no one wants to do.

On Tuesday, 26 November 2019 at 05:05:09 UTC, Jab wrote:
> On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:
>> a) Remove bugs
>
>
> I feel this gets brought up a bit, how pull requests sit idle for years along with bug reports. People working on D work on whatever they want, fixing bugs and handling pull requests are just chores that no one wants to do.

Fixing D bugs is a one way process so I don't even recommend doing this seriously, e.g on a daily basis, several hours per days. This will inexorably leads to frustration. Fix bugs if at work your company needs some particular fixes, fix bugs if you need some fixes for your own side-projects, fix bugs if this is required for your studies. But don't fix bugs just for the love of the D programming language.

On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:
> 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.

Yes this is called gamification, it's very common to give a RPG aspect like what you describe. Unfortunately the gamification you describe is childish IMO. "a star next to the name in the forum", common I don't care that people think I'm a level 100. I prefer being an anonymous but efficient fixer that regularly gets 100 bucks for the work.