The Flight Part 4

At 5,000 feet above sea level, the take-off roll at Albuquerque New Mexico is long even in a Beechcraft Bonanza. It’s our third day “on the road,” and after a nice breakfast, my passenger and I ride into the clear air of the high desert. The view is tremendous. The orange ground in contrast with the vivid blue sky is a gift.

For my passenger, Professor Niklaus Wirth--creator of languages, a huge influence on the history of computer science, retired teacher of many leading computer folks--is at attention, eyes wide, soaking up the beauty of the American West in the early morning.

Our flight plan is easy: follow I-40 across New Mexico and Arizona, turn down the valley to Blythe, refuel, and continue on south to San Diego.

West of Albuquerque, we spot Mt. Taylor just off to the right. The Bonanza climbs slowly as we make it to our 12,500 feet. I keep eye on both the altitude and my passenger, looking for signs of hypoxia. There are none. Wirth is in great shape, and as we follow I-40, everything proceeds smoothly.

In all my years of flying, I’ve never had an engine problem. Plane engines are a simple and well-proven technology. The number of moving parts is minimal: dual spark plugs in each cylinder, two magnetos for creating the high voltage impulses for those plugs, crankshaft, camshaft, pistons, connecting rods, two gears that function as an oil pump. That’s about all the moving parts. Elegance has its reward, and very rarely do these engines break.

Most accidents occur because pilots fly into bad weather. Many don’t know how to control the airplane using instruments alone. It takes an additional 40 hours of training, a knowledge test, and a check ride to add an instrument rating to a private license. Either they lack instrument knowledge, or they fly into thunderstorms and run out of luck going lower than the charted altitudes on approach.

None of that applies today, of course. We can see for fifty miles in every direction.

When mastering a craft, it’s easy to miss the key lesson. Usually, we internalize a teaching, almost unconsciously, and embed it in our practice without really being conscious of it. Only looking back can we see its significance.

For programming, my key programming lesson came from two very different sources, or so I thought. That key thing is the iterative approach to software development, and I learned it from Brian Kernighan and Niklaus Wirth.

Very early in my career, I walked into Bob Stearn’s office in the University of Georgia’s computer center. On his desk sat a plain white book with orange text reading Software Tools.

Noticing my gaze, Bob said, “Take it. It’s by the Bell Labs Unix guys.”

I borrowed it and my life changed forever. In Software Tools, Brian Kernighan and Bill Plauger teach programming using a dialect of Fortran they designed called RATFOR, or Rational Fortran. The book was published in 1976 when Fortran was king and C was only a wee babe. They wrote a preprocessor, first in YACC and then in RATFOR, that would turn RATFOR into ANSI standard Fortran. (We spelled it FORTRAN in those days.)

The theme of the book was how iterative the development of the software is. Get something working. Add to it. Think, edit, compile, run, repeat. Do this a lot. Do this quickly.

As I read the book, I wasn’t aware that the habit was forming. The iterative approach just became ingrained in me. At times in my career, I’ve noticed people trying to design a program before starting to write it. They believe they can’t get the code down until they’ve planned it all out. These people tend to write beaucoup lines of code before actually compile anything. They also tend to be a bit grumpy.

Software Tools book implicitly taught people to think about what they wanted to accomplish, maybe scratching out brief notes or short pseudo code. Later, I would sketch data structures. You know, little rectangles with arrows showing the relationship between dynamically allocated structures. Once drawn, I’d start to write the core of the code a bit at a time.

This is where “Hello, world\n” came from.

All this was so subconscious that it wasn’t until I found Wirth’s 1971 paper “Program Development by Stepwise Refinement” did I explicitly understand how I was using iterative development.

The air becomes bumpy as we descend into Blythe to refuel. We’ve flown past some of the most breathtaking vistas, and at 12,500 feet above sea level, breathtaking is the right phrase. We’ve circled Meteor Crater, flown past the trees of Flagstaff and Humphrey’s Peak, seen the vast expanse of the Grand Canyon, followed the Colorado River, sailed above London Bridge in Lake Havasu City and along the river valley with its green irrigated farms to the edge of California and the airport in Blythe.

It’s been quite a morning.

As we descend to 1,400 above sea level, lower than we’ve been in days, the bubbles of hot air boiling off the desert floor slam into the plane producing some nasty turbulence. The lower we get, the more violent it becomes. It’s much like slamming into huge, invisible hot-air balloons, continually being launched from the surface.

