www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Some thoughts

reply berni44 <dlang d-ecke.de> writes:
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 


[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/
Nov 25 2019
next sibling parent Ron Tarrant <rontarrant gmail.com> writes:
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.
Nov 25 2019
prev sibling next sibling parent reply mipri <mipri minimaltype.com> writes:
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
Nov 25 2019
parent berni44 <dlang d-ecke.de> writes:
On Monday, 25 November 2019 at 18:39:42 UTC, mipri wrote:
 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.
Yes, exactly. Thanks for clearifying. :-)
Nov 26 2019
prev sibling next sibling parent reply matheus <matheus gmail.com> writes:
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).
Nov 25 2019
parent bachmeier <no spam.net> writes:
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.
Nov 25 2019
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Nov 25 2019
parent reply berni44 <dlang d-ecke.de> writes:
On Monday, 25 November 2019 at 19:59:21 UTC, Ola Fosheim Grøstad 
wrote:
 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.
Well, Coca Cola tries to address people who like risks. There red is the right colour. But think of a company who calmly decides between several languages. They don't want danger, they want something serious.
Nov 26 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 November 2019 at 13:15:02 UTC, berni44 wrote:
 On Monday, 25 November 2019 at 19:59:21 UTC, Ola Fosheim 
 Grøstad wrote:
 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.
Well, Coca Cola tries to address people who like risks. There red is the right colour. But think of a company who calmly decides between several languages. They don't want danger, they want something serious.
I guess we just have to agree to diagree, red is a very common logo/profiling colour. But you are perhaps thinking of companies like IBM that use blue and black, which is very corporate and perhaps give an impression of something serious, but also very very boring. The original Microsoft logo was also pretty bad, but their colourful Windows logo was actually quite good. Same with Google, simple uplifting design (with red). Colourful logos are difficult to design, but I think they work better and are more memorable. Anyway, the original name for D was Mars, so red makes sense for that reason alone. I personally prefer logos that retain the history. Also I don't think a corporate profile is a good idea, because then expectations would be... a ready-made with no changes and little user activity. But this is just bikeshedding anyway :) It probably doesn't matter much unless you target mainstream consumers.
Nov 26 2019
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 27/11/2019 3:38 AM, Ola Fosheim Grøstad wrote:
 On Tuesday, 26 November 2019 at 13:15:02 UTC, berni44 wrote:
 On Monday, 25 November 2019 at 19:59:21 UTC, Ola Fosheim Grøstad wrote:
 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.
Well, Coca Cola tries to address people who like risks. There red is the right colour. But think of a company who calmly decides between several languages. They don't want danger, they want something serious.
I guess we just have to agree to diagree, red is a very common logo/profiling colour. But you are perhaps thinking of companies like IBM that use blue and black, which is very corporate and perhaps give an impression of something serious, but also very very boring. The original Microsoft logo was also pretty bad, but their colourful Windows logo was actually quite good. Same with Google, simple uplifting design (with red). Colourful logos are difficult to design, but I think they work better and are more memorable. Anyway, the original name for D was Mars, so red makes sense for that reason alone. I personally prefer logos that retain the history. Also I don't think a corporate profile is a good idea, because then expectations would be... a ready-made with no changes and little user activity. But this is just bikeshedding anyway :) It probably doesn't matter much unless you target mainstream consumers.
Color has different meanings in different cultures. This entire discussion is moot unless you specify which ;)
Nov 26 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 November 2019 at 14:50:00 UTC, rikki cattermole 
wrote:
 Color has different meanings in different cultures. This entire 
 discussion is moot unless you specify which ;)
It is true that culture can modify biological perceptional responses, but colours, light intensity and patterns evoke emotional responses at a rather low level. On top of that you have the semiotics (the cultural customs or idioms if you will). People like sunsets for a reason, it's time to stop up and change your activity, then return to your safe village as you don't get to see the predators after dark. It makes sense to feel at peace with blue, it is evening, save energy and find sleep (Microsoft used blue for software crashes...). It makes sense to enjoy green surroundings, you are more likely to find food there.
Nov 26 2019
prev sibling next sibling parent reply aliak <something something.com> writes:
On Tuesday, 26 November 2019 at 14:38:33 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 November 2019 at 13:15:02 UTC, berni44 wrote:
 On Monday, 25 November 2019 at 19:59:21 UTC, Ola Fosheim 
 Grøstad wrote:
 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.
