> (1) Ada is not really 'reflective', a property valuable to a RAD
> environment, in that it that it makes it easier to manipulate and extend the
> environment according to the developer's taste and special requirements;

Maybe.  What about Ada-to-J-code?  The benefits of Ada plus dynamic
loading.

> (2) the Ada language is very verbose, which is as inappropriate for
> 'quickie' programs as it is advantageous for longer-lived ones;

I would not call it "very" verbose--just more verbose than C.  When you
recognize that the alleged verbosity is more objectively called
"readability," you understand why this difference alone makes Ada more
appropriate than C even for some situations where C might otherwise win
out.

For "quickie" programs, I use Ada, perl, ksh, Excel, or Word macros,
according to the nature of the problem.  Only rarely do I find C useful.
I  have found that in about half of such programs, a similar problem comes
up again, and the Ada, perl, or ksh can be reused.  Not so the rest.

And on the subject of verbosity, writing a simple GUI with the current
silver bullet takes three to ten times the amount of text as TCL/Tk.  For
more complicated GUIs, I suppose Java catches up.  But I wouldn't know, as
I haven't gotten a simple one to work right yet.

> (3) Ada is not interactive, and an interactive morphology (e.g. ACE) tends
> to end up being substantially different to the compiled language whilst
> retaining much of the the unwanted verbosity.

Define interactive.

If you want terseness, extensibility, and "interactivity," and don't care
about reuse or maintainability, perhaps you should consider a variant of
FORTH.  (This is NOT an endorsement.)

--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau