Ideology Driven Development

You have a community of meta-programming-crazed iconoclasts, who can and will make their entire toolkits look like Adr. -Monkyyy

One of my greatest discomfitures with the D community, and a large reason why I have kept myself relegated to the quiet seriousness of the Slack channel, is the relatively high number of religious ideologues cosplaying as iconoclasts on the forums.

By way of example, I am reminded of a conversation I had during one of the DConfs (2017 IIRC) with a well-known D contributor who shall remain nameless and Andrei Alexandrescu on the topic of Garbage Collection versus Manual Memory Management. The core of the argument revolved around whether or not you can know the execution delay you are incurring when calling a destructor and why that was superior to the indeterminate delay of a Garbage collection cycle. The nameless debater took the standpoint that only a system where total control of when and where memory was collected was a valid system due to the unknowable costs of Garbage Collection. After a while, Andrei said something to the effect of "You have no way to know how many other destructors are going to be triggered when you call even one destructor." which is, in typical Andrei fashion, distilled truth. The person responded that they absolutely could know and shortly thereafter Andrei and I gave up and moved on to different conversations.

This is a religious ideology and one that is still highly prevalent in the D community, but most of the arguments I see defending it when confronted with the flaws in the argument (ex: from examples in C++), can usually be decomposed into some form of "No True Scotsman" logical fallacy where the offending language suffered from a lack of sufficiently rigorous adherence to the ideologues One True Path. Religion masquerading as iconoclasm.

One of the more fascinating side-effects of the lack of "corporation" in the D community is that it has become something of a haven for the ideological cast-offs of other, more corporate, languages who are looking for a language that is both small enough that they stand a chance of influencing enough people to convert to their Ideology and yet large enough that they can prove the correctness of their Ideology in a statistically relevant sample size. The result of this has been that D occasionally suffers from bitter internecine ideological warfare with a depressing regularity that has set D back years in terms of actual code shipped.

This has resulted in what I've termed "Ideology Driven Development" or IDD. Which I define as: "A development process whereby one or more groups of ideologically possessed users and their maintainer allies attempt to impose their chosen ideology on the rest of the community by forcing their implementation into the language."

There are two critical components of IDD, the first of which is the omnipresence of the ideologues in the community offering up their ideology as The Solution to whatever it is that has prevented the language from gaining market share. All the community has to do is utterly embrace The Solution and the floodgates of success will open. A common corollary of this is the argument that Large Company "XYZ" (usually the one they work for) will be entirely unable to use the language until the solution has been fully fleshed out and there is no way they could consider it beforehand.

A second and equally critical component of this process are the strident and persistent calls by the Faithful for the removal of all other competing ideologies for the sole purpose of enforcing The One True Path to Enlightenment on the rest of the community. The most common reason given for this demand is that once The Solution has been implemented there is simply no reason to retain any alternatives as The One True Path perfectly covers all possible situations and retaining the alternatives will result in unnecessary code that will consume scarce maintenance resources for no additional benefit as everybody finds Enlightenment and moves their code to The Solution.

I have had many conversations over the years with the Allocator Adherents in the D community where they have made more or less the exact argument that was made above. The Allocator Adherents made a concerted effort to have the GC removed from D on the theory that because we now had Allocators, there was no need to keep the GC as everything would be handled with allocators and keeping the GC just encouraged lazy practices and would unnecessarily delay the removal of GC code in the standard library. Thankfully cooler heads prevailed and Walter kept the GC.

The point of all of this is not to promise that making D more corporate will somehow remove all ideology from the community. That would be impossible. However, the priorities of a corporation mean that they must carefully ringfence their contingent of noisy ideologues to prevent them from running roughshod over their bottom lines.

Another drawback of IDD is that when large corporate teams are evaluating a language for a project beyond "can it do the job" (topic for another article), the primary things that they look for are flexibility and consistency in the language. Ideologies are inherently inflexible ("Why would you go any other way but The One True Path?!") and routinely present stumbling blocks to the team as they leave no way to work around the inherent lack of capability that an inflexible system requires.

Large teams need flexible languages that can approach a problem from a multitude of paths while maintaining broadly consistent idioms. There is a reason that Java and C# are so omnipresent in corporate software toolkits. They are ugly beasts that everyone loves to hate but they just can't seem to quit them because they keep getting the job done with a minimum of fuss. Getting the job done with a minimum of fuss needs to be a top priority for D, and to achieve that goal, D needs to jettison the ideologues that keep fussing.