Well, Coca Cola tries to address people who like risks. There red is the right colour. But think of a company who calmly decides between several languages. They don't want danger, they want something serious.
I guess we just have to agree to diagree, red is a very common
What is it you disagree with? Colours have been shown to invoke a general tendency towards specific emotional states. And red happens to tend towards danger (among other things). Evolutionarily, red is something you stay away from in nature. (whether it matters significantly or not for a programming language I don't know, but it does it you want to get more tips, be rated higher visually, or perform worse/better on cogniitive tests) Many research papers listed in this article if interested: https://www.bbc.com/future/article/20140827-how-the-colour-red-warps-the-mind
Nov 26 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 November 2019 at 15:59:27 UTC, aliak wrote:
 a general tendency towards specific emotional states. And red 
 happens to tend towards danger (among other things). 
 Evolutionarily, red is something you stay away from in nature.
Nah, ripe fruits tend to be red in order to be eaten, so that plants can spread their seeds. Cheers!
Nov 26 2019
prev sibling parent reply berni44 <dlang d-ecke.de> writes:
On Tuesday, 26 November 2019 at 14:38:33 UTC, Ola Fosheim Grøstad 
wrote:
 Anyway, the original name for D was Mars, so red makes sense 
 for that reason alone. I personally prefer logos that retain 
 the history.
Just for clearification: I do not want to ban red completely from the website. For me it feels just to be a little bit too much of red. Meanwhile I played arround a little bit with the style files and allready be quite an improvement in the sense of what I mean.
Nov 27 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 27 November 2019 at 13:39:57 UTC, berni44 wrote:
 Just for clearification: I do not want to ban red completely 
 from the website. For me it feels just to be a little bit too 
 much of red.
Yes, sure. Red draws attention and it can be a bit tiresome with many red links. I thought it was a bit fun that you focused on big things (bugs) and then ended with a focus on something small (colours) in the same post. :-) Like: "hey, if we can't get these bugs fixed can we at least get a different colour on the website?" (I know you didn't say that, but it could be construed that way :-)
Nov 27 2019
parent reply berni44 <dlang d-ecke.de> writes:
On Wednesday, 27 November 2019 at 13:48:10 UTC, Ola Fosheim 
Grøstad wrote:
 I thought it was a bit fun that you focused on big things 
 (bugs) and then ended with a focus on something small (colours) 
 in the same post. :-)  Like: "hey, if we can't get these bugs 
 fixed can we at least get a different colour on the website?"
I was a bit amused myself when I read the whole thing three days after I wrote it. In the beginning I complain about people talking about the colour of the car and later it's me who talks about colour... ;-)
Nov 27 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 27 November 2019 at 15:41:03 UTC, berni44 wrote:
 I was a bit amused myself when I read the whole thing three 
 days after I wrote it. In the beginning I complain about people 
 talking about the colour of the car and later it's me who talks 
 about colour... ;-)
I think we all experience that from time to time. I've certainly expressed surprise many times when I see that car dealers offers 10 different shades of gray, black, white and 2 shades of dark blue and no other colours... I can't belive that everybody want so boring looking cars! Anyway, all programmers can relate to the frustration the emerge after looking for a bug in ones own code only to discover that the bug is somewhere else...
Nov 27 2019
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
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.
Nov 25 2019
next sibling parent berni44 <dlang d-ecke.de> writes:
On Monday, 25 November 2019 at 20:03:27 UTC, bachmeier wrote:
 There are many comparisons with the experience provided by Go 
 and Rust. Those languages had tremendous financial resources 
 behind them.
