Re: Ada and QNX

["Ken Garlington" <Ken.Garlington@computer.org>]

"Igor Kovalenko" <kovalenko@home.com> wrote in message
news:39EA9161.6469DDE2@home.com...

[snip]

> Oh, yeah. I bought Ada book some years ago. So many capabilities. Couple
> hundred pages worth of docs printed in small-font.

An odd metric... My copy of "Standard C" by Plauger and Brodie is 207 pages
of fairly small font.

> If someone manages to
> a) write a good compiler for that (portable and with runtime-efficient
> code)

GNAT appears to be fairly portable (at least, it's available on a number of
hosts). Without knowing what the precise definition of "efficient" is in
this context, I can't say if there's a compiler that meets your needs in
that respect. It's certainly been used in hard real-time embedded
environments, which is a pretty good operational definition of "efficient".

> and b) somehow teach programmers to understand the whole damn
> thing, then yes it might resurrect.

I haven't seen any problems in this area in my organization.

> Even then, I have doubts personally.
> Ada is way too high and abstract to be good for system level programming
> (even C++ is too high).

I'm trying to think of a low-level construct available in C, but not Ada,
that would be used for system level programming, and I'm drawing a blank.
Bit-level operations? Pointer manipulation? Interrupt management? I've done
all those in Ada without any difficulty.

> And yet it is not as portable and distributable
> as Java to be good for new-age applications.

Since Ada can run on the JVM, how could it be less portable or
distributable?

> Plus, it smells too much
> like Pascal and that turns me down immediately.

Now I think you're on to something. Too many programmers have the "secret
handshake" syndrome: They want to use languages that are inscrutable to the
unwashed non-programmer.

> Of course, those are
> just my humble personal opinions, I know that others will disagree and I
> don't say that those opinions are absolute right.
>
> In any case I don't think that pissing into C++ pool will do any good
> for Ada. At best it might just serve you as a good way to kill time
> until a) and b) is done.

"a) and b)" are not the problem. Ada's troubles are not technology related.
Ada's troubles come from poor marketing earlier in its history -- too many
vendors making too many mistakes. The worst performers are gone now, but
they left behind bitter feelings in a lot of potential users.