> (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
|