Favorite texts?

Hey people, what are some of your favorite stories, jokes, etc. Two of mine
are posted below.

The Tao Of Programming
The deep mysteries and the path of programming as explained by the masters.



The Tao Of Programming
Translated By Geoffrey James
Table of Contents
Book 1 – The Silent Void
Book 2 – The Ancient Masters
Book 3 – Design
Book 4 – Coding
Book 5 – Maintenance
Book 6 – Management
Book 7 – Corporate Wisdom
Book 8 – Hardware and Software
Book 9 – Epilogue



The Silent Void
Book One
Thus spake the master programmer:
“When you have learned to snatch the error code from the trap frame, it will
be
time for you to leave.”
1.1
Something mysterious is formed, born in the silent void. Waiting alone and
unmoving, it is at once still and yet in constant motion. It is the source
of
all programs. I do not know its name, so I will call it the Tao of
Programming.
If the Tao is great, then the operating system is great. If the operating
system
is great, then the compiler is great. If the compiler is great, then the
application is great. The user is pleased and there is harmony in the world.
The Tao of Programming flows far away and returns on the wind of morning.
1.2
The Tao gave birth to machine language. Machine language gave birth to the
assembler.
The assembler gave birth to the compiler. Now there are ten thousand
languages.
Each language has its purpose, however humble. Each language expresses the
Yin
and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
1.3
In the beginning was the Tao. The Tao gave birth to Space and Time.
Therefore
Space and Time are Yin and Yang of programming.
Programmers that do not comprehend the Tao are always running out of time
and
space for their programs. Programmers that comprehend the Tao always have
enough
time and space to accomplish their goals.
How could it be otherwise?
1.4
The wise programmer is told about Tao and follows it. The average programmer
is
told about Tao and searches for it. The foolish programmer is told about Tao
and
laughs at it.
If it were not for laughter, there would be no Tao.
The highest sounds are hardest to hear. Going forward is a way to retreat.
Great
talent shows itself late in life. Even a perfect program still has bugs.



The Ancient Masters
Book Two
Thus Spake the Master Programmer:
“After three days without programming, life becomes meaningless.”
2.1
The programmers of old were mysterious and profound. We cannot fathom their
thoughts, so all we do is describe their appearance.
Aware, like a fox crossing the water. Alert, like a general on the
battlefield.
Kind, like a hostess greeting her guests. Simple, like uncarved blocks of
wood.
Opaque, like black pools in darkened caves.
Who can tell the secrets of their hearts and minds?
The answer exists only in Tao.
2.2
Grand Master Turing once dreamed that he was a machine. When he awoke he
exclaimed:
“I don’t know whether I am Turing dreaming that I am a machine, or a machine
dreaming that I am Turing!.”
2.3
A programmer from a very large computer company went to a software
conference
and then returned to report to his manager, saying: “What sort of
programmers
work for other companies? They behaved badly and were unconcerned with
appearances. Their hair was long and unkept and their clothes were wrinkled
and
old. They crashed out hospitality suite and they made rude noises during my
presentation.”
The manager said: “I should have never sent you to the conference. Those
programmers live beyond the physical world. They consider life absurd, an
accidental coincidence. They come and go without knowing limitations.
Without a
care, they live only for their programs. Why should they bother with social
conventions?
They are alive within the Tao.”
2.4
A novice asked the Master: “Here is a programmer that never designs,
documents
or tests his programs. Yet all who know him consider him one of the best
programmer in the world. Why is this?”
The Master replies: “That programmer has mastered the Tao. He has gone
beyond
the need for design; he does not become angry when the system crashes, but
accepts the universe without concern. He has gone beyond the need for
documentation; he no longer cares if anyone else sees his code. He has gone
beyond the need for testing; each of his programs are perfect within
themselves,
serene and elegant, their purpose self-evident. Truly, he has entered the
mystery of Tao.”



Design
Book Three
Thus spake the Master Programmer:
“When the program is being tested, it is too late to make design changes.”
3.1
There once was a man who went to a computer trade show. Each day as he
entered,
the man told the guard at the door:
“I am a great thief, renowned for my feats of shoplifting. Be forewarned,
for
this trade show shall not escape unplundered.”
This speech disturbed the guard greatly, because there were millions of
dollars
of computer equipment inside, so he watched the man carefully. But the man
merely wandered from booth to booth, humming quietly to himself.
When the man left, the guard took him aside and searched his clothes, but
nothing was to be found.
On the next day of the trade show, the man returned and chided the guard
saying:
“I escaped with a vast booty yesterday, but today will be even better.” So
the
guard watched him ever more closely, but to no avail.
On the final day of the trade show, the guard could restrain his curiosity
no
longer. “Sir Thief,” he said, “I am so perplexed, I cannot live in peace.
Please
enlighten me. What is it that you are stealing?”
The man smiled. “I am stealing ideas,” he said.
3.2
There once was a master programmer who wrote unstructured programs. A novice
programmer, seeking to imitate him, also began to write unstructured
programs.
When the novice asked the master to evaluate his progress, the master
criticized
him for writing unstructured programs, saying “What is appropriate for the
master is not appropriate for the novice. You must understand Tao before
transcending structure.”
3.3
There was once a programmer who was attached to the court of the warlord of
Wu.
The warlord asked the programmer: “Which is easier to design: an accounting
package or an operating system?”
“An operating system,” replied the programmer.
The warlord uttered an exclamation of disbelief. “Surely an accounting
package
is trivial next to the complexity of an operating system,” he said.
“Not so,” said the programmer, “when designing an accounting package, the
programmer operates as a mediator between people having different ideas: how
it
must operate, how its reports must appear, and how it must conform to the
tax
laws. By contrast, an operating system is not limited by outside
appearances.
When designing an operating system, the programmer seeks the simplest
harmony
between machine and ideas. This is why an operating system is easier to
design.”

The warlord of Wu nodded and smiled. “That is all good and well, but which
is
easier to debug?”
The programmer made no reply.
3.4
A manager went to the master programmer and showed him the requirements
document
for a new application. The manager asked the master: “How long will it take
to
design this system if I assign five programmers to it?”
“It will take one year,” said the master promptly.
“But we need this system immediately or even sooner! How long will it take
if I
assign ten programmers to it?”
The master programmer frowned. “In that case, it will take two years.”
“And what if I assign a hundred programmers to it?”
The master programmer shrugged. “Then the design will never be completed,”
he
said.



Coding
Book Four
Thus spake the master programmer:
“A well-written program is its own heaven;
a poorly-written program is its own hell.”
4.1
A program should be light and agile, its subroutines connected like a string
of
pearls. The spirit and intent of the program should be retained throughout.
There should be neither too little or too much, neither needless loops nor
useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the ‘Law of Least Astonishment’. What is this law?
It is
simply that the program should always respond to the user in the way that
astonishes him least.
A program, no matter how complex, should act as a single unit. The program
should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of
disorder
and confusion. The only way to correct this is to rewrite the program.
4.2
A novice asked the master: “I have a program that sometime runs and
sometimes
aborts. I have followed the rules of programming, yet I am totally baffled.
What
is the reason for this?”
The master replied: “You are confused because you do not understand Tao.
Only a
fool expects rational behavior from his fellow humans. Why do you expect it
from
a machine that humans have constructed? Computers simulate determinism; only
Tao
is perfect.
The rules of programming are transitory; only Tao is eternal. Therefore you
must
contemplate Tao before you receive enlightenment.”
“But how will I know when I have received enlightenment?” asked the novice.
“Your program will then run correctly,” replied the master.
4.3
A master was explaining the nature of Tao of to one of his novices, “The Tao
is
embodied in all software – regardless of how insignificant,” said the
master.
“Is the Tao in a hand-held calculator?” asked the novice.
“It is,” came the reply.
“Is the Tao in a video game?” continued the novice.
“It is even in a video game,” said the master.
“And is the Tao in the DOS for a personal computer?”
The master coughed and shifted his position slightly. “The lesson is over
for
today,” he said.
4.4
Prince Wang’s programmer was coding software. His fingers danced upon the
keyboard. The program compiled without an error message, and the program ran
like a gentle wind.
“Excellent!” the Prince exclaimed, “Your technique is faultless!”
“Technique?” said the programmer turning from his terminal, “What I follow
is
Tao – beyond all techniques! When I first began to program I would see
before
me the whole problem in one mass. After three years I no longer saw this
mass.
Instead, I used subroutines. But now I see nothing. My whole being exists in
a
formless void. My senses are idle. My spirit, free to work without plan,
follows
its own instinct. In short, my program writes itself. True, sometimes there
are
difficult problems. I see them coming, I slow down, I watch silently. Then I
change a single line of code and the difficulties vanish like puffs of idle
smoke. I then compile the program. I sit still and let the joy of the work
fill
my being. I close my eyes for a moment and then log off.”
Prince Wang said, “Would that all of my programmers were as wise!”



Maintenance
Book Five
Thus spake the master programmer:
“Though a program be but three lines long, someday it will have to be
maintained.”
5.1
A well-used door needs no oil on its hinges. A swift-flowing stream does not
grow stagnant. Neither sound nor thoughts can travel through a vacuum.
Software
rots if not used.
These are great mysteries.
5.2
A manager asked a programmer how long it would take him to finish the
program on
which he was working. “I will be finished tomorrow,” the programmer promptly
replied.
“I think you are being unrealistic,” said the manager, “Truthfully, how long
will it take?”
The programmer thought for a moment. “I have some features that I wish to
add.
This will take at least two weeks,” he finally said.
“Even that is too much to expect,” insisted the manager, “I will be
satisfied if
you simply tell me when the program is complete.”
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement
lunch, he
discovered the programmer asleep at his terminal. He had been programming
all
night.
5.3
A novice programmer was once assigned to code a simple financial package.
The novice worked furiously for many days, but when his master reviewed his
program, he discovered that it contained a screen editor, a set of
generalized
graphics routines, an artificial intelligence interface, but not the
slightest
mention of anything financial.
When the master asked about this, the novice became indignant. “Don’t be so
impatient,” he said, " I’ll put in the financial stuff eventually."
5.1
Does a good farmer neglect a crop he has planted?
Does a good teacher overlook even the most humble student?
Does a good father allow a single child to starve?
Does a good programmer refuse to maintain his code?




Management
Book Six
Thus spake the master programmer:
“Let the programmer be many and the managers few – then all will be
productive.”
6.1
When managers hold endless meetings, the programmers write games. When
accountants talk of quarterly profits, the development budget is about to be
cut. When senior scientists talk blue sky, the clouds are about to roll in.
Truly, this is not the Tao of Programming.
When managers make commitments, game programs are ignored. When accountants
make
long-range plans, harmony and order are about to be restored. When senior
scientists address the problems at hand, the problems will soon be solved.
Truly, this is the Tao of Programming.
6.2
Why are programmers non-productive? Because their time is wasted in
meetings.
Why are programmers rebellious? Because the management interferes to much.
Why are the programmers resigning one by one? Because they are burnt out.
Having worked for poor management, they no longer value their jobs.
6.3
A manager was about to be fired, but a programmer who worked for him
invented a
new program that became popular and sold well. As a result, the manager
retained
his job.
The manager tried to give the programmer a bonus, but the programmer refused
it,
saying, “I wrote the program because I thought it was an interesting
concept,
and thus I expect no reward.”
The manager upon hearing this remarked, “This programmer, though he holds a
position of small esteem, understands well the proper duty of an employee.
Lets
promote him to the exalted position of management consultant!”
But when told this, the programmer once more refused, saying, “I exist so
that I
can program. If I were promoted, I would do nothing but waste everyone’s
time.
Can I go now? I have a program that I’m working on.”
6.4
A manager went to his programmers and told them: “As regards to your work
hours:
you are going to have to come in at nine in the morning and leave at five in
the
afternoon.” At this, all of them became angry and several resigned on the
spot."

So the manager said: “All right, in that case you may set your own working
hours, as long as you finish your projects on schedule.” The programmers,
now
satisfied, began to come in at noon and work to the wee hours of the
morning.



Corporate Wisdom
Book Seven
Thus spake the master programmer:
“You can demonstrate a program for a corporate executive, but you can’t make
him
computer literate.”
7.1
A novice asked the master: “In the east there is a great tree- structure
that
men call ‘Corporate Headquarters’. It is bloated out of shape with vice
presidents and accountants. It issues a multitude of memos, each saying ‘Go,
Hence!’ or ‘Go, Hither!’ and nobody knows what is meant. Every year new
names
are put onto the branches, but all to no avail. How can such an unnatural
entity
exist?”
The master replies: “You perceive this immense structure and are disturbed
that
it has no rational purpose. Can you not take amusement from its endless
gyrations? Do you not enjoy the untroubled ease of programming beneath its
sheltering branches? Why are you bothered by its uselessness?”
7.2
In the east there is a shark which is larger than all other fish. It changes
into a bird whose wings are like clouds filling the sky. When this bird
moves
across the land, it brings a message from Corporate Headquarters. This
message
it drops into the midst of the programmers, like a seagull making its mark
upon
the beach. Then the bird mounts on the wind and, with the blue sky at its
back,
returns home.
The novice programmer stares in wonder at the bird, for he understands it
not.
The average programmer dreads the coming of the bird, for he fears its
message.
The master programmer continues to work at his terminal, for he does not
know
that the bird has come and gone.
7.3
The Magician of the Ivory Tower brought his latest invention for the master
programmer to examine. The magician wheeled a large black box into the
master’s
office while the master waited in silence.
“This is an integrated, distributed, general-purpose workstation,” began the
magician, “ergonomically designed with a proprietary operating system, sixth
generation languages, and multiple state of the art user interfaces. It took
my
assistants several hundred man years to construct. Is it not amazing?”
The master raised his eyebrows slightly. “It is indeed amazing,” he said.
“Corporate Headquarters has commanded,” continued the magician, “that
everyone
use this workstation as a platform for new programs. Do you agree to this?”
“Certainly,” replied the master, " I will have it transported to the data
center
immediately!" And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master
programmer
and said, “I cannot find the listing for my new program. Do you know where
it
might be?”
“Yes,” replied the master, “the listings are stacked on the platform in the
data
center.”
7.4
The master programmer moves from program to program without fear. No change
in
management can harm him. He will not be fired, even if the project is
cancelled.
Why is this? He is filled with Tao.



Hardware and Software
Book Eight
Thus spake the master programmer:
“Without the wind, the grass does not move. Without software,hardware is
useless.”
8.1
A novice asked the master: “I perceive that one computer company is much
larger
than all others. It towers above its competition like a giant among dwarfs.
Any
one of its divisions could comprise an entire business. Why is this so?”
The master replied, “Why do you ask such foolish questions? That company is
large because it is large. If it only made hardware, nobody would buy it. If
it
only made software, nobody would use it. If it only maintained systems,
people
would treat it like a servant. But because it combines all of these things,
people think it one of the gods! By not seeking to strive, it conquers
without
effort.”
8.2
A master programmer passed a novice programmer one day. The master noted the
novice’s preoccupation with a hand-held computer game. “Excuse me”, he said,
“may I examine it?”
The novice bolted to attention and handed the device to the master. I see
that
the device claims to have three levels of play: Easy, Medium and Hard", said
the
master. “Yet every such device has another level of play, where the device
seeks
not to conquer the human, nor to be conquered by the human.”
“Pray, great master”, implored the novice, “how does one find this
mysterious
settings?”
The master dropped the device to the ground and crushed it under foot. And
suddenly the novice was enlightened.
8.3
There was once a programmer who worked upon microprocessors. “Look at how
well
off I am here,” he said to a mainframe programmer who came to visit, “I have
my
own operating system and file storage device. I do not have to share my
resources with anyone. The software is self- consistant and easy-to-use. Why
do
you not quit your present job and join me here?”
The mainframe programmer then began to describe his system to his friend,
saying
“The mainframe sits like an ancient sage meditating in the midst of the data
center. Its disk drives lie end-to-end like a great ocean of machinery. The
software is as multifaceted as a diamond, and as convoluted as a primeval
jungle. The programs, each unique, move through the system like a
swift-flowing
river. That is why I am happy where I am.”
The microcomputer programmer, upon hearing this, fell silent. But the two
programmers remained friends until the end of their days.
8.4
Hardware met Software on the road to Changtse. Software said: “You are Yin
and I
am Yang. If we travel together we will become famous and earn vast sums of
money.” And so they set forth together, thinking to conquer the world.
Presently they met Firmware, who was dressed in tattered rags and hobbled
along
propped on a thorny stick. Firmware said to them: “The Tao lies beyond Yin
and
Yang. It is silent and still as a pool of water. It does not seek fame,
therefore nobody knows its presence. It does not seek fortune, for it is
complete within itself. It exists beyond space and time.”
Software and Hardware, ashamed, returned to their homes.



