A Programmer's Guide to the Meaning of Life

Lee Bradley

Table of Contents
1. Things take time. Why most endeavors need to go thru many
revisions before they are complete.

2. Know your limitations. Why it's important to know the environment
you're in.

3. Add something. Contribute something new.

4. Recycle, Reuse, Reduce. It's not just true for plastic and
paper any more.

5. If you can't find it, build it. When you can't locate something
you thought was interesting, roll your own!

6. Give yourself a call. The pervasive nature of recursion.

7. Work together. Mix 'n' Match. Teamwork is key.

8. Fake it! Simulate when you can't solve.

9. Don't Shade Your Eyes, Analogize! Understanding comes from seeing
relationships between things.

10. Write to the Top! Try to contact the people you've read and love
with questions and kudos.

11. What's with that cover?! Changes since the first publication.

"Everyone should learn how to program a computer because it teaches you
how to think." Steve Jobs

Amby Burfoot's book, "The Runner's Guide to the Meaning of Life," has
motivated me to write "A Programmer's Guide to the Meaning of Life."⁰

0. http://primepuzzle.com/tc/programmer's_guide.html

Lesson 1: Things take time.

It is now March 16, 2020. This "Lesson" used to start with a discussion
of a program I wrote that factors numbers. It is written in tiny-c.
The source code may be found at http://primepuzzle.com/jslinux/factor.6.2.tc

Factoring numbers (writing them as the product of their prime factors)
is complicated. It's difficult to explain how this program does it.
Instead of doing this I will summarize by saying that it went through
countless changes until I was satisfied with it.

I tutor at a local community college. Here's a paper I wrote a few years
back that compares writing a computer program to writing an English
paper.

Writing a good English essay is a bit like writing a good computer
program. This article will highlight what they have in common and, by
doing so, help writers produce better papers. As it is likely the reader
is not a programmer, she will learn something about this skill along the
way! To accomplish this comparison, we will talk about how programs and
essays are organized, what basic elements are used in their construction
and how they evolve.

A classic tool for essay writing is a "Graphic Organizer." This is a
diagram with, typically, five boxes, one up top, three below in a
horizontal row and, at the bottom, a final box. You fill the top box
with your paper's topic (subject) and thesis (position or argument
you'll be taking). An introductory remark that tells the reader what you
intend to expand on belongs here as well. (As I write this, I am
actually doing what I am describing; we are currently turning the first
of the three boxes that fall below the top box into English!)

The elements of a paper include a title, paragraphs and, of course,
words, punctuation and, often, footnotes and references. The words
(built from upper and lowercase letters and special characters, like
hyphens) are governed by a variety of rules (spelling, grammar, etc.)
The words possess "attributes," which we call parts of speech (noun,
verb, etc.) (What box are we filling in now?!)

Who thinks I wrote the above three paragraphs straight "off the top of
my head?" I did not. Papers evolve. (We are in the third box of that
horizontal row of three now, in case you missed it!) Writing is a
dynamic endeavor and good papers usually go through several draft stages
before they are ready for publication. Words get crossed out, changed.
Sentences get moved around. Overly complicated explanations get
simplified.

Computer programs ("I was wondering when he was going to tie this in!")
exhibit features similar to the three discussed above for English
papers.

The graphic organizer of programming is the "Flowchart." Although
less used today than in the past, a flowchart is a tool for sequencing
the major steps, decision points and loops a program will use to
accomplish its task. Often, a box representing a major task will be
"refined" into a sequence of sub-tasks, not unlike what we are doing
here as we turn the concept of a graphic organizer into sentences
illustrating their use.

The elements of a computer program have their English paper
counterparts. A paper's title is like a program's name. A series of
individual instructions can be blocked together using brackets or braces
to form a paragraph-like element. The "nouns" of computer programs are
called "variables." You name these variables. "counter" might be what
you call a variable that keeps track of how often something happens.
They end up as places in computer "memory" which hold data (a number, a
character string etc.) The "verbs," as in English, cause some sort of
action or change. They are called "functions" or "methods" or
"procedures." For example, you could define a function called "plot" and
use it in a program statement like plot("*",3,12) which would put an
asterisk on the screen at row 3, column 12.

Computer programs seldom "work" on the first shot, just as English
papers never are perfect after an initial draft. Both have syntactic and
semantic problems. Both can be made more efficient, simpler, easier to
understand. Instead of a tutor or a teacher or a peer review to help you
improve your paper, you have the computer itself to help you by
providing error messages, unexpected output, etc.

We have finally reached that promised bottom box of our paper. It's time
to wrap up what we've said with a conclusion or two. We have (hopefully)
made good on our claim that English papers and computer programs share
many fundamental similarities. It follows that if you learn something
about one skill you will get better at the other! Did it ever occur to
you that learning how to program in C would make you a better
communicator in English?

Lesson 2: Know your limitations.

