Ten years after - Embedded.com

Ten years after

Ten years ago this month, what was then Embedded Systems Programming magazine published my first Programming Pointers column, entitled “How I Got Here.” In it, I described the events that led me to start writing this column, and what I thought I'd write about. A ten-year anniversary is one of those times when columnists look back and reflect on what they've written. So I guess it's my turn.

The first half of that first column was a recap of my early experiences at the Embedded Systems Conferences, principally how the titles and contents of my conference lectures evolved in response to audience reaction. Those experiences led me to two observations that have colored my work ever since and still appear to be true.

The first observation is that embedded applications are very diverse. This is still true, but there's more I should have said about this, so I'll say it now. It's not just the applications that are diverse: the hardware they run on and the backgrounds of the people who write them are also very diverse. It's difficult to make accurate generalizations about this business. (How's that for a generalization?)

Every so often in those early years at the conferences, I'd make some sweeping statement that began with phrases like “All platforms have…” or “Compilers never let you…”. Much more often than not, someone in the audience would raise a hand and say “But on my platform…”, or “But with my compiler…”. I soon learned to avoid making such all or nothing statements. In my speaking and writing, I now rarely use words like “all”, preferring instead more measured phrasing like “most” or “nearly all”. “Typically” and “almost always” have replaced “always”, and “rarely” has replaced “never”. I don't think it means I'm a wimp. I think it reflects the reality of this business.The other observation is that, although embedded systems programming is different in some ways from desktop or server programming, it's not that different. Most embedded systems programming is just plain programming; therefore, by and large, good embedded systems programming technique is just plain good programming technique. It was true then, and it seems to have gotten truer.

Ten years ago, I thought I'd be writing about techniques specifically of interest to embedded systems developers–things like placing data into ROM, manipulating device registers, and handling interrupts. I have done some of that. But ten years ago, I couldn't have predicted that I'd have written as much about general programming language issues, such as my recent articles on scope, storage duration, and linkage.

My experience is that many developers (not just embedded systems developers) just don't understand much of what their compilers are doing for them. This appears to be true whether their preferred language is C or C++. I strongly suspect it's true for programmers using other languages as well. This lack of understanding limits what they can do to improve the quality of their work. For example, it's hard to write good, type-safe code if you don't understand what a data type is and how the compiler checks types, but there's hardly anywhere to go to learn this stuff. When confronted with a compiler complaining about type mismatches, too many programmers throw in a cast to make the compiler shut up so they can get on with their work. Too often, using a cast leads to bugs elsewhere in the code and maintenance problems down the road.

Computer science students used to learn about type checking in courses on compiler construction, which seem to be disappearing. I don't know how electrical engineers who program for a living ever pick it up. I'm surprised to find myself years later trying to fill that need, but not too surprised.

Anyway, I'm not going to make any predictions about where this business is going other than this: I don't see any really fundamental changes in the programming process coming in the next ten years. If you program for all or most of your living, your compilers will likely remain your most crucial tool. How well you master that tool will have a big impact on the quality of your work. I'll try to stick around for a while and help you out.

Dan Saks is president of Saks & Associates, a C/C++ training and consulting company. For more information about Dan Saks, visit his website at www.dansaks.com. Dan also welcomes your feedback: e-mail him at . For more information about Dan .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.