GC/nogc status in docs

[Mike Parker]

On Monday, 13 July 2020 at 19:43:07 UTC, aberba wrote:

>
>> I started the GC series on the blog partly to counter 
>> misinformation here and on reddit. Didn't matter (I find an 
>> opportunity to link to it most D threads on reddit). Whether 
>> it's GC or any of the other complaints we hear about, it won't 
>> matter.
>
> Actually it did and still making more impact than you think. I 
> see that post referenced in many places. Some do actually read 
> to understand. Its actually a gem I use for the D preaching 
> work.

Oh, I'm sure some folks may find it useful as an introductory 
reference. My point is that it isn't going to kill the noise that 
pops up about D's GC. Trying to change a narrative that's been 
going almost 20 years is a losing battle.

>
> You're right, there are naysayers but also people with genuine 
> interest in making a decision.
>
> 1. 
> https://blog.elementary.io/busting-major-myths-around-elementary-os/

Yes, and those people who want to make a decision are the ones 
you target. What I'm trying to say is, bust the myths without 
telling people you're busting the myths.

Notice how in that blog page the author is essentially listing 
arguments and counterarguments. When you do that, you're 
naturally putting the reader in a position to view you as being 
on the defensive. You're also triggering the "which side should I 
believe" mode. As someone who doesn't know anything about 
Elementary OS, I'm going to have to follow the links the author 
provides and dig a bit into the other side, the myths he's 
supposedly busting, to decide if I trust him or not. That means I 
have to be motivated to spend the time to do that.

I can't say that sort of page will never change a mind, or spark 
an interest, but I'm pretty confident it isn't the most efficient 
way to do so. What if, instead, the author took each of those 
myths and wrote an individual article targeting each of them, 
incorporating the counterarguments without once presenting them 
as counterarguments for a myth?

Take the first myth about GNOME Shell. As it is on that page, I 
can actually accept that the author is truthful in saying they 
use their homegrown Pantheon instead. By why should that matter 
to me? He mentions a couple of points where Pantheon is a better 
choice (GNOME is monolithic and written in JavaScript vs. 
Patheon's component-based architecture written in Vala), but 
that's directly triggering my "who should I believe" mode. He's 
using one paragraph for each, giving me nothing to work with in 
making a decision.

What if, instead, he wrote an article about Pantheon's 
component-based architecture? The entirety of the article would 
be focused on that topic. He could show diagrams, examples of it 
in use, sample code. I could get a broader picture of the 
components, and from the example code see that it's using Vala 
without his ever bringing a comparison to JavaScript into the 
equation. He could mention JavaScript if he wanted to, and 
monolithic architectures, and he could do it in a way that 
doesn't trigger any sort of comparison mode in my mind, e.g., "We 
chose Vala instead of other candidates like JavaScript because of 
these reasons." or "Older desktop environments, like GNOME, are 
monolithic. We opted for a component based approach for these 
reasons." And the reasons could be listed just as they are, 
without ever comparing them to the features of or reasons not to 
use JavaScript or Gnome. It puts the reader in a completely 
different mindset.

Promotional text should try to avoid leaving the reader with any 
sort of conflict or negativity in their mind by the end of the 
article. It's okay to take a jab at a competing 
language/product/etc somewhere in the middle (the more subtly so 
the better), but it should always open and end on a positive 
note. A page full of busted myths, particularly one with that 
term in the title, is the very opposite. It's confrontational and 
conflicting from beginning to end.

That's why I recommend anyone wanting to promote D do so by 
writing articles about D that show off particular features, or 
libraries, or algorithms, etc. Show D how and where it is used 
and let the text stand on its own merit. I firmly believe we 
reach more people that way.

Look at the my first post in the GC series. I saw an opportunity 
for a catchy title, so I used it. Catchy titles draw more eyes. 
In the first paragraph I mention how the GC has benefits and 
drawbacks. That's true. I then proceed with some advice on how to 
mitigate the drawbacks. Although the article (and the entire 
series) is presented as a D tutorial, my primary motivation was 
to counter misinformation about the GC. People who aren't yet 
using D yet but might be interested in it, they are my target. I 
wanted them to see that working with the GC in D isn't as bad as 
they might have read. The tutorial format was just an easy way to 
present it, with the added benefit that existing D users might 
find it useful.

I think I can boil it all down to this: evangelize without being 
an evangelist.