Epilogue
Book Nine
Thus spake the Master Programmer:
“Time for you to leave.”

In the Beginning was the Command Line

by Neal Stephenson


About twenty years ago Jobs and Wozniak, the founders of Apple, came up with
the very strange idea of selling information processing machines for use in
the home. The business took off, and its founders made a lot of money and
received the credit they deserved for being daring visionaries. But around
the same time, Bill Gates and Paul Allen came up with an idea even stranger
and more fantastical: selling computer operating systems. This was much
weirder than the idea of Jobs and Wozniak. A computer at least had some sort
of physical reality to it. It came in a box, you could open it up and plug
it in and watch lights blink. An operating system had no tangible
incarnation at all. It arrived on a disk, of course, but the disk was, in
effect, nothing more than the box that the OS came in. The product itself
was a very long string of ones and zeroes that, when properly installed and
coddled, gave you the ability to manipulate other very long strings of ones
and zeroes. Even those few who actually understood what a computer operating
system was were apt to think of it as a fantastically arcane engineering
prodigy, like a breeder reactor or a U-2 spy plane, and not something that
could ever be (in the parlance of high-tech) “productized.”

Yet now the company that Gates and Allen founded is selling operating
systems like Gillette sells razor blades. New releases of operating systems
are launched as if they were Hollywood blockbusters, with celebrity
endorsements, talk show appearances, and world tours. The market for them is
vast enough that people worry about whether it has been monopolized by one
company. Even the least technically-minded people in our society now have at
least a hazy idea of what operating systems do; what is more, they have
strong opinions about their relative merits. It is commonly understood, even
by technically unsophisticated computer users, that if you have a piece of
software that works on your Macintosh, and you move it over onto a Windows
machine, it will not run. That this would, in fact, be a laughable and
idiotic mistake, like nailing horseshoes to the tires of a Buick.

A person who went into a coma before Microsoft was founded, and woke up now,
could pick up this morning’s New York Times and understand everything in
it–almost:


Item: the richest man in the world made his fortune from-what? Railways?
Shipping? Oil? No, operating systems. Item: the Department of Justice is
tackling Microsoft’s supposed OS monopoly with legal tools that were
invented to restrain the power of Nineteenth-Century robber barons. Item: a
woman friend of mine recently told me that she’d broken off a (hitherto)
stimulating exchange of e-mail with a young man. At first he had seemed like
such an intelligent and interesting guy, she said, but then “he started
going all PC-versus-Mac on me.”

What the hell is going on here? And does the operating system business have
a future, or only a past? Here is my view, which is entirely subjective; but
since I have spent a fair amount of time not only using, but programming,
Macintoshes, Windows machines, Linux boxes and the BeOS, perhaps it is not
so ill-informed as to be completely worthless. This is a subjective essay,
more review than research paper, and so it might seem unfair or biased
compared to the technical reviews you can find in PC magazines. But ever
since the Mac came out, our operating systems have been based on metaphors,
and anything with metaphors in it is fair game as far as I’m concerned.


MGBs, TANKS, AND BATMOBILES

Around the time that Jobs, Wozniak, Gates, and Allen were dreaming up these
unlikely schemes, I was a teenager living in Ames, Iowa. One of my friends’
dads had an old MGB sports car rusting away in his garage. Sometimes he
would actually manage to get it running and then he would take us for a spin
around the block, with a memorable look of wild youthful exhiliration on his
face; to his worried passengers, he was a madman, stalling and backfiring
around Ames, Iowa and eating the dust of rusty Gremlins and Pintos, but in
his own mind he was Dustin Hoffman tooling across the Bay Bridge with the
wind in his hair.

In retrospect, this was telling me two things about people’s relationship to
technology. One was that romance and image go a long way towards shaping
their opinions. If you doubt it (and if you have a lot of spare time on your
hands) just ask anyone who owns a Macintosh and who, on those grounds,
imagines him- or herself to be a member of an oppressed minority group.

The other, somewhat subtler point, was that interface is very important.
Sure, the MGB was a lousy car in almost every way that counted: balky,
unreliable, underpowered. But it was fun to drive. It was responsive. Every
pebble on the road was felt in the bones, every nuance in the pavement
transmitted instantly to the driver’s hands. He could listen to the engine
and tell what was wrong with it. The steering responded immediately to
commands from his hands. To us passengers it was a pointless exercise in
going nowhere–about as interesting as peering over someone’s shoulder while
he punches numbers into a spreadsheet. But to the driver it was an
experience. For a short time he was extending his body and his senses into a
larger realm, and doing things that he couldn’t do unassisted.

The analogy between cars and operating systems is not half bad, and so let
me run with it for a moment, as a way of giving an executive summary of our
situation today.

Imagine a crossroads where four competing auto dealerships are situated. One
of them (Microsoft) is much, much bigger than the others. It started out
years ago selling three-speed bicycles (MS-DOS); these were not perfect, but
they worked, and when they broke you could easily fix them.

There was a competing bicycle dealership next door (Apple) that one day
began selling motorized vehicles–expensive but attractively styled cars
with their innards hermetically sealed, so that how they worked was
something of a mystery.

The big dealership responded by rushing a moped upgrade kit (the original
Windows) onto the market. This was a Rube Goldberg contraption that, when
bolted onto a three-speed bicycle, enabled it to keep up, just barely, with
Apple-cars. The users had to wear goggles and were always picking bugs out
of their teeth while Apple owners sped along in hermetically sealed comfort,
sneering out the windows. But the Micro-mopeds were cheap, and easy to fix
compared with the Apple-cars, and their market share waxed.

Eventually the big dealership came out with a full-fledged car: a colossal
station wagon (Windows 95). It had all the aesthetic appeal of a Soviet
worker housing block, it leaked oil and blew gaskets, and it was an enormous
success. A little later, they also came out with a hulking off-road vehicle
intended for industrial users (Windows NT) which was no more beautiful than
the station wagon, and only a little more reliable.

Since then there has been a lot of noise and shouting, but little has
changed. The smaller dealership continues to sell sleek Euro-styled sedans
and to spend a lot of money on advertising campaigns. They have had GOING
OUT OF BUSINESS! signs taped up in their windows for so long that they have
gotten all yellow and curly. The big one keeps making bigger and bigger
station wagons and ORVs.

On the other side of the road are two competitors that have come along more
recently.

One of them (Be, Inc.) is selling fully operational Batmobiles (the BeOS).
They are more beautiful and stylish even than the Euro-sedans, better
designed, more technologically advanced, and at least as reliable as
anything else on the market–and yet cheaper than the others.

With one exception, that is: Linux, which is right next door, and which is
not a business at all. It’s a bunch of RVs, yurts, tepees, and geodesic
domes set up in a field and organized by consensus. The people who live
there are making tanks. These are not old-fashioned, cast-iron Soviet tanks;
these are more like the M1 tanks of the U.S. Army, made of space-age
materials and jammed with sophisticated technology from one end to the
other. But they are better than Army tanks. They’ve been modified in such a
way that they never, ever break down, are light and maneuverable enough to
use on ordinary streets, and use no more fuel than a subcompact car. These
tanks are being cranked out, on the spot, at a terrific pace, and a vast
number of them are lined up along the edge of the road with keys in the
ignition. Anyone who wants can simply climb into one and drive it away for
free.

Customers come to this crossroads in throngs, day and night. Ninety percent
of them go straight to the biggest dealership and buy station wagons or
off-road vehicles. They do not even look at the other dealerships.

Of the remaining ten percent, most go and buy a sleek Euro-sedan, pausing
only to turn up their noses at the philistines going to buy the station
wagons and ORVs. If they even notice the people on the opposite side of the
road, selling the cheaper, technically superior vehicles, these customers
deride them cranks and half-wits.

The Batmobile outlet sells a few vehicles to the occasional car nut who
wants a second vehicle to go with his station wagon, but seems to accept, at
least for now, that it’s a fringe player.

The group giving away the free tanks only stays alive because it is staffed
by volunteers, who are lined up at the edge of the street with bullhorns,
trying to draw customers’ attention to this incredible situation. A typical
conversation goes something like this:

Hacker with bullhorn: “Save your money! Accept one of our free tanks! It is
invulnerable, and can drive across rocks and swamps at ninety miles an hour
while getting a hundred miles to the gallon!”

Prospective station wagon buyer: “I know what you say is true…but…er…I
don’t know how to maintain a tank!”

Bullhorn: “You don’t know how to maintain a station wagon either!”

Buyer: “But this dealership has mechanics on staff. If something goes wrong
with my station wagon, I can take a day off work, bring it here, and pay
them to work on it while I sit in the waiting room for hours, listening to
elevator music.”

Bullhorn: “But if you accept one of our free tanks we will send volunteers
to your house to fix it for free while you sleep!”

Buyer: “Stay away from my house, you freak!”

Bullhorn: “But…”

Buyer: “Can’t you see that everyone is buying station wagons?”


BIT-FLINGER


The connection between cars, and ways of interacting with computers,
wouldn’t have occurred to me at the time I was being taken for rides in that
MGB. I had signed up to take a computer programming class at Ames High
School. After a few introductory lectures, we students were granted
admission into a tiny room containing a teletype, a telephone, and an
old-fashioned modem consisting of a metal box with a pair of rubber cups on
the top (note: many readers, making their way through that last sentence,
probably felt an initial pang of dread that this essay was about to turn
into a tedious, codgerly reminiscence about how tough we had it back in the
old days; rest assured that I am actually positioning my pieces on the
chessboard, as it were, in preparation to make a point about truly hip and
up-to-the minute topics like Open Source Software). The teletype was exactly
the same sort of machine that had been used, for decades, to send and
receive telegrams. It was basically a loud typewriter that could only
produce UPPERCASE LETTERS. Mounted to one side of it was a smaller machine
with a long reel of paper tape on it, and a clear plastic hopper underneath.

In order to connect this device (which was not a computer at all) to the
Iowa State University mainframe across town, you would pick up the phone,
dial the computer’s number, listen for strange noises, and then slam the
handset down into the rubber cups. If your aim was true, one would wrap its
neoprene lips around the earpiece and the other around the mouthpiece,
consummating a kind of informational soixante-neuf. The teletype would
shudder as it was possessed by the spirit of the distant mainframe, and
begin to hammer out cryptic messages.

Since computer time was a scarce resource, we used a sort of batch
processing technique. Before dialing the phone, we would turn on the tape
puncher (a subsidiary machine bolted to the side of the teletype) and type
in our programs. Each time we depressed a key, the teletype would bash out a
letter on the paper in front of us, so we could read what we’d typed; but at
the same time it would convert the letter into a set of eight binary digits,
or bits, and punch a corresponding pattern of holes across the width of a
paper tape. The tiny disks of paper knocked out of the tape would flutter
down into the clear plastic hopper, which would slowly fill up what can only
be described as actual bits. On the last day of the school year, the
smartest kid in the class (not me) jumped out from behind his desk and flung
several quarts of these bits over the head of our teacher, like confetti, as
a sort of semi-affectionate practical joke. The image of this man sitting
there, gripped in the opening stages of an atavistic fight-or-flight
reaction, with millions of bits (megabytes) sifting down out of his hair and
into his nostrils and mouth, his face gradually turning purple as he built
up to an explosion, is the single most memorable scene from my formal
education.

Anyway, it will have been obvious that my interaction with the computer was
of an extremely formal nature, being sharply divided up into different
phases, viz.: (1) sitting at home with paper and pencil, miles and miles
from any computer, I would think very, very hard about what I wanted the
computer to do, and translate my intentions into a computer language–a
series of alphanumeric symbols on a page. (2) I would carry this across a
sort of informational cordon sanitaire (three miles of snowdrifts) to school
and type those letters into a machine–not a computer–which would convert
the symbols into binary numbers and record them visibly on a tape. (3) Then,
through the rubber-cup modem, I would cause those numbers to be sent to the
university mainframe, which would (4) do arithmetic on them and send
different numbers back to the teletype. (5) The teletype would convert these
numbers back into letters and hammer them out on a page and (6) I, watching,
would construe the letters as meaningful symbols.

The division of responsibilities implied by all of this is admirably clean:
computers do arithmetic on bits of information. Humans construe the bits as
meaningful symbols. But this distinction is now being blurred, or at least
complicated, by the advent of modern operating systems that use, and
frequently abuse, the power of metaphor to make computers accessible to a
larger audience. Along the way–possibly because of those metaphors, which
make an operating system a sort of work of art–people start to get
emotional, and grow attached to pieces of software in the way that my
friend’s dad did to his MGB.

People who have only interacted with computers through graphical user
interfaces like the MacOS or Windows–which is to say, almost everyone who
has ever used a computer–may have been startled, or at least bemused, to
hear about the telegraph machine that I used to communicate with a computer
in 1973. But there was, and is, a good reason for using this particular kind
of technology. Human beings have various ways of communicating to each
other, such as music, art, dance, and facial expressions, but some of these
are more amenable than others to being expressed as strings of symbols.
Written language is the easiest of all, because, of course, it consists of
strings of symbols to begin with. If the symbols happen to belong to a
phonetic alphabet (as opposed to, say, ideograms), converting them into bits
is a trivial procedure, and one that was nailed, technologically, in the
early nineteenth century, with the introduction of Morse code and other
forms of telegraphy.

We had a human/computer interface a hundred years before we had computers.
When computers came into being around the time of the Second World War,
humans, quite naturally, communicated with them by simply grafting them on
to the already-existing technologies for translating letters into bits and
vice versa: teletypes and punch card machines.

These embodied two fundamentally different approaches to computing. When you
were using cards, you’d punch a whole stack of them and run them through the
reader all at once, which was called batch processing. You could also do
batch processing with a teletype, as I have already described, by using the
paper tape reader, and we were certainly encouraged to use this approach
when I was in high school. But–though efforts were made to keep us unaware
of this–the teletype could do something that the card reader could not. On
the teletype, once the modem link was established, you could just type in a
line and hit the return key. The teletype would send that line to the
computer, which might or might not respond with some lines of its own, which
the teletype would hammer out–producing, over time, a transcript of your
exchange with the machine. This way of doing it did not even have a name at
the time, but when, much later, an alternative became available, it was
retroactively dubbed the Command Line Interface.

When I moved on to college, I did my computing in large, stifling rooms
where scores of students would sit in front of slightly updated versions of
the same machines and write computer programs: these used dot-matrix
printing mechanisms, but were (from the computer’s point of view) identical
to the old teletypes. By that point, computers were better at
time-sharing–that is, mainframes were still mainframes, but they were
better at communicating with a large number of terminals at once.
Consequently, it was no longer necessary to use batch processing. Card
readers were shoved out into hallways and boiler rooms, and batch processing
became a nerds-only kind of thing, and consequently took on a certain
eldritch flavor among those of us who even knew it existed. We were all off
the Batch, and on the Command Line, interface now–my very first shift in
operating system paradigms, if only I’d known it.