This sounds like a negative thought. Quite the opposite. The environment
we live in is both an opportunity and a challenge. You need to become
familiar with it if you want to be productive. In the case of tiny-c,
you can't use numbers that are larger than 32767. You also are limited
in the number of variables you may declare. Fortunately, I found that I
did not exceed the variable restriction when I determined I needed to
declare the array that holds the prime numbers in our current sample
program to be 3513 elements. Also, all primes less than 32767
could be held in this array which meant that I no longer needed to check
for the index variable s going out of bounds.

There are many other examples of why it's important to know your
limitations. Variable names must start with a letter, can't contain
certain characters and only the first 7 and the last character of a name
matter. Violating these rules results in errors. It's not unlike what
happens when you speak to someone using words that are not known to the
person who hears them. They don't understand what you are talking about!

Limitations are an opportunity. tiny-c is a fairly old language and is
incapable of carrying out all sorts of things more modern languages have
no trouble with. However, if you take advantage of key features it does
support, you can solve very complex problems. An upside to the fact that
it is a limited language is that it is easier to learn than more modern
languages. In fairness, it is not a total breeze to learn and its
limitations will often bite you with errors that take time to resolve.
Perhaps a corollary to Lesson 2 is You Have to Work at it! Remember, this
little book is called "A Programmer's Guide to the Meaning of Life!"

Lesson 3: Add something.

Garelick Farms (a local dairy) has this motto: "The key to life is what
you add to it. Add something."

I have added things to the tiny-c language. I implemented it when it was
created by typing in many pages of code and debugging it. I reached out
for help during this period and hooked up with another programmer who
saw features the language was missing and added them. Much later, I
created a social media group dedicated to the language. The author of
tiny-c, Tom Gibson, discovered this group and offered to write a memoir of sorts
giving us a detailed account of how it all started and eventually became
a product. Later yet, he wrote about his work in Java, another
programming language. He used a game he wrote in tiny-c as a base for
what eventually became a tutorial in object-oriented thinking.

My role seems often to be that of an editor. I fixed his spelling and
sentence structure. I am a good tester and documenter. I add by
promoting and by creating applications. Add something.

Lesson 4: Recycle, Reuse, Reduce.

I keep a bunch of 3-ring binders which contain many of the programs I've
written. It's like a dictionary (because it's tab-indexed
alphabetically) but it has listings, not words. When I get an idea for a
computer program I search my memory for something I've written that
might be similar and if I'm lucky I can remember the name and quickly go
to the binder and turn to the code. For example, one of the things I
have difficulty remembering is how to write web pages that contain input
forms. When you browse these pages, you enter stuff and then click a
button and some sort of processing takes place. The results are fed back
to the page. The language that is often used to support this kind of
thing is Javascript.

"There is nothing new under the sun." In a way, all such pages are the
same. "Don't reinvent the wheel." Reuse. Copy the code and then
modify it.

I learned Javascript when I was asked to develop a website for somebody.
They showed me a site they liked and said "Make my site look like that."
When you are browsing a website you can ask the browser to show you the
source code that is driving it. You grab the code, save it and then
change it to fit your needs. Recycle.

The idea of reusing things is fundamental in life. We build and buy
tools, store them in boxes, garages, basements, pockets etc. When we
need to do something (repair the deck) we remember "my hammer and my saw
will take care of it." So we fetch them and use them. In computer
programming, the analog is fetching applications you wrote or learned about
and reusing them, usually after changing them. Perhaps the most elementary
example of reuse is the function. Many programming languages
allow you to collect together little modules of code that often expect
some input, do some processing and return some output. These vary from
very low-level operations to very complex routines. The job they must do is
identified during program development. Frequently, the program will need
to call for their services multiple times.

Using this approach, the size of the program is reduced. Further
reduction in program size results when you discover you don't need a
variable you declared after all because you can reuse one that has
served one purpose and can be used for another.

When programs run, there is a constant recycling of computer memory as
functions get invoked and finish their job. Variables local to the
function grab memory, use it, and then release it. The activity behind
the scenes of a running program is mind-boggling and goes completely
unnoticed. The term "garbage collection" is actually used to describe
this memory recycling.

Lesson 5: If you can't find it, build it.

