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