By Jack Ganssle

Time to Move On?

Summary: Are developers starting to think about moving beyond C and C++?

C sucks.

OK - that's a provocative remark made partly in jest to underscore a point. I enjoy C. It's fun. So is assembly language, and C removes assembly's drudgery. But C is fairly dangerous as it's ill-defined (the standard lists around 200 items that are in conflict or that may be implementation-dependent). It provides no protection for common pitfalls like overflows, it allows (some say it even encourages) poor memory management and pointer mayhem.

Some years ago at an Embedded Systems Conference I took some swipes at the language. For months emails and the blogosphere rattled angry sabers about those comments, mostly to the effect of "it's a poor craftsman who blames his tools." I believe that statement is sophistry. Sure, a genius can build a Krenov-inspired cabinet with nothing more than an 8 pound maul. Most of us, however, would chose to use a room full of tools; a table saw, planes, jointer and the like. If we were in the cabinet business simple efficiency concerns would mandate the use of a wide range of tools so we could sell at a reasonable price and while making a profit.

We're in the business of selling embedded systems, so similar efficiency concerns suggest we make use of a stable-full of tools. Assembly is the right choice for some systems; C and C++ match others. But we do have additional options beyond those limited and sometimes blunt instruments.

And so I was fascinated to read the responses to my recent article about software quality (http://www.embedded.com/columns/breakpoint/223200082 ). In marked contrast to the firestorm I provoked at the ESC years ago, quite a few wrote that we need to move beyond the C paradigm. Is there dissent in the ranks, a quiet though growing rumbling that change is needed? Are developers starting to recognize limitations to the current language choices?

I feel C/C++ scales poorly as systems grow, and am encouraged to find that other alternatives can yield higher productivity with fewer bugs (indeed, projects get finished precisely because there are fewer bugs and therefore less debugging).

Well over 90% of all embedded systems are programmed in C and C++. That creates an overwhelming inertia. All of us are overworked, so where does one find time to investigate, learn, and deploy alternatives?

Published May 7, 2010