FW: How come Ada isn't more popular?

["Randy Brukardt" <randy@rrsoftware.com>]

Markus E Leypold writes:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> > Markus E Leypold writes:
...
> >> "it's usually the entire structure" => In a world without
> >> representation sharing. In one with representation sharing (and that
> >> makes the production of new trees from existing ones really
> >> efficient), one would have to traverse the whole subtree any time a
> >> tree referencing this subtree is deleted - if only to adjust the
> >> reference counters. In a world with GC you just overwrite one
> >> reference to some subtree. When the GC hits it just traverses the tree
> >> once (and then perhaps decides which parts to deallocate). Dependend
> >> on the application domain (e.g. if you produce and drop many shared
> >> representions between GC cycles) that might be much more efficient.
> >
> > In an imperative language like Ada (and this *is* the Ada newsgroup!),
>
> Yes, yes. But I *had* the impression that we're now talking about
> languages in general and general purpose languages.

Perhaps others are, but not me. I'm not much interested in most other
languages because they don't meet my personal requirements.

[In case you're wondering, here are some of them:
(1) Pascal-like syntax;
(2) Good support for encapsulation/information hiding, including good
support
    for initialization/finalization;
(3) Great compile-time and run-time checking, with as much as possible at
    compile-time;
(4) The possibility of getting close-to-the-metal performance.]

...
...
> I _do_ think that this concern for overhead in most cases is a case of
> premature optimization. As I already noted in this thread:
>
> For all the increase in processing power we have seen in the last
> decades I once would like to buy myself the convenient luxury of using
> GC because it's easier on the developer (candy for developers). For
> once I don't want to see that processing power go into useless
> blinking and flickering of smooth GUIs (candy for users). After all
> the users (indirectly) pay the development time and it's their money
> that is being saved if the developers spent less time with getting the
> memory manangement right.

That's fair, but I disagree. (Perhaps it's just my advancing years --
although it is weird to think of oneself as old at 48, considering I work
with much older people on the ARG -- it's still old in computer years. I
started out on a 4MHZ Z80 with 48K (not M!) of memory, and that will always
color my impressions.)

Anyway, I think that it is very important to be able to get high performace
out of code without having to rewrite it into a different language or (in
the case of GC) implementation style. When you find out that the memory
management overhead is too high in your code, what can someone who depends
on GC do? Very little, without completely breaking encapsulation. And just
turning GC off of the offending types is likely to produce a program that
leaks memory like a sieve, as objects are dropped everywhere.

The issue for me is not so much that everything has to have high performance
(that surely *is* premature optimization), but rather that I can get to the
highest performance without replacing large parts of my code. The worst
example of that is writing the program in some poorly performing language
which is not quite good enough (I won't name names here, as I don't have
enough experience with other languages to say anything useful). In that
case, you might be forced to rewrite the entire system into Ada or C. For
me, that would be a disaster (I hardly have enough time to do something
once!).

But, of course, you mileage may vary. And I don't think much else remains to
be said: our perspectives are too different to come to any sort of
agreement.

                         Randy.