It's all about the ball

I know many people who like to run.  They run for relaxation, they run for weight loss, they run for the sure zen and pleasure of it.  And I don't get it.

I don't like to run -- it's just too painful.  The air scrapes my larynx and I feel nothing but aches and pains coming from my legs.  I've never liked running.  I remember the first time I ran cross-country in a gym class in junior high school.  There were some who just seemed to enjoy it. And others who waited behind the trees and joined the crowd later (no, I wasn't one of them).

But, I have discovered that there is one circumstance where I will run.  In fact, I'll run until I can't move.  There has to be a ball.  I first discovered this in high school when my history teacher, the infamous Ron Jones (of the Third Wave) announced that he was coaching the lightweight basketball team.  The lightweight league used age, weight and height to determine which section was acceptable.  In the first year, I was in the D League.  But Coach Jones had a diabolical method of pruning the possible players: the first few practices were brutal.  I remember the drills and the running.  But, at the end of it all he didn't cut anyone. There were two strings and the leftovers.  And I was in the leftovers.

The first time I discovered I had any athletic ability was my senior year in high school. We played badminton and we (doubles) managed to defeat the entire class.  Finally I had found my sport.  Badminton is incredibly fast and doesn't use strength but rather stamina and stealth.  The fundamental idea is to push the opponent into the corners where they can't return your next shot.  Unfortunately, in this country badminton is viewed as a kind of  backyard game instead of the crafty diabolical speed game that it can be.

When I got to the university, I briefly played handball.  I played it until the day I scraped my fingernails against the side wall.  But I liked the idea that unlike tennis, the ball would return back to you. I then discovered racquetball.  And this led to squash.  I'd heard that squash was a posh game played by ivy leaguers.  Squash and racquetball look the same, but they are not.  The squash ball doesn't bounce very high.  It's not going to come to you, you are going to have to move.  To run. There is the additional complication that the bottom of the front wall (a kill zone in racquetball) is covered by the tin and is out.  And finally, the racquetball racquet is short and easily handled as a kind of wrist extension. The squash racquet is more like a tennis racquet with a long handle.  In squash, you can lob, smash and drop the ball.  It's a game of finesse.  And, you have all the advantages of a walled court: the ball doesn't escape and you can use the walls to sap energy from the ball. Also, unlike racquetball, the ceiling is out of bounds.

Unlike today, I grew up in a world where baseball, basketball and football were the only  sports that boys played. In high school, soccer was introduced but I never played outside of gym class.  Strangely enough, it was in graduate school that I started playing again.  It wasn't quite the way I remembered it, now it was more fun.

Where I live now, soccer is a big deal.  Not only does it have a well developed child soccer system, it also has the adult leagues as well.  I signed up for the "Over 40s" Master's League. My first adventure out on the field was a shock.  I discovered that playing squash did not adequately prepare me for the rigors of a field sprint.  And, I was lost on the field.  It was bigger than I remembered and while running I would lose the sidelines and my field position.  As expected, I had lost any ball handling skill I used to have so I had to start building that up as well.

I have always liked to play midfield, which is the position with the most running and to my mind, the most strategic position.  Because you shift back and forth from offense to defense, you must always be alert for the sudden shift in play. And, for the most part, you also avoid catastrophic mistakes as well since you hope the defense will be behind you when you make an error.  And it happens...

In my second season, I was feeling more secure on the field, and in spite of being the worst player on the team,  my tactical skills were improving and my ball handling was also improving since I was practicing at the  lunch hour as well.  I managed to score my first goal ever --- which I promptly reported to my 80+ year old parents.  I felt like a child again: so proud and yet, so embarrassed by my delight in such a simple thing.

Unfortunately, cardiovascular decline waits for no one.  One loses one beat per minute of "top end" per year.  So, you get slower and slower.  Eventually, it was time for me to move to the Over-50 league.  It's slower and gentler (for the most part) than the Over-40 league. I'm still playing outside midfield.  And I still live for the good pass.