From psychology I know, that it isn't a good idea to compare oneself to others. It's better to compare to one self. I don't know if this is true for programming languages too, but I guess it is. At least I would not compare D to these two languages, because they have large companies behind them, while D is community driven. And that's a huge difference.
Nov 26 2019
prev sibling parent reply Laeeth isharc <laeeth laeeth.com> writes:
On Monday, 25 November 2019 at 20:03:27 UTC, bachmeier wrote:
 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.
I think often it's less about financial resources than a coordination problem. Lots of people probably wouldn't mind fixing bugs or improving documentation to earn some extra money and maybe some people or companies would be willing to support the ecosystem through funding but unless somebody takes it upon themselves to organise a way to make it happen then it won't. It might be as simple as setting up a page where people can indicate their willingness to fix bugs and send email address along with the sort of daily rate they would need. Then it's much easier to ask for support if someone will oversee that process. You could allow people to channel money to bugs they care about provided they channel some to community bug fixing needs. The difference between a bug bounty I guess is they might be a bit too passive for our current stage of development. The barrier to getting Symmetry Autumn of Code started was much more about organisational questions than the dollar cost itself.
Nov 26 2019
parent reply bachmeier <no spam.net> writes:
On Tuesday, 26 November 2019 at 22:53:49 UTC, Laeeth isharc wrote:

 I think often it's less about financial resources than a 
 coordination problem.
That's a good point. And as has been said before, once you have some money on the line, it forces you to get things in order. One problem of a volunteer system is that there's no incentive to make it work, even when money is not itself the issue.
 Lots of people probably wouldn't mind fixing bugs or improving 
 documentation to earn some extra money and maybe some people or 
 companies would be willing to support the ecosystem through 
 funding but unless somebody takes it upon themselves to 
 organise a way to make it happen then it won't.

 It might be as simple as setting up a page where people can 
 indicate their willingness to fix bugs and send email address 
 along with the sort of daily rate they would need.  Then it's 
 much easier to ask for support if someone will oversee that 
 process.  You could allow people to channel money to bugs they 
 care about provided they channel some to community bug fixing 
 needs.
I like that idea. College students would be prime candidates for this but they might avoid it because they wouldn't know what their rate should be. It might have to be stated as $X/day or a negotiated rate if that isn't enough. I think there's room for reducing the cost of getting involved with development/writing documentation. I eventually gave up because there's so much overhead associated with getting everything set up and dealing with Git and all that. I wouldn't even accept money if it were offered, and others with high salaries are probably in the same boat, but I don't want to spend my limited time dealing with overhead rather than doing work that has value. Sometimes it's unclear who's even in charge. Dub, for instance. I wish you could find the email address of the decision maker for a particular issue on the website.
 The barrier to getting Symmetry Autumn of Code started was much 
 more about organisational questions than the dollar cost itself.
We're lucky to have that barrier out of the way. It's been a big boost for the language, and will become bigger as time goes on - every improvement has an effect for many years.
Nov 27 2019
parent reply Laeeth Isharc <laeeth laeeth.com> writes:
On Wednesday, 27 November 2019 at 23:19:07 UTC, bachmeier wrote:
 On Tuesday, 26 November 2019 at 22:53:49 UTC, Laeeth isharc 
 wrote:

 I think often it's less about financial resources than a 
 coordination problem.
That's a good point. And as has been said before, once you have some money on the line, it forces you to get things in order. One problem of a volunteer system is that there's no incentive to make it work, even when money is not itself the issue.
Well there's clearly an incentive to take some steps towards making things work as a volunteer but it's an emotional one which means people will only take steps in a sequence that's in some way personally satisfying. The problem right now is I think just a coordination problem because the people using D in business likely aren't mature firms, or at least mature groups, which means they are short of time and attention.
 Lots of people probably wouldn't mind fixing bugs or improving 
 documentation to earn some extra money and maybe some people 
 or companies would be willing to support the ecosystem through 
 funding but unless somebody takes it upon themselves to 
 organise a way to make it happen then it won't.

 It might be as simple as setting up a page where people can 
 indicate their willingness to fix bugs and send email address 
 along with the sort of daily rate they would need.  Then it's 
 much easier to ask for support if someone will oversee that 
 process.  You could allow people to channel money to bugs they 
 care about provided they channel some to community bug fixing 
 needs.
