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.

On Thursday, 9 July 2020 at 12:55:45 UTC, aberba wrote:
> Has there been any consideration on tagging Phobos function as either GC or no-GC depending on how they behave for general awareness when reading the docs?
>
> I'm thinking it could be useful to know what you get.

I mentored work on adding @nogc information to every function in Phobos. It's not done yet, but it's nearly there.

On Tuesday, 14 July 2020 at 12:03:30 UTC, Atila Neves wrote:
> I mentored work on adding @nogc information to every function in Phobos. It's not done yet, but it's nearly there.

Did you do it as @nogc unittests? Doing it with the direct annotation would be overly limiting due to lambdas etc.

On Tuesday, 14 July 2020 at 12:07:47 UTC, Adam D. Ruppe wrote:
> On Tuesday, 14 July 2020 at 12:03:30 UTC, Atila Neves wrote:
>> I mentored work on adding @nogc information to every function in Phobos. It's not done yet, but it's nearly there.
>
> Did you do it as @nogc unittests?

Yes.

> Doing it with the direct annotation would be overly limiting due to lambdas etc.

I'm open to ideas on how to do it otherwise.

On Tuesday, 14 July 2020 at 13:35:12 UTC, Atila Neves wrote:
> I'm open to ideas on how to do it otherwise.

@nogc unittests are good, and the docs should probably show that too - if the declaration has a @nogc unittest attached, the doc generator could and show it is at least conditionally compatible.

A @nogc on the function itself would reject non-@nogc lambdas and such and that's unnecessarily limiting, but inference + unittest + docs showing unittest annotations = win.

I'll prolly change adrdox later this week to do that, will be interesting to see how much of phobos will show conditional nogc/safe/pure as it is.