On the radio, I hear a Cessna 152 in the traffic pattern at Blythe doing touch and gos. A student. What a tough place to learn to fly.

Refueled with both 100 octane low lead and treats from a snack machine, we launch out again into the heat. The performance of the plane is so bad, I check the engine instruments to make sure everything is running correctly. Manifold pressure? Check. RPMs? They look good. Oil pressure and temps? All okay. It’s just hot.

We follow a new highway, I-10, deeper into California.

A difference between Wirth and other computer-science founders is that he actually built things. (Edsger Dijkstra, in the end, didn’t even use a computer to write his papers, doing thing by hand and distributing copies of them.)

But Wirth is a builder. He calls himself an Engineer. Even in his retirement, years since 2007 and our cross-country trip, he has continued to build. He’s created things like his own processor architecture, implemented in an FPGA, and reworked his Oberon compiler to generate code for it. He rewrote his book on Oberon to reflect this and wrote the hardware design language to design his FPGA.

There’s a difference between the stepwise refinement taught by Wirth and Kerninghan and the iteration I see by folks today who don’t know any better. Stepwise refinement begins with the basic problem. It starts with the overall objective and creates a new solution using the basic primitives of the language. Today, I see a lot of programmers who search the web for a function to glue into a project. A great deal of the code I see is written that way. While that appears at first glance to be iterative, it’s not what we mean by stepwise refinement.

Stepwise refinement leads to things like the PIX with its unique operating system designed just for the task of firewall and NAT. Contrast this with the ballooning mass of code that are the OSs behind most “appliances.” Elegance, simplicity, low-cost, low-touch, and high-performance require true stepwise refinement. When you start at the top, work your way down, and design for a specific task, you wind up with the least amount of code, the fewest bugs, and the most performance of any other possible solution.

I remember a startup, a storage startup actually, that had a bunch of smart, experienced people. They had great ideas about block storage but decided they’d use an open source timesharing system as a base. They got stuck with only 80,000 IOPS (Coraid can hit a million). They looked at the code path. “Surely,” they thought, “we can refactor the code to optimize performance.” But you can’t rearrange such massive things as the modern timesharing operating systems. The startup went out of business.

Googling is great. I do it all the time. But I don’t look for cookbook solutions to my coding needs. I use stepwise refinement. I understand the underlying technology and just write what I need.

All this I owe to Niklaus Wirth and others like him who diligently taught the world how. They demonstrated it with code they created. They corrected and critiqued, maybe evened bullied, to set a high standard for creating software of high quality. They defined what quality software is.

We float above the Salton Sea, a large mud puddle just east of the coastal mountain range of southern California. Created in 1905 by a screw up on a canal, the ancient lake bed flooded. Although in the beginning it was freshwater, over the years become twice as salty at the Pacific ocean.

To the east is the coastal mountain ridge and beyond that a haze of humid Pacific air. We fly over rolling hills that lead down to the sea. On to the Jullian VOR and then toward McClellan-Palomar airport in Carlsbad. The airport is on a mesa overlooking the ocean. It’s a beautiful end to a great day of flying.

The trip continued, and the Good Professor and I spent more time together at the History of Programming Languages conference, but I’ll leave that for another time. I’ll only mention two things about the conference.

First, Wirth and I had dinner with his long-time friend Chuck Thacker. At the table, Wirth asked, “How do you think I got here?” Chuck shrugged.

“I flew with Brantley,” he said pointing to me.

The look on Chuck’s face was priceless. Horror washed over it, mouth open and eyes big. It wasn’t a look of ignorance, but one of knowledge, I could tell. He understood something of flying, I guessed.

“I have a commercial license and an instrument rating,” I quickly added. The look of relief was immediate. He later explained that he indeed had a private license and had stopped flying because the Silicon Valley area was so crowded with airplanes.

The second thing that stands out about the conference was the very large number of people who came up to Klaus and expressed their gratitude for his books, teaching, and languages. Their words were soaked with warmth and affection. He had for them, like for me, made a real and positive difference in their lives.

The trip was an amazing blessing that I could not have foreseen. What I learned in the six days with Niklaus Wirth could fill a book. My time in his code and books unknowingly prepared me for our conversations. I’m sure his gentlemanly manner, much the same as one other great influence in my life, Dennis Ritchie, has helped a great many others see how to create lean, cogent, and well thought out technology in the face of the storm of time pressures, chaotic fads, and management bent on just making a buck.

The world is a better place for his being in it. I’ll always be grateful for my flight across the country with Niklaus Wirth.