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.
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.
- 2. 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
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
- 3. 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
- 4. 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
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 user-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, without 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.
- 5. 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
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
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
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.
Freedom to change code is a benefit only when there is
|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
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.
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
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
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.