Computer Science

The Shen of Programming

I wish to convey to those who come after me, who may work on Shen, a code and philosophy different from those motivating much contemporary thought. The word 'Shen' is Chinese for 'spirit'. The spirit of Shen is embodied in this programming philosophy, because from it Qi and Shen both emerged. It is quite short.

The principles given here are applied in a modern setting, but arise from very ancient traditions and may be found in the works of the yoga-sage Patanjali, in the martial arts and in the works of the ancient Taoists. They reflect my personal view and are very different from what you will read from Eric S. Raymond and Richard Stallman. I have organised this philosophy, in the manner of Patanjali, in a series of 7 aphorisms to which I have attached a commentary.

The Aphorisms

  1. Correctness in approach arises from one-pointed focus in solving the problem. This requires emptiness of mind.
Any attempt to solve a problem begins with one-pointed focus on solving the problem. This sounds so simple. In fact it is very hard.

For small problems the focus may not have to be very great. For great problems it may be total. You may have to give up your life. Years may pass by. A great problem, like a beautiful woman, does not surrender herself easily.

Most of the truly beautiful creations of the human race are the creations of one-pointedness. Whether it is dance, music, martial arts, mathematics or computer science, anything of real note requires this mind. When we are not one-pointed, when our minds wander, the results are always unsatisfactory. For this reason, languages which result from the design of a committee are rarely beautiful. They reflect the passions and the egos of the personalities who make it up. They are usually a political compromise and politics is the death of beauty.

The first aphorism, that solving a problem requires one-pointedness sounds very simple. It is in fact one of the hardest to accomplish because it requires control of the mind and its desires. The greater the problem, the greater the mastery. Even the fear of not solving the problem must be set aside. There has to be total immersion.

  1. To release early and often is to pluck the fruits of the tree before they are ripe. Few will eat the fruit and few will return to the tree.
When we pick the unripe fruit of a tree, and offer it to strangers they will judge the fruit by what they taste. If the taste is bad, they will think the fruit is bad. If they have never tasted the fruit when it is ripe, they will judge the tree that bears it as worthless - as only good for bad fruit. They will approach with reserve, any person who offers them similar fruit, even if it is free. Even if the fruit becomes ripe, they will avoid it. 

The philosophy of 'release early and release often' is a philosophy arising from the picking of unripe fruit; of distributing work that should have remained on the developer's computer. It is a guarantee of acquiring a bad reputation quickly. In most areas of life, attending an interview, giving a live performance, the first date, the initial impressions are important. Often there is no second chance.

Some developers have not learned this. In some cases when people later refuse their fruit, they become angry and shout. They may even throw the fruit and say 'Eat it, it is free!'. Or they may fool themselves into believing that their unripe fruit is delicious. They may even cultivate the sour taste.
  1. To value the created above the creators. Such a mind must eventually destroy even itself and also what it takes.
A besetting vice of valuing things only for what we can get out of them; this has been a habit of the civilised mind for centuries. It leads us to see forests in terms of lumber, animals in terms of meat, land in terms of crops, and people in terms of labour.

This attitude of mind has now made its way into the digital medium where consumers demand products at zero price that took great time or money to produce; films, books, programs ....

When we approach life in this manner, seeing everything only in terms of what we can get out of it, careless of the consequences of our craving, we suck dry the resources that sustain us. The forests are felled, desert and scrub take hold, animals go extinct, the land blows away as dust and people die or walk away.

In the creative arts, demanding products to be given away leads to a situation where the creative habitat is destroyed and nothing remains for a next generation. When the creative habitat is destroyed, when nothing remains but to copy the work of an earlier generation, then what was desired has been destroyed in the act of seizing it. This is the nature of the desiring mind, which finally devours even itself after nothing else is left.

  1. To add is nothing. To add what is already there is less than nothing. To subtract and take away nothing is greater. To subtract and be left with more is true achievement.
In any software system of significant size, it is always possible to add extra features. Any programmer worth his salt can always add extra bells and whistles to his implementation. Large scale commercial companies, which depend on selling new releases, use bells and whistles to counteract the stagnating effects of market saturation. Microsoft's Word is an example of this approach.

Language design is different. In language design, adding extra features takes very little effort when the basis is firmly established. However we clutter the design when we add extra features which can already be easily implemented in the standard itself. This decision is the beginning of a move from functional efficiency, and cleanness of form to something complex and eventually overburdened.

Perlis observed this: he remarked that languages begin simply, become baroque, then rococco and eventually collapse into dust when they become overburdened with the complexities of their creators. Such a progression can be seen in martial arts, and in the art of war; where styles that were minimal and efficient become ornamented with showy detail which eventually undermine the efficacy of the fighting form.

In language design we are aiming to achieve power in economy. Adding already implementable features is not correct. It is akin to adding as an axiom, something that can already be proved as a theorem. It is not nothing, but less than nothing, to do this inside the language standard. That is, it is best avoided. Such work belongs in the library.