I like that idea. College students would be prime candidates for this but they might avoid it because they wouldn't know what their rate should be. It might have to be stated as $X/day or a negotiated rate if that isn't enough.
Well you could make the rate optional and in such cases it could be negotiated. Costs of living and market wages vary a great deal between different places, as does productivity of programmers.
 Sometimes it's unclear who's even in charge. Dub, for instance. 
 I wish you could find the email address of the decision maker 
 for a particular issue on the website.
Someone should send pull requests to add to the website after getting consent from relevant people. I will try to help if we can but very busy right now. Maybe next year a community development and documentation project could be part of SAoC? SAoD.. of documentation. I don't know if there would be any interest. But we would certainly consider hiring people who can write good documentation (for internal purposes).
Nov 27 2019
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 27 November 2019 at 23:49:55 UTC, Laeeth Isharc 
wrote:
 Maybe next year a community development and documentation 
 project could be part of SAoC?

 SAoD..  of documentation.

 I don't know if there would be any interest.  But we would 
 certainly consider hiring people who can write good 
 documentation (for internal purposes).
I like that idea. Can't say I've ever heard of such an initiative before, but it could potentially be a selling point to have outstanding documentation.
Nov 29 2019
parent Les De Ridder <les lesderid.net> writes:
On Saturday, 30 November 2019 at 03:09:20 UTC, bachmeier wrote:
 On Wednesday, 27 November 2019 at 23:49:55 UTC, Laeeth Isharc 
 wrote:
 Maybe next year a community development and documentation 
 project could be part of SAoC?

 SAoD..  of documentation.

 I don't know if there would be any interest.  But we would 
 certainly consider hiring people who can write good 
 documentation (for internal purposes).
I like that idea. Can't say I've ever heard of such an initiative before, but it could potentially be a selling point to have outstanding documentation.
Google is doing a similar thing (in addition to GSoC): https://developers.google.com/season-of-docs I believe it was mentioned here on the NG before. If we can find enough people to mentor etc., it might be a good idea for next year.
Dec 03 2019
prev sibling parent Murilo <murilomiranda92 hotmail.com> writes:
On Wednesday, 27 November 2019 at 23:49:55 UTC, Laeeth Isharc 
wrote:
 On Wednesday, 27 November 2019 at 23:19:07 UTC, bachmeier wrote:
 On Tuesday, 26 November 2019 at 22:53:49 UTC, Laeeth isharc 
 wrote:

 I think often it's less about financial resources than a 
 coordination problem.
Hi Mr. Isharc, the reason why I'm comment on this post of yours is because I didn't find any other way to contact you. I noticed that you have forked my repo on git with the OCR program and the image files. I wanted you to know that I have recently finished making all images, it is now perfect. All images for all uppercase and lowercase letters of the English alphabet. So you may wanna update your fork. Cheers.
Jan 17
prev sibling next sibling parent reply Jab <jab_293 gmall.com> writes:
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.
Nov 25 2019
next sibling parent reply S.G <S.G sdfsdfsfsdfsdf.gs> writes:
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.
Nov 26 2019
next sibling parent reply berni44 <dlang d-ecke.de> writes:
On Tuesday, 26 November 2019 at 09:11:33 UTC, S.G wrote:
 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.
I strongly disagree here. Fixing bugs is a little bit like doing the cleaning up. Of course you can start to clean your cooking pot just before you need it. But chances are, that at that time you've got not the time to do so. And additionally, fixing bugs also helps others. Of course, if fixing bugs leads to frustration, then you shouldn't do it if you do not need to. But not all people are the same. For me it's often like solving sort of a mathematical problem and I feel happy, when I managed to do so. (And getting money for it might even be contraproductive in my case.) And there is one more benefit for removing bugs early: Bugs in software tend to produce more bugs, because changes often have to work around old bugs and when the bug is fixed later, these places might become new bugs. On Tuesday, 26 November 2019 at 09:24:19 UTC, S.G wrote:
 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.
