Buddhism & Programming

What happens when a guy’s vocational interest in Programming meets his recreational fascination with Buddhism?

A thought-provoking (albeit, unproductive) evening spent trying to understand how programs should view time.

Every time I’ve humoured my interest in Buddhist philosophy, I’ve always been struck by how its principles run orthogonal (if not downright antithetical) to those of Programming. Where Buddhism relies on the concepts of anicca (impermanence of being), dukkha (imperfection) & anatta (not self) to characterise sentience, programs depend on hard-edged entities, precision & unambiguously defined rules & identities. Sunyata (a state of emptiness) is about the last thing a programmer experiences when he’s going about writing his code. And while the Noble Truths of Buddhism propound an outlook that should be bereft of expectations, Programming is all about defining deterministic systems that conform to the expectations of those that build and use them.

So, ostensibly, it would appear that there isn’t much for Programming to learn from Buddhism.

Recently, though, I was watching Rich Hickey’s talk, Are we there yet?, on the current state of programming. In it he talks about how the widely observed design practices of Object Oriented Programming (OOP) have come to conflate the actually distinct concepts of entities (putative things) & states (values assumed by entities). This is a consequence of how our brains have been trained to perceive reality.

A great analogy Hickey uses here is that of a river. He leads with this fascinating quote:

No man ever steps in the same river twice.

As humans, we use abstractions to make sense of the world around us. The ‘river’ is but an abstraction for a large stream of water (which in itself is also an abstraction; but let’s not overcomplicate this for now) flowing from one point to another. But when broken down, it’s nothing but some water at a point in space and then later other water at that same point. ‘River’ is just the identity we’ve superimposed on the water and the continuum of its states at different points in time. In doing so, we’ve succumbed to one of the pitfalls of OOP, wherein we fail to distinguish between entities and their many states over time.

This is where Immutability (especially as implemented in languages like Clojure) shines by preserving all the states of entities over time and treating them as what they are — unchangeable snapshots of the entity’s existence at specific points in time. So, when viewed, the entity is representative of its state only at that point in time. This makes the entity immutable. The entity never changes, it just associates itself with different, causally-related states.

Poetically beautiful, is how I’d describe the resonance this has with the Buddhist view of time — which is that there is no time. Only an illusion of it; that stems from the series of “epochal transitions” we observe entities going through. Nowhere is this view more eloquently articulated than in these lines from one of my favourite books, Siddhartha. In them, the protagonist, Siddhartha, arrives at an epiphany after spending time by a — wait for it — river!

“Did you,” so he asked him at one time, “did you too learn that secret from the river: that there is no time?”
“Yes, Siddhartha,” he spoke. “It is this what you mean, isn’t it: that the river is everywhere at once, at the source and at the mouth, at the waterfall, at the ferry, at the rapids, in the sea, in the mountains, everywhere at once, and that there is only the present time for it, not the shadow of the past, not the shadow of the future?”

If programs were to also give up this illusion of time and embrace the concept more as a progression of instants, a succession of indelible ’now’-s, we’d actually be moving to a model much better equipped to handle the challenges of concurrency & parallelism, that arise with modern computing architecture.

It’s funny how two seemingly divergent outlooks — one based on immutability and another entrenched in impermanence can find common ground on something as fundamental as time. But it’s nice to find that Programming can in fact learn from Buddhism, even if it involves a significant amount of un-learning on the part of programmers in viewing not just their code, but also the world.

Originally published at akaashanky.github.io on November 27, 2014.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.