Is it better for a programming language to enable the utmost creativity of a programmer? Or, is it better if the programming environment helps programmers think through what the user wants and needs, and then lay out the system in a structured way, letting the programming tool generate the actual code? For the former, think the programming language C++. For the latter, learn about “intentional software,” promoted by former Microsoft leader Charles Simonyi.
The January/February 2007 edition of the MIT Technology Review features three articles on the subject of how we program. Editor Jason Pontin’s editorial establishes the foundation for the discussion. Following that is an interview with the inventor of the C++ language—Bjarne Stroustrup. A full-length feature article about Charles Simonyi wraps up the discussion. Well worth reading at www.technologyreview.com.
Power and complexity
If any of you have done anything in C++, you understand both the power and the complexity of the language. There are almost no rules. TR quotes Stroustrup as saying he learned from the Danish philosopher Kierkegaard a fanatical concern for the individual. Hence, he did not want to put anything in the language that would constrain individual creativity. The downside is that the language is hard to learn, and that makes it hard to conceptualize the high level of the project, since programmers are buried in minutiae.
On the other hand, Simonyi is concerned with what he calls a “meta program,” that is, a way to visualize the whole and then automatically generate code. Simonyi calls his “intentional programming” or “intentional software” a method to reflect the intention of the user—and end up giving the user tools to tweak things later as the intention changes. This method is also intended to help software designers manage large software projects. Simonyi says it’s now impossible to realistically schedule a project, improve individual productivity or coordinate work across a large team.
I’ve been pondering this sort of question since the mid-1980s when I was a manager of a company that designed and built “special” automation machines. One of the departments I managed was application engineering (the people who conceptualized and quoted projects). I would take the quoted amount for program development, debug and runoff, and routinely double it. Eventually, I tripled it. We still lost money too often at those stages. Why? The programmer would start writing his ladder logic with a limit switch at one end of the machine and work his way around the machine. Then he’d add some timers in to “control” part or machine movements. We’d start up, something wouldn’t work. No one could find the problem in the code quickly. Drove me crazy.
So, when I learned about sequential function charts, I thought that was nirvana. A couple of us were so enamored of them, in fact, that we worked long into the night on programming class projects. That’s why I like the work that the Packaging Work Group of OMAC has done developing a state model for packaging machine programming. I think that someone should expand that work to many more classes of machines. Think of how much time and cost that end-users would save in machine installation and troubleshooting. Imagine the time and cost savings for machine builders as they standardized machine control. Does anyone want to step up and work on this? Another project for OMAC? What do you think?
Another useful tool for machine design is Lean Thinking. The concepts used by Pearson Packaging, as reported by Dave Gehman in this issue, are truly revolutionary. Jim Pinto, in his February column, is going deeper in his thinking on innovation. We also have a new column this month from Cronus Partners. This investment banking firm will provide a regular analysis of the financial side of the automation industry.
Gary Mintchell Editor In Chief, gmintchell@automationworld.com
