Re: How come Ada isn't more popular?
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Sun, 4 Feb 2007 18:55:47 +0100
On Sat, 03 Feb 2007 15:51:33 +0100, Markus E Leypold wrote:
"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> writes:
On Fri, 02 Feb 2007 14:57:17 +0100, Markus E Leypold wrote:
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
Really popular, at least in Europe and the US, I think. Pascal was a
real contender on micros in the eighties but it had practically lost
out in the nineties despite there being still a good number of Delphi
shops/people/developers around.
learned C after Ada. My personal transition was FORTRAN-IV/PL/1 -> Ada 83.
I think so. GNAT was a quite poor compiler for too long. Another important
GNAT is still annoying the hell out of me in fringe areas of the
language. And the errors are so fundamental, that I begin to think
that it will take a long time to smoke them out.
Well, visibility in generics is still a great problem.
Furthermore I believe there is simply no incentive for AdaCore (who as
I understand maintain most of the GNAT code in the GCC repository) to
establish a good or stable baseline in the publicly accessible
repository.
Yes, at least a publicly available bug tracking system. I have an
impression that the same bugs come and go over and over again.
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;
OK, then But non contigous representation of arrays will really stress
memory management, fragment the heap (we can't do that on the stack
AFAIS).
Maybe, but it is no different from what would happen in any other
implementation. Note that there is a sufficiently different case, when all
Y'Class are of the same shape. For this I propose Tag discriminants:
type X (Shape : Y'Class'Tag.) is array (...) of Y'Ckass (Shape);
Here the compiler can allocate X in one chunk of memory.
And what about mapping of C arrays to Ada arrays
That were not possible, but it also were no problem. When you apply pragma
Convention to an array type, the compiler should tell you that you can't
have dynamic bounds and elements. You cannot pass String down to C, but you
could try String(1..20). [If there were no Interfaces.C of course.]
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.
No. Values have no "identity".
It depends. Polymorphic value has an identity. But I understand what you
mean, and that meaning is correct.
"Object identity" smacks heavily of
storage and memory chunks.
No. Identity is just a function id:X->I, where I is some set of comparable
values. No magic. X'Address or X'Access can serve as an identity function.
Or not, if you have relocatable objects, for instance. In general nothing
in objects requires X'Address. There are other kinds of identity. For
example id:X->T, where T is the type of X.
I fail to see how "identity" comes into the question of
"value-oriented" languages (your term, BTW) and represenation
sharing. GC is about references (to memory) and representation sharing
works with references to parts of another "value" (see lisp
lists). Represnattion sharing needs either reference counting
(inefficient, is also just some kind of instant GC) or GC.
The example you mentioned was a tree. Do you want to share subtrees between
other trees? When a subtree C of a tree A changes, should it ("it" is an
identity (:-)) in the tree B be changed as well? You cannot answer these
questions in terms of tree values. For all possible answers there exist
corresponding values of A, B, C, C in A, C in B, A/\B etc. It is a semantic
problem which has nothing to do with representation, be it
immutable-functional or shared. Identity is a way to express this
semantics. Value vs. reference is a semantically irrelevant implementation
detail.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- Follow-Ups:
- Re: How come Ada isn't more popular?
- From: Markus E Leypold
- Re: How come Ada isn't more popular?
- References:
- Re: How come Ada isn't more popular?
- From: Markus E Leypold
- Re: How come Ada isn't more popular?
- From: Maciej Sobczak
- Re: How come Ada isn't more popular?
- From: Markus E Leypold
- Re: How come Ada isn't more popular?
- From: Dmitry A. Kazakov
- Re: How come Ada isn't more popular?
- From: Markus E Leypold
- Re: How come Ada isn't more popular?
- Prev by Date: Re: in defense of GC (was Re: How come Ada isn't more popular?)
- Next by Date: Re: in defense of GC
- Previous by thread: Re: How come Ada isn't more popular?
- Next by thread: Re: How come Ada isn't more popular?
- Index(es):
Relevant Pages
|
