By Jim Montague, Executive Editor
I and many other people, engineers and parents I know are so busy with present tasks that months and years go by before we notice some things are missing—and its not just gloves, umbrellas and our youth. For example, just as email replaced paper mail, it and other kinds of electronic texting also appear to be eliminating telephone calls.
Being an annoying reporter and editor, I don't get many calls or callbacks anyway, but recently those few jingles surprisingly dwindled down to almost nothing.
Likewise, similarly to the sudden appearance of skin on top of my head, I was recently startled to realize that I haven't run across object-oriented programming (OOP) software and architectures for a long time. Now, other industries and publications deal with software more often and deeply than Control, but I used to cover OOP regularly. Just a few years ago, there was a steady stream of innovations and announcements from companies constructing and organizing programming code into various blocks and objects that could be stored in libraries. As I remember it, the main thrill was that numerous lines of code could be grouped into a more graphical form, linked to perform functions, and then copied and reused as needed—saving substantial programming time and labor. However, this apparent growth industry seemed to fade over time, until some of us were left wondering what happened to it.
The funny thing is that I still run across lots of similar software blocks in countless on-screen, drag-and-drop, flowchart-based programs everywhere. So OOP or its twins seem to be alive and well, even though they're not as explicitly mentioned as they were in the past. Probably the most famous of these is Microsoft's Object Linking and Embedding (OLE) specification, which was used to develop the process control industry's OLE for Process Control (OPC) standard that is still on a roll today.
Still, the lack of hoopla about OOP is pretty deafening. I think what happened is that so many software objects got written, and so many libraries of them got filled that the need for new objects slackened and slowed down, even as use of existing objects swelled. If you can reuse a block, why build a new one? So OOP put itself out of business, while its descendants succeeded and became all-pervasive.
However, I have to wonder if something isn't lost along with OOP's ability to serve up uniform pieces of code. What of you need a new and different object that isn't in the libraries? Sure, you can call on one of the many small companies that write software objects to create a new one for you. However, what if you and the programmer have been using pre-formed, pre-digested software blocks for so long that it's hard to remember how to match the new function or operation you need with the underlying code? Can you become a prisoner of your Lego-like software modules?
Not if you make an effort to remember how OOP originated and preserve the basic programming skills it requires. There are lots of disciplines like this. For example, I thought old-time, handbill-type printing was dead until I saw an exhibit at the Nashville airport about how many of today's alternative rock groups are clamoring for retro-style concert posters that used to be made for artists performing at the Grand Old Opry. This has pleasantly revived the fortunes of the printer that still makes these posters. Many artisanal disciplines from bookbinding to cheesemaking are experiencing similar revivals. OOP can certainly do the same.
No, I'm not getting overly nostalgic. I've just done too many stories where old-fashioned values and methods were used solve some intractable 21st century problem. Personally, I'd bet the Inca stonemasons who shaped the tight-fitting blocks at Machu Pichu without steel or wheels would have plenty to teach today's engineers. So hang onto and don't lose useful skills and past lessons you may need later. And keep on pushing kids to learn mathematical concepts before allowing them to use calculators.