Programming Languages Are Authoring Tools for Platforms

Introduction...

When planning a new project and deciding which language to use, people often fall into one of two illusions. They either venerate an "academic lineage" such as functional paradigms or the purity of a type system, or they blindly follow "community trends" swept up by GitHub star counts and the buzz in programmer communities. It is a naive assumption that elegant mathematical proofs or trendy syntax will guarantee a product's survival, though in some ways it is understandable. People want the language they staked their career on learning, and its Worldview / Paradigm, to stand the test of time. Honestly, if C# and TypeScript started losing market share tomorrow, I would be plastering every programming forum with arguments for how superior they are.

Regardless, every program's execution ultimately reduces to instructions and state transitions carried out by a machine. When an interpreter reads source code or bytecode step by step, the original program may never be fully translated into machine code. Even so, if we're only concerned with computability, high-level languages are not strictly necessary. The same computations can be expressed in machine code or assembly alone.

Yet actual history unfolded as we know it. People did not write every program in assembly and C alone. A vast number of high-level languages and runtime environments emerged to address different problems and Platforms.

Each time new hardware appeared, operating systems arose, and browsers and smartphones became widespread, the languages and tools for working with those surfaces followed close behind. That is because the more expensive problem shifted from whether a machine can compute something to how many programs people can build on top of that machine.

IBM's ceding of PC Platform leadership to Microsoft can be read through the same lens. IBM created the hardware standard known as the PC, but the application software and developer ecosystem built on top of it became bound to MS-DOS and the Windows API rather than to IBM's machines. As compatible PCs proliferated, hardware became a commodity, and Microsoft, which controlled the interface through which developers wrote their programs, became the Platform's true owner.

An empty Platform is not yet a product. Only when games, productivity applications, and content accumulate on top of it does it become a world where users stay. A language is the tool that authors that world.

And the moment a programmer takes hold of that tool and imposes logic and rules on the empty space, they become something more than a mere machine operator.

Joseph Weizenbaum, the creator of ELIZA, wrote in Computer Power and Human Reason:

"The computer programmer, however, is a creator of universes for which he alone is the lawgiver."

Yet the fact that programmers can build worlds with a language does not, by itself, explain that language's success. A highly expressive language can remain confined to a small research community, while a widely criticized language can encounter a massive Runtime environment and become an industry standard.

In my view, reading the history of languages requires distinguishing at least three questions:

1. Why was it created?
2. Why did developers adopt it?
3. Why did it remain dominant for so long?

Platforms and Complementary Goods

The value of an operating system, a browser, a game console, or a smartphone grows alongside the programs that run on it. What users encounter every day is not the system's kernel or its design elegance, but the end products: productivity applications and games. A game console with no games to play is nothing more than an expensive piece of living room furniture.

In economics, goods that maximize their value when consumed together are called Complementary Goods. Platforms and applications have exactly this kind of complementary relationship.

If infrastructure is a vast empty stage, then applications and content are the actors and scripts that fill it. A platform's real commercial value and market dominance are determined not by its own computational power, but wholly and dependently by the total volume of Complementary Goods continuously produced within its ecosystem.

For platform operators, development tools are analogous to factory equipment. It does not matter if selling compilers is not the core revenue source. When developers can build programs more cheaply and quickly, the number of Complementary Goods on the platform increases, and the platform itself becomes more valuable. The strategy Joel Spolsky described as "commoditize your complements" applies equally to languages and SDKs.

The Costs That Languages Reduce

The costs a language reduces go well beyond the amount of typing it saves.

Saying "you can implement it in assembly" is an answer about Turing completeness—that is, about computational expressiveness. But whether it can be built within a business schedule, whether a different team can modify it years later, and whether it can be ported to the next machine are entirely different questions about development cost and practical utility.

Turing-complete languages can express the same computations, but the cost of writing, verifying, and maintaining those computations varies dramatically. When hardware was scarce and costly, execution efficiency was the dominant constraint. But as software grew larger and development organizations expanded, the human costs of writing, verifying, and maintaining code became equally significant.

High-level languages transfer some of the work once shouldered by human memory and attention to compilers, type systems, garbage collectors, and libraries. In that sense, a programming language serves primarily as an economic leverage tool to reduce software production costs.