Programming in Structured English

Programming in Structured English

It’s a gray Saturday here in Seattle.  We get quite a few of those.

I was planning to take a hike today, but my goal wasn’t really the exercise.  Hikes, like many things I do, are just excuses to go take some cool pictures.  And on a cloudy day, with rain a possibility, and no good light for getting creative with pictures, I decided to wait until tomorrow for a hike.  If it’s not gray then, too.

So I’m spending the day in Visual Studio instead.  I’m working on learning the System.IO.Packaging API, and frankly I’m working on learning C#, .NET and Visual Studio (VS) better too.  I want to get together some code samples to publish on OpenXmlDeveloper.org soon, and my lack of VS experience definitely slows me down.

I’ve dabbled in VS many times, but I’ve never delivered a line of production code in it.  As a longtime FoxPro developer who worked exclusively in assembly language before that, and in Fortran on big iron before that, I always found Visual Studio a bit claustrophobic.  I’m used to a top-down creative process, starting with a high-level view and then filling in the details as I go.  And I’ve been doing things this way for a long time.  For example, here’s a story from the summer of 1979, when I was a young Fortran programmer at Boeing …

I needed to write a program to read data out of some files that contained acoustic data from a flight test.  The acoustic data was essentially a three-dimensional matrix, with axes for time, frequency, and decibels, and there was one of these matrices for each test case.  A guy at Boeing Computer Services had written a Fortran library for manipulating this data, and I wanted to use his functions in my program.  But I was struggling a bit to understand how they should fit into my design, so I took my design notes over to the 10-71 building in Renton and met with the guy.  (Can’t remember his name — let’s say it was Bob.)

Keep in mind that this program was eventually going to be “written” on punched cards.  So I’d get my notes organized on paper, then when I thought I had something that would work, I’d punch cards for each of the statements, go submit that card deck to the girls in the computer room downstairs, then go back to my desk and wait for them to call and say the program had run.  Then I’d go downstairs and pick up my card deck and the printout of the program, 14″ wide greenbar paper that either contained my hoped-for results or a massive core dump of what happened to be in memory, byte-by-byte, when the program crashed.

So I was definitely in the “envisioning” stage when I sat down with Bob to discuss his library.  I told him what I was trying to accomplish, and how I wanted to use his library.  I kept talking, wondering if I was making a fool of myself, intimidated by this man and wanting his help.  He said hardly a word; we had the social dynamic of an eager young student and a stern old master.

Then he saw my notes written on a tablet of graph paper.  There were just rough notes about the flow of the program, pseudo-code as we all used to call it.

“Ahh … I see you have some Pascal experience” he said, in a tone of camaraderie that I hadn’t heard from him up to this point.

“No,” I started, hesitant to let go of this assumed connection that might soften him up.  I had never written a line of Pascal, hadn’t even seen one.

“Oh … Structured Fortran, then,” he responded with certainty.  Now, “structured” Fortran was the latest greatest variation of Fortran, but I was actually working in mundane Fortran 66.  I hadn’t moved up to structured Fortran ’77.  But one of the advances in structured Fortran was the IF/THEN/ELSE concept (it was all IF/GOTO before then), and I had used the word ELSE in my notes, which had apparently caught Bob’s eye.   Such an unusual word to use, you know.

“No,” I said, reluctantly exposing my lack of experience in cool programming languages.  “Just structured English.”

Bob turned to a co-worker.  “Hey, this guy’s working in structured English, you think that will compile?”  They snickered at my ways, but Bob was actually very helpful after that and I got what I needed from him that day.

So that’s how I’m used to working.  In those days, I wrote my structured English on paper.  Then in the 80s, working in assembly language, I wrote it in a text editor, usually WordStar although I got into Brief in a big way later.  In FoxBase and FoxPro, I just typed “modify command” and started typing notes, roughing out the flow of my program, sketching in details of classes and procedures I’d need, making notes about interactions between components, and so on.  I might spend hours in that text window and write lots of code before my first attempt to compile or execute any of it.

I’m convinced, from many years of experience, that a deliberate disconnect between thinking creatively and focusing on syntax is what really frees up your brain to see interesting possibilities and new approaches.  And it’s not just a programming thing: look at how many good writers make it a point to never think about grammar, punctuation and word choice until their vision is clear and complete.  Nitpicky little syntactical details need to be kept out of the creative process until late in the game.  Anyone can see that, right?

But Visual Studio doesn’t want me to work that way.  Like old Bob, Visual Studio doesn’t recognize structured English.  So it nags me about what I “should” be typing, or what’s “missing” from my code, or — most annoying of all — it “helps” me by adding references to DLLs that I’ve never heard of or even writing code in places where I thought I hadn’t written any code yet.  Working in VS often doesn’t feel like I’m designing or creating a program, it feels like playing a complex video game or something (which I certainly enjoy, but I enjoy programming, too!).

Then this morning I learned that I’m not the only one who feels this way.  Here’s what I’m talking about — a great transcript of a talk by Windows programming guru Charles Petzold last fall.  Thanks, Charles, you’ve made my day!  If a guy can understand and teach C# and .NET programming at the level he does, and still feel that way about working in Visual Studio, maybe there’s hope for me after all.

I’m headed for my favorite breakfast spot with a tablet of graph paper and a ballpoint pen …