Quoth Bjarne Stroustrup, creator of C++, in a 2006 interview with MIT Technology Review, answering the implied question of whether simplifying the process of coding to enable more wide-spread participation was a good idea:

The idea of programming as a semiskilled task, practiced by people with a few months’ training, is dangerous. We wouldn’t tolerate plumbers or accountants that poorly educated. We don’t have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.

Obviously, we don’t want our tools–including our programming languages–to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals–not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let’s not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.

He is right that the idea of programming as a semiskilled task is dangerous (insofar as we’re willing to uncritically accept the output, at least), but completely wrong when he willfully glosses over the nature of what makes programming a skilled task in the first place, and indirectly encourages a notion that’s equally dangerous (if not more so): that whatever passes for being qualified in the use of “professional tools” also serves as qualification for working on “the infrastructure of our technical civilization”. It’s certainly true that commercial business is transacted as if this were actually true – but that’s more for lack of anything better.

Telling here is the tentatively implied correlation between effort required to master “tools that will serve skilled professionals” and “education”. You’ll be hard pressed to find a plumber or accountant claiming that knowledge of all the ways to hold a pipe wrench, or how to write array formulas in Excel, was at the very heart of their professional education – but with programming we feel comfortable putting a great deal of it on “tools” (which, as Stroustrup notes, is not restricted to programming languages – as he puts it, “most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity”). There is a dangerous and fatal notion embedded here that doing complicated things requires complicated tools, or at the very least that those complicated things are more effectively done with complicated tools. Stroustrup conveniently conjures up a dichotomy between “tools designed for amateurs” and “tools that will serve skilled professionals” in such a way that any amount of complexity can be hand-waved away with the remark that it’s there because the tool was intended for professionals to do their job (as often expressed in the content-free but ever popular chestnuts of “the right tool for the right job” and “any tool can be misused”).

You might say I’m being unfair to Stroustrup, here – all he did, after all, was caution against the idea that oversimplifying things was the answer, and the popular idea that programming should be simpler so that more people can do it (or even “so simple that anyone can do it”) is admittedly more naive and misguided than the opposite idea that making things more complicated will improve matters. But Stroustrup’s way of framing this shows a misconception endemic to the “professional world”, I feel, and is more worthy of a rebuttal than the easier strawman of not oversimplifying things, or the trivial observation that programming is not, in fact, something that can be done casually by anyone.

If a sign of professionalism is the quality of work, we are forced to admit that professionals who encourage the use of complex tools are not less prone to making mistakes, or even just less prone to making easy mistakes. On the contrary, the very complexity they so admire encourages mistakes that are easy to make, but hard to solve, and even harder to diagnose in the first place. But these mistakes are tolerated and seen as the cost of doing business, because this fits the narrative of programming as a highly skilled profession suited only to the most exalted minds (or, at least, a profession which ought to be like that even if it currently isn’t). Programmers in love with complexity tend to appreciate hard to fix mistakes as problems they care about solving, to the detriment of the actual problems that the programs are intended to solve. The existence of hard to understand, self-inflicted problems becomes a self-fulfilling prophecy about how programming can only be entrusted to those willing to spend a lot of time on complexity and difficulty, “as things are meant to be”, rather than an impetus for investigating how the problems came to be in the first place, and whether they are avoidable, or at least admit effective mitigations. The mere fact that a tool takes a lot of time and effort to master proves neither that the tool itself is worth mastering, nor that the person doing so possesses the skills to make them effective in their profession – nor does an unwillingness or inability to master it necessarily prove the opposite. This is understandably hard to consider, since most professional programmers (including myself) happen to be people who have invested a lot of time and effort into mastering some tools and nobody wants to think that time might possibly have been better spent, but it’s nevertheless worth considering, if only to remain intellectually honest.

Programming is simply too young and too underdeveloped as a discipline for anyone to believe that we can put it on the same level as engineering bridges and trains – even putting it on the same level as plumbing seems rather charitable. Plumbers, at least, have a higher success rate with getting things right on the first try, and certainly far higher success rates if we allow for fixing mistakes when they don’t get it right on the first try. Their profession is also mature enough that they don’t seek to justify dissatisfaction with the work of amateur plumbers by the existence of overly simple tools, or spurious claims that professionals could be “forced” to use them. Programming has a long way to go yet before such reasoning is no longer seen as a valid defense of the frankly squalid state it’s in – which is as depressingly true as it will be in 2020 as it was in 1960.