To take away something that already exists in the standard, withut losing any of the power of the system, is much more difficult and worthy of admiration. It is the paring away of the non-essential to reveal the underlying idea. The highest skill is to change the standard, to simplify and yet increase the power. This is true action in inaction.

  1. There are two paths in programming; the path of power and the path of understanding. The path of power gives quick results and leads to stagnation. The path of understanding gives power.
The way of understanding begins with asking Socratic questions. 'What is a window?' 'What is an operating system?' The way of power begins with questions of the form 'How do I?'. 'How do I make a window appear?'.

Of these two cultures, the power culture is by far the most dominant. It reflects the Western compulsion to get things done; of valuing the yang. The way of understanding begins with stillness. Looking out of the window, walking in a tranquil landscape are the settings for this process. It is very yin, very unspectacular.

Corporations and now even universities do not understand these processes, and choosing the way of understanding will cost you your job. The person who begins in the yin looks very inactive.

If you want to measure productivity by lines of code, papers published, then the power approach will deliver. It is very yang, you do get quick results and you impress people. However the whole edifice is built on shallow understanding. As your system expands and grows more complex, the failure of your weak understanding will become manifest. This is the one reason for the poor quality of many large-scale commercial and open source systems.

Of 100 system administrators and software writers, hardly one could answer the questions 'What is a window?', 'What is a mail tool?' i.e. formally define them as a mathematical structures. They are too busy trying to make things work. Many programmers are busy putting another layer of code or patching the holes in legacy software. Ultimately they are deservedly devoured by their own creations. Unbalanced yang always burns itself out.

In contrast the way of understanding begins with tackling these fundamental questions at the beginning. It is very yin and introspective in its beginnings with little to see. The power is all internal. But it manifests as great power over the creative phase and the mature products are much more impressive and stable than the products of the power approach. There is no need to prop up a crumbling tower.

  1. Freedom to change code is a benefit only when there is discrimination.
Protagonists of open source value freedom; the freedom to change the source code at will. This was the vision of Eric Raymond in 'The Cathedral and the Bazaar'. From the free interaction of many would come the emergence of something complex and wonderful.

There is a parallel to be found in nature, which is evolution. From thousand of experiments repeated over millions of years, in which mutations and adaptations are thrown up and discarded, survival of the fittest eventually ensures that the final result which emerges is optimally tuned to succeed in its environment. Freedom to innovate plus natural selection inevitably leads to good results.

And yet, more than a decade after Raymond's essay, and after millions of dollars and millions of man hours, the flagship product of the open source movement, Linux, has yet to significantly penetrate the desktop market or achieve the friendliness and reliability of Windows XP or Windows 7. If it does, it will certainly not be using the open source model of development. What is missing?

What is missing is discrimination.

Open source methodology works in nature because nature ruthlessly applies a fitness function, it discriminates against the unfit and feeble and wipes them out. In software the counterpart to the fitness function is supplied by the discrimination of the programmer.

But when programmers lack discrimination, when they are self-consciously obsessed with scratching their own itch, when they lack a knowledge of the history of programming languages, when they are concerned with popularity amongst their peer group, then freedom becomes self-defeating. Evolution is no longer a necessary migration from worse to better, but in fact may move from better to worse. The result is successful in pleasing the people who created it, because that is how they measure success, but the work is trapped in a ghetto. Linux has been there for a decade.

  1. The idea is more important than the platform. Flame wars arise from not understanding this.
The yoga sage Patanjali said

Fear of death arises from false consciousness.

What he meant was that when we falsely identify with the mortal body, rather than the immortal self, we experience the fear that arises from the idea of our dissolution.

This is very natural; we invest many hours grooming and taking care of our bodies; there is a whole industry devoted to keeping us young. Everything around us, our culture and advertising, compels us to identify with our bodies. Therefore false consciousness arises very easily.

Like people, programming languages have a life span. They are created, they achieve popularity, and they later decline to the point where there are no or very few users. We can say that they experience a sort of senesence, a death. Even software can die.

During the time they are alive, they can attract many users who invest many hours learning them. They groom them, and advertise them to their friends. They build web sites and news groups devoted to them. If their language begins to decline in popularity, to die, they may become defensive and fearful and closed to all criticism. Something like this happened in Common Lisp.

This attitude of mind is rooted in false consciousness; it identifies what is important in a language with the concrete embodiment of the language, its syntax, manuals, web sites and so on. These are not so important; they are mere platforms for the delivery of ideas.

What is important are the ideas themselves, the insights present in the language. When we value a language for its insights, we cease to become defensive and fearful, because these ideas, if they are worthy, are immortal. They will, either deliberately or inadvertently, find their way in other languages. Thus much of what is useful in Common Lisp has found its way into Python and Clojure. When we learn to value ideas, and not platforms, then much of the angst around software death disappears and our competitors become our friends.