A huge stack of accordion-fold paper sat on the floor underneath each one of
these glorified teletypes, and miles of paper shuddered through their
platens. Almost all of this paper was thrown away or recycled without ever
having been touched by ink–an ecological atrocity so glaring that those
machines soon replaced by video terminals–so-called “glass
teletypes”–which were quieter and didn’t waste paper. Again, though, from
the computer’s point of view these were indistinguishable from World War
II-era teletype machines. In effect we still used Victorian technology to
communicate with computers until about 1984, when the Macintosh was
introduced with its Graphical User Interface. Even after that, the Command
Line continued to exist as an underlying stratum–a sort of brainstem
reflex–of many modern computer systems all through the heyday of Graphical
User Interfaces, or GUIs as I will call them from now on.


GUIs


Now the first job that any coder needs to do when writing a new piece of
software is to figure out how to take the information that is being worked
with (in a graphics program, an image; in a spreadsheet, a grid of numbers)
and turn it into a linear string of bytes. These strings of bytes are
commonly called files or (somewhat more hiply) streams. They are to
telegrams what modern humans are to Cro-Magnon man, which is to say the same
thing under a different name. All that you see on your computer screen–your
Tomb Raider, your digitized voice mail messages, faxes, and word processing
documents written in thirty-seven different typefaces–is still, from the
computer’s point of view, just like telegrams, except much longer, and
demanding of more arithmetic.

The quickest way to get a taste of this is to fire up your web browser,
visit a site, and then select the View/Document Source menu item. You will
get a bunch of computer code that looks something like this:

C R Y P T O N O M I C O N \ \

This crud is called HTML (HyperText Markup Language) and it is basically a
very simple programming language instructing your web browser how to draw a
page on a screen. Anyone can learn HTML and many people do. The important
thing is that no matter what splendid multimedia web pages they might
represent, HTML files are just telegrams.

When Ronald Reagan was a radio announcer, he used to call baseball games by
reading the terse descriptions that trickled in over the telegraph wire and
were printed out on a paper tape. He would sit there, all by himself in a
padded room with a microphone, and the paper tape would eke out of the
machine and crawl over the palm of his hand printed with cryptic
abbreviations. If the count went to three and two, Reagan would describe the
scene as he saw it in his mind’s eye: “The brawny left-hander steps out of
the batter’s box to wipe the sweat from his brow. The umpire steps forward
to sweep the dirt from home plate.” and so on. When the cryptogram on the
paper tape announced a base hit, he would whack the edge of the table with a
pencil, creating a little sound effect, and describe the arc of the ball as
if he could actually see it. His listeners, many of whom presumably thought
that Reagan was actually at the ballpark watching the game, would
reconstruct the scene in their minds according to his descriptions.

This is exactly how the World Wide Web works: the HTML files are the pithy
description on the paper tape, and your Web browser is Ronald Reagan. The
same is true of Graphical User Interfaces in general.

So an OS is a stack of metaphors and abstractions that stands between you
and the telegrams, and embodying various tricks the programmer used to
convert the information you’re working with–be it images, e-mail messages,
movies, or word processing documents–into the necklaces of bytes that are
the only things computers know how to work with. When we used actual
telegraph equipment (teletypes) or their higher-tech substitutes (“glass
teletypes,” or the MS-DOS command line) to work with our computers, we were
very close to the bottom of that stack. When we use most modern operating
systems, though, our interaction with the machine is heavily mediated.
Everything we do is interpreted and translated time and again as it works
its way down through all of the metaphors and abstractions.

The Macintosh OS was a revolution in both the good and bad senses of that
word. Obviously it was true that command line interfaces were not for
everyone, and that it would be a good thing to make computers more
accessible to a less technical audience–if not for altruistic reasons, then
because those sorts of people constituted an incomparably vaster market. It
was clear the the Mac’s engineers saw a whole new country stretching out
before them; you could almost hear them muttering, “Wow! We don’t have to be
bound by files as linear streams of bytes anymore, vive la revolution, let’s
see how far we can take this!” No command line interface was available on
the Macintosh; you talked to it with the mouse, or not at all. This was a
statement of sorts, a credential of revolutionary purity. It seemed that the
designers of the Mac intended to sweep Command Line Interfaces into the
dustbin of history.

My own personal love affair with the Macintosh began in the spring of 1984
in a computer store in Cedar Rapids, Iowa, when a friend of
mine–coincidentally, the son of the MGB owner–showed me a Macintosh
running MacPaint, the revolutionary drawing program. It ended in July of
1995 when I tried to save a big important file on my Macintosh Powerbook and
instead instead of doing so, it annihilated the data so thoroughly that two
different disk crash utility programs were unable to find any trace that it
had ever existed. During the intervening ten years, I had a passion for the
MacOS that seemed righteous and reasonable at the time but in retrospect
strikes me as being exactly the same sort of goofy infatuation that my
friend’s dad had with his car.

The introduction of the Mac triggered a sort of holy war in the computer
world. Were GUIs a brilliant design innovation that made computers more
human-centered and therefore accessible to the masses, leading us toward an
unprecedented revolution in human society, or an insulting bit of
audiovisual gimcrackery dreamed up by flaky Bay Area hacker types that
stripped computers of their power and flexibility and turned the noble and
serious work of computing into a childish video game?

This debate actually seems more interesting to me today than it did in the
mid-1980s. But people more or less stopped debating it when Microsoft
endorsed the idea of GUIs by coming out with the first Windows. At this
point, command-line partisans were relegated to the status of silly old
grouches, and a new conflict was touched off, between users of MacOS and
users of Windows.

There was plenty to argue about. The first Macintoshes looked different from
other PCs even when they were turned off: they consisted of one box
containing both CPU (the part of the computer that does arithmetic on bits)
and monitor screen. This was billed, at the time, as a philosophical
statement of sorts: Apple wanted to make the personal computer into an
appliance, like a toaster. But it also reflected the purely technical
demands of running a graphical user interface. In a GUI machine, the chips
that draw things on the screen have to be integrated with the computer’s
central processing unit, or CPU, to a far greater extent than is the case
with command-line interfaces, which until recently didn’t even know that
they weren’t just talking to teletypes.

This distinction was of a technical and abstract nature, but it became
clearer when the machine crashed (it is commonly the case with technologies
that you can get the best insight about how they work by watching them
fail). When everything went to hell and the CPU began spewing out random
bits, the result, on a CLI machine, was lines and lines of perfectly formed
but random characters on the screen–known to cognoscenti as “going
Cyrillic.” But to the MacOS, the screen was not a teletype, but a place to
put graphics; the image on the screen was a bitmap, a literal rendering of
the contents of a particular portion of the computer’s memory. When the
computer crashed and wrote gibberish into the bitmap, the result was
something that looked vaguely like static on a broken television set–a
“snow crash.”

And even after the introduction of Windows, the underlying differences
endured; when a Windows machine got into trouble, the old command-line
interface would fall down over the GUI like an asbestos fire curtain sealing
off the proscenium of a burning opera. When a Macintosh got into trouble it
presented you with a cartoon of a bomb, which was funny the first time you
saw it.

And these were by no means superficial differences. The reversion of Windows
to a CLI when it was in distress proved to Mac partisans that Windows was
nothing more than a cheap facade, like a garish afghan flung over a
rotted-out sofa. They were disturbed and annoyed by the sense that lurking
underneath Windows’ ostensibly user-friendly interface was–literally–a
subtext.

For their part, Windows fans might have made the sour observation that all
computers, even Macintoshes, were built on that same subtext, and that the
refusal of Mac owners to admit that fact to themselves seemed to signal a
willingness, almost an eagerness, to be duped.

Anyway, a Macintosh had to switch individual bits in the memory chips on the
video card, and it had to do it very fast, and in arbitrarily complicated
patterns. Nowadays this is cheap and easy, but in the technological regime
that prevailed in the early 1980s, the only realistic way to do it was to
build the motherboard (which contained the CPU) and the video system (which
contained the memory that was mapped onto the screen) as a tightly
integrated whole–hence the single, hermetically sealed case that made the
Macintosh so distinctive.

When Windows came out, it was conspicuous for its ugliness, and its current
successors, Windows 95 and Windows NT, are not things that people would pay
money to look at either. Microsoft’s complete disregard for aesthetics gave
all of us Mac-lovers plenty of opportunities to look down our noses at them.
That Windows looked an awful lot like a direct ripoff of MacOS gave us a
burning sense of moral outrage to go with it. Among people who really knew
and appreciated computers (hackers, in Steven Levy’s non-pejorative sense of
that word) and in a few other niches such as professional musicians, graphic
artists and schoolteachers, the Macintosh, for a while, was simply the
computer. It was seen as not only a superb piece of engineering, but an
embodiment of certain ideals about the use of technology to benefit mankind,
while Windows was seen as a pathetically clumsy imitation and a sinister
world domination plot rolled into one. So very early, a pattern had been
established that endures to this day: people dislike Microsoft, which is
okay; but they dislike it for reasons that are poorly considered, and in the
end, self-defeating.


CLASS STRUGGLE ON THE DESKTOP

Now that the Third Rail has been firmly grasped, it is worth reviewing some
basic facts here: like any other publicly traded, for-profit corporation,
Microsoft has, in effect, borrowed a bunch of money from some people (its
stockholders) in order to be in the bit business. As an officer of that
corporation, Bill Gates has one responsibility only, which is to maximize
return on investment. He has done this incredibly well. Any actions taken in
the world by Microsoft-any software released by them, for example–are
basically epiphenomena, which can’t be interpreted or understood except
insofar as they reflect Bill Gates’s execution of his one and only
responsibility.

It follows that if Microsoft sells goods that are aesthetically unappealing,
or that don’t work very well, it does not mean that they are (respectively)
philistines or half-wits. It is because Microsoft’s excellent management has
figured out that they can make more money for their stockholders by
releasing stuff with obvious, known imperfections than they can by making it
beautiful or bug-free. This is annoying, but (in the end) not half so
annoying as watching Apple inscrutably and relentlessly destroy itself.

Hostility towards Microsoft is not difficult to find on the Net, and it
blends two strains: resentful people who feel Microsoft is too powerful, and
disdainful people who think it’s tacky. This is all strongly reminiscent of
the heyday of Communism and Socialism, when the bourgeoisie were hated from
both ends: by the proles, because they had all the money, and by the
intelligentsia, because of their tendency to spend it on lawn ornaments.
Microsoft is the very embodiment of modern high-tech prosperity–it is, in a
word, bourgeois–and so it attracts all of the same gripes.

The opening “splash screen” for Microsoft Word 6.0 summed it up pretty
neatly: when you started up the program you were treated to a picture of an
expensive enamel pen lying across a couple of sheets of fancy-looking
handmade writing paper. It was obviously a bid to make the software look
classy, and it might have worked for some, but it failed for me, because the
pen was a ballpoint, and I’m a fountain pen man. If Apple had done it, they
would’ve used a Mont Blanc fountain pen, or maybe a Chinese calligraphy
brush. And I doubt that this was an accident. Recently I spent a while
re-installing Windows NT on one of my home computers, and many times had to
double-click on the “Control Panel” icon. For reasons that are difficult to
fathom, this icon consists of a picture of a clawhammer and a chisel or
screwdriver resting on top of a file folder.

These aesthetic gaffes give one an almost uncontrollable urge to make fun of
Microsoft, but again, it is all beside the point–if Microsoft had done
focus group testing of possible alternative graphics, they probably would
have found that the average mid-level office worker associated fountain pens
with effete upper management toffs and was more comfortable with ballpoints.
Likewise, the regular guys, the balding dads of the world who probably bear
the brunt of setting up and maintaining home computers, can probably relate
better to a picture of a clawhammer–while perhaps harboring fantasies of
taking a real one to their balky computers.

This is the only way I can explain certain peculiar facts about the current
market for operating systems, such as that ninety percent of all customers
continue to buy station wagons off the Microsoft lot while free tanks are
there for the taking, right across the street.

A string of ones and zeroes was not a difficult thing for Bill Gates to
distribute, one he’d thought of the idea. The hard part was selling
it–reassuring customers that they were actually getting something in return
for their money.

Anyone who has ever bought a piece of software in a store has had the
curiously deflating experience of taking the bright shrink-wrapped box home,
tearing it open, finding that it’s 95 percent air, throwing away all the
little cards, party favors, and bits of trash, and loading the disk into the
computer. The end result (after you’ve lost the disk) is nothing except some
images on a computer screen, and some capabilities that weren’t there
before. Sometimes you don’t even have that–you have a string of error
messages instead. But your money is definitely gone. Now we are almost
accustomed to this, but twenty years ago it was a very dicey business
proposition. Bill Gates made it work anyway. He didn’t make it work by
selling the best software or offering the cheapest price. Instead he somehow
got people to believe that they were receiving something in exchange for
their money.

The streets of every city in the world are filled with those hulking,
rattling station wagons. Anyone who doesn’t own one feels a little weird,
and wonders, in spite of himself, whether it might not be time to cease
resistance and buy one; anyone who does, feels confident that he has
acquired some meaningful possession, even on those days when the vehicle is
up on a lift in an auto repair shop.

All of this is perfectly congruent with membership in the bourgeoisie, which
is as much a mental, as a material state. And it explains why Microsoft is
regularly attacked, on the Net, from both sides. People who are inclined to
feel poor and oppressed construe everything Microsoft does as some sinister
Orwellian plot. People who like to think of themselves as intelligent and
informed technology users are driven crazy by the clunkiness of Windows.

Nothing is more annoying to sophisticated people to see someone who is rich
enough to know better being tacky–unless it is to realize, a moment later,
that they probably know they are tacky and they simply don’t care and they
are going to go on being tacky, and rich, and happy, forever. Microsoft
therefore bears the same relationship to the Silicon Valley elite as the
Beverly Hillbillies did to their fussy banker, Mr. Drysdale–who is
irritated not so much by the fact that the Clampetts moved to his
neighborhood as by the knowledge that, when Jethro is seventy years old,
he’s still going to be talking like a hillbilly and wearing bib overalls,
and he’s still going to be a lot richer than Mr. Drysdale.

Even the hardware that Windows ran on, when compared to the machines put out
by Apple, looked like white-trash stuff, and still mostly does. The reason
was that Apple was and is a hardware company, while Microsoft was and is a
software company. Apple therefore had a monopoly on hardware that could run
MacOS, whereas Windows-compatible hardware came out of a free market. The
free market seems to have decided that people will not pay for cool-looking
computers; PC hardware makers who hire designers to make their stuff look
distinctive get their clocks cleaned by Taiwanese clone makers punching out
boxes that look as if they belong on cinderblocks in front of someone’s
trailer. But Apple could make their hardware as pretty as they wanted to and
simply pass the higher prices on to their besotted consumers, like me. Only
last week (I am writing this sentence in early Jan. 1999) the technology
sections of all the newspapers were filled with adulatory press coverage of
how Apple had released the iMac in several happenin’ new colors like
Blueberry and Tangerine.

Apple has always insisted on having a hardware monopoly, except for a brief
period in the mid-1990s when they allowed clone-makers to compete with them,
before subsequently putting them out of business. Macintosh hardware was,
consequently, expensive. You didn’t open it up and fool around with it
because doing so would void the warranty. In fact the first Mac was
specifically designed to be difficult to open–you needed a kit of exotic
tools, which you could buy through little ads that began to appear in the
back pages of magazines a few months after the Mac came out on the market.
These ads always had a certain disreputable air about them, like pitches for
lock-picking tools in the backs of lurid detective magazines.