I came across an old book in my basement some time ago. "Karel the
Robot." I don't think I ever read it after I bought it. I could not even
remember where or why I bought it. While running a few days later a
light went off in my head and I vaguely remembered some software that
implemented what the book discussed. I searched every dusty disc I could
find and only came up with about half of what I needed. I even tried to
contact the author of the software but she had long since moved on to
other things. (I've had this experience several other times.) It annoyed
me no end. Karel the Robot fascinated me and I couldn't get him to do
his thing. I'll tell you what "his thing" was in a few moments. Then it
occurred to me ... this might be a huge project but why not write an
emulator for Karel in tiny-c? I will never forget the day when I got a
piece of paper out and sketched a simple rectangle, labeled the left
edge with "street" names 1, 2, 3 etc. and the lower edge with "avenue"
names 1, 2, 3 etc, and, voilà, Karel's grid world was born. It would be
months later that I'd figured out how to encode these addresses and
write routines that captured Karel's primitive instructions ... turn
left, pick beeper, put beeper, move forward etc. If you can't find
it, build it.

Karel simulators that are way more modern and graphical and powerful are
easy to find. One thing I like to do is try and contact authors who've
written things I learn from and love. Every so often I get lucky and
they get back. I tell them why I like what they did and, when it
applies, what I've done that complements their work. On real lucky days
they praise me for my work. Sometimes I think a large fraction of what
people do is what I call "Look Ma." How many of us when we were young
boys/girls made sure we made our parents who were nearby become aware
of the dive we were about to make off the diving board? Many of us never
grow up and like to show off what we make and hope we get an attaboy. To
solidify my stature as a legitimate Karel developer I actually added a
line item to a Wikipedia page. I was both amazed and a little concerned
that the Wiki police found my entry possibly self-promoting but I stuck
to my guns and didn't remove it because I was not about to hide
something I'd spent so much time working on. I don't know if anybody's
ever looked at my code but I like to think it is a minor masterpiece and
hope at least a few visitors learn something from it.

Note: A closely related lesson is If you can't understand how someone
else did it, try to figure it out yourself. An example of this: I
learned that someone had written a Bulls and Cows solver which used the
concept of entropy. I couldn't quite follow the Python code and, after
much effort, produced a working solution. The game and my solution are
documented in

http://primepuzzle.com/tc/cliffsnotes.html

Lesson 6: Give yourself a call.

Here's a picture of Karel in action ...

The code that supports Karel's trip over the "hurdles" follows.

* recursive sample program */

seek_next [
if (front_is_clear) [
if (right_is_blocked) [move;seek_next] /* recurse */
]
]

hurdle [
while (right_is_blocked) move
turnright;move;turnright
while (front_is_clear) move
turnleft
seek_next
if (front_is_blocked) [turnleft;hurdle] /* recurse */
]

turnright [turnleft;turnleft;turnleft]

turnaround [turnleft;turnleft]

main [
putbeeper /* leave marker */
turnleft
while (right_is_blocked) [
move
while (next_to_a_beeper) pickbeeper /* 2/13/2013 */
]
turnright
move
turnright
while (front_is_clear) move
turnleft /* heading north */
hurdle
turnaround;move
while (any_beepers_in_bag) putbeeper
turnaround
move
turnright
move
turnright
while (not_next_to_a_beeper) move
pickbeeper
turnright
]

Showing you just 6 frames of his trip doesn't do it justice but may
suffice.² The hurdle function calls itself! There's something about
hurdling that's repetitive. And ... hurdle itself calls the function
seek_next which also calls itself.

We are emphasizing the importance of recursion (calling yourself) here
but here's another big idea: problems we encounter in life are best
attacked by what is called "step-wise refinement." Here, main plays the
role of the complete task. After some preliminary "beeper picking," our
cute little robot (the yellow figure) will be heading north and have the
first hurdle on his right. We tell him to hurdle. Eventually, he'll have
gotten over all of them and will do other stuff to finish his task.

We refine the hurdle task in a separate function called hurdle. Again,
we're not trying to teach you programming here but this Karel language
is fairly readable and you can probably guess what's going on.

Give yourself a call. That's crazy! You can't call yourself! If
you pick up the phone and call yourself (I really need to try this!)
you'd probably find the line would be busy. But in programming and in
many natural phenomenon, things follow rules that are self-referencing.

Here's what's called a syntax diagram. Notice how a mathematical
expression, deep down, includes itself in its definition.

My experience has been that routines I find I need and have named (like
hurdle and dpf, see below) almost miraculously beg self-reference. I
wrote something that mimicked long division, a fundamentally repetitive
algorithm. The task was to convince my language, tiny-c, which does not
do decimals, to display the decimal representation of fractions like
17/239.

/* display proper fraction */

dpfx int n,d,p [
if p [MC 10*n/d,14;dpfx 10*n%d,d,p-1]
]

dpf int n,d,p [
putchar '.'
dpfx n,d,p
]

When you run this function you get:

tc>.dpf 17,239,21
.071129707112970711297

Notice how dpfx calls itself. There are many things in the code above
that need explaining but we'll skip doing that. Try manually dividing
239 into 17 sometime. You will be reminded of the good ol' days when you
first learned long division. Just kidding.

Determine the first number of the quotient after the decimal point.
Multiply it and the divisor and subtract the product from the dividend.
Repeat.

That's what dpfx does!

2. Full video at http://youtu.be/imQBhNPc_ic

Lesson 7: Work together. Mix 'n' Match.

Tobeellama Libstik

Summ tyme ago a frend ov mye brother's notissed er kat wuz tawkun
lyke a baby and aboot ten month's lader a full-blown application dat
helped udda kat owners teach their katz tah dew da saym wuz
world-famous.

Translation by http://primepuzzle.com/blog/jspeek.html

using a 1543 word dictionary.

Let's try that again, in English, lol.

Some time ago a friend of my brother's noticed her cat was talking
like a baby and about ten month's later a full-blown application that
helped other cat owners teach their cats to do the same was
world-famous.

Her cat's name was Toby. He has since left us but while he was with us
he provided us with many opportunities to create funny stories and
challenging puzzles. Her artistic skills and my programming skills were
a perfect match. We worked together, created a blog and amused ourselves
for a couple of years, creating words that were close to real words but
silly enough to make you smile.

Translation from English to Toby Speak ended up being a fairly
non-trivial undertaking. Toby's "Mom" and I debugged and developed
together. My original ideas for what the translator would do were too
ambitious and it simplified to merely looking up English words and, if
found, turning them into Toby words. Real languages aren't so
straightforward. For example, in French

I love you. -> Je t'aime.

But in Toby Speak

I love you. -> Ize luv u.

Notice how the word order changes in French and the need for a contraction.

We had a ball. Toby's "Mom" would send me messages in Toby Speak and I
would spot the new made-up words, realize what the English word was and
add it to the dictionary. She and my brother would soon tire of the
daily updates to my translator (think Lesson 1).

One of the most important aspects of why this project was successful was
that both developers love fantasy and also have an interest in things
like Quantum Mechanics, weather, ancient history, Eastern religion etc.
We matched these fields and our fantasy, and had Toby becoming a "Roman
Emperor, an expert in Quantum Mechanics, a Zen Master etc.".

Excuse me ...

"Roman Empurroar, an expuht in Kwantum Mekaniks, a Zen Mastah etc."

I will never forget how amazed I was when I decided to implement my
translator in Javascript and knocked it out in a day or so! What had
taken me months to build in one language took me only a couple of
days in another. Mix 'n' Match!. I was translating a translator, so
I already had a working process. It's easier when you've already done it.

I think I have written a "file dumper" in at least four languages. I
first saw how this could be done in 6502 assembly language. Then I saw
how someone else did it in a C-like language called SIL. A Z-System
developer figured out how to turn this version into a Z-System utility.
I won't go into details on this but I do want to say I learned a lot
from what he did and was also very pleased he found what I had done
interesting enough to improve it.

Here's what my tiny-c file dumper does to this paragraph.

rdump.tc - tct - 3/21/10

Rec 0

49 20 74 68 69 6E 6B 20 49 20 68 61 76 65 20 77 I think I have w
72 69 74 74 65 6E 20 61 20 22 66 69 6C 65 20 64 ritten a "file d
75 6D 70 65 72 22 20 69 6E 20 61 74 20 6C 65 61 umper" in at lea
73 74 20 66 6F 75 72 20 6C 61 6E 67 75 61 67 65 st four language
73 2E 20 49 0A 66 69 72 73 74 20 73 61 77 20 68 s. I.first saw h
6F 77 20 74 68 69 73 20 63 6F 75 6C 64 20 62 65 ow this could be
20 64 6F 6E 65 20 69 6E 20 36 35 30 32 20 61 73 done in 6502 as
73 65 6D 62 6C 79 20 6C 61 6E 67 75 61 67 65 2E sembly language.

Rec 1

20 54 68 65 6E 20 49 20 73 61 77 0A 68 6F 77 20 Then I saw.how
73 6F 6D 65 6F 6E 65 20 65 6C 73 65 20 64 69 64 someone else did
20 69 74 20 69 6E 20 61 20 43 2D 6C 69 6B 65 20 it in a C-like
6C 61 6E 67 75 61 67 65 20 63 61 6C 6C 65 64 20 language called
53 49 4C 2E 20 41 20 5A 2D 53 79 73 74 65 6D 0A SIL. A Z-System.
64 65 76 65 6C 6F 70 65 72 20 66 69 67 75 72 65 developer figure
64 20 6F 75 74 20 68 6F 77 20 74 6F 20 74 75 72 d out how to tur
6E 20 74 68 69 73 20 76 65 72 73 69 6F 6E 20 69 n this version i

Strike Any Key (space to quit)

Rec 2

6E 74 6F 20 61 20 5A 2D 53 79 73 74 65 6D 20 75 nto a Z-System u
74 69 6C 69 74 79 2E 0A 49 20 77 6F 6E 27 74 20 tility..I won't
67 6F 20 69 6E 74 6F 20 64 65 74 61 69 6C 73 20 go into details
6F 6E 20 74 68 69 73 20 62 75 74 20 49 20 64 6F on this but I do
20 77 61 6E 74 20 74 6F 20 73 61 79 20 49 20 6C want to say I l
65 61 72 6E 65 64 20 61 20 6C 6F 74 0A 66 72 6F earned a lot.fro
6D 20 77 68 61 74 20 68 65 20 64 69 64 20 61 6E m what he did an
64 20 77 61 73 20 61 6C 73 6F 20 76 65 72 79 20 d was also very

Rec 3

70 6C 65 61 73 65 64 20 68 65 20 66 6F 75 6E 64 pleased he found
20 77 68 61 74 20 49 20 68 61 64 20 64 6F 6E 65 what I had done
0A 69 6E 74 65 72 65 73 74 69 6E 67 20 65 6E 6F .interesting eno
75 67 68 20 74 6F 20 69 6D 70 72 6F 76 65 20 69 ugh to improve i
74 2E 0A 0A t...

tc>

As a programmer at Travelers Insurance Company the Work together
mantra was everywhere. We worked on huge projects involving many teams,
extensive testing and thousands of lines of code. Specifications were
given in spreadsheet form. Very high level languages were used by the
programmers. What they produced was translated into lower-level
languages and finally ultimately compiled into executable code.

Lesson 8: "Fake it!"

Not sure the Lesson title is good but let's roll with it. Speaking of
rolls, the idea of rolling dice in games to determine next steps is
common. In the game of Craps, "snake eyes" (both die show one pip) is a
bad thing. The probability of snake eyes is 1 in 36, i.e. very unlikely.

Some problems we encounter are so hard we often resort to using random
number generators to approximate solutions. We create fake
reality by rolling software dice.

Here's an example. Enter Andy the Amoeba!

Note: "Andy" was dreamed up after "Toby" posed the problem. A
handwritten exposition of the mathematics behind this problem may be
found at http://primepuzzle.com/tc/amoeba.html.

Graphic by Chip Bradley

Tobee mayd a nu poozle. He haz a jar wid wun amoeba in id. Eweree minit,
eweree amoeba turns into 0, 1, 2, or 3 amoebae wid a probubbillitee ov
25% foah each case (dies, duz nuddin, splits into 2, or splits into 3).
Wat iz da probubbillitee dat da amoeba population eventually dies owd?

For those of you who can't read Toby Speak ...

Toby made a new puzzle. He has a jar with one amoeba in it. Every minute,
every amoeba turns into 0, 1, 2, or 3 amoebae with a probability of
25% for each case (dies, does nothing, splits into two, or splits into 3).
What is the probability that the amoeba population eventually dies out?

It turns out this probability can be solved for analytically and is
equal to √2-1 or roughly .41. This means that if you investigate
10 situations that start off with a single amoeba about 4 would die
out.

// amoeba.linux.tc - tct - 7/10/19

int gseed

randint [
int k1,ix;ix=gseed
k1=ix/127773
ix=16807*(ix-k1*127773)-k1*2836
if (ix<0) ix=ix+2147483647
gseed=ix
]

main [
pl "amoeba.linux.tc - tct - 7/10/19";pl ""
pl "An amoeba either dies, lives, splits into two or splits into three,"
pl "each with probability 1/4. It can be proved that out of 10"
pl "simulations, about 10*(sqrt(2)-1), which equals about 4,"
pl "populations will die out. It can also be proved that 1.5^n"
pl "is the expected number of amoebas after n generations. If n=10,"
pl "58 amoebas are expected.";pl ""
int c,p,pp,psp,s,gens,n,ptot
pl "seed? ";gseed=gn
gens=10
s=1
while s<=10 [
p=1;n=gens
while n*p [
n=n-1;psp=0
pp=1
while pp<=p [
randint;psp=psp+gseed%4
pp=pp+1
]
p=psp;if p==0 c=c+1
]
ptot=ptot+p;ps "simulation ";pn s;ps ": population";pn p;pl ""
s=s+1
]
pl "";pn ptot/10;ps " amoebas, on average, were living after"
pn gens;ps " generations.";pl ""
pn c;ps " population(s) died out.";pl ""
]

The reader may be aware that, according to Quantum Mechanics, reality
itself is driven by random events and what we experience is in the
deepest sense driven by probabilities. The field of Statistics is based
on "probability distributions" and is used to test hypotheses about such
things as the expected value of some measurement like the height or
weight of individuals from a certain population.

One of the most amusing games I've ever seen is Piranha Fish. I won't
show you any of the code but I will show you the rules. The various
strengths of players and the probabilities of certain events is shown
below. This game is pre-Pac Man, pre-Mario Brothers, pre-Graphics so
don't get too excited about the interface if you ever run it.

But the realism of what happens in a given game is pretty good. And it's
all because a random number generator is used to simulate reality.

I can't resist. Here's one of the functions used in Piranha Fish.

/* A fish jumped in the boat. This is what happens. */

onefish [
char p
pl"A piranha fish has jumped into the boat. He is swimming"
pl"around. He is looking at the toe of the "
pname(p=move(random(1,ngoing)))
ps"."
if(health(p)>4) pl"Oh, well. He's dead anyway ..."
else if(p>6) [
pl"The missionary is calm. He is staring back at the"
pl"fish. The fish just jumped back into the river."
]
else if(p<3) [
pl"The cannibal has speared the fish."
if(random(0,1)) [
pl"Unfortunately he made a hole in the"
pl"boat, increasing its sink rate 10%."
sinkrate=sinkrate+sinkrate/10
]
]
else if(p<5) [
pl"The hunter has panicked. He is rocking tbe boat ..."
capsize
]
else if(p==5) [
if(random(0,1)) [
pl"The doctor is quick. He shoots the fish full of"
pl"a drug."
]
else [
pl"The doctor has panicked. He is rocking the boooooat!"
capsize
]
]
else [
pl"The nurse has panicked. She is rocking the boat."
pl"Everybody is yelling at her. Yell - yell - yell."
if(random(0,1)) pl"She is calm now, and sits down."
else [
pl"She falls out of the boat. She is swimming."
swim 6
]
]
]

Note: As mentioned earlier, Tom Gibson wrote Piranha Fish. Much later he
used it as the starting point for illustrating Object Oriented
Programming in Java. Here's the graphics version! (This will appear
if you are browsing this file with Firefox *and* you have the Java 6
plugin installed.)

