
The Tao of Programming - galapago
http://www.mit.edu/~xela/tao.html
======
keithflower
_In the days when Sussman was a novice, Minsky once came to him as he sat
hacking at the PDP-6._

 _" What are you doing?", asked Minsky._

 _" I am training a randomly wired neural net to play Tic-tac-toe", Sussman
replied._

 _" Why is the net wired randomly?", asked Minsky._

 _" I do not want it to have any preconceptions of how to play", Sussman
said._

 _Minsky then shut his eyes._

 _" Why do you close your eyes?" Sussman asked his teacher._

 _" So that the room will be empty."_

 _At that moment, Sussman was enlightened._

Hacker Koans:
[http://en.wikipedia.org/wiki/Hacker_koan](http://en.wikipedia.org/wiki/Hacker_koan)

~~~
makmanalp
This one is my favourite:

    
    
        A novice was trying to fix a broken Lisp machine by turning the power off and on.
        Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
    
        Knight turned the machine off and on.
        The machine worked.
    

It's often not this dramatic but I see this happen all the time, when someone
doesn't know the source of a problem and tries to solve it by brute force
(with C, it's usually "adding and removing * and & until it works") when
stopping to understand what's going wrong would have lead them to the issue
directly.

------
gbog
I didn't see the one that I'd say is the most important taoist teaching for
programmers: "Vomit your intelligence" (found in Zhuangzi, not sure how it is
translated in English, in French it's "Vomis ton intelligence").

I understand it this way: intelligence in our activities is this kind of
explicit cleverness that is usually visible and smells its freshly graduated
student eager to use whatever he learnt recently. Look, I can use
metabrogramming to avoid duplicating these two lines of code!

Most very annoying landmines I find in refactoring code code are just side
effects of this kind of intelligence. And usually "dumb code" work faster,
better, is easier to maintain, and, well, requires more (real) intelligence
and experience to write.

Please note that this is a point of view from seasoned coders. From the first
time php-scripter, using intelligence and moderate factorisation is obviously
advised.

So, to this nice list, I'd add a

    
    
        Vomit your intelligence, bro!

------
cousin_it
This one hurt. Ouch!

 _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
luncheon, he discovered the programmer asleep at his terminal. He had been
programming all night._

~~~
gwern
> 30\. In programming, everything we do is a special case of something more
> general -- and often we know it too quickly.

> 56\. Software is under a constant tension. Being symbolic it is arbitrarily
> perfectible; but also it is arbitrarily changeable.

[http://www.cs.yale.edu/homes/perlis-
alan/quotes.html](http://www.cs.yale.edu/homes/perlis-alan/quotes.html)

------
tombh
Similarly,
[http://thecodelesscode.com/contents](http://thecodelesscode.com/contents)

It's a bit more contemporary and is still being added to. I can't figure out
who the author is though. All I know is they go by the name of Qi
[https://github.com/QilessQi](https://github.com/QilessQi)

Also, all the koans are on Github and translations can be submitted via PRs
[https://github.com/alessandro1997/the-codeless-
code](https://github.com/alessandro1997/the-codeless-code)

------
teddyh
Considering this is a book _still in print_ , this is especially blatant
copyright violation. It _is_ a very good book, though.

[https://en.wikipedia.org/wiki/The_Tao_of_Programming](https://en.wikipedia.org/wiki/The_Tao_of_Programming)

~~~
peaton
Hmm... that explains the full text links on the wikipedia page...

~~~
_kst_
Hmm? How does it explain anything? The sites hosting the full text are
(presumably) violating the author's and/or publisher's copyright. The links to
those sites (from here and from Wikipedia) may or may not be doing so (IANAL).

------
thallukrish
The difficult part of programming is programming. I mean just sit and dissolve
yourself into the code and it engulfs you in a timeless world. I often feel
the urge to be on the email or internet or HN kills this sort of dissolution
and very rarely I get this. When you get it, it is absolutely delightful!

------
_pmf_
Not to forget: Master Foo Discourses on the Graphical User Interface
[http://catb.org/esr/writings/unix-koans/gui-
programmer.html](http://catb.org/esr/writings/unix-koans/gui-programmer.html)

------
ozim
I live in dark world of cold steel and dungeons. One have to hack and slash
bugs not go easy on those. So this Tao thing is not for me, I am the crusher
of users. Behold as I wield their skulls! I only have to hide from manager
when I'm posting on HN instead of slashing another bug. :)

------
cfeduke
Upon my departure from the Marine Corps I received a Ka-bar with "After three
days without programming, life becomes meaningless" etched on the blade. One
of the greatest things ever.

~~~
bradleysmith
that is a great thing, would love to see that. Thanks for sharing.

------
mattgreenrocks
The points about rejecting fame deserve mention. Not just fame, but the
pursuit of it.

You have a finite amount of time in a day. You can allocate it between careful
study and practice of programming, or retweeting today's tech groupthink so
you can stay relevant.

------
falcolas
Fun read. However, it seems to promote a very strict philosophy - the most a
novice coder can hope to achieve is the mastering of Programming Tao.

I disagree with this.

Programming is a means to an end, not an end in and of itself. Coding in the
shade of a great tree might be all well and good, but how will you ever see
the world if you stay in the shade of the greatest of trees?

~~~
thallukrish
I feel programming is only an act like painting. The point is when you are
fully into something, it does not matter if you are sitting in the shade of a
tree or otherwise. You begin to flow.. and outside disappears.

------
JamesBaxter
Does anyone know if the Turing quote is real?

"I don't know whether I am Turing dreaming that I am a machine, or a machine
dreaming that I am Turing!"

~~~
thristian
The original would be the Chinese philosopher Zhuangzi¹, from the 3rd century
BC:

"Now I do not know whether I was then a man dreaming I was a butterfly, or
whether I am now a butterfly, dreaming I am a man."

...so I'm guessing that was not a real Turing quote, but possibly a reference
to the Turing Test.

¹:
[https://en.wikiquote.org/wiki/Zhuangzi](https://en.wikiquote.org/wiki/Zhuangzi)

~~~
JamesBaxter
Thanks, I've read a lot about Turing and some of his works and had never seen
it before

------
sillysaurus3

      Thus spake the Master Programmer:
    
      "After three days without programming, life becomes
      meaningless."
    

Sounds like the Master Programmer has never worked at a company that crunched
you for 80 hour weeks, for weeks.

    
    
      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.
    

I don't understand this one. Apple seems like the embodiment of hardware and
software earning vast sums of money. It's worked out well for them.

Maybe they're saying that firmware is an important design consideration that
requires careful attention.

~~~
weland
Firmware is a subtle body,with elements from both worlds ("hardware" and
"software"), and a computing system is harmonious when "software" and
"hardware" do not step over each others' abstractions, but build a coherent,
meaningful system, making the distinction between them relevant in terms of
taxonomy, but not disonant in terms of code.

Sadly, there are relatively few well-known examples of this nowadays. I
struggle to build such systems every day, but I think I fail most of the time
:-).

~~~
d23
I'd be curious to hear your examples in real world terms :-)

~~~
weland
There are good examples to see in well-written device drivers. I don't have
specific code at hand, but there are bits and pieces that stuck to me.

For example, there was this driver that could do pattern-matching on button
presses, written by an ex-colleague of mine. The way this is done by most
developers is to hardcode some state machines (there's a limited set of
patterns that have to be matched anyway) and populate an array of callbacks
for each. This one did something rather different (hopefully, I can remember
what; it's been a few years since I've seen that code).

The patterns it had to recognize were arbitrary combinations of short and long
button press or hold sequence, double presses and triple presses. Instead of
having the state machines hardcoded, the programmer would define a state
machine by defining an array of press patterns (e.g. button_event_t events[] =
{BTN_CLICK, BTN_HOLD, BTN_DBL_CLICK, BTN_SEQ_END}) and register it with the
driver, which added it into a list of patterns to match against. Each pattern
could also have as many callbacks to be launched as needed.

The button driver itself had absolutely no idea about all this pattern crap,
all it did was receive interrupts from GPIO ports and place them in a queue.
An "event" matcher would munch on that queue, interpret elementary events
(like button was pressed, button was depressed, button was held etc.) and put
these in another queue that was pushed to the "action" matcher. Each time
there was an interaction with it, it would start a new pattern matching drill;
it would walk the list of events it knew about, "add" those whose first step
matched the current one to a temporarily-used list (it was only adding
pointers, of course, not copying the actual event) and "remove" the first
press pattern (it would actually increment an index counter so as not to start
copying bytes around). If nothing happened before a certain amount of time
passed, the list would be disposed of. If it did, however, the temporary list
would be walked again, removing those elements whose new first step didn't
match the current one, and so on until the list would be brought down to one
element. The callbacks would then be scheduled to run (these were actually
delayed jobs, not blocking function calls), the one-element list disposed of
and so on.

This was beautifully structured in every possible way:

1\. The button driver, that did the GPIO magic, only worked with GPIO
interrupts.

2\. Recognizing specific user presses was done by another subsystem, and

3\. Recognizing specific _sequences_ of user presses was done by another
subsystem

None of these had to do anything foreign to them: the button driver (which
encompassed roughly #1 and #2 with nice separation between them) only did
button stuff. Matching sequences of button actions superficially sounds like
"button stuff" which is why it's routinely mashed in the same soup, with
horrible results, but this one wasn't.

It had the further advantage that now automatic testing of anything was
blatantly trivial (background: each sequence of presses would trigger actions
that could potentially take up to one hour), since events like BUTTON_PRESSED
or BUTTON_HOLD didn't have to come from actual interaction, they could be
pushed in there by a test routine communicating with a PC through a serial
port. Extending the range of possible actions or redefining them was trivial,
since all that had to be done was edit arrays. It was also trivial to allow
customization of these sequences by end-users.

But this is also aesthetically pleasing: there's no conflict of abstraction
between "software"and "hardware". There is one module that abstracts only what
is relevantly abstracted in hardware, and produces purely software-
abstractions, that are meaningful only to humans, not silicon, such as
BUTTON_HOLD events (silicon only knows about signals it translates into a bit
flip which we like to call an interrupt). It didn't push non-silicon stuff
into software that spoke to silicon, nor did it push silicon stuff high up
there where there should only be software stuff.

Oh yeah: this was on a microcontroller that had 4K of RAM, and the software
also included a communication stack for some weird-ass protocol, a flash
driver, a temperature sensor, energy metering, LED signaling, toggling an
array of relays, driving a buzzer, a firmware upgrade mechanism, a sort of
application settings manager, a clock (the kind that shows the hour) with
multiple alarms and the rest of the OS, pretty much all of it written by us.
This guy was a guru though. The parts written by me sucked.

------
dbpokorny
"When a program is being tested, it is too late to make design changes"

Clearly never used HyperCard.

------
Sweyla
With not a single mention of a female programmer (but many he's and him's), I
can't get behind this. Let's be an inclusive community, please.

~~~
AnimalMuppet
You're looking at an old text here (even though it was just posted on HN).
From the mention of DOS, I'm guessing it was written in the 1980s. Inclusive
language was not yet common at the time.

You'd like it to be re-written with inclusive language. It's OK to want that,
I guess, but... when faced with a pre-inclusive-language text, what will you
do? Accept it for what it is (old, written by people not yet aware of this
issue)? Or will you reject it because of what it is not?

Perhaps the best answer is to find the author and gently suggest an inclusive
re-write. (And perhaps that's what you were trying to do, but I suspect that
the poster is not the author. Finding the author may unfortunately take a bit
more digging.)

~~~
Sweyla
I see. I had the impression it was newly written in a retro style. This makes
a lot more sense now and I can appreciate it as a historical document.

