>>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.)