>>Does anyone else find it strange and ironic that Ada, originally >>conceived for what were then called DoD embedded systems, has such >>a weak presence in the current embedded systems world? i find this completely unsurprising. i know two groups who actually have to earn money doing embedded work, and i know a bit first hand about several others doing avionics and military work. in many, many commercial embedded systems, you are dealing with incredibly simple but general purpose microprocessors replacing bespoke electromechanical discrete control systems. furthermore, a few dollars difference in the cost of the computing devices installed on a volume consumer product (including cars, televisions, videos, etc.) makes a huge difference to the manufacturer's profit or even the viability of the product in the market. (the Oak people learnt this lesson painfully, but they could have checked, first...) this applies as much to memory components as it does to the cost and complexity of the processing units. for instance, in one significant application i know, the platform is a 16-bit micro with 0-64K addressible space. that includes the application and all real-time operating system support. it is considered highly desirable to write in something other than assembly language, although that was used previously. nevertheless, it's a black mark actually to take 64K, since reducing memory requirements allows several more dollars to be saved on something that sells a good many million units. this can be done without compromising correctness (in fact the resulting run time support is so much smaller and simpler than anything required for Ada that the reasoning is easier.) extra `features' must be remarkably compelling to tilt the cost/benefit equation. >>Are we really dealing with two completely different definitions >>of "embedded"? yes. it's like `real time'. `embedded' to people who are controlling expensive low-volume devices such as aircraft -- especially warplanes -- or spacecraft can afford more computing power. the cost is lost in the noise. (if they are really lucky, the test version of the expensive thing will blow up and they'll get a contract to build another.) Ada probably is a viable thing in those markets; on the other hand, many groups using it seem in practice to be using mainly SPARK-like subsets of Ada, since there is a reasonable amount of mechanical support for rigorous development. given that, and if that's the main application area, why bother implementing the full language at all, with the consequent costs and pain? there are many commercial applications where the cost constraints and platform size lie well between those two extremes (eg, PostScript laser printers), but since so much of the infrastructure (eg, Postscript interpreter in that case) is now in C and C++, it's hard to compete with something as big and complex to implement and run as Ada95 that also lacks that infrastructure. my own view is that Ada did a `Fortran 90' on itself in the move from Ada83 to Ada95. it took a lot of time and effort, distracted people who could probably have done more good for existing Ada elsewhere, invalidated existing implementations, and changed and added enough to the language that previous implementors put reimplementation in the balance. as well as the implementations, Ada95 also invalidated the arguments i'd heard during the mid to late 80s that you didn't need all that inheritance stuff that C++ provided; Ada83 was Just Fine and indeed object-oriented as it stood. (and no, although Ada isn't my choice of language, neither is C++, by any means.)