The Developer’s Middle-Way (or: how the Buddha invented Functional Programming)
This is the actual story of the Buddha (as told to programmers), and how over 2500 years ago he invented functional programming.
Well, that’s clearly false. The Buddha didn’t know the first thing about computers and programming, he lived way before they were invented. But still, he invented functional programming… sort of.
To put it more accurately, the following story is an analogy to the original story of Buddhism. Better, it’s an analogy that uses software engineering concepts and terminology (hurray!).
I argue that this kind of analogy makes sense. If you think of your brain as a computer (how else?), then I argue that your consciousness is analogous to a program that runs on this computer. We all have demonstrably different programs (or program flavors, if you will), but I think the Buddhist programs are of their own separate kind. In a way what the Buddha did was fork the regular program, and make crucial changes to it. Should you pull these changes to your local branch? Hopefully this will help you decide.
Let’s start at the beginning.
This story is about Siddhartha. A young Indian boy from a very high-class family who lives in a palace. Siddhartha is a prodigy. His parents have great expectations for his future programming career and are the kind of parents who take raising their kids very very seriously.
They decide, probably because they’ve seen it on some morning show, that it’s best to not expose young and still molding Siddhartha with the hardship of programming life. They want him to think that the tech life is perfect, that there are no such things as frustration, desperation and termination.
The palace where Siddhartha grew up was a shelter from all those calamities. The programmers in the palace never had bugs. They never had warnings. everything was 100% smooth-sailing for them all the time. I’m not sure how they did it, actually (it’s a legend, don’t forget) but I think it’s a fair assumption that little company value was created in that palace those days.
When at last Siddhartha was old enough to exit his parents shielding care (did someone say garage?), at the tender age of 29 (no joke), he was in for a shock.
For the first time, Siddhartha encountered programmers who had bugs (not just in their hair). They were frustrated, they were desperate, and some quit or got fired.
It was entirely new for Siddhartha. He had never heard of such monstrosities as compile errors, memory leaks, stack overflows, C++. He felt deeply sorry for those poor programmers, and he wished there was something he could do.
He looked up in despair, and saw the most inspiring motivational poster on his office wall. He knew then and there what he must do.
He decided he was going to go on a mission to end programmer suffering. He started investigating. He read books, went to conferences, saw lectures, followed blogs, even joined twitter.
The first logical step for him, was to go talk to the Yogis (yes, the ones from your office yoga class! they were HUGE once). They were the masters of their time when it came to programmer misery. They agreed to teach him, and he learned quickly.
What the Yogis taught was that suffering was an inevitable part of programming, one that needs be totally embraced.
The Yogis did not reuse code. They didn’t test, didn’t use an IDE, had no tools, ignored warnings, and deployed on Fridays.
Siddhartha learned to work this way. He actually became one of the top Yogis, but he wasn’t satisfied. He looked for a middle-way between his previous life and the Yogis’. A middle way between being happy at the expense of all else, and self-tormenting.
One day, sitting under the Sacred Fig (then: fig) in his office, after a whole week of investigating a bug, a coworker passed by and gave Siddhartha an abstraction that solved his bug. It is said that at that moment Siddhartha reached the most full and complete enlightenment, and became The Programming Buddha.
The Buddha realized that programmer suffering didn’t come from a minimal use of tools and methods, or from not using the most cutting edge technology. The problem was something else.
He realized that his bad programs had a common problem. They would cling to the world, by holding an internal representation of it, which didn’t always match the world exactly. That was the main cause (or samudaya) for the suffering (or dukkha).
In other words, those programs had state. Clinging (having state) is what causes (bugs which cause programmer-)suffering!
With this extraordinary revelation (at least for it’s time!) the Buddha started hosting webinars in which he taught how programs should work in his view. He compared good programs to mirrors. They reflect the world. They are not affected by it, they don’t hold on to it. (no state, no side effects, functional programming FTW!).
Remember, this is the actual story. With the minor caveat that programs should be minds.
Programming nirvana doesn’t come from embracing the pain of errors or being self-indulgent and use a bunch of tools that will do the work for you. It comes from simply writing good (functional) code.
And the bonus: you can do all that in your real lives as well, like in some other less zeitgeist-y version of this story. Try experiencing things without prejudice based on past experiences. Don’t let one experience affect another, unrelated one. Be a functional person.
If you manage to do this, no only are you a Programming Buddha, you are an Old School Buddha as well. Nice!
