In his brief 1982 essay (EWD831), computer science giant Edsger Dijkstra examines a topic that (inappropriately, as it turns out) vexes some programmers: Why in the world do computer people count starting at zero? Everyone knows that counting starts at one!
As it turns out, there are two very good reasons for counting from zero!
In the first two parts of this series I’ve introduced state engines and taken apart a specific instance of an engine. Now it’s time to tie together the design idea with approaches to building a variety of such engines.
Because the programming logic is in the state table, the engine can be fairly generic. That means it’s possible to create a state engine framework you can reuse for a variety of applications.
Last time I introduced state engines and state tables. I showed parts of a simple implementation of one in Python. It parsed the language introduced in Little Programming Languages. This post continues that, so be sure you’ve read that first article.
I got as far as the state table implementing the process, and that’s where this post picks up. I’ll also get into the
SourceReader class that does the heavy lifting.
At one point in my career, the state engine (SE) was one of my favorite AWK hammers. At the time much of the work involved text processing or, in some cases, serial byte processing (which is not quite the same thing). That sort of thing is right in the wheelhouse for a state engine.
They are a very useful tool and an important part of any programmer’s toolkit.
There is a common tendency, as we crank out code, to think that we’ll come back later and write some really good comments — comments that future reviewers will view with admiration for their clarity, completeness, and humor. But if we’re honest we have to admit: Later never comes. We never go back and write those great comments. Often we don’t write any comments at all other than some placeholder we might dash off at the time.
Which is why Rule #4: Comment As You Go!
This is a brief explanation of which is which and why.
Last week I took my car in for scheduled service, and when I asked how long it might take, the guy said it was specified as one-and-a-half hours of labor. He could do that because there are thousands upon thousands of data points where a competent mechanic has performed that exact service, so there is a very clear idea how long it takes.
But ask a researcher how long it will take to find what they’re looking for, and the answer is usually, “I have no idea. I’ll know after I find it.” The path a researcher follows is usually new and unexplored, so it’s impossible to predict how long the path actually is.
Creating new software is much more like research than auto service, because it involves traveling unknown ground. Despite this, software development managers often act as if new development is predictable.
It often isn’t!
Computer Programming is hard! It’s at least as hard as what commercial architects do, and I will argue that it’s as intellectually difficult as what doctors and lawyers do.
Many people think it’s easy, because they know some nine-year-old who “programs,” but there’s a difference between fooling around with the computer and building good software applications.