This monopolistic policy can be explained in at least three different ways.

THE CHARITABLE EXPLANATION is that the hardware monopoly policy reflected a
drive on Apple’s part to provide a seamless, unified blending of hardware,
operating system, and software. There is something to this. It is hard
enough to make an OS that works well on one specific piece of hardware,
designed and tested by engineers who work down the hallway from you, in the
same company. Making an OS to work on arbitrary pieces of hardware, cranked
out by rabidly entrepeneurial clonemakers on the other side of the
International Date Line, is very difficult, and accounts for much of the
troubles people have using Windows.

THE FINANCIAL EXPLANATION is that Apple, unlike Microsoft, is and always has
been a hardware company. It simply depends on revenue from selling hardware,
and cannot exist without it.

THE NOT-SO-CHARITABLE EXPLANATION has to do with Apple’s corporate culture,
which is rooted in Bay Area Baby Boomdom.

Now, since I’m going to talk for a moment about culture, full disclosure is
probably in order, to protect myself against allegations of conflict of
interest and ethical turpitude: (1) Geographically I am a Seattleite, of a
Saturnine temperament, and inclined to take a sour view of the Dionysian Bay
Area, just as they tend to be annoyed and appalled by us. (2)
Chronologically I am a post-Baby Boomer. I feel that way, at least, because
I never experienced the fun and exciting parts of the whole Boomer
scene–just spent a lot of time dutifully chuckling at Boomers’ maddeningly
pointless anecdotes about just how stoned they got on various occasions, and
politely fielding their assertions about how great their music was. But even
from this remove it was possible to glean certain patterns, and one that
recurred as regularly as an urban legend was the one about how someone would
move into a commune populated by sandal-wearing, peace-sign flashing flower
children, and eventually discover that, underneath this facade, the guys who
ran it were actually control freaks; and that, as living in a commune, where
much lip service was paid to ideals of peace, love and harmony, had deprived
them of normal, socially approved outlets for their control-freakdom, it
tended to come out in other, invariably more sinister, ways.

Applying this to the case of Apple Computer will be left as an exercise for
the reader, and not a very difficult exercise.

It is a bit unsettling, at first, to think of Apple as a control freak,
because it is completely at odds with their corporate image. Weren’t these
the guys who aired the famous Super Bowl ads showing suited, blindfolded
executives marching like lemmings off a cliff? Isn’t this the company that
even now runs ads picturing the Dalai Lama (except in Hong Kong) and
Einstein and other offbeat rebels?

It is indeed the same company, and the fact that they have been able to
plant this image of themselves as creative and rebellious free-thinkers in
the minds of so many intelligent and media-hardened skeptics really gives
one pause. It is testimony to the insidious power of expensive slick ad
campaigns and, perhaps, to a certain amount of wishful thinking in the minds
of people who fall for them. It also raises the question of why Microsoft is
so bad at PR, when the history of Apple demonstrates that, by writing large
checks to good ad agencies, you can plant a corporate image in the minds of
intelligent people that is completely at odds with reality. (The answer, for
people who don’t like Damoclean questions, is that since Microsoft has won
the hearts and minds of the silent majority–the bourgeoisie–they don’t
give a damn about having a slick image, any more then Dick Nixon did. “I
want to believe,”–the mantra that Fox Mulder has pinned to his office wall
in The X-Files–applies in different ways to these two companies; Mac
partisans want to believe in the image of Apple purveyed in those ads, and
in the notion that Macs are somehow fundamentally different from other
computers, while Windows people want to believe that they are getting
something for their money, engaging in a respectable business transaction).

In any event, as of 1987, both MacOS and Windows were out on the market,
running on hardware platforms that were radically different from each
other–not only in the sense that MacOS used Motorola CPU chips while
Windows used Intel, but in the sense–then overlooked, but in the long run,
vastly more significant–that the Apple hardware business was a rigid
monopoly and the Windows side was a churning free-for-all.

But the full ramifications of this did not become clear until very
recently–in fact, they are still unfolding, in remarkably strange ways, as
I’ll explain when we get to Linux. The upshot is that millions of people got
accustomed to using GUIs in one form or another. By doing so, they made
Apple/Microsoft a lot of money. The fortunes of many people have become
bound up with the ability of these companies to continue selling products
whose salability is very much open to question.


HONEY-POT, TAR-PIT, WHATEVER


When Gates and Allen invented the idea of selling software, they ran into
criticism from both hackers and sober-sided businesspeople. Hackers
understood that software was just information, and objected to the idea of
selling it. These objections were partly moral. The hackers were coming out
of the scientific and academic world where it is imperative to make the
results of one’s work freely available to the public. They were also partly
practical; how can you sell something that can be easily copied?
Businesspeople, who are polar opposites of hackers in so many ways, had
objections of their own. Accustomed to selling toasters and insurance
policies, they naturally had a difficult time understanding how a long
collection of ones and zeroes could constitute a salable product.

Obviously Microsoft prevailed over these objections, and so did Apple. But
the objections still exist. The most hackerish of all the hackers, the
Ur-hacker as it were, was and is Richard Stallman, who became so annoyed
with the evil practice of selling software that, in 1984 (the same year that
the Macintosh went on sale) he went off and founded something called the
Free Software Foundation, which commenced work on something called GNU. Gnu
is an acronym for Gnu’s Not Unix, but this is a joke in more ways than one,
because GNU most certainly IS Unix,. Because of trademark concerns (“Unix”
is trademarked by AT&T) they simply could not claim that it was Unix, and
so, just to be extra safe, they claimed that it wasn’t. Notwithstanding the
incomparable talent and drive possessed by Mr. Stallman and other GNU
adherents, their project to build a free Unix to compete against Microsoft
and Apple’s OSes was a little bit like trying to dig a subway system with a
teaspoon. Until, that is, the advent of Linux, which I will get to later.

But the basic idea of re-creating an operating system from scratch was
perfectly sound and completely doable. It has been done many times. It is
inherent in the very nature of operating systems.

Operating systems are not strictly necessary. There is no reason why a
sufficiently dedicated coder could not start from nothing with every project
and write fresh code to handle such basic, low-level operations as
controlling the read/write heads on the disk drives and lighting up pixels
on the screen. The very first computers had to be programmed in this way.
But since nearly every program needs to carry out those same basic
operations, this approach would lead to vast duplication of effort.

Nothing is more disagreeable to the hacker than duplication of effort. The
first and most important mental habit that people develop when they learn
how to write computer programs is to generalize, generalize, generalize. To
make their code as modular and flexible as possible, breaking large problems
down into small subroutines that can be used over and over again in
different contexts. Consequently, the development of operating systems,
despite being technically unnecessary, was inevitable. Because at its heart,
an operating system is nothing more than a library containing the most
commonly used code, written once (and hopefully written well) and then made
available to every coder who needs it.

So a proprietary, closed, secret operating system is a contradiction in
terms. It goes against the whole point of having an operating system. And it
is impossible to keep them secret anyway. The source code–the original
lines of text written by the programmers–can be kept secret. But an OS as a
whole is a collection of small subroutines that do very specific, very
clearly defined jobs. Exactly what those subroutines do has to be made
public, quite explicitly and exactly, or else the OS is completely useless
to programmers; they can’t make use of those subroutines if they don’t have
a complete and perfect understanding of what the subroutines do.

The only thing that isn’t made public is exactly how the subroutines do what
they do. But once you know what a subroutine does, it’s generally quite easy
(if you are a hacker) to write one of your own that does exactly the same
thing. It might take a while, and it is tedious and unrewarding, but in most
cases it’s not really hard.

What’s hard, in hacking as in fiction, is not writing; it’s deciding what to
write. And the vendors of commercial OSes have already decided, and
published their decisions.

This has been generally understood for a long time. MS-DOS was duplicated,
functionally, by a rival product, written from scratch, called ProDOS, that
did all of the same things in pretty much the same way. In other words,
another company was able to write code that did all of the same things as
MS-DOS and sell it at a profit. If you are using the Linux OS, you can get a
free program called WINE which is a windows emulator; that is, you can open
up a window on your desktop that runs windows programs. It means that a
completely functional Windows OS has been recreated inside of Unix, like a
ship in a bottle. And Unix itself, which is vastly more sophisticated than
MS-DOS, has been built up from scratch many times over. Versions of it are
sold by Sun, Hewlett-Packard, AT&T, Silicon Graphics, IBM, and others.

People have, in other words, been re-writing basic OS code for so long that
all of the technology that constituted an “operating system” in the
traditional (pre-GUI) sense of that phrase is now so cheap and common that
it’s literally free. Not only could Gates and Allen not sell MS-DOS today,
they could not even give it away, because much more powerful OSes are
already being given away. Even the original Windows (which was the only
windows until 1995) has become worthless, in that there is no point in
owning something that can be emulated inside of Linux–which is, itself,
free.

In this way the OS business is very different from, say, the car business.
Even an old rundown car has some value. You can use it for making runs to
the dump, or strip it for parts. It is the fate of manufactured goods to
slowly and gently depreciate as they get old and have to compete against
more modern products.

But it is the fate of operating systems to become free.

Microsoft is a great software applications company. Applications–such as
Microsoft Word–are an area where innovation brings real, direct, tangible
benefits to users. The innovations might be new technology straight from the
research department, or they might be in the category of bells and whistles,
but in any event they are frequently useful and they seem to make users
happy. And Microsoft is in the process of becoming a great research company.
But Microsoft is not such a great operating systems company. And this is not
necessarily because their operating systems are all that bad from a purely
technological standpoint. Microsoft’s OSes do have their problems, sure, but
they are vastly better than they used to be, and they are adequate for most
people.

Why, then, do I say that Microsoft is not such a great operating systems
company? Because the very nature of operating systems is such that it is
senseless for them to be developed and owned by a specific company. It’s a
thankless job to begin with. Applications create possibilities for millions
of credulous users, whereas OSes impose limitations on thousands of grumpy
coders, and so OS-makers will forever be on the shit-list of anyone who
counts for anything in the high-tech world. Applications get used by people
whose big problem is un

Cryptonomincon by Neal
Stephenson

GREAT TRUTHS ABOUT LIFE THAT LITTLE CHILDREN HAVE LEARNED:

  1. No matter how hard you try, you can’t baptize cats.

  2. When your Mom is mad at your Dad, don’t let her brush your hair.

  3. If your sister hits you, don’t hit her back. They always catch the

second person.

  1. Never ask your 3-year old brother to hold a tomato.

  2. You can’t trust dogs to watch your food.

  3. Don’t sneeze when someone is cutting your hair.

  4. Never hold a Dust-Buster and a cat at the same time.

:sunglasses: You can’t hide a piece of broccoli in a glass of milk.

  1. Don’t wear polka-dot underwear under white shorts.

  2. The best place to be when you’re sad is Grandpa’s lap.



    GREAT TRUTHS ABOUT LIFE, THAT ADULTS HAVE LEARNED:

  3. Raising teenagers is like nailing Jell-O to a tree.

  4. Wrinkles don’t hurt.

  5. Families are like fudge . . .mostly sweet, with a few nuts.

  6. Today’s mighty oak is just yesterday’s nut that held its ground.

  7. Laughing is good exercise. It’s like jogging on the inside.

  8. Middle age is when you choose your cereal for the fibre, not the toy.

GREAT TRUTHS ABOUT GROWING OLD

  1. Growing old is mandatory; growing up is optional.

  2. Forget the health food. I need all the preservatives I can get.

  3. When you fall down, you wonder what else you can do while you’re down

there.

  1. You’re getting old when you get the same sensation from a rocking

chair that you once got from a roller coaster.

  1. It’s frustrating when you know all the answers, but nobody bothers to

ask you the questions.

  1. Time may be a great healer, but it’s a lousy beautician.

  2. Wisdom comes with age, but sometimes age comes alone.

THE FOUR STAGES OF LIFE:

  1. You believe in Santa Claus

  2. You don’t believe in Santa Claus.

  3. You are Santa Claus

  4. You look like Santa Claus.

Here is one that is more technical :wink:

% cat “food in cans”

cat: can’t open food in cans

% nice man woman

No manual entry for woman.

% rm God

rm: God nonexistent

% ar t God

ar: God does not exist]

% ar r God

ar: creating God

% "How would you rate Quayle’s incompetence?

Unmatched ".

% [Where is Jimmy Hoffa?

Missing ].

% ^How did the sex change operation go? ^

Modifier failed.

