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 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 …



  1. You know my coding skills (and limitations) better than most, so you won’t be surprised that I was eventually offered a couple of very readable-code options by my current boss to soup up my understanding of command structures and OO and so forth. First it was Rexx – the old PS/2 scripting language. Honestly, it DOES read almost like a conversation, right down to using “say” instead of “print” or “echo.” You can write a pretty beefy Rexx script within an hour of cracking a book, and it does promote fairly good structure.

    Rexx led me into Object Rexx (with a bunch of visual tools that were keen for designing GUIs and otherwise very polite about keeping out of your way), and that was a gateway drug for me to Python. Python reads very well, too – I don’t know if you’ve poked around with it, but it’s very intuitive. I understand Applescript is even more conversational, but I haven’t really dug into it yet.

    What little experience I’ve had with Visual Studio has been, er, challenging. Granted, I was only using it to try to repair code a previous employee (who was fired for incompentence) had written. Still, the interface is so clunky and over-complicated that I spent more time trying to figure IT out than changing the (as it turned out) four lines of VB that were getting in the way.

    I wonder if there IS any way to write a “visual” programming environment for a complicated language. After all, a GUI to allow you to write code to create a GUI that executes code gets pretty circular. One disparate element (oddly behaving control, for example, or a hard-to-find tool) in that whole structure is going to be more of a distraction than a help and knock everything else off-track.

    As for writing stuff out, I’ve just recently started doing this (I’ve been a sit-down-and-code guy until now, and my work kind of negatively reflects that). I don’t write by hand, though – I do English lists in my editor of what I need to do, beef that back out with deeper English descriptions and conditionals and so forth, and then comment ALL of that by line and start coding each bit. By the time I write my first real line, I have such a deep understanding of what I’m doing (and such a detailed laundry list in front of me) that it’s very easy to write. I think you taught me some of that – it’s only taken me twenty years to start using it!


  2. This is a great article. I just added you to Spolski’s list of candidates to consider for “Best Software Writing II.” (Does Visual Studio Rot the Mind was already there, but I hadn’t known about this until you linked it.)

    You’ll see from my commentary at that I mirror Tom’s approach too. In my discussion of my first experience with a power user in the section on “Accountability” at you’ll see that you and I share some common experience, though mine was with Fortran I running on the IBM 704 over by the wind tunnel. The engineer in Renton Transport Division was Theodore L. Lomax and a buddy engineering aide who also wanted to get into computing was a part-time student named Art Van Ausdale.

  3. Hmm, maybe this whole top-down thinking isn’t so unusual after all. Could Tom, Dennis, Charles and Doug be representative of a larger group than we realize? I certainly hope so.

    Tom, it’s funny you mention Python. There’s project called Iron Python, which I believe started as a GotDotNet workspace, that lets you use .NET from within Python. I’ve got some internal emails on it stowed away to read some time, since it sounded interesting. I’ve always wanted to know Python/Perl/PHP better, and although I’ve learned a bit of PHP from customizing my WordPress blog I still haven’t found a good excuse to dig into Python or Perl. Maybe the .NET connection will help me ease into it eventually.

    And using a GUI to design a GUI, I agree that it seems strange. As Petzold says in that article, he doesn’t feel like he’s teaching programming when he tells the reader to drag something from a toolbar and drop it on a designer. And it’s not just a matter of style: a CPU only knows to plow through memory executing one instruction at a time, so an awareness of that linear aspect of the code we produce (“write” is too strong a word, in a GUI IDE) seems to me a good thing, in general. To write tight code, one must have compassion for one’s CPU!

    Small world, Dennis. (And thanks for the kind words!) The wind tunnel … hadn’t thought of that for a while. I remember driving over there to pick up tapes of test data. And my Dad worked in the DC over there near Boeing Field, on an HP 3000. I worked in the noise staff, at the IBM Building in Renton and then later at the newly built Valley Office Park. The guy sitting next to me used to anwser the phone “cue sticks, shout!” Or so I thought — turns out his name was Schaut, and he was saying “acoustics, Schaut.” The old-timers called our department “acoustics” instead of “noise,” for some reason. Memories. :-)

    You know, I noticed late yesterday afternoon that it had turned into a nice sunny day. But I’m having so much fun with my new OOX class library that I’m spending another day with my new friend VS. He’s pushy, arrogant, and a little set in his ways for one so young, but after a long day with him I’m starting to like him a little better. There’s no denying he’s smart and well-connected. By Monday, we may be close enough to start taking coffee breaks together. I guess he’s not so bad once you get to know his ways a bit.

    Although he can sure be obscure. Yesterday I wrote a little test program, and I wanted to use the packaging API in it. So I needed to add a reference to WindowsBase.dll. Sounds simple enough, but I couldn’t find that file anywhere. I searched under the Windows folder, thinking it should be in the Global Assembly Cache or something. (Misguided perhaps, but I’m new to this!) No luck. So I searched the net for mentions of WindowsBase.dll on blogs, and stumbled across something Jim Galasyn had written less than 24 hours earlier, which showed me that WindowsBase.dll could be found in the folder c:Program FilesReference AssembliesMicrosoftWinFXv3.0. Doh!

  4. There is less obscure way to add the WindowsBase reference to your project.

    1. Select Project menu (or from Solution Explorer, right-click on the project).
    2. Select “Add Reference”
    3. Select .NET tab
    4. Scroll down to the bottom to select “WindowsBase”. For some reason we don’t yet have a “Microsoft” as part of the assembly name.

    This menu path in VS will be well known as you start building apps that call web services or reference other components. I suppose until you have to do the the first time you generally won’t know it’s there.

Leave A Reply