Re: How come Ada isn't more popular?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 02 Feb 2007 14:57:17 +0100, Markus E Leypold wrote:

> Can't it? Wasn't there a trick with renaming somewhere? Like
> 
>    A : Limited_Type renames some_function(...);

You can return a limited object within the same scope.
 
> I seem to remember something like this. Might be mistaken: I usually
> end up to eliminate limited types in my programs against my will,
> since they play bad with unlimited base classes (like found in
> GtkAda).

Yes, I still can't understand why they made collected objects (widgets)
non-limited. For packing my limited objects into widgets I am using handles
to. A handle is non-limited. This is quite in GTK+ spirit.

> When I talk about all those transitions, I see, that there was no
> C->Ada transition, at least no mass movement. So we come back to the
> C->initial question: Why not? 

How much popular was C that time? I am asking this question because I
learned C after Ada. My personal transition was FORTRAN-IV/PL/1 -> Ada 83.

> I think some of the posts here have already given answers to that:
> Historical reasons. 
> 
> Those transitions would have had to happen around 1995-2000 which in
> my eyes was a period where people were looking for new languages (GUI
> development in C and all this became rather unfeasible at the
> time). But a process of bringing the candidate languages into the
> public awareness would have to have started earlier. Was the Ada 95
> standard just a tiny bit too late (it is understandable that Ada 83
> was not a serious contender for this, people were looking for OO
> really urgently)? Or was it the vendor situation? GCC has had C++ for
> some time, but did GNAT come too late? 

I think so. GNAT was a quite poor compiler for too long. Another important
thing was (is) a lack of good IDE. C++ vendors paid much attention to
design IDE, much more than to compiler quality... This is the first thing a
newcomer sees.

>> Why? OO is about encapsulation and polymorphism, these don't need
>> references everywhere.
> 
> Yes, but -- you want to keep, say, a list of Shape(s). Those can be
> Triangle(s), Circle(s) etc, which are all derived from class
> Shape. How do you store this list? An array of Shape'Class is out of
> question because of the different allocation requirements for the
> descendants of Shape(s).

Why should this worry you (and me)? It should Randy and Robert! (:-))

The language does not require array implementation to be contiguous. Randy
told once that Janus Ada is practically ready for

   type X is array (...) of Y'Ckass;

>> What about maintainability and reasoning?
> 
> What about it? It's easy with value-oriented languages (i.e. languages
> that just produce new values from old ones in a non-destructive
> fashion). Functional languages do this therefore reasoning is a well
> developed art there. But the representations of all those values
> (trees, lists, ...) (a) rely heavily on representation sharing and (b)
> use references because of that. They need and use GC.

You are mixing by-value vs. by-reference semantics with no-identity vs.
has-identity. These are two semantically different things. One is about
implementation another is about properties of the domain. "Premature
optimization" is you know what... If identity is in question, then objects
should be made limited and could then be accessed through referential
objects. But that alone does not require GC. I might also require no
reference object if self-recursive types supported.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de