Stroustrup: complexity in programming isn't a bug, it's a feature
Bjarne Stroustrup, the architect of C++, isn't mincing words about the modern programming landscape. In a recent resurgence of commentary, the language’s creator has forcefully argued that the increasing complexity in software development isn’t something to be avoided, but rather an inherent requirement for tackling today’s challenges—a position likely to ruffle feathers in the ever-expanding world of low-code and no-code solutions.
The two-tiered world of programming languages
Stroustrup’s core assertion centers on a fundamental division within the engineering software realm: languages that allow for granular control and those that don’t. He deems the latter, while perhaps appealing for their ease of use, ultimately inadequate for tackling serious, large-scale engineering projects. The proliferation of ecosystems like Python, JavaScript, and Ruby, while undeniably popular, speaks to a broader trend of abstraction—a trend Stroustrup views with a degree of skepticism. “There are only two kinds of programming languages,” he famously quipped, “those people complain about, and those nobody uses.”
The Danish computer scientist isn’t simply observing this shift; he’s actively shaping it. His insistence that learning to code effectively cannot be achieved solely through online tutorials—a commentary on the superficiality of much contemporary online education—underscores his belief in the necessity of rigorous, foundational knowledge. And his admonishment against being “too clever” in pursuit of a career in software engineering reveals a disdain for superficiality and a preference for pragmatic problem-solving.
C++: complexity as a virtue
While C++ isn’t the largest language by user count—trailing behind C#, Java, and even Python—Stroustrup maintains its reputation for complexity is, paradoxically, a strength. The initial goal of C++ was not simplicity, but rather versatility and performance. He designed it to be a language that could adapt and address evolving technical needs over decades, a task it continues to excel at. He points out that what is perceived as 'easy' in modern languages often comes at the cost of efficiency and flexibility, relying on extensive external libraries and heavy environments—a complexity just hidden beneath a veneer of simplicity.
The core issue, Stroustrup suggests, is that these 'easy' languages tend to shy away from the very control needed for robust, reliable systems. The languages that truly move the needle in industries like finance and aerospace—C++, Java, Python—are the ones that consistently draw complaints, precisely because they demand a deeper understanding and are used to build systems that demand a high degree of stability. The alternatives, meanwhile, reside primarily in academia or experimentation—a purgatory for languages lacking the raw power needed for real-world implementation.
Stroustrup’s philosophy isn’t about dismissing the value of accessibility or new tools. Instead, he’s advocating for a realistic assessment of tradeoffs.