Again: People are different. If you may make people do the work for stars next to the name, you do not need to found the 100 bucks.
Nov 26 2019
parent S.G <S.G sdfsdfsfsdfsdf.gs> writes:
On Tuesday, 26 November 2019 at 13:28:17 UTC, berni44 wrote:
 Again: People are different. If you may make people do the work 
 for stars next to the name, you do not need to found the 100 
 bucks.
What kind of people are to even think that this would work... You want 16 y.o neebies to do the work and give them candies ? Common common man. I just want to say COMMON.
Nov 26 2019
prev sibling next sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Tuesday, 26 November 2019 at 09:11:33 UTC, S.G wrote:
 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.
I have fixed 150+ bugs and closed another 200+ (invalid or fixed) in the compiler and I can say that this is a great way to understand the innards of the software. Since documentation is scarce, fixing bugs is a fun way to understand (and document) what happens in either dmd, druntime or phobos and I encourage anyone who is interested in having an in depth understanding of the D compiler to pursue this endeavor. Although the list of unresolved bugs is large I'm sure that aproximately 40% of them have been fixed in the meantime or are invalid, 40% are easy to fix, thus leaving only 20% that are more difficult to fix. This estimations are based on the distribution of bugs that I have encountered so far.
Nov 26 2019
parent S.G <S.G sdfsdfsfsdfsdf.gs> writes:
On Tuesday, 26 November 2019 at 13:41:52 UTC, RazvanN wrote:
 On Tuesday, 26 November 2019 at 09:11:33 UTC, S.G wrote:
 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.
I have fixed 150+ bugs and closed another 200+ (invalid or fixed) in the compiler and I can say that this is a great way to understand the innards of the software.
This is actually interesting to compare ourselve because I've fixed pretty much the same amount. You match to the definition of what I call the student case. I match more to what I had described as the guy who should not have done anything.
Nov 26 2019
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/26/19 4:11 AM, S.G wrote:
 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.
Some weird people like fixing bugs for the fun of it. Don't tell me what not to do ;) -Steve
Nov 26 2019
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 26.11.19 10:11, S.G wrote:
 But don't fix bugs just for the love of the D programming language.
I have fixed some bugs in `static foreach` interactions with features that I don't use. If there is a `static foreach`-related problem and you bring it to my attention, it is pretty likely that I will look into it.
Nov 26 2019
prev sibling parent reply Suleyman <sahmi.soulaimane gmail.com> writes:
On Tuesday, 26 November 2019 at 09:11:33 UTC, S.G wrote:
 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.
If you don't regularly fix bugs they will mess up your schedule once you start working on a project and find yourself spending most of your time inside the debugger instead of coding your logic.
Nov 29 2019
parent S.G <sorryidontrememberthemailu nowhere.fi> writes:
On Saturday, 30 November 2019 at 00:21:13 UTC, Suleyman wrote:
 On Tuesday, 26 November 2019 at 09:11:33 UTC, S.G wrote:
 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.
If you don't regularly fix bugs they will mess up your schedule once you start working on a project and find yourself spending most of your time inside the debugger instead of coding your logic.
It's not about regularly fixing or not. Fixing bugs is not about pissing 5000 lines of code every day, it's more precision work. You can work during two hours and finally only one line of code will be written. It's maybe the reason why it's not well recognized, but truth is, if it was so simple there would be 10 bugfixs merged every day. Is this the case ? No, clearly not.
Nov 29 2019
prev sibling parent Suleyman <sahmi.soulaimane gmail.com> writes:
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.
Nicholas Wilson was doing great as a PR manager. There is both organizational and financial limits to the problem.
Nov 29 2019
prev sibling next sibling parent S.G <S.G sdfsdfsfsdfsdf.gs> writes:
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.
Nov 26 2019
prev sibling parent Suleyman <sahmi.soulaimane gmail.com> writes:
On Monday, 25 November 2019 at 16:53:43 UTC, berni44 wrote:
 [snip]

 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 

Really, we could reduce the amount of red in the forum. I think red here signifies Mars but we earthlings are not used to see a lot of red everyday.
Nov 29 2019