I watch the joggers run by here and there all the while knowing that it just doesn't have any appeal to me.  I don't get it.  Without the ball, I don't run.  It's that simple: it's all about the ball.

A review of "Coders at Work"

Once upon a time, I was proud to call myself a "hacker".  Those were the often bearded long-haired guys who knew every intimate detail of the machine. But then of course the media got a hold of the word and it came to mean a teenage kid trying to crack passwords and steal information --- also known as the "script kiddies".  I suppose that these days the preferred word might be "coders".

So, I saw a reference to the book "Coders at Work" and checked it out.  It is a collection of interviews with noted programmers and edited by Peter Seibel.  Of course, it's impossible to be completely impartial and his preferences leak out over the course of the book.   I should note that I actually know two of the interviewees and have talked to three others.

I thought I'd also use this book to remember some of my history about learning to program and various trials I've had along the way.  Seibel begins with the same question: "How/where did you learn to program?".  How and when depends critically on the interviewee.  For example, the younger members had opportunities that the older ones didn't.

For myself, the first program I ever wrote was in Sunday School.  My mother believed that children should have a religious education even if they never believed, just so they could at least see what others believed.  Strangely enough, in 8th grade some member of the Palo Alto Unitarian Church agreed to teach the class programming.  We were taught ALGOL-60 --- which was  amazing in itself.  Why ALGOL?  Because SRI had a B5500, that's why.  And so I grabbed some equations from my friend Tracy Mallory's father's physics PhD thesis --- something about waveguides I'm fairly certain.  And I coded it up on special coding sheets.  And it ran.  Of course I had no idea if the numbers were right or not.  As Hamming so famously put it: "The purpose
of computing is insight, not numbers".  But it wasn't until I landed in the Hewlett-Packard Microwave Lab that I really started to write programs.  One of my sponsors suggested that I should learn to program.  There was a small room with four noisy ASR-33 teletypes.  The passwords were on the wall. The programming language was BASIC, either on a GE-645 or the Tymshare SDS-940.  I liked the Tymshare system better but was getting bored writing BASIC and was up for a challenge.  So, I started to write a program to use as many of the OS system calls as possible.  I was spending hours and HP's money.  Because I put my name in the code, I was eventually asked to cut it out.  But by then it was too late, I had found the East Meadow machine room of Tymshare and I was hired that summer.

Back to the book: There are various quotes that stood out.  Here's one from the first chapter: Seibel: "Do you like Perl or is it just handy?" Zawinski: "Oh, I despise it.  It's a horrible language.  But it is  installed absolutely everywhere."

Absolutely 100% in agreement.  Using Perl is awful.  It reminds me of the old Lavoris commercial:  "Do you like the taste of Lavoris?  It's awful, but I use it twice a day!".  I only use Perl when I feel awk is just too painful. It doesn't happen that often.  The next interviewee totally disagrees with the Perl hate and professes his love for Perl.  I know there are people like that.  I don't understand it.

Seibel:: "I've noticed that one thing that separates good programmers from bad programmers is that good programmers are more facile at jumping between layers of abstraction..."

That's a critical aspect of programming and I don't know how to teach it. The idea that you can "drill down" to the bug, fix it and then pop back up without understanding most of the code is challenging to many.  Of course, it depends on the bug.  Some are just too entwined.

Seibel: "Is there a key skill programmers must have?"  Zewinski: "Well, curiosity -- taking things apart.  Wanting to know what's going on under the hood."

I disagree.  For me, absolutely, it's all about the machine.  For others who don't have that aspect, no.

Seibel: "Do you have any advice for self-taught programmers?"  Fitzpatrick: "Always try to do something harder... Read Code...  Then I really enjoyed reading code, because whenever I didn't understand some pattern, I was like, "Wait, why the fuck did they do it like this? ... Wow that is really clever..."

Yes, reading code is how I learned the SDS-940 assembler as well as the  PDP-10 assembler.  There's really no substitute for reading code.   I spent most of my latter high school years code at night.  Sussman at MIT once told me that the way to teach a new language was to have students read code and augment it.  I tried this and was impressed how much the students benefited from this approach.

