[Editor's Note: This was originally posted on the Embedded Master] 

Apple’s recent change to section 3.3.1 of the iPhone Developer Program License Agreement for the 4.0 SDK explicitly limits developers to using

“…Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs application”

While this limitation applies to application code, my own project experience for embedded control systems suggests that other development teams also impose analogous selection criteria on language and development tool choices. In some cases, our choices were limited to a short approved list of languages and development tool environments that applied across many suppliers that were contributing different subsystems to a single, long-lived end-system.

Understanding what criteria developers use to limit language and tool selection is more than an academic concern. In countless presentations I have seen software development tools rank at or near the top in importance in selecting a processor as the final candidate for designs. Suggested reasons why development tools manifest so highly in processor choices include familiarity with the toolset and its specific quirks to avoid a new learning curve and preserve an aggressive design schedule.

Technical reasons for specific selections might include execution efficiency of the compiled code, compilation speed, code size efficiency of the generated executable, as well as the tool’s flexibility to spot-optimize all of these considerations. The tool’s static and dynamic analysis capabilities, as well as traceability and testing components may also be important considerations.

I suspect that the selection criteria across all embedded design teams vary widely and are reliant on the target applications, size and maturity of the development team, and expected maintenance lifecycle of the end product. For example, if an end-product has a 10, 20, or even 30 year maintenance lifecycle (such as an automobile, aircraft, or spacecraft), then it is imperative to choose a language and set of tools that have high chance of being supported throughout that lifecycle period. Another important consideration for such long lived products is whether there will continue to be a sufficient pool of skilled engineers with working experience in the selected language into the future.

With this in mind, I am hoping to uncover common sets of reasoning for formal language and tool selection criteria across the range of embedded development projects. Understanding that, please share any formal selection criteria you use and for what type of applications do you use them for?

This entry was posted on Wednesday, April 14th, 2010 at 12:00 pm and is filed under Question of the Week. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.