Re: How come Ada isn't more popular?

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

On Sun, 04 Feb 2007 21:44:17 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 03 Feb 2007 15:16:21 +0100, Markus E Leypold wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> On Fri, 02 Feb 2007 13:34:21 +0100, Markus E Leypold wrote:
>>>>
>>> I've been expressing myself sloppily. It should return a CountVal, not
>>> an Additive'Class. CountVal(s) could not be added to Vectors -- there
>>> is a difference.
>>
>> When Inc returns CountVal then it is not a member of Additive in the
>> result. So you cannot reuse the result for other members of Additive.
> 
> Exactly. So it should not return Additive'Class (which can be added to
> other members of Additive'Class), but must return CountVal to prevent
> this.

If that was the only reason, then that worked perfectly in Ada 83, before
Ada 95 broke it for tagged types [there were some reasons, though]:

type Isolated_CountVal is new CountVal; -- Done

>>>> No, it does Additive'Class! Thus, no problem.
> 
> that means your approach fails. Do you see the different type
> structure the approach using generics produces as compared to your
> class inheritance approach?

First, what was the problem? Moving target is a difficult thing to track.

>>>> (note that the goal was polymorphic Inc, if you wanted it covariant that
>>> 
>>> No. The goal was to have mechanism to write the algorithms once and
>>> being able to pull various actual operators/procedures from that
>>> without replicating the specification of the algorithm.
>>
>> If you want to reuse Inc's algorithm in various specific Inc, then you
>> would use wrappers:
> 
> No I wouldn't. At the most I'd want to instantiate one generic. See:
> We are not talking about one procedure. In general we are talking
> about whole libraries (i.e. BTree manipulation and search) which
> contain -- in extremis -- 10 to hundred procedures, and I certainly do
> NOT want to wrap all of them for every new instance differently typed
> instance of the problem.

That indeed looks like type X is new Y; Compare ONE line vs. hundred
instantiations!

BTW, there is no generic libraries in a sane sense of this word. Only
instantiations of generic libraries are libraries. (:-))
 
>> Should I show you generic specifications of this mess? 
> 
> And it does become better with OO? I doubt that very much.

Nobody tied. If the efforts spent on fixing Ada generics were invested into
the type system, who knows.

> Indeed the
> trick is, not to have n+m+1 instances but package instances of
> generics into libraries and instantiate whole "world" in one
> stroke.

I does not work, because it is not a world it is a multiverse of
interconnected worlds of different types.

The great idea of Ada numeric types with its ranges and accuracy gets lost,
because for any of them you have to instantiate all this pathetic mess. It
ends up with C-ish everything is double.

Generics is not Ada!

>> I DON"T want it. I need a clean way to describe an algebra and a lattice
>> and then mix and bend them as I want. 
> 
> I doubt OO is the way.

Nobody seriously tried it. Ironically, but C++ which was started as "C with
classes" suddenly turned into #define++!

>> I want to be able to derive everything from a scalar. There is
>> always much talk about how mathematical are generics and FP, it is
>> amazing to me how readily people believe in that.
> 
> So they are wrong? :-)) Perhaps a big conspiracy, like the big C/C++
> conspiracy and the big Java conspiracy.

An argumentation to popularity? (:-))

> People, you make me laugh.

I don't speak for Ada community. I bet the silent majority is rather with
you than with me.

> Isn't it avantgarde enough just to use Ada?
> Must everyone else in this world be a misguided moron or an evil
> propagandist?

Huh, c.l.a is a quite tolerant group, IMO.

>> You need two interfaces: Array and Weakly_Ordered. 
> 
> Which forced me to use tagged type all day long and all the way, where
> simply traditional array access would suffice.

All types shall be tagged, including Boolean.

> Let's have a look at
> verifiability: I'm sure, generics can be verified better and easier. I
> heard something about tagged types being really out in that sector,
> and by the way, I agree. The dispatch over 13 subclasses mess
> "patterns" introduce is just spagetthi programming with a big
> name. (Not to disparage pattern, but making something OO doesn't make
> it modular or structured per se).

What about 13 generic packages?

>> You could also sort same elements of same container object using
>> different orders. [However usually in such cases one better uses a
>> sorted view, rather than physically sorts.
> 
> That you can do, but I still could just sort accesses to the
> elements. Withou the OO mess.

1. It is not a generic solution.
2. Elements must be aliased, which changes the container type.
3. You can do that with OO.

Class-wide (OO), generic, functional are orthogonal approaches which can be
mixed in different proportions. In a proper type system they all will
converge because both generics and procedures will become proper types and
values. I fail to see the reason why this so irritates you.

>>> Yes. But Georg used generics, so it worked. You said, you don't want
>>> generics, but it doesn't work. I fail to see, how George has to use
>>> select an example that makes your misguided hypothesis -- that
>>> generics are not neeeded -- hold up. Quite the opposite.
> 
> 
>> generic
>>    type Element is private;
>>    with function "<" (Left, Right : Element)  return Boolean;
>>    with function "=" (Left, Right : Element)  return Boolean;
>>    type Container ...
>> procedure Quick_Sort (...);
> 
>> How can this can sort the same container?
> 
> Which "same container"?

Of the same type and the same object.

>> This is a clear case where generics don't work. 
> 
>  Have you recently had a look to Ada.Containers? There is a generic array sort. So? 

What is generic there? How polymorphism of comparison is achieved.
Statically, dynamically, ad-hoc?

>> You need "<" and "=" be passed as proper functions
>> rather than formal generic functions. [It is not static polymorphism
>> anymore.]
> 
> And, what is the problem with that.

That it is not generic. You cannot call a car solar just because you carry
wrist-watch with solar cells while driving it...

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