Seibel always asks a question about Knuth's books.  Everyone admits to  at least glancing at them.  Some of the interviewees admit to being not very mathematical (and Knuth's books can get very mathematical) but my impression is that everyone asked the question knows and appreciates them. I got my first volume as a going away present from Tymshare when I went to college (Thanks Norm and Ann!)

Another popular question for Seibel is "What is the worst bug you have ever had to track down"?  For me, the answer is easy: it was the compacting relocating garbage collector in Bravo, the first WYSIWYG editor.  The problem was that it would crash but of course this was the result of a bad pointer.  And when you have a compacting GC, you are moving data around and possibly not updating pointers.  As I recall, it took me two days of concentrated and painstaking work.

Seibel: "Because, like the Spanish Inquisition, no one really expects floating point".

One assumes that the realm of floating point only belongs to the numerical analyst.  In fact, numerical programming haunts everyone when they deal with signals from the real world.  And so I discovered when I wanted to process audio signals.

Seibel: "As a programmer, do you consider yourself a scientist, an engineer, an artist or a craftsman"?

I think this is a matter of self-perception.  These days I view myself as a kind of sloppy engineer.  The advantage of software is that mistakes can often corrected rapidly.  In hardware, it can be horrible --- like the time I reversed a 32 bit bus and had to unwrap all the wires and then rewrap them. (Wire wrapping is why rock and roll was invented, I am sure).

Guy Steele: "I set out to be a pure math major... and then discovered I had no intuition whatsoever for infinite dimensional Banach spaces. That's what did me in."

I regret to say that's what did me in, in a matter of speaking.  In my  case it was Real Analysis.  I realized I just didn't have the insight. It didn't matter that I could do multi-dimensional calculus until the cows moo-ed.  This was different.

Steele: "It's hard to find good code worth reading.  We haven't developed a body of accepted literature..."

I couldn't agree more.  With the emphasis on open source, we (as a community) recognize various programs as being exceptionally well written.  Of course, who makes that decision?

Peter Deutsch: "If you look at programming languages I would make the strong case that programming languages have not improved qualitatively in the last 40 years. There is no programming language in use today that is better than Simula-67"

No comment!

LPD: "The reason I don't program in Lisp anymore: I can't stand the syntax."

This is remarkable.  Peter wrote one of first interpreters of LISP for the PDP-1 (he was in high school).  He wrote his dissertation in LISP (as I did as well).  And now...

LPD: "Well, my description of Perl is something that came out the wrong end of a dog.  I think Larry Wall has a lot of nerve talking about language design --- Perl is an abomination as a language.  But let's not go there."

Tell it!

Ken Thompson: "But I love the teaching: the hard work of the first class, the fun of the second class.  Then the misery of the third."

Amen!  Tell it!

KT: "The PDP-11s a great LISP machine.  The PDP-10's a great LISP machine. There's no need to build a Lisp machine that's not faster."

This was lesson of Symbolics and the lisp machine craze.  The moral of the lesson (I learned this as well) is that Moore's Law waits for no one.  And you can emulate a Lisp machine on stock architecture as faster than custom hardware.  A hard lesson.

KT: "99% of the time something simple and brute-force will work fine."

This is really important.  Often we often tend to grab these real fancy dancy all-singing all-dancing data structures but in fact a simple linked list search will do Just Fine.

Fran Allen: "We have seriously regressed since C developed.  C has destroyed out ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a HLL to the machine.  This is one of the reasons compilers are ... basically not taught anymore in the colleges and universities."

I disagree.  That's not the issue.  In fact, much of compilers have become boiler plate --- lexical analysis and parsing are both table driven these days.  So, what does that leave us?  Also, the regularization of machine architecture means that the wide variety of machine designs are gone.  So all those fancy algorithms are not required (remember Call by Name?!?).  Also, there are Domain Specific Languages (DSLs) that require compiler construction techniques.

The last interview is with Don Knuth.  And that's an appropriate end to an interesting book --- I'm not sure I learned anything new, but I enjoyed seeing how other programmers approached their art/craft.