% If I had a ( for every $ the Congress spent, what

would I have?

Too many ('s.

% make love

Make: Don’t know how to make love. Stop.

% sleep with me

bad character

% got a light?

No match.

% man: why did you get a divorce? man::

Too many arguments.

% !:say, what is saccharine?

Bad substitute.

% %blow

%blow: No such job.

$ PATH=3Dpretending!/usr/ucb/which sense

no sense in pretending!

OK … this is the last one … honest :wink:

English is tough stuff

Multi-national personnel at North Atlantic Treaty Organization headquarters

near Paris found English to be an easy language … until they tried to

pronounce it. To help them discard an array of accents, the verses below

were devised. After trying them, a Frenchman said he’d prefer six months at

hard labor to reading six lines aloud. Try them yourself.

ENGLISH IS TOUGH STUFF

======================

Dearest creature in creation,

Study English pronunciation.

I will teach you in my verse

Sounds like corpse, corps, horse, and worse.

I will keep you, Suzy, busy,

Make your head with heat grow dizzy.

Tear in eye, your dress will tear.

So shall I! Oh hear my prayer.

Just compare heart, beard, and heard,

Dies and diet, lord and word,

Sword and sward, retain and Britain.

(Mind the latter, how it’s written.)

Now I surely will not plague you

With such words as plaque and ague.

But be careful how you speak:

Say break and steak, but bleak and streak;

Cloven, oven, how and low,

Script, receipt, show, poem, and toe.

Hear me say, devoid of trickery,

Daughter, laughter, and Terpsichore,

Typhoid, measles, topsails, aisles,

Exiles, similes, and reviles;

Scholar, vicar, and cigar,

Solar, mica, war and far;

One, anemone, Balmoral,

Kitchen, lichen, laundry, laurel;

Gertrude, German, wind and mind,

Scene, Melpomene, mankind.

Billet does not rhyme with ballet,

Bouquet, wallet, mallet, chalet.

Blood and flood are not like food,

Nor is mould like should and would.

Viscous, viscount, load and broad,

Toward, to forward, to reward.

And your pronunciation’s OK

When you correctly say croquet,

Rounded, wounded, grieve and sieve,

Friend and fiend, alive and live.

Ivy, privy, famous; clamour

And enamour rhyme with hammer.

River, rival, tomb, bomb, comb,

Doll and roll and some and home.

Stranger does not rhyme with anger,

Neither does devour with clangour.

Souls but foul, haunt but aunt,

Font, front, wont, want, grand, and grant,

Shoes, goes, does. Now first say finger,

And then singer, ginger, linger,

Real, zeal, mauve, gauze, gouge and gauge,

Marriage, foliage, mirage, and age.

Query does not rhyme with very,

Nor does fury sound like bury.

Dost, lost, post and doth, cloth, loth.

Job, nob, bosom, transom, oath.

Though the differences seem little,

We say actual but victual.

Refer does not rhyme with deafer.

Foeffer does, and zephyr, heifer.

Mint, pint, senate and sedate;

Dull, bull, and George ate late.

Scenic, Arabic, Pacific,

Science, conscience, scientific.

Liberty, library, heave and heaven,

Rachel, ache, moustache, eleven.

We say hallowed, but allowed,

People, leopard, towed, but vowed.

Mark the differences, moreover,

Between mover, cover, clover;

Leeches, breeches, wise, precise,

Chalice, but police and lice;

Camel, constable, unstable,

Principle, disciple, label.

Petal, panel, and canal,

Wait, surprise, plait, promise, pal.

Worm and storm, chaise, chaos, chair,

Senator, spectator, mayor.

Tour, but our and succour, four.

Gas, alas, and Arkansas.

Sea, idea, Korea, area,

Psalm, Maria, but malaria.

Youth, south, southern, cleanse and clean.

Doctrine, turpentine, marine.

Compare alien with Italian,

Dandelion and battalion.

Sally with ally, yea, ye,

Eye, I, ay, aye, whey, and key.

Say aver, but ever, fever,

Neither, leisure, skein, deceiver.

Heron, granary, canary.

Crevice and device and aerie.

Face, but preface, not efface.

Phlegm, phlegmatic, ass, glass, bass.

Large, but target, gin, give, verging,

Ought, out, joust and scour, scourging.

Ear, but earn and wear and tear

Do not rhyme with here but ere.

Seven is right, but so is even,

Hyphen, roughen, nephew Stephen,

Monkey, donkey, Turk and jerk,

Ask, grasp, wasp, and cork and work.

Pronunciation – think of Psyche!

Is a paling stout and spikey?

Won’t it make you lose your wits,

Writing groats and saying grits?

It’s a dark abyss or tunnel:

Strewn with stones, stowed, solace, gunwale,

Islington and Isle of Wight,

Housewife, verdict and indict.

Finally, which rhymes with enough –

Though, through, plough, or dough, or cough?

Hiccough has the sound of cup.

My advice is to give up!!!

Author Unknown

That is just marvelous :slight_smile:
Keep it up Kris, this soon will be the last remaining NG at QNX that is
still interesting to read :wink:

Kris Warkentin wrote:

The Tao Of Programming
The deep mysteries and the path of programming as explained by the masters.



The Tao Of Programming
Translated By Geoffrey James
Table of Contents
Book 1 – The Silent Void
Book 2 – The Ancient Masters
Book 3 – Design
Book 4 – Coding
Book 5 – Maintenance
Book 6 – Management
Book 7 – Corporate Wisdom
Book 8 – Hardware and Software
Book 9 – Epilogue



The Silent Void
Book One
Thus spake the master programmer:
“When you have learned to snatch the error code from the trap frame, it will
be
time for you to leave.”
1.1
Something mysterious is formed, born in the silent void. Waiting alone and
unmoving, it is at once still and yet in constant motion. It is the source
of
all programs. I do not know its name, so I will call it the Tao of
Programming.
If the Tao is great, then the operating system is great. If the operating
system
is great, then the compiler is great. If the compiler is great, then the
application is great. The user is pleased and there is harmony in the world.
The Tao of Programming flows far away and returns on the wind of morning.
1.2
The Tao gave birth to machine language. Machine language gave birth to the
assembler.
The assembler gave birth to the compiler. Now there are ten thousand
languages.
Each language has its purpose, however humble. Each language expresses the
Yin
and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
1.3
In the beginning was the Tao. The Tao gave birth to Space and Time.
Therefore
Space and Time are Yin and Yang of programming.
Programmers that do not comprehend the Tao are always running out of time
and
space for their programs. Programmers that comprehend the Tao always have
enough
time and space to accomplish their goals.
How could it be otherwise?
1.4
The wise programmer is told about Tao and follows it. The average programmer
is
told about Tao and searches for it. The foolish programmer is told about Tao
and
laughs at it.
If it were not for laughter, there would be no Tao.
The highest sounds are hardest to hear. Going forward is a way to retreat.
Great
talent shows itself late in life. Even a perfect program still has bugs.



The Ancient Masters
Book Two
Thus Spake the Master Programmer:
“After three days without programming, life becomes meaningless.”
2.1
The programmers of old were mysterious and profound. We cannot fathom their
thoughts, so all we do is describe their appearance.
Aware, like a fox crossing the water. Alert, like a general on the
battlefield.
Kind, like a hostess greeting her guests. Simple, like uncarved blocks of
wood.
Opaque, like black pools in darkened caves.
Who can tell the secrets of their hearts and minds?
The answer exists only in Tao.
2.2
Grand Master Turing once dreamed that he was a machine. When he awoke he
exclaimed:
“I don’t know whether I am Turing dreaming that I am a machine, or a machine
dreaming that I am Turing!.”
2.3
A programmer from a very large computer company went to a software
conference
and then returned to report to his manager, saying: “What sort of
programmers
work for other companies? They behaved badly and were unconcerned with
appearances. Their hair was long and unkept and their clothes were wrinkled
and
old. They crashed out hospitality suite and they made rude noises during my
presentation.”
The manager said: “I should have never sent you to the conference. Those
programmers live beyond the physical world. They consider life absurd, an
accidental coincidence. They come and go without knowing limitations.
Without a
care, they live only for their programs. Why should they bother with social
conventions?
They are alive within the Tao.”
2.4
A novice asked the Master: “Here is a programmer that never designs,
documents
or tests his programs. Yet all who know him consider him one of the best
programmer in the world. Why is this?”
The Master replies: “That programmer has mastered the Tao. He has gone
beyond
the need for design; he does not become angry when the system crashes, but
accepts the universe without concern. He has gone beyond the need for
documentation; he no longer cares if anyone else sees his code. He has gone
beyond the need for testing; each of his programs are perfect within
themselves,
serene and elegant, their purpose self-evident. Truly, he has entered the
mystery of Tao.”



Design
Book Three
Thus spake the Master Programmer:
“When the program is being tested, it is too late to make design changes.”
3.1
There once was a man who went to a computer trade show. Each day as he
entered,
the man told the guard at the door:
“I am a great thief, renowned for my feats of shoplifting. Be forewarned,
for
this trade show shall not escape unplundered.”
This speech disturbed the guard greatly, because there were millions of
dollars
of computer equipment inside, so he watched the man carefully. But the man
merely wandered from booth to booth, humming quietly to himself.
When the man left, the guard took him aside and searched his clothes, but
nothing was to be found.
On the next day of the trade show, the man returned and chided the guard
saying:
“I escaped with a vast booty yesterday, but today will be even better.” So
the
guard watched him ever more closely, but to no avail.
On the final day of the trade show, the guard could restrain his curiosity
no
longer. “Sir Thief,” he said, “I am so perplexed, I cannot live in peace.
Please
enlighten me. What is it that you are stealing?”
The man smiled. “I am stealing ideas,” he said.
3.2
There once was a master programmer who wrote unstructured programs. A novice
programmer, seeking to imitate him, also began to write unstructured
programs.
When the novice asked the master to evaluate his progress, the master
criticized
him for writing unstructured programs, saying “What is appropriate for the
master is not appropriate for the novice. You must understand Tao before
transcending structure.”
3.3
There was once a programmer who was attached to the court of the warlord of
Wu.
The warlord asked the programmer: “Which is easier to design: an accounting
package or an operating system?”
“An operating system,” replied the programmer.
The warlord uttered an exclamation of disbelief. “Surely an accounting
package
is trivial next to the complexity of an operating system,” he said.
“Not so,” said the programmer, “when designing an accounting package, the
programmer operates as a mediator between people having different ideas: how
it
must operate, how its reports must appear, and how it must conform to the
tax
laws. By contrast, an operating system is not limited by outside
appearances.
When designing an operating system, the programmer seeks the simplest
harmony
between machine and ideas. This is why an operating system is easier to
design.”

The warlord of Wu nodded and smiled. “That is all good and well, but which
is
easier to debug?”
The programmer made no reply.
3.4
A manager went to the master programmer and showed him the requirements
document
for a new application. The manager asked the master: “How long will it take
to
design this system if I assign five programmers to it?”
“It will take one year,” said the master promptly.
“But we need this system immediately or even sooner! How long will it take
if I
assign ten programmers to it?”
The master programmer frowned. “In that case, it will take two years.”
“And what if I assign a hundred programmers to it?”
The master programmer shrugged. “Then the design will never be completed,”
he
said.



Coding
Book Four
Thus spake the master programmer:
“A well-written program is its own heaven;
a poorly-written program is its own hell.”
4.1
A program should be light and agile, its subroutines connected like a string
of
pearls. The spirit and intent of the program should be retained throughout.
There should be neither too little or too much, neither needless loops nor
useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the ‘Law of Least Astonishment’. What is this law?
It is
simply that the program should always respond to the user in the way that
astonishes him least.
A program, no matter how complex, should act as a single unit. The program
should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of
disorder
and confusion. The only way to correct this is to rewrite the program.
4.2
A novice asked the master: “I have a program that sometime runs and
sometimes
aborts. I have followed the rules of programming, yet I am totally baffled.
What
is the reason for this?”
The master replied: “You are confused because you do not understand Tao.
Only a
fool expects rational behavior from his fellow humans. Why do you expect it
from
a machine that humans have constructed? Computers simulate determinism; only
Tao
is perfect.
The rules of programming are transitory; only Tao is eternal. Therefore you
must
contemplate Tao before you receive enlightenment.”
“But how will I know when I have received enlightenment?” asked the novice.
“Your program will then run correctly,” replied the master.
4.3
A master was explaining the nature of Tao of to one of his novices, “The Tao
is
embodied in all software – regardless of how insignificant,” said the
master.
“Is the Tao in a hand-held calculator?” asked the novice.
“It is,” came the reply.
“Is the Tao in a video game?” continued the novice.
“It is even in a video game,” said the master.
“And is the Tao in the DOS for a personal computer?”
The master coughed and shifted his position slightly. “The lesson is over
for
today,” he said.
4.4
Prince Wang’s programmer was coding software. His fingers danced upon the
keyboard. The program compiled without an error message, and the program ran
like a gentle wind.
“Excellent!” the Prince exclaimed, “Your technique is faultless!”
“Technique?” said the programmer turning from his terminal, “What I follow
is
Tao – beyond all techniques! When I first began to program I would see
before
me the whole problem in one mass. After three years I no longer saw this
mass.
Instead, I used subroutines. But now I see nothing. My whole being exists in
a
formless void. My senses are idle. My spirit, free to work without plan,
follows
its own instinct. In short, my program writes itself. True, sometimes there
are
difficult problems. I see them coming, I slow down, I watch silently. Then I
change a single line of code and the difficulties vanish like puffs of idle
smoke. I then compile the program. I sit still and let the joy of the work
fill
my being. I close my eyes for a moment and then log off.”
Prince Wang said, “Would that all of my programmers were as wise!”



Maintenance
Book Five
Thus spake the master programmer:
“Though a program be but three lines long, someday it will have to be
maintained.”
5.1
A well-used door needs no oil on its hinges. A swift-flowing stream does not
grow stagnant. Neither sound nor thoughts can travel through a vacuum.
Software
rots if not used.
These are great mysteries.
5.2
A manager asked a programmer how long it would take him to finish the
program on
which he was working. “I will be finished tomorrow,” the programmer promptly
replied.
“I think you are being unrealistic,” said the manager, “Truthfully, how long
will it take?”
The programmer thought for a moment. “I have some features that I wish to
add.
This will take at least two weeks,” he finally said.
“Even that is too much to expect,” insisted the manager, “I will be
satisfied if
you simply tell me when the program is complete.”
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement
lunch, he
discovered the programmer asleep at his terminal. He had been programming
all
night.
5.3
A novice programmer was once assigned to code a simple financial package.
The novice worked furiously for many days, but when his master reviewed his
program, he discovered that it contained a screen editor, a set of
generalized
graphics routines, an artificial intelligence interface, but not the
slightest
mention of anything financial.
When the master asked about this, the novice became indignant. “Don’t be so
impatient,” he said, " I’ll put in the financial stuff eventually."
5.1
Does a good farmer neglect a crop he has planted?
Does a good teacher overlook even the most humble student?
Does a good father allow a single child to starve?
Does a good programmer refuse to maintain his code?




Management
Book Six
Thus spake the master programmer:
“Let the programmer be many and the managers few – then all will be
productive.”
6.1
When managers hold endless meetings, the programmers write games. When
accountants talk of quarterly profits, the development budget is about to be
cut. When senior scientists talk blue sky, the clouds are about to roll in.
Truly, this is not the Tao of Programming.
When managers make commitments, game programs are ignored. When accountants
make
long-range plans, harmony and order are about to be restored. When senior
scientists address the problems at hand, the problems will soon be solved.
Truly, this is the Tao of Programming.
6.2
Why are programmers non-productive? Because their time is wasted in
meetings.
Why are programmers rebellious? Because the management interferes to much.
Why are the programmers resigning one by one? Because they are burnt out.
Having worked for poor management, they no longer value their jobs.
6.3
A manager was about to be fired, but a programmer who worked for him
invented a
new program that became popular and sold well. As a result, the manager
retained
his job.
The manager tried to give the programmer a bonus, but the programmer refused
it,
saying, “I wrote the program because I thought it was an interesting
concept,
and thus I expect no reward.”
The manager upon hearing this remarked, “This programmer, though he holds a
position of small esteem, understands well the proper duty of an employee.
Lets
promote him to the exalted position of management consultant!”
But when told this, the programmer once more refused, saying, “I exist so
that I
can program. If I were promoted, I would do nothing but waste everyone’s
time.
Can I go now? I have a program that I’m working on.”
6.4
A manager went to his programmers and told them: “As regards to your work
hours:
you are going to have to come in at nine in the morning and leave at five in
the
afternoon.” At this, all of them became angry and several resigned on the
spot."

So the manager said: “All right, in that case you may set your own working
hours, as long as you finish your projects on schedule.” The programmers,
now
satisfied, began to come in at noon and work to the wee hours of the
morning.



Corporate Wisdom
Book Seven
Thus spake the master programmer:
“You can demonstrate a program for a corporate executive, but you can’t make
him
computer literate.”
7.1
A novice asked the master: “In the east there is a great tree- structure
that
men call ‘Corporate Headquarters’. It is bloated out of shape with vice
presidents and accountants. It issues a multitude of memos, each saying ‘Go,
Hence!’ or ‘Go, Hither!’ and nobody knows what is meant. Every year new
names
are put onto the branches, but all to no avail. How can such an unnatural
entity
exist?”
The master replies: “You perceive this immense structure and are disturbed
that
it has no rational purpose. Can you not take amusement from its endless
gyrations? Do you not enjoy the untroubled ease of programming beneath its
sheltering branches? Why are you bothered by its uselessness?”
7.2
In the east there is a shark which is larger than all other fish. It changes
into a bird whose wings are like clouds filling the sky. When this bird
moves
across the land, it brings a message from Corporate Headquarters. This
message
it drops into the midst of the programmers, like a seagull making its mark
upon
the beach. Then the bird mounts on the wind and, with the blue sky at its
back,
returns home.
The novice programmer stares in wonder at the bird, for he understands it
not.
The average programmer dreads the coming of the bird, for he fears its
message.
The master programmer continues to work at his terminal, for he does not
know
that the bird has come and gone.
7.3
The Magician of the Ivory Tower brought his latest invention for the master
programmer to examine. The magician wheeled a large black box into the
master’s
office while the master waited in silence.
“This is an integrated, distributed, general-purpose workstation,” began the
magician, “ergonomically designed with a proprietary operating system, sixth
generation languages, and multiple state of the art user interfaces. It took
my
assistants several hundred man years to construct. Is it not amazing?”
The master raised his eyebrows slightly. “It is indeed amazing,” he said.
“Corporate Headquarters has commanded,” continued the magician, “that
everyone
use this workstation as a platform for new programs. Do you agree to this?”
“Certainly,” replied the master, " I will have it transported to the data
center
immediately!" And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master
programmer
and said, “I cannot find the listing for my new program. Do you know where
it
might be?”
“Yes,” replied the master, “the listings are stacked on the platform in the
data
center.”
7.4
The master programmer moves from program to program without fear. No change
in
management can harm him. He will not be fired, even if the project is
cancelled.
Why is this? He is filled with Tao.



Hardware and Software
Book Eight
Thus spake the master programmer:
“Without the wind, the grass does not move. Without software,hardware is
useless.”
8.1
A novice asked the master: “I perceive that one computer company is much
larger
than all others. It towers above its competition like a giant among dwarfs.
Any
one of its divisions could comprise an entire business. Why is this so?”
The master replied, “Why do you ask such foolish questions? That company is
large because it is large. If it only made hardware, nobody would buy it. If
it
only made software, nobody would use it. If it only maintained systems,
people
would treat it like a servant. But because it combines all of these things,
people think it one of the gods! By not seeking to strive, it conquers
without
effort.”
8.2
A master programmer passed a novice programmer one day. The master noted the
novice’s preoccupation with a hand-held computer game. “Excuse me”, he said,
“may I examine it?”
The novice bolted to attention and handed the device to the master. I see
that
the device claims to have three levels of play: Easy, Medium and Hard", said
the
master. “Yet every such device has another level of play, where the device
seeks
not to conquer the human, nor to be conquered by the human.”
“Pray, great master”, implored the novice, “how does one find this
mysterious
settings?”
The master dropped the device to the ground and crushed it under foot. And
suddenly the novice was enlightened.
8.3
There was once a programmer who worked upon microprocessors. “Look at how
well
off I am here,” he said to a mainframe programmer who came to visit, “I have
my
own operating system and file storage device. I do not have to share my
resources with anyone. The software is self- consistant and easy-to-use. Why
do
you not quit your present job and join me here?”
The mainframe programmer then began to describe his system to his friend,
saying
“The mainframe sits like an ancient sage meditating in the midst of the data
center. Its disk drives lie end-to-end like a great ocean of machinery. The
software is as multifaceted as a diamond, and as convoluted as a primeval
jungle. The programs, each unique, move through the system like a
swift-flowing
river. That is why I am happy where I am.”
The microcomputer programmer, upon hearing this, fell silent. But the two
programmers remained friends until the end of their days.
8.4
Hardware met Software on the road to Changtse. Software said: “You are Yin
and I
am Yang. If we travel together we will become famous and earn vast sums of
money.” And so they set forth together, thinking to conquer the world.
Presently they met Firmware, who was dressed in tattered rags and hobbled
along
propped on a thorny stick. Firmware said to them: “The Tao lies beyond Yin
and
Yang. It is silent and still as a pool of water. It does not seek fame,
therefore nobody knows its presence. It does not seek fortune, for it is
complete within itself. It exists beyond space and time.”
Software and Hardware, ashamed, returned to their homes.



Epilogue
Book Nine
Thus spake the Master Programmer:
“Time for you to leave.”

THE ABC’S OF UNIX

A is for Awk, which runs like a snail, and
B is for Biff, which reads all your mail.

C is for CC, as hackers recall, while
D is for DD, the command that does all.

E is for Emacs, which rebinds your keys, and
F is for Fsck, which rebuilds your trees.

G is for Grep, a clever detective, while
H is for Halt, which may seem defective.

I is for Indent, which rarely amuses, and
J is for Join, which nobody uses.

K is for Kill, which makes you the boss, while
L is for Lex, which is missing from DOS.

M is for More, from which Less was begot, and
N is for Nice, which it really is not.

O is for Od, which prints out things nice, while
P is for Passwd, which reads in strings twice.

Q is for Quota, a Berkeley-type fable, and
R is for Ranlib, for sorting ar [sic] table.

S is for Spell, which attempts to belittle, while
T is for True, which does very little.

U is for Uniq, which is used after Sort, and
V is for Vi, which is hard to abort.

W is for Whoami, which tells you your name, while
X is, well, X, of dubious fame.

Y is for Yes, which makes an impression, and
Z is for Zcat, which handles compression.

Not trying to throw water on anyone’s fun or anything, but isn’t this
(The Tao of Programming) copyright? I actually have a bound, printed
copy of this in a little booklet; it’s one of my favorites. It is
definitely copyright :slight_smile:.

Or did Mr. James allow distribution later on (I got my copy over 10
years ago…)?

Anyway…

Paul D. Smith <pausmith@nortelnetworks.com> HASMAT–HA Software Mthds & Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad Scientist

These are my opinions—Nortel Networks takes no responsibility for them.

Beats me. There are many copies of it on the web.
http://www.canonical.org/~kragen/tao-of-programming.html for example.

Kris

“Paul D. Smith” <pausmith@nortelnetworks.com> wrote in message
news:p53cqvsfo6.fsf@lemming.engeast.baynetworks.com

Not trying to throw water on anyone’s fun or anything, but isn’t this
(The Tao of Programming) copyright? I actually have a bound, printed
copy of this in a little booklet; it’s one of my favorites. It is
definitely copyright > :slight_smile:> .

Or did Mr. James allow distribution later on (I got my copy over 10
years ago…)?

Anyway…


Paul D. Smith <> pausmith@nortelnetworks.com> > HASMAT–HA Software Mthds &
Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad
Scientist


These are my opinions—Nortel Networks takes no responsibility for
them.

This is not so much a programming one but I was always fond of it when I was
a sysadmin.If you like this sort of stuff, you can find more at
http://bofh.ntk.net/Bastard.htmlFrom: Ben@lspace.org (Ben)
Subject: Wear a Leatherman
Date: Wed, 12 May 1999 11:58:56 GMT

Sysadmins of the class of '99:

Wear a Leatherman.

If I could offer you only one tip for the future, having a Leatherman
would be
it. The long-term benefits of a Leatherman have been proved by BOFHs,
whereas
the rest of my advice has no basis more reliable than my own meandering
experience. I will dispense this advice now.

Enjoy the power and beauty of root. Oh, never mind. You will not
understand the
power and beauty of your root access until it’s taken away. But trust me,
when
you need to kill a runaway process, you’ll think back to the scripts you
had
and recall in a way you can’t grasp now how much possibility lay before
you and
how much you could do. You are not as powerless as you imagine.

Don’t worry about the Y2K bug. Or worry, but know that worrying is as
effective
as trying to mount an old chain of Exabyte tape drives by chewing bubble
gum.
The real troubles on your network are apt to be things that never crossed
your
worried mind, the kind that get you called in at 4 a.m. on some weekend
when
you were supposed to be recovering.

Do one thing every day that scares the lusers.

LART.

Don’t be reckless with other people’s files (if it can be traced back to
you).
Come down like a ton of bricks on people who are reckless with yours.

Nerf.

Don’t waste your time on lusers’ backups. Sometimes you’re ahead on
patches,
sometimes you’re behind. The race to maintain an up-to-date system is long
and,
in the end, it’s only with yourself.

Remember compliments you receive. Log the insults in a database, cross-
referenced on date, time, reason and luser. If you succeed in doing this,
tell
me how (and ftp me the binary).

Archive your lusers’ old web caches. Throw away your logs.

Drink Jolt.

Don’t feel guilty if you don’t know what you want to do with your old
glibc
libraries. The most interesting sysadmins I know didn’t know at 22 what
they
wanted to do with their systems. Some of the most interesting 40-year-old
BOFHs
I know still don’t.

Get plenty of UPSes. Be kind to your power supplies. You’ll miss them when
they’re gone.

Maybe you’ll recover, maybe you won’t. Maybe you’ll have lusers, maybe you
won’t. Maybe you’ll become a PHB at 40, maybe you’ll dance on the head of
your
boss on your last day before you wipe the servers. Whatever you do, don’t
congratulate yourself too much, or berate yourself either. Your choices
are
half chance. So are everybody else’s. But at least you can read their
email.

Enjoy your network. Use it every way you can. Don’t be afraid of it or of
what
other people think of it. It’s the greatest instrument you’ll ever own.
No
matter what the PHBs think.

Compile, even if you have nowhere to do it but on your laptop.

RTFM, even if you still use ‘tar -xvf’ rather than ‘tar xvf’.

Do not read NT magazines. They will only make you feel ill.

Get to know your hardware suppliers. You never know when they’ll go out of
business. Be nice to your PFY. They’re your best link to your past and the
people most likely to play along when you kill the electrician with a
power
spike.

Understand that lusers come and go, but with a precious few you should
wring
their necks as soon as possible. Work hard to bridge the gaps in their
knowledge and Clue, because the older you get, the more you need the
people who
knew you when you were nasty, and had a real mean temper when roused.

Live in your office once, but leave before it makes you arrive too early
for
work. Live in the machine room once, but leave before you start to whistle
at
28.8. Travel without moving with a line into the CCTV system.

Accept certain inalienable truths: hardware prices will rise. Lusers won’t
learn.

You, too, will get old. And when you do, you’ll fantasize that when you
were
young, prices were reasonable, lusers were just as bad but sometimes they
respected their sysadmin.

Only respect your ass.

Don’t expect anyone else to support you when you purchase a Starfire.
Maybe you
have photos of the Boss with a secretary. Maybe you’ll have a wealthy
company
with more money than sense. But you never know when either one might run
out,
or they’ll find out about the camera in the boardroom.

Don’t mess too much with your chair or by lunchtime you won’t be able to
sleep
in it.

Be careful whose software you buy, don’t be patient with those who supply
it.
Software is a form of nostalgia. Dispensing it is a way of fishing the
minds of
bad programmers for the ‘really neat’ ideas, wiping them off, painting
over the
ugly parts and selling it for more than it’s worth.

But trust me on the Leatherman.

Ben


“I’m sorry, you must be confusing
me with someone who gives a damn.”

My all time favourite is the Bastard Operator from Hell (BOFH). The first
installment is below. The rest can be found at
http://bofh.ntk.net/Bastard.html or a hundred other places on the 'net.

The Bastard Operator From Hell #1
It’s backup day today so I’m pissed off. Being the BOFH, however, does have
it’s advantages. I reassign null to be the tape device - it’s so much more
economical on my time as I don’t have to keep getting up to change tapes
every 5 minutes. And it speeds up backups too, so it can’t be all bad can
it? Of course not.

A user rings

“Do you know why the system is slow?” they ask

“It’s probably something to do with…” I look up today’s excuse “… clock
speed”

“Oh” (Not knowing what I’m talking about, they’re satisfied) “Do you know
when it will be fixed?”

“Fixed? There’s 275 users on your machine, and one of them is you. Don’t be
so selfish - logout now and give someone else a chance!”

“But my research results are due in tommorrow and all I need is one page of
Laser Print…”

“SURE YOU DO. Well; You just keep telling yourself that buddy!” I hang up.

You’d really think people would learn not to call…

The phone rings. It’ll be him again, I know. That annoys me. I put on a
gruff voice

“HELLO, SALARIES!”

“Oh, I’m sorry, I’ve got the wrong number”

“YEAH? Well what’s your name buddy? Do you know WASTED phone calls cost
money? DO YOU? I’ve got a good mind to subtract your wasted time, my wasted
time, and the cost of this call from your weekly wages! IN FACT I WILL! By
the time I’ve finished with you, YOU’LL OWE US money! WHAT’S YOUR NAME - AND
DON’T LIE, WE’VE GOT CALLER ID!!”

I hear the phone drop and the sound of running feet - he’s obviously going
to try and get an alibi by being at the Dean’s office. I look up his
username and find his department. I ring the Dean’s secretary.

“Hello?” she answers

“Hi, SIMON, B.O.F.H HERE, LISTEN, WHEN THAT GUY COMES RUNNING INTO YOUR
OFFICE IN ABOUT 10 SECONDS, CAN YOU GIVE HIM A MESSAGE?”

“I think so…” she says

“TELL HIM `HE CAN RUN, BUT HE CAN’T HIDE’”

“Um. Ok”

“AND DON’T FORGET NOW, I WOULDN’T WANT TO HAVE TO TELL ANYONE ABOUT THAT
FILE IN YOUR ACCOUNT WITH YOUR ANSWERS TO THE PURITY TEST IN IT…”

I hear her scrabbling at the terminal…

“DON’T BOTHER - I HAVE A COPY. BE A GOOD PERVY AND PASS THE MESSAGE ON…”

She sobs her assent and I hang up. And the worst thing is, I was just
guessing about the purity test thing. I grab a quick copy anyway, it might
make for some good late-night reading.

Meantime backups have finished in record time, 2.03 seconds. Modern
technology is wonderful, isn’t it?

Another user rings.

“I need more space” he says

“Well, why not move to Texas?” I ask

“No, on my account, stupid.”

Stupid? Uh-Oh…

“I’m terribly sorry” I say, in a polite manner equal to that of Jimmy
Stewart in a Weekend Family Matine Feature “I didn’t quite catch that. What
was it that you said?”

I smell the fear coming down the line at me, but it’s too late, he’s a goner
and he knows it.

“Um, I said what I wanted was more space on my account, please

“Sure, hang on”

I hear him gasp his relief even though he’d covered the mouthpeice.

“There, you’ve got plenty of space now!”

“How much have I got?” he simps

Now this REALLY PISSES ME OFF! Not only do they want me to give them
extra space, they want to check it, then correct me if I don’t give them
enough! They should be happy with what I give them and that’s it!

Back into Jimmy Stewart mode.

“Well, let’s see, you have 4 Meg available”

“Wow! Eight Meg in total, thanks!” he says, pleased with his bargaining
power

“No” I interrupt, savouring this like a fine red at room temperature, with
steak, extra rare, to follow; “4 Meg in total…”

“Huh? I’d used 4 Meg already, How could I have 4 Meg Available?”

I say nothing. It’ll come to him.

“aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaagggggghhhhhH!”

I kill me; I really do!

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:ap3mob$eid$1@nntp.qnx.com

Hey people, what are some of your favorite stories, jokes, etc.

I’m absolutly seriously. Linux project has a lot of “howto” articles, they
are different level, different quality, from different people. But anyway,
it’s great idea. Here is link to the best howto IMHO:

http://www.fazekas.hu/~nagydani/rth/Russian-tea-HOWTO-v2.html

Cheers,
Eduard.

Hmmmm…
I think their recipe forgets an important step. You’re supposed to warm
up the pot before putting leaves into it :slight_smile:

ed1k wrote:

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ap3mob$eid$> 1@nntp.qnx.com> …

Hey people, what are some of your favorite stories, jokes, etc.


I’m absolutly seriously. Linux project has a lot of “howto” articles, they
are different level, different quality, from different people. But anyway,
it’s great idea. Here is link to the best howto IMHO:

http://www.fazekas.hu/~nagydani/rth/Russian-tea-HOWTO-v2.html

Cheers,
Eduard.

Robert Rutherford <ruzz@nospamplease.ruzz.com> wrote:

My all time favourite is the Bastard Operator from Hell (BOFH). The first
installment is below. The rest can be found at
http://bofh.ntk.net/Bastard.html > or a hundred other places on the 'net.

Ah yes, I always feel a thrill of national pride when I remember that
this guy was a Kiwi… ;v)

The Bastard Operator From Hell #1
It’s backup day today so I’m pissed off. Being the BOFH, however, does have
it’s advantages. I reassign null to be the tape device - it’s so much more
economical on my time as I don’t have to keep getting up to change tapes
every 5 minutes. And it speeds up backups too, so it can’t be all bad can
it? Of course not.

A user rings

“Do you know why the system is slow?” they ask

“It’s probably something to do with…” I look up today’s excuse “… clock
speed”

“Oh” (Not knowing what I’m talking about, they’re satisfied) “Do you know
when it will be fixed?”

“Fixed? There’s 275 users on your machine, and one of them is you. Don’t be
so selfish - logout now and give someone else a chance!”

“But my research results are due in tommorrow and all I need is one page of
Laser Print…”

“SURE YOU DO. Well; You just keep telling yourself that buddy!” I hang up.

You’d really think people would learn not to call…

The phone rings. It’ll be him again, I know. That annoys me. I put on a
gruff voice

“HELLO, SALARIES!”

“Oh, I’m sorry, I’ve got the wrong number”

“YEAH? Well what’s your name buddy? Do you know WASTED phone calls cost
money? DO YOU? I’ve got a good mind to subtract your wasted time, my wasted
time, and the cost of this call from your weekly wages! IN FACT I WILL! By
the time I’ve finished with you, YOU’LL OWE US money! WHAT’S YOUR NAME - AND
DON’T LIE, WE’VE GOT CALLER ID!!”

I hear the phone drop and the sound of running feet - he’s obviously going
to try and get an alibi by being at the Dean’s office. I look up his
username and find his department. I ring the Dean’s secretary.

“Hello?” she answers

“Hi, SIMON, B.O.F.H HERE, LISTEN, WHEN THAT GUY COMES RUNNING INTO YOUR
OFFICE IN ABOUT 10 SECONDS, CAN YOU GIVE HIM A MESSAGE?”

“I think so…” she says

“TELL HIM `HE CAN RUN, BUT HE CAN’T HIDE’”

“Um. Ok”

“AND DON’T FORGET NOW, I WOULDN’T WANT TO HAVE TO TELL ANYONE ABOUT THAT
FILE IN YOUR ACCOUNT WITH YOUR ANSWERS TO THE PURITY TEST IN IT…”

I hear her scrabbling at the terminal…

“DON’T BOTHER - I HAVE A COPY. BE A GOOD PERVY AND PASS THE MESSAGE ON…”

She sobs her assent and I hang up. And the worst thing is, I was just
guessing about the purity test thing. I grab a quick copy anyway, it might
make for some good late-night reading.

Meantime backups have finished in record time, 2.03 seconds. Modern
technology is wonderful, isn’t it?

Another user rings.

“I need more space” he says

“Well, why not move to Texas?” I ask

“No, on my account, stupid.”

Stupid? Uh-Oh…

“I’m terribly sorry” I say, in a polite manner equal to that of Jimmy
Stewart in a Weekend Family Matine Feature “I didn’t quite catch that. What
was it that you said?”

I smell the fear coming down the line at me, but it’s too late, he’s a goner
and he knows it.

“Um, I said what I wanted was more space on my account, please

“Sure, hang on”

I hear him gasp his relief even though he’d covered the mouthpeice.

“There, you’ve got plenty of space now!”

“How much have I got?” he simps

Now this REALLY PISSES ME OFF! Not only do they want me to give them
extra space, they want to check it, then correct me if I don’t give them
enough! They should be happy with what I give them and that’s it!

Back into Jimmy Stewart mode.

“Well, let’s see, you have 4 Meg available”

“Wow! Eight Meg in total, thanks!” he says, pleased with his bargaining
power

“No” I interrupt, savouring this like a fine red at room temperature, with
steak, extra rare, to follow; “4 Meg in total…”

“Huh? I’d used 4 Meg already, How could I have 4 Meg Available?”

I say nothing. It’ll come to him.

“aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaagggggghhhhhH!”

I kill me; I really do!




cburgess@qnx.com

I love reading stuff like that. Russians sometimes remind me of the Ents in
Lord of the rings. This whole elegant, deliberate way of doing things…
The Tea HOWTO reminded me of a great description I read once of the proper
way to drink vodka: http://theshredder.com/columns/vodka1.html

cheers,

Kris

“Igor Kovalenko” <kovalenko@attbi.com> wrote in message
news:3DB90704.5010904@attbi.com

Hmmmm…
I think their recipe forgets an important step. You’re supposed to warm
up the pot before putting leaves into it > :slight_smile:

ed1k wrote:
“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ap3mob$eid$> 1@nntp.qnx.com> …

Hey people, what are some of your favorite stories, jokes, etc.


I’m absolutly seriously. Linux project has a lot of “howto” articles,
they
are different level, different quality, from different people. But
anyway,
it’s great idea. Here is link to the best howto IMHO:

http://www.fazekas.hu/~nagydani/rth/Russian-tea-HOWTO-v2.html

Cheers,
Eduard.
\

“Igor Kovalenko” <kovalenko@attbi.com> wrote in message
news:3DB90704.5010904@attbi.com

Hmmmm…
I think their recipe forgets an important step. You’re supposed to warm
up the pot before putting leaves into it > :slight_smile:

Like any documentation it’s not very clear, but here is it:
http://www.fazekas.hu/~nagydani/rth/Russian-tea-HOWTO-v2.html#ss3.1

Cheers,
Eduard.

ed1k wrote:
“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ap3mob$eid$> 1@nntp.qnx.com> …

Hey people, what are some of your favorite stories, jokes, etc.


I’m absolutly seriously. Linux project has a lot of “howto” articles,
they
are different level, different quality, from different people. But
anyway,
it’s great idea. Here is link to the best howto IMHO:

http://www.fazekas.hu/~nagydani/rth/Russian-tea-HOWTO-v2.html

Cheers,
Eduard.
\

Real Men Don’t Use Pascal – 1982
by Ed Post
Back in the good old days – the “Golden Era” of computers, it was easy to
separate the men from the boys (sometimes called “Real Men” and “Quiche
Eaters” in the literature). During this period, the Real Men were the ones
that understood computer programming, and the Quiche Eaters were the ones
that didn’t. A real computer programmer said things like “DO 10 I=1,10” and
“ABEND” (they actually talked in capital letters, you understand), and the
rest of the world said things like “computers are too complicated for me”
and “I can’t relate to computers – they’re so impersonal”. (A previous work
[1] points out that Real Men don’t “relate” to anything, and aren’t afraid
of being impersonal.)
But, as usual, times change. We are faced today with a world in which little
old ladies can get computerized microwave ovens, 12 year old kids can blow
Real Men out of the water playing Asteroids and Pac-Man, and anyone can buy
and even understand their very own Personal Computer. The Real Programmer is
in danger of becoming extinct, of being replaced by high-school students
with TRASH-80s!

There is a clear need to point out the differences between the typical
high-school junior Pac-Man player and a Real Programmer. Understanding these
differences will give these kids something to aspire to – a role model, a
Father Figure. It will also help employers of Real Programmers to realize
why it would be a mistake to replace the Real Programmers on their staff
with 12 year old Pac-Man players (at a considerable salary savings).

LANGUAGES
The easiest way to tell a Real Programmer from the crowd is by the
programming language he (or she) uses. Real Programmers use FORTRAN. Quiche
Eaters use PASCAL. Nicklaus Wirth, the designer of PASCAL, was once asked,
“How do you pronounce your name?”. He replied “You can either call me by
name, pronouncing it ‘Veert’, or call me by value, ‘Worth’.” One can tell
immediately from this comment that Nicklaus Wirth is a Quiche Eater. The
only parameter passing mechanism endorsed by Real Programmers is
call-by-value-return, as implemented in the IBM/370 FORTRAN G and H
compilers. Real programmers don’t need abstract concepts to get their jobs
done: they are perfectly happy with a keypunch, a FORTRAN IV compiler, and a
beer.

Real Programmers do List Processing in FORTRAN.
Real Programmers do String Manipulation in FORTRAN.
Real Programmers do Accounting (if they do it at all) in FORTRAN.
Real Programmers do Artificial Intelligence programs in FORTRAN.
If you can’t do it in FORTRAN, do it in assembly language. If you can’t do
it in assembly language, it isn’t worth doing.

STRUCTURED PROGRAMMING
Computer science academicians have gotten into the “structured programming”
rut over the past several years. They claim that programs are more easily
understood if the programmer uses some special language constructs and
techniques. They don’t all agree on exactly which constructs, of course, and
the examples they use to show their particular point of view invariably fit
on a single page of some obscure journal or another – clearly not enough of
an example to convince anyone. When I got out of school, I thought I was the
best programmer in the world. I could write an unbeatable tic-tac-toe
program, use five different computer languages, and create 1000 line
programs that WORKED. (Really!) Then I got out into the Real World. My first
task in the Real World was to read and understand a 200,000 line FORTRAN
program, then speed it up by a factor of two. Any Real Programmer will tell
you that all the Structured Coding in the world won’t help you solve a
problem like that – it takes actual talent. Some quick observations on Real
Programmers and Structured Programming:

Real Programmers aren’t afraid to use GOTOs.
Real Programmers can write five page long DO loops without getting confused.
Real Programmers enjoy Arithmetic IF statements because they make the code
more interesting.
Real Programmers write self-modifying code, especially if it saves them 20
nanoseconds in the middle of a tight loop.
Programmers don’t need comments: the code is obvious.
Since FORTRAN doesn’t have a structured IF, REPEAT … UNTIL, or CASE
statement, Real Programmers don’t have to worry about not using them.
Besides, they can be simulated when necessary using assigned GOTOs.
Data structures have also gotten a lot of press lately. Abstract Data Types,
Structures, Pointers, Lists, and Strings have become popular in certain
circles. Wirth (the above-mentioned Quiche Eater) actually wrote an entire
book [2] contending that you could write a program based on data structures,
instead of the other way around. As all Real Programmers know, the only
useful data structure is the array. Strings, lists, structures, sets –
these are all special cases of arrays and and can be treated that way just
as easily without messing up your programing language with all sorts of
complications. The worst thing about fancy data types is that you have to
declare them, and Real Programming Languages, as we all know, have implicit
typing based on the first letter of the (six character) variable name.


OPERATING SYSTEMS
What kind of operating system is used by a Real Programmer? CP/M? God
forbid – CP/M, after all, is basically a toy operating system. Even little
old ladies and grade school students can understand and use CP/M.
Unix is a lot more complicated of course – the typical Unix hacker never
can remember what the PRINT command is called this week – but when it gets
right down to it, Unix is a glorified video game. People don’t do Serious
Work on Unix systems: they send jokes around the world on USENET and write
adventure games and research papers.

No, your Real Programmer uses OS/370. A good programmer can find and
understand the description of the IJK305I error he just got in his JCL
manual. A great programmer can write JCL without referring to the manual at
all. A truly outstanding programmer can find bugs buried in a 6 megabyte
core dump without using a hex calculator. (I have actually seen this done.)

OS/370 is a truly remarkable operating system. It’s possible to destroy days
of work with a single misplaced space, so alertness in the programming staff
is encouraged. The best way to approach the system is through a keypunch.
Some people claim there is a Time Sharing system that runs on OS/370, but
after careful study I have come to the conclusion that they are mistaken.


PROGRAMMING TOOLS
What kind of tools does a Real Programmer use? In theory, a Real Programmer
could run his programs by keying them into the front panel of the computer.
Back in the days when computers had front panels, this was actually done
occasionally. Your typical Real Programmer knew the entire bootstrap loader
by memory in hex, and toggled it in whenever it got destroyed by his
program. (Back then, memory was memory – it didn’t go away when the power
went off. Today, memory either forgets things when you don’t want it to, or
remembers things long after they’re better forgotten.) Legend has it that
Seymour Cray, inventor of the Cray I supercomputer and most of Control
Data’s computers, actually toggled the first operating system for the
CDC7600 in on the front panel from memory when it was first powered on.
Seymour, needless to say, is a Real Programmer.
One of my favorite Real Programmers was a systems programmer for Texas
Instruments. One day, he got a long distance call from a user whose system
had crashed in the middle of some important work. Jim was able to repair the
damage over the phone, getting the user to toggle in disk I/O instructions
at the front panel, repairing system tables in hex, reading register
contents back over the phone. The moral of this story: while a Real
Programmer usually includes a keypunch and lineprinter in his toolkit, he
can get along with just a front panel and a telephone in emergencies.

In some companies, text editing no longer consists of ten engineers standing
in line to use an 029 keypunch. In fact, the building I work in doesn’t
contain a single keypunch. The Real Programmer in this situation has to do
his work with a text editor program. Most systems supply several text
editors to select from, and the Real Programmer must be careful to pick one
that reflects his personal style. Many people believe that the best text
editors in the world were written at Xerox Palo Alto Research Center for use
on their Alto and Dorado computers [3]. Unfortunately, no Real Programmer
would ever use a computer whose operating system is called SmallTalk, and
would certainly not talk to the computer with a mouse.

Some of the concepts in these Xerox editors have been incorporated into
editors running on more reasonably named operating systems. EMACS and VI are
probably the most well known of this class of editors. The problem with
these editors is that Real Programmers consider “what you see is what you
get” to be just as bad a concept in text editors as it is in women. No, the
Real Programmer wants a “you asked for it, you got it” text editor –
complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.

It has been observed that a TECO command sequence more closely resembles
transmission line noise than readable text [4]. One of the more entertaining
games to play with TECO is to type your name in as a command line and try to
guess what it does. Just about any possible typing error while talking with
TECO will probably destroy your program, or even worse – introduce subtle
and mysterious bugs in a once working subroutine.

For this reason, Real Programmers are reluctant to actually edit a program
that is close to working. They find it much easier to just patch the binary
object code directly, using a wonderful program called SUPERZAP (or its
equivalent on non-IBM machines). This works so well that many working
programs on IBM systems bear no relation to the original FORTRAN code. In
many cases, the original source code is no longer available. When it comes
time to fix a program like this, no manager would even think of sending
anything less than a Real Programmer to do the job – no Quiche Eating
structured programmer would even know where to start. This is called “job
security”.

Some programming tools NOT used by Real Programmers:


FORTRAN preprocessors like MORTRAN and RATFOR. The Cuisinarts of
programming – great for making Quiche. See comments above on structured
programming.
Source language debuggers. Real Programmers can read core dumps.
Compilers with array bounds checking. They stifle creativity, destroy most
of the interesting uses for EQUIVALENCE, and make it impossible to modify
the operating system code with negative subscripts. Worst of all, bounds
checking is inefficient.
Source code maintainance systems. A Real Programmer keeps his code locked up
in a card file, because it implies that its owner cannot leave his important
programs unguarded [5].

THE REAL PROGRAMMER AT WORK
Where does the typical Real Programmer work? What kind of programs are
worthy of the efforts of so talented an individual? You can be sure that no
real Programmer would be caught dead writing accounts-receivable programs in
COBOL, or sorting mailing lists for People magazine. A Real Programmer wants
tasks of earth-shaking importance (literally!):

Real Programmers work for Los Alamos National Laboratory, writing atomic
bomb simulations to run on Cray I supercomputers.
Real Programmers work for the National Security Agency, decoding Russian
transmissions.
It was largely due to the efforts of thousands of Real Programmers working
for NASA that our boys got to the moon and back before the cosmonauts.
The computers in the Space Shuttle were programmed by Real Programmers.
Programmers are at work for Boeing designing the operating systems for
cruise missiles.
Some of the most awesome Real Programmers of all work at the Jet Propulsion
Laboratory in California. Many of them know the entire operating system of
the Pioneer and Voyager spacecraft by heart. With a combination of large
ground-based FORTRAN programs and small spacecraft-based assembly language
programs, they can to do incredible feats of navigation and improvisation,
such as hitting ten-kilometer wide windows at Saturn after six years in
space, and repairing or bypassing damaged sensor platforms, radios, and
batteries. Allegedly, one Real Programmer managed to tuck a pattern-matching
program into a few hundred bytes of unused memory in a Voyager spacecraft
that searched for, located, and photographed a new moon of Jupiter.

One plan for the upcoming Galileo spacecraft mission is to use a gravity
assist trajectory past Mars on the way to Jupiter. This trajectory passes
within 80 +/- 3 kilometers of the surface of Mars. Nobody is going to trust
a PASCAL program (or PASCAL programmer) for navigation to these tolerances.

As you can tell, many of the world’s Real Programmers work for the U.S.
Government, mainly the Defense Department. This is as it should be.
Recently, however, a black cloud has formed on the Real Programmer horizon.

It seems that some highly placed Quiche Eaters at the Defense Department
decided that all Defense programs should be written in some grand unified
language called “ADA” (registered trademark, DoD). For a while, it seemed
that ADA was destined to become a language that went against all the
precepts of Real Programming – a language with structure, a language with
data types, strong typing, and semicolons. In short, a language designed to
cripple the creativity of the typical Real Programmer. Fortunately, the
language adopted by DoD has enough interesting features to make it
approachable: it’s incredibly complex, includes methods for messing with the
operating system and rearranging memory, and Edsgar Dijkstra doesn’t like it
[6]. (Dijkstra, as I’m sure you know, was the author of “GoTos Considered
Harmful” – a landmark work in programming methodology, applauded by Pascal
Programmers and Quiche Eaters alike.) Besides, the determined Real
Programmer can write FORTRAN programs in any language.

The real programmer might compromise his principles and work on something
slightly more trivial than the destruction of life as we know it, providing
there’s enough money in it. There are several Real Programmers building
video games at Atari, for example. (But not playing them. A Real Programmer
knows how to beat the machine every time: no challange in that.) Everyone
working at LucasFilm is a Real Programmer. (It would be crazy to turn down
the money of 50 million Star Wars fans.) The proportion of Real Programmers
in Computer Graphics is somewhat lower than the norm, mostly because nobody
has found a use for Computer Graphics yet. On the other hand, all Computer
Graphics is done in FORTRAN, so there are a fair number people doing
Graphics in order to avoid having to write COBOL programs.


THE REAL PROGRAMMER AT PLAY
Generally, the Real Programmer plays the same way he works – with
computers. He is constantly amazed that his employer actually pays him to do
what he would be doing for fun anyway, although he is careful not to express
this opinion out loud. Occasionally, the Real Programmer does step out of
the office for a breath of fresh air and a beer or two. Some tips on
recognizing real programmers away from the computer room:

At a party, the Real Programmers are the ones in the corner talking about
operating system security and how to get around it.
At a football game, the Real Programmer is the one comparing the plays
against his simulations printed on 11 by 14 fanfold paper.
At the beach, the Real Programmer is the one drawing flowcharts in the sand.
A Real Programmer goes to a disco to watch the light show.
At a funeral, the Real Programmer is the one saying “Poor George. And he
almost had the sort routine working before the coronary.”
In a grocery store, the Real Programmer is the one who insists on running
the cans past the laser checkout scanner himself, because he never could
trust keypunch operators to get it right the first time.

THE REAL PROGRAMMER’S NATURAL HABITAT
What sort of environment does the Real Programmer function best in? This is
an important question for the managers of Real Programmers. Considering the
amount of money it costs to keep one on the staff, it’s best to put him (or
her) in an environment where he can get his work done.
The typical Real Programmer lives in front of a computer terminal.
Surrounding this terminal are:


Listings of all programs the Real Programmer has ever worked on, piled in
roughly chronological order on every flat surface in the office.
Some half-dozen or so partly filled cups of cold coffee. Occasionally, there
will be cigarette butts floating in the coffee. In some cases, the cups will
contain Orange Crush.
Unless he is very good, there will be copies of the OS JCL manual and the
Principles of Operation open to some particularly interesting pages.
Taped to the wall is a line-printer Snoopy calender for the year 1969.
Strewn about the floor are several wrappers for peanut butter filled cheese
bars (the type that are made stale at the bakery so they can’t get any worse
while waiting in the vending machine).
Hiding in the top left-hand drawer of the desk is a stash of double stuff
Oreos for special occasions.
Underneath the Oreos is a flow-charting template, left there by the previous
occupant of the office. (Real Programmers write programs, not documentation.
Leave that to the maintainence people.)
The Real Programmer is capable of working 30, 40, even 50 hours at a
stretch, under intense pressure. In fact, he prefers it that way. Bad
response time doesn’t bother the Real Programmer – it gives him a chance to
catch a little sleep between compiles. If there is not enough schedule
pressure on the Real Programmer, he tends to make things more challenging by
working on some small but interesting part of the problem for the first nine
weeks, then finishing the rest in the last week, in two or three 50-hour
marathons. This not only inpresses his manager, who was despairing of ever
getting the project done on time, but creates a convenient excuse for not
doing the documentation. In general:

No Real Programmer works 9 to 5. (Unless it’s 9 in the evening to 5 in the
morning.)
Real Programmers don’t wear neckties.
Real Programmers don’t wear high heeled shoes.
Real Programmers arrive at work in time for lunch. [9]
A Real Programmer might or might not know his wife’s name. He does, however,
know the entire ASCII (or EBCDIC) code table.
Real Programmers don’t know how to cook. Grocery stores aren’t often open at
3 a.m., so they survive on Twinkies and coffee.

THE FUTURE
What of the future? It is a matter of some concern to Real Programmers that
the latest generation of computer programmers are not being brought up with
the same outlook on life as their elders. Many of them have never seen a
computer with a front panel. Hardly anyone graduating from school these days
can do hex arithmetic without a calculator. College graduates these days are
soft – protected from the realities of programming by source level
debuggers, text editors that count parentheses, and user friendly operating
systems. Worst of all, some of these alleged computer scientists manage to
get degrees without ever learning FORTRAN! Are we destined to become an
industry of Unix hackers and Pascal programmers?
On the contrary. From my experience, I can only report that the future is
bright for Real Programmers everywhere. Neither OS/370 nor FORTRAN show any
signs of dying out, despite all the efforts of Pascal programmers the world
over. Even more subtle tricks, like adding structured coding constructs to
FORTRAN have failed. Oh sure, some computer vendors have come out with
FORTRAN 77 compilers, but every one of them has a way of converting itself
back into a FORTRAN 66 compiler at the drop of an option card – to compile
DO loops like God meant them to be.

Even Unix might not be as bad on Real Programmers as it once was. The latest
release of Unix has the potential of an operating system worthy of any Real
Programmer. It has two different and subtly incompatible user interfaces, an
arcane and complicated terminal driver, virtual memory. If you ignore the
fact that it’s structured, even C programming can be appreciated by the Real
Programmer: after all, there’s no type checking, variable names are seven
(ten? eight?) characters long, and the added bonus of the Pointer data type
is thrown in. It’s like having the best parts of FORTRAN and assembly
language in one place. (Not to mention some of the more creative uses for
#define.)

No, the future isn’t all that bad. Why, in the past few years, the popular
press has even commented on the bright new crop of computer nerds and
hackers ([7] and [8]) leaving places like Stanford and M.I.T. for the Real
World. From all evidence, the spirit of Real Programming lives on in these
young men and women. As long as there are ill-defined goals, bizarre bugs,
and unrealistic schedules, there will be Real Programmers willing to jump in
and Solve The Problem, saving the documentation for later. Long live
FORTRAN!

ACKNOWLEGEMENT
I would like to thank Jan E., Dave S., Rich G., Rich E. for their help in
characterizing the Real Programmer, Heather B. for the illustration, Kathy
E. for putting up with it, and atd!avsdS:mark for the initial inspriration.

REFERENCES
[1] Feirstein, B., Real Men Don’t Eat Quiche, New York, Pocket Books, 1982.


[2] Wirth, N., Algorithms + Datastructures = Programs, Prentice Hall, 1976.

[3] Xerox PARC editors . . .

[4] Finseth, C., Theory and Practice of Text Editors - or - a Cookbook for
an EMACS, B.S. Thesis, MIT/LCS/TM-165, Massachusetts Institute of
Technology, May 1980.

[5] Weinberg, G., The Psychology of Computer Programming, New York, Van
Nostrabd Reinhold, 1971, page 110.

[6] Dijkstra, E., On the GREEN Language Submitted to the DoD, Sigplan
notices, Volume 3, Number 10, October 1978.

[7] Rose, Frank, Joy of Hacking, Science 82, Volume 3, Number 9, November
1982, pages 58 - 66.

[8] The Hacker Papers, Psychology Today, August 1980.

[9] Datamation, July, 1983, pp. 263-265.

As long as we’re on the subject of ‘Real Programmers’, here’s another of my
favorites.

The Story of Mel
This was posted to Usenet by its author, Ed Nather
(<nather@astro.as.utexas.edu>), on May 21, 1983.


A recent article devoted to the macho side of programming
made the bald and unvarnished statement:

Real Programmers write in FORTRAN.

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and user-friendly'' software but back in the Good Old Days, when the term software’’ sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I’ll call him Mel,
because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster — drum-memory computer.
Cores cost too much,
and weren’t here to stay, anyway.
(That’s why you haven’t heard of the company,
or the computer.)

I had been hired to write a FORTRAN compiler
for this new marvel and Mel was my guide to its wonders.
Mel didn’t approve of compilers.

If a program can't rewrite its own code'', he asked, what good is it?’’

Mel had written,
in hexadecimal,
the most popular computer program the company owned.
It ran on the LGP-30
and played blackjack with potential customers
at computer shows.
Its effect was always dramatic.
The LGP-30 booth was packed at every show,
and the IBM salesmen stood around
talking to each other.
Whether or not this actually sold computers
was a question we never discussed.

Mel’s job was to re-write
the blackjack program for the RPC-4000.
(Port? What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.

In modern parlance,
every single instruction was followed by a GO TO!
Put that in Pascal’s pipe and smoke it.

Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the read head'' and available for immediate execution. There was a program to do that job, an optimizing assembler’’,
but Mel refused to use it.

You never know where it's going to put things'', he explained, so you’d have to use separate constants’’.

It was a long time before I understood that remark.
Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier ``add’’ instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.

I compared Mel’s hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel’s always ran faster.
That was because the ``top-down’’ method of program design
hadn’t been invented yet,
and Mel wouldn’t have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn’t smart enough to do it that way.

Mel never wrote time-delay loops, either,
even when the balky Flexowriter
required a delay between output characters to work right.
He just located instructions on the drum
so each successive one was just past the read head
when it was needed;
the drum had to execute another complete revolution
to find the next instruction.
He coined an unforgettable term for this procedure.
Although optimum'' is an absolute term, like unique’’, it became common verbal practice
to make it relative:
not quite optimum'' or less optimum’’
or not very optimum''. Mel called the maximum time-delay locations the most pessimum’’.

After he finished the blackjack program
and got it to run
(Even the initializer is optimized'', he said proudly), he got a Change Request from the sales department. The program used an elegant (optimized) random number generator to shuffle the cards’’ and deal from the ``deck’’,
and some of the salesmen felt it was too fair,
since sometimes the customers lost.
They wanted Mel to modify the program
so, at the setting of a sense switch on the console,
they could change the odds and let the customer win.

Mel balked.
He felt this was patently dishonest,
which it was,
and that it impinged on his personal integrity as a programmer,
which it did,
so he refused to do it.
The Head Salesman talked to Mel,
as did the Big Boss and, at the boss’s urging,
a few Fellow Programmers.
Mel finally gave in and wrote the code,
but he got the test backwards,
and, when the sense switch was turned on,
the program would cheat, winning every time.
Mel was delighted with this,
claiming his subconscious was uncontrollably ethical,
and adamantly refused to fix it.

After Mel had left the company for greener pa$ture$,
the Big Boss asked me to look at the code
and see if I could find the test and reverse it.
Somewhat reluctantly, I agreed to look.
Tracking Mel’s code was a real adventure.

I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.

Perhaps my greatest shock came
when I found an innocent loop that had no test in it.
No test. None.
Common sense said it had to be a closed loop,
where the program would circle, forever, endlessly.
Program control passed right through it, however,
and safely out the other side.
It took me two weeks to figure it out.

The RPC-4000 computer had a really modern facility
called an index register.
It allowed the programmer to write a program loop
that used an indexed instruction inside;
each time through,
the number in the index register
was added to the address of that instruction,
so it would refer
to the next datum in a series.
He had only to increment the index register
each time through.
Mel never used it.

Instead, he would pull the instruction into a machine register,
add one to its address,
and store it back.
He would then execute the modified instruction
right from the register.
The loop was written so this additional execution time
was taken into account —
just as this instruction finished,
the next one was right under the drum’s read head,
ready to go.
But the loop had no test in it.

The vital clue came when I noticed
the index register bit,
the bit that lay between the address
and the operation code in the instruction word,
was turned on —
yet Mel never used the index register,
leaving it zero all the time.
When the light went on it nearly blinded me.

He had located the data he was working on
near the top of memory —
the largest locations the instructions could address —
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.

I haven’t kept in touch with Mel,
so I don’t know if he ever gave in to the flood of
change that has washed over programming techniques
since those long-gone days.
I like to think he didn’t.
In any event,
I was impressed enough that I quit looking for the
offending test,
telling the Big Boss I couldn’t find it.
He didn’t seem surprised.

When I left the company,
the blackjack program would still cheat
if you turned on the right sense switch,
and I think that’s how it should be.
I didn’t feel comfortable
hacking up the code of a Real Programmer.






This is one of hackerdom’s great heroic epics, free verse or no. In a few
spare images it captures more about the esthetics and psychology of hacking
than all the scholarly volumes on the subject put together. For an opposing
point of view, see the entry for Real Programmer.

[1992 postscript – the author writes: "The original submission to the net
was not in free verse, nor any approximation to it – it was straight prose
style, in non-justified paragraphs. In bouncing around the net it apparently
got modified into the free verse' form now popular. In other words, it got hacked on the net. That seems appropriate, somehow." The author adds that he likes the free-verse’ version better than his prose original…]

[1999 update: Mel’s last name is now known. The manual for the LGP-30 refers
to “Mel Kaye of Royal McBee who did the bulk of the programming […] of the
ACT 1 system”.]

[2001: The Royal McBee LPG-30 turns out to have one other claim to fame. It
turns out that meteorologist Edward Lorenz was doing weather simulations on
an LGP-30 when, in 1961, he discovered the “Butterfly Theorem” and
computational chaos. This seems, somehow, appropriate.]

[2002: A copy of the programming manual for the LGP-30 lives at
http://ed-thelen.org/comp-hist/lgp-30-man.html]

I love this stuff. And it’s all true! The youngins’ today don’t know what
the hell a bit switch is!

True story:

I used to work on an IBM Series/1. They came out with a new
(latest/greatest) model. We got it because we needed it. But our system
was so heavily loaded that we found a hardware bug that no one else found.
After months of trying to get IBM to “repair” the machine and the EDX OS
guys trying to figure out the problem, IBM finally brought up the designer
of the Series/1 to our office.

He stuck a zillion trace triggering O’scope to the backplane of the system
(without looking at any wiring diagrams of course) and waited for the
failure to occur. We knew that by executing a certain routine it would
occur fairly quickly. We did and it did. He looked, and after a few “uh
hun’s” rebooted the system and flipped a patch into the timer ISR on the
system (again without looking at any manuals). Then he said, try to make it
fail now. We couldn’t.

He explained to us that some gate was being released a cycle or two
prematurely and that it was being clobbered by the next instruction before
it was done being needed by the last instruction. The patch he gave us just
reordered some instructions. We made the same patch on disk so that it
would persist after a reboot. He gave the work-around to the OS guys and
went back to Boca Ratone, FL to document the EC. But not until we took him
out for a very nice lunch. He solved our problem after months of a crashing
systems. We were very thankful.

After setting up, he spent maybe 45 minutes working on the problem. There
have been very few people in this world that truly amaze me. But he was
certainly one of them.

Source language debuggers, BA HUMBUG!


“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aq9dk5$g1d$1@nntp.qnx.com

[very long but very entertaining story deleted]