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.
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 s olving 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 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.
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 is left.
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 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 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 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.
6.
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.
7. 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.
|