Re: Ada is almost useless in embedded systems

[john@assen.demon.co.uk (John McCabe)]

>Still off topic:

>Quoting The Jargon File, version 3.3.0:

>> :troll: v.,n.  To utter a posting on {Usenet} designed to
>>    attract stupid responses or {flame}s.  May derive from the
>>    phrase "trolling for {newbie}s" or some similar construction.
>>    The well-constructed troll is a post that induces lots of newbies
>>    and flamers to make themselves look even more like idiots than they
>>    already do, while subtly conveying to the more savvy and
>>    experienced that it is in fact a deliberate troll.  If you don't
>>    fall for the joke, you get to be in on it.

That's interesting. As the originator of this thread, I can only say
that the original posting was _not_ designed to attract _stupid_
responses. 

Hopefully some of the discussion that has gone on under this thread
has shown that to be the case.

I honestly believed that I would receive intelligent responses
explaining all the good features of Ada for embedded systems but I was
obviously a bit naive.

As you should have seen by now I had what I felt to be a number of
valid points on the unsuitability of Ada (83 remember) in embedded
systems. 

During the discussions that have taken place as a result of this, I
have learned a great deal about Ada, especially that the new version
(Ada 95) is well worth looking into, although it is unlikely that I
will be able to use Ada 95 for some time.

In particular, w.r.t the original points I mentioned (and in that
order):

1) Strong Typing is also very good if you have a large system with a
large number of programmers. Obviously it is advisable to catch errors
as early as possible as the later you find them, the more expensive
they tend to be to find. Also I have seen an article on 'lint' and its
usage and there are some very good points in it related to the fact
that it gives a lot of detail about trivial errors which can lead to
the user unintentionally ignoring the serious errors!

2) Bitwise logical functions - can be used on one dimensional packed
arrays of booleans.  I have also learned a more general lesson which
is to be a lot more sceptical about my customer's requirements and to
design defensively. Finally, I have learned about Ada 95's modular
types which from what I have heard, will be a very valuable addition
to the language.

3) Enumeration representation clauses - I knew that I could get round
the problem I described and I now also know the reasons why the
restrictions exist although I have not really changed my opinion on
that point. Richard O'Keefe pointed out the Ada 95 definition of these
clause, but I have not managed to obtain the Ada 95 LRM yet to get the
exact context so I cannot really comment for the moment.

4) Variant Records. Now here is one place where I believe I really
screwed up! As soon as I was given an example (well, a 2nd example) by
Bob Gilbert on this point, the stuff I'd learned on my 1989 Ada
Training course came flooding back. In my defense all I can say is it
was about 2 years between that course and actually getting into the
position where I could use Ada in earnest and I had forgotten it.
Still no excuse really! I appreciate all the information I've been
given on this one.

5) Chapter 13. Mmmm well. Yes, Ada makes it obvious that there are
implementation dependant language features whereas other languages do
not. I'm still not convinced about the flexible this allows on the
implementations but the impression I get from what I've heard on Ada
95 is that far more definition has gone into this area.
Best Regards
John McCabe <john@assen.demon.co.uk>