The Revolution in Programming
A manifesto for the future of the Web
The Blockchain revolution is upon us. A.I. is having its breakthrough moment. But there is a third revolution unfolding in silence, far from the eyes of the public, and it is time we talk about it.
For the first time in the history of computing we have blockchain technology, the first mainstream field that challenges programmers to go searching for the elusive foundations of their craft.
I work at MultiversX, a blockchain company from Romania. Everything in this text is inspired by my personal experience over the past few years. There are patterns and recurring issues that I see everywhere I look, and each time they lead me to the same conclusion: the only way out is a return to mathematics.
The mathematics I am talking about is not new. It is older than the Turing machine, older than all modern programming languages, older than the entirety of our tech stacks. But for decades, its mysteries were reserved to the theoreticians, or to fringe applications, such as space and aeronautics.
But here we are, developing on the blockchain in a rapidly moving space, where audits cost fortunes and rarely uncover the truly deep and dangerous errors, where hundreds of millions of dollars get regularly hacked or lost, where our old languages and tools feel less adequate than ever before. It is reasonable to ask: what if our problems are foundational? What if we have reached the point where simply throwing ever more resources at the problem will not get us any further?
Programming
What is programming? An appointment is programming. An architect’s plan for a building is programming. So are the gears inside a running engine. Everything that goes on in each computer, and ultimately, the web.
Programming is our imagination, disciplined into structure. It is our creativity operationalized.
The better the structures, the more our imaginations can achieve. The computer was born out of our need to enhance what we can think and simulate. But so was mathematics. So were arts.
At some point our imaginations met, and we started building these structures together. From tropes, to societies, ultimately the web.
Now we are trying to create a new generation of interactive virtual worlds, and yet we struggle to engineer them. Should it be that our models are not equal to the task? Is our discipline lacking?
The unfinished dome
The ancient Romans built countless impressive structures, despite owning a very primitive grasp over mathematics. So did the architects and masons that erected the grand cathedrals of the Middle Ages. One does feel awe-struck when encountering them, and yet there was always an invisible barrier that these builders of the past could not surpass.
Without our modern science and technology, it would be impossible to have skyscrapers, our modern roads and railways, our cities and our economies. The engineering method got us far, it got us aqueducts and cathedrals, and yet the greatest leaps only ever came when the engineering method was married to the scientific method, and to mathematics.
We’ve always wanted to build taller, for hundreds of years it was not our imagination the one that prevented us from doing so.
The web
Today we are building the greatest collaborative technology ever seen by man. Our achievements are unprecedented, and yet there is a feeling of chaos and unreliability pervading our collective creation.
We found it almost impossible to enforce a common language, common standards and practices, and so we’ve found refuge with huge monolithic proprietary platforms. We feel that we could be doing more, but none of us can do it alone, and we are struggling to build together.
Even though we know how to make independent platforms communicate, the links are fragile. Breaches in the unwritten contracts between us can cascade and tear down overly dependent systems, so often revert to self-sufficiency and isolation.
The contract
Maybe this is the issue with today’s web. Its underlying contracts are unwritten and unenforced.
Web 2.0 couldn’t come up with native money, or autonomous organizations. But even though we, blockchain people, have built a layer of trust upon which contracts can be written and enforced, we are struggling with the language of these contracts.
We have suddenly been confronted with the messy reality of what for almost 100 years now we have been collectively sweeping under the rug: our programming methods and practices are not up to par with what we would expect of our buildings, roads and vehicles. They offer us no certainties, their promises are weak; in hunting down faults we have little help.
A path forward
If 10 years ago I had told someone that I think programming is not done properly and that we should find the way back to its mathematical foundations, I would have been laughed in the face.
With what money? Who is willing to spend 10x times as much writing theorems and proofs for an app that will change anyway in a few months.
And it’s fair. For the most part it’s important to be nimble. That is … if you’re building alone. But what if you are working on a protocol on which millions will entrust their savings one day? What if your app will be used by dozens of other projects, which in turn will be used by dozens more. How would one go about earning the trust of its users and dependent platforms when an app is expected to change every few months and offer no guarantees in the process?
Audits are palliative, they don’t address the key issue. And they are not scalable. Once the number of projects reaches a certain threshold, there will be no way to audit them all, not to mention that audits are not bulletproof.
No. We need to bring the power of mathematics to software developers, as we did with the rest of engineering.
It’s not a pipe dream, it’s possible. There are steps in the right direction, but they are timid, because we are not trying hard enough. We’re still in denial, still hoping just a little more of the same will be enough.
It won’t.
Once a system becomes complex enough, there is no other way.
The Garden
I like to envision large technological projects like gardens. For a garden to thrive, it needs both growth and trimming.
We often only think about growth. This is fair — in the early stages of projects, growth is the most important factor. We add features, onboard developers and users, imagine more and more.
But an untrimmed garden at some point will start to suffer from overgrowth. The paths will stop being accessible, plants will suffocate one another and will stop bearing fruits. A skilled gardener knows when and how to trim, to allow the garden to keep growing.
In programming we are still figuring out how to trim. We have clean code practices and architectures, we have testing, and reviews. They work on individual projects if implemented correctly, but they are almost hopeless if we try to scale them to the level of an entire blockchain ecosystem, or the entire web.
We need better shears.
Where does A.I. fit in our story?
A.I. (machine learning to be more exact) has grown spectacularly in the past year. It offers us unprecedented opportunities, but we must remember: it is a tool for growing, not for trimming.
A.I. alone cannot fix our problems with reliability, cleanliness and composition, since it is itself not completely reliable. Large language models work well when their output can be independently tested, verified, inspected. It may be the only way for us to build rich, engaging worlds, but to ensure the stability and health of these worlds, the opposite toolset is needed.
Discovery, not invention
We’ve started to figure out how to manage our dependencies in all major programming platforms, now we’re figuring out how to version and upgrade our smart contracts.
We’ve figured out how to make contracts interact, now we’re figuring out how to make sure that these interactions are correct and will remain correct, always.
We’ve figured out how to prove things about small algorithms, now we’re figuring out how to expand this to the size of the entire web.
We’ve figured out how to connect services and microservices, now we need to figure out how to ensure we reliably communicate correct information.
What is the secret solution?
It’s a mathematical model of everything. The blockchain is a mathematical model. Tokens are a mathematical model. So is the VM. Each smart contract is one too.
What kind of a model is it? I don’t think anyone knows precisely just yet, but I expect we’ll come up with a formulation that contains words like “functor”, “monad”, “continuation”, “dependent types”, “bisimulation”.
It’s likely to sound pretentious and inaccessible at first, but once properly explored and explained, it will seem elementary, in hindsight. We’ll teach it in schools and we’ll smirk at how “those people of the past” could not figure it out earlier.
This is a process of discovery, not invention.
All the paths of engineering converge to the same limited sets of mathematical truths. I’m sure everyone will reach the same destination eventually.
We’re probably less than 50 years away from reaching that destination, even without any concerted effort. It’s an inevitability. But the point is not to wait 50 years for it, it’s to be deliberate about it and make it happen here and now, in a few years at most.
A (blurry) roadmap
Category theory is the foundation of any large system, like a blockchain ecosystem, or the web. This is because category theory is the mathematics of composability, and composability is the foundation of any ecosystem-wide tech.
Category theory leads us smoothly to type theory. Type theory is probably the most powerful tool we have at our disposal, since it can simultaneously model the entirety of mathematics, while also conveniently fitting into our day to day programs.
Types don’t only help us have safer variables. We often forget that types also describe functions, and by extension entire programs. A powerful type system can extend beyond simple programs: tokens are types, interactions between smart contracts are types, storage layout is a type, the ABI is a type, VM queries are types, microservices are types, I even believe UX is a system of interconnected types.
Types might also be familiar to developers, so will hopefully ease the transition to more powerful tools. They can also help with performance concerns — we’ve already experimented with abstracting many implementation details in a high-performance environment, in our Rust framework. At their full power, they might allow us to prove theorems and invariants about our smart contracts, without any penalty in performance.
Going further, WebAssembly is a great weapon we have: it has amazing speed, it’s universal, while being well described and modeled. My belief is that executable formal models are cool, but not fast enough for production. We need to uncover some equivalence principles between high-level models and low-level fast execution; we have a good chance to bridge the chasm via WebAssembly and its K Framework formal specification.
One final thought: we want no-code platforms, and this seems like a less technical task than designing something for developers. It is the opposite! To make something simple that is usable by anyone, you need the most powerful models out there, exceeding in sophistication the best tools we know of. Of course, the end user will see nothing of this, but for them to build useful stuff, the abstractions operating behind the scenes will need to be perfectly bulletproof, especially from a compositionality (ergo, category theory) point of view.
Final thoughts
Instead of a conclusion, I will directly quote from Bartosz Milewski’s preface to Category Theory for Programmers:
Changes in hardware and the growing complexity of software are forcing us to rethink the foundations of programming. Just like the builders of Europe’s great gothic cathedrals we’ve been honing our craft to the limits of material and structure. There is an unfinished gothic cathedral in Beauvais, France, that stands witness to this deeply human struggle with limitations. It was intended to beat all previous records of height and lightness, but it suffered a series of collapses. Ad hoc measures like iron rods and wooden supports keep it from disintegrating, but obviously a lot of things went wrong. From a modern perspective, it’s a miracle that so many gothic structures had been successfully completed without the help of modern material science, computer modeling, finite element analysis, and general math and physics. I hope future generations will be as admiring of the programming skills we’ve been displaying in building complex operating systems, web servers, and the internet infrastructure. And, frankly, they should, because we’ve done all this based on very flimsy theoretical foundations. We have to fix those foundations if we want to move forward.
We’re close.
If we squint, it’s right there, on the horizon. It’s time to get it.