Lesson 9: Don't Shade Your Eyes, Analogize!

Of course this is a play on the great Tom Lehrer's "Don't Shade Your
Eyes, Plagiarize."³

As suggested in Lesson 4, using the work of others to create your
own is recommended. Here, we're recommending you look for similarities
among things in order to understand them.

Parables, myths and the like are a good way to learn concepts. Another,
very different, approach is to use fantasy and humor. For example, take
Lebsterberg's Uncertainty Principle.

Lebsterberg's Uncertainty Principle

The inequality

Uncertainty in Knowledge * Uncertainty in Letters > Rank's constant

In other words, the less unsure our Knowledge of something is, the more
Letters we need to describe it. The precise value of Rank's constant is not known
(because there aren't enough numbers to write it). For a marginally related concept,
please see The Law of the Conservation of Letters.

Now, this is of course a totally bogus Principle, but, if you've ever
heard of Heisenberg's Uncertainty Principle, you'll both smile a bit and
also see that in some deranged sense Lebsterberg's analog might actually
be sort of true.

I have studied the Java programming language. A co-worker asked me
to help her with her assignment. Her class used BlueJ, a
Java development environment. I have used many IDEs (Integrated
Development Environments). These days, very high-level, often online, graphical
interfaces are available to code and test. They of course differ from
each other but they also have many things in common. Menus, mouse usage
and even the low-level language constructs are similar. Learning
object-oriented programming in Java makes learning object-oriented
programming in Python easier.

The job market has clearly migrated away from a command-line, procedural
language environment to a point-and-click, GUI (Graphical User
Interface) environment. Seeing the analogies between the concepts of these
new environments is a requirement for survival in the field.

The analogies between abstract mathematical concepts and physical
reality are well-known. Hilbert spaces were never predicted to have any practical
use but are now seen to model the probability waves of Quantum
Mechanics. Steven Weinberg writes "The universe is an enormous direct product of
representations of symmetry groups."⁴ The brain itself has
been compared to a highly complex programmed processor. Watson and
Crick's double helix is a duplicating "machine." Models like these suggest
the meaning of life is somewhat understandable if we create things with
certain properties and "behaviours" which mimic what we observe.

3. https://www.youtube.com/watch?v=UQHaGhC7C2E

4. http://www.cmth.ph.ic.ac.uk/people/d.vvedensky/groups/Chapter6.pdf

Lesson 10: Write to the Top!

Amby Burfoot has an Insight titled "A Runner's Essential Reading." Here
we mention authors I've actually written letters to and/or admire.

Often, my decision to write to someone is motivated by my being stymied
by a problem which only the world authority on the subject can answer.
So I write to the top man or woman in the field. It's a thrill to
hear back from them. It does not always happen but when it does I learn
more and thus give my (their) life more meaning.

Everyone has her/his list of heroes. Who are yours?

Joe Wright was a leading developer for an enhancement to Gary
Kildall's (see below) CP/M operating system called Z-System. I phoned
him a long time ago and asked him about something he had written in a
journal I subscribed to. It was like "talking to God." Just kidding of
course but having a brilliant person on the other end of the line, a
person I had never met, was amazing. I felt I had to choose my words
carefully, not waste his time. The end result was that I had identified
a bug in what he'd written and later figured out how to fix it. Joe and
Howard Goldstein were co-developers of Z-System. At a meeting attended
much later in New Jersey Joe described Howard as the man "with a black
thumb." By this he meant Howard could find bugs better than anybody. And
here was little ol' me finding a bug in Joe's work!

I contacted Fabrice Bellard and asked him for help on compiling
the tiny-c interpreter under Linux. You've got to have guts to do this.
Fabrice is one of the smartest men on the planet. I fell upon a piece
some time ago that was a collection of statements various people had
crafted comparing his brilliance with that of other luminaries. It was
very funny. I am kicking myself for not saving it for, despite multiple
efforts, I can't find it again. Maybe I should ask him if he's ever seen
it! Oh well. I was shocked when I actually heard back from him. He told
me what I needed to do.

tcc analyze.c lnx.c scan.c utility.c main.c stack.c custom.c mc.c
symbol.c enter.c -o tinyctcc -L/usr/lib/ -lc

tcc is his compiler. The uppercase L and lowercase l options at
the end were what I needed. They both have to do with library look ups.
Here I had a very complex collection of .c modules and I was sure all I
needed was to know the "magic script" that was needed to build the
executable. It worked like a charm.

Peter Grogono has written books on Pascal and Mouse, both
programming languages. I'll never forget the day I spotted his book
"Mouse: A Language for microcomputers" at a local bookstore. I flipped
thru the pages and spotted a Z80 assembly language listing of the
interpreter for his Mouse language. There was also an interpreter written
in Pascal. I typed it in. Compiled it with my Turbo Pascal compiler.
I called him up just to thank him. Amazing. I actually talked to Peter
Grogono! It's worth pointing out that these conversations are often as
interesting to the caller as they are to the called. Peter built a blog
dedicated to Mouse and mentioned the four or so people who had developed
things using his language.

Mouse is a tiny language. All instructions are a single character long!
Unless you have worked with it for quite awhile, it's pretty unreadable.
But it supports recursion, macros, local and global variables. Here's
the nursery rhyme "Old MacDonald had a farm."⁵

~ MacDonald's Farm - pg - 7/8/84

~ lrb - 9/17/14 - Added snakes. Other cosmetic mod's.

("!!How many verses ? " ? n : n . 7 > [7 n :] n . 0 > ^ #S,1,n .;)

$S "!" #V,0; ",!And on this farm he had some "
#W,1%; #R; ", !With a " #V,1%; ".!" #X;
1% 2% < [#S,1% 1 +,2%;] @

$V 1% 0 = ["Old MacDonald had a farm" #R; @]
#A,#M,1%;,#N,1%;; "!" #V,1% 1 -; @

$X 10 y : (y . ^ 32767 x : (x . ^ x . 1 - x :) y . 1 - y :) @

$A #C,1%,2%; "!" #B,"H",1%; #B," th",2%; #B," everywh",1% " " 2%; @

$B 1% "ere a " 2% "," @

$C 1% " " 2% " here and a " 1% " " 2% " there," @

$R ", ee-igh, ee-igh, oh" @

$M 1% 1 = ["Chick" @] 1% 2 = ["Quack" @]
1% 3 = ["Gobble" @] 1% 4 = ["Oink" @]
1% 5 = ["Moo" @] 1% 6 = ["Hee" @]
1% 7 = ["Hiss" @]

$N 1% 6 < 1% 7 = + [#M,1%; @] "Haw" @

$W 1% 1 = ["chicks" @] 1% 2 = ["ducks" @]
1% 3 = ["turkeys" @] 1% 4 = ["pigs" @]
1% 5 = ["cows" @] 1% 6 = ["donkeys" @]
1% 7 = ["snakes" @]

Donald Knuth is writing "The Art of Computer Programming," a
multi-volume work. The title alone tells a lot. He feels programming is
an art, no less so than painting, dance etc. Programmers are (or can
be/should be) artists. Programs can be beautiful. He has a quote from a
cookbook at the very beginning of Volume 1 that's both amusing and true:

Here is your book, the one your thousands of letters have asked us to
publish. It has taken us years to do, checking and rechecking countless
recipes to bring you only the best, only the interesting, only the
perfect. Now we can say, without a shadow of a doubt, that every single
one of them, if you follow the directions to the letter, will work for
you exactly as well as it did for us, even if you have never cooked
before.
-- McCall's Cookbook (1963)

Knuth is a bit of a recluse I think. He doesn't do email. The computer he
works on has no internet connection. He tells you that if you want to
contact him write a letter to his secretary. And he indicates getting a
response is unlikely. I wrote him a letter and did not hear back. I did
not expect to hear back. I can't even remember now what I said in my
letter. I think I just wanted to thank him.

Roger Penrose's "The Road To Reality - A Complete Guide To The
Laws Of The Universe" is ambitious to say the least. The book is very
thick. It covers, well, everything! For example, the first thing I
checked was to see if he mentioned Hugh Everett III's take on Quantum
Mechanics. Everett had an interpretation that went counter to the one
Niels Bohr promoted. I believe Everett was even encouraged by Albert
Einstein to visit Bohr. It should be noted that Einstein himself was
never convinced that Quantum Theory was true. Penrose did not disappoint
and dedicated many pages to this alternate interpretation. I never
expected Penrose to get back. He didn't. Again, I just wanted to thank
him.

Ken Barbier has written many books. The one that I first bought
was "CP/M Assembly Language Programming." The book starts off by
telling you to type a very short assembly language program in at your
keyboard. No. I take it back. He told you to directly punch in some
hexadecimal bytes directly into computer memory and then "run" them
using a program called DDT (no, not the banned insecticide, the "Dynamic
Debugging Tool" of CP/M). The program caused the character '$' I think
to display on the console. Not your most exciting or useful program but
it was the beginning of a journey that ended with the reader knowing how
to write a program that copied files. The learn-by-doing approach is a
powerful teaching tool. The book taught me hundreds of important ideas.
A key one was to modularize a task.

I either wrote or discovered a program much later that allowed you to
transfer files between two computers using a "null modem" cable. I
shared it with Barbier. In one of his later books he had a chapter on
how one would do such a thing and the code looked suspiciously like
"mine." He did not give any references to his code. I've always wondered
if he, well, you know.

Tom Gibson wrote tiny-c. Our correspondence was hinted at in
Lesson 3.

I never spoke with Buckminster Fuller but I had the rare
privilege of seeing him speak at the University of Massachusetts. I had
read that people who had seen him were mesmerized by his enthusiasm and
energy. He wrote "Synergetics: Explorations in the Geometry of
Thinking." The book is, for me anyway, right up there with James Joyce's
"Ulysses" in that it is essentially unreadable. This does not mean it is
bad. I'm just not at their level. They both used vocabulary, especially
Fuller, that they made up. They added something. See Lesson 3.

Leor Zolman wrote the BDS C compiler. This was an important
product in the early days of "PCs." Actually, it predated the time
computers were called PCs. In any case, it was a step up from tiny-c.
Interestingly, Zolman did not use tiny-c to bootstrap his compiler.
After selling many thousands of copies he decided to put it in the
Public Domain. He had a website and for awhile entertained questions
from people like me who were still wanting help and/or promoting their
work in C language development.

Larry Wall created Perl. "Perl officially stands for Practical
Extraction and Report Language, except when it doesn't." This quote was
taken from some online documentation for Perl. A sense of humor is key
in life. His name came up (I can't remember the context) and I sent him
a message thanking him for his work and telling him about some of mine.
Again, this is like writing to the top. He got back! And had some
kind words.

Perl is a little like COBOL in that it is the backbone of the web in the
same way that COBOL is the backbone of commercial applications. They are
very different languages but are both important. One of the things I
told Wall was that I found a use for something someone had written in
Perl to drive part of a system my runner friends and I use to exchange
information on our running. When my brother was selling his art online
he hired a guy to write the shopping cart software for it. It was all in
Perl.

Paul Erdös was a Number Theorist. He travelled the world visiting
other mathematicians and stayed, self-invited, at their houses. He owned
a briefcase and very little else. The book "The Man Who Loved Only
Numbers" tells his story. He proved the Prime Number Theorem by
elementary means (he did not use complex number theory). He is so famous
people talk about their "Erdös number." Erdös himself has the Erdös
number 0. If you published a paper with him, your number is 1. If you
published a paper with a person who has Erdös number 1 your number is 2.

"Erdös, like many mathematicians, believed that mathematical truths are
discovered, not invented. And he had an evocative way of conveying that
notion. He spoke of a Great Book in the sky, maintained by God, that
contained the most elegant proofs of every mathematical problem. He used
to joke about what he might find if he could just have a glimpse of that
book."

Ward Christensen created the first BBS (Bulletin Board System).
Today, with the internet, we see Facebook chat and online forums. The
earliest inter-computer connections were over phone lines using 300 baud
acoustic coupler modems. XMODEM was a program he wrote to do file
transfers. I ran a Remote Bulletin Board System for years. He was
definitely a key player.

Gary Kildall, mentioned earlier, wrote the first operating system for
microprocessor-based computers, CP/M. He founded Digital Research, Inc.
A hobbyist's dream, CP/M let you create and save programs on discs. All
subsequent operating systems owe their existence to his seminal work.

Peter Schorn wrote an Altair 8800 simulator. This computer was
introduced in 1975. It was the first "personal computer." Simulators
allow you to run software long after the hardware it was written for no
longer exists. I currently run Ubuntu (a Linux distribution) on my
desktop computer and have installed his simulator. The Altair had an
8-bit CPU (Intel 8080), no hard disc, and no operating system. His
simulator does much much more than the Altair. CP/M programs and full-up
Z-System run under his simulator! Peter and I have corresponded on
several occasions.

5. Full video at http://youtu.be/mwWDEXFye5I

Lesson 11: What's with that cover?!

Note: I am pretty happy with the book but have added this "Lesson" just
to cover a few changes I have made since it was first published.

The cover for the book has changed. It uses an image⁶ of a
"random walk" of some two million steps. I tried to come up with
something that was somewhat "mystical." I doubt anyone would guess what
it was without this explanation. I began to wonder if I could get Karel
to do a random walk. I had to break a few rules but here's the code.
Visit the link⁷ below to see a run of this walk.

setup [
system("clear")
pos 20,10,"randwalk.tc - tct - 11/12/21"
sleep 3
color '7'
pos 20,20,"seed (odd number from 1-999)? ";last=seed=gn
pos 20,21,"bag (1-9999)? ";bag=gn
sleep 3
system("clear")
off
]

turn [int r;r=random(0,3);while(r) [r=r-1;turnleft]]

main [
while 1 [
putbeeper;wait 0
if front_is_clear() move
turn
]]

6. http://primepuzzle.com/tc/Random_walk_2000000.png

7. Problem 7 in Karel the Robot Problem Book