Re: How come Ada isn't more popular?

[Maciej Sobczak <no.spam@no.spam.com>]

Markus E Leypold wrote:

> Let's ditch the thread safety aspect and instead:
> Giving pointers to internal state of objects violates (a)
> encapsulation (it fixes a specific implementation) and (b) is not type
> safe.

That's right. This is a result of the fact that C-style strings are not 
encapsulated at all and interfacing to them means stepping down to the 
common ground.

>> We've been talking not only about performance, but also about
>> readability and maintenance. ;-)
> 
> Of this thread? :-)

:-)

>>>>> Furthermore I've been convinced that manual memory management hinders
>>>>> modularity.
>>>> Whereas I say that I don't care about manual memory management in my
>>>> programs. You can have modularity without GC.
>>> Certainly. But you can have more with GC.
>> In a strictly technical sense of the word, yes. But then there comes a
>> question about possible loses in other areas, like program structure
>> or clarity.
> 
> I think the absence of manual memory management code actually furthers
> clarity.

I believe so. And I stress again - GC is not the only solution for 
manual memory management.

>> Being able to just drop things on the floor is a nice feature when
>> considered in isolation, but not necessarily compatible with other
>> objectives that must be met at the same time.
> 
> Which?

Determinism in both timing and resource consumption?

>>> People who don't have GC often say that they can do anything with
>>> manual memory management.
>> And I say that this is misconception. I don't have/use GC and I don't
>> bother with *manual* memory management neither. That's the point. In
>> Ada this point is spelled [Limited_]Controlled (it's a complete mess,
>> but that's not the fault of the concept) and in C++ it's spelled
>> automatic storage duration.
> 
> My impression was that Ada Controlled storage is actually quite a
> clean concept compared to C++ storage duration.

Clean? It adds tag to the type, which then becomes a controlling type in 
every primitive operation. I got bitten by this recently.
Adding a destructor to C++ class never has any side effects like this.

Apart from this, the bare existence of *two* base types Controlled and 
Limited_Controlled means that the concepts of controlled and limited are 
not really orthogonal in the sense that adding one of these 
meta-properties affects the interface that is "shared" by the other aspect.

It's a mess. Actually, it prevents me from thinking clearly about what I 
want to achieve.

> But both tie allocation to program scope, synchronous with a stack. I
> insist that is not always desirable: It rules out some architecture,
> especially those where OO abounds.

What architecture?

> The problem with Controlled, BTW, is that it seems to interact with
> the rest of the language in such a way that GNAT didn't get it right
> even after ~10 years of development. Perhaps difficult w/o a formal
> semantics.

You see.

>> On the other hand, most languages with GC get it wrong by relying
>> *only* on GC, everywhere, whereas it is useful (if at all) only for
>> memory. 

> Now, now. Having GC doesn't preclude you from managing ressources
> unrelated to memory in a manual fashion.

Of course. No, thank you. I prefer a language which enables me to use 
the same logic for all resources, so I *don't have to* manage *anything* 
manually.
In other words, it's very nice that GC doesn't preclude me from doing 
some stuff manually, but that's not enough.

> Apart from that languages
> with GC often provide nice tricks to tie external ressources to their
> memory proxy and ditch them when the memory proxy is unreachable

These "nice tricks" are not so nice. Most of all, they provide no 
guarantee whatsoever, even that they will be invoked at all.
A friend of mine spent long evenings recently hunting for database 
connection leaks in a big Java application. That's telling something.

> And BTW - in
> fcuntional langauges you can do more against ressource leaks, sicne
> you can "wrap" functions:
> 
>   (with_file "output" (with_file "out_put" copy_data))
> 
> It's not always done, but a useful micro pattern.

Yes, it basically emulates something that is just natural in those 
languages that provide scope-based lifetime out of the box.

>> Languages like Ada or C++ provide more general solution, which is
>> conceptually not related to any kind of resource and can be
>> therefore applied to every one.
> 
> Since you're solving a problem here, which I deny that it exists

You might wish to tell this to my friend - the one hunting database 
connection leaks. :-)

> But I notice, that
> 
>  "Languages like C provide a more general solution (with regard to
>   accessing memory), which is conceptually not related to any kind of
>   fixed type system and can therefore implement any type and data model"
> 
> would become a valid argument if I agreed with you.

Except that it's not the point I'm making.

> In an FP I write (usually) something like:
> 
>      with_lock "/var/foo/some.lck" (fun () -> do_something1 (); do_something2 param;  ...).
> 
> The fact that Ada and C++ don't have curried functions and cannot
> construct unnamed functions or procedures is really limiting in this
> case and probably causal to your misconception that it would be
> necessary to add tons of exceaption handling at the client side.

Tons of exception handling (and not only - every way to leave a scope 
needs to be guarded, not only by exception) are necessary in those 
languages that rely on GC without providing the above possibility at the 
same time. The other possibility is to rely on scoped lifetime in the 
first place, where neither GC nor the above tricks are necessary to 
achieve proper cleanup.

> And BTW: In Ada I would encapsulate the ressource in a Controlled
> object (a ressource proxy or handle) and get the same effect (tying it
> to a scope).

Yes.

> Indeed I have already done so, to make a program which
> uses quite a number of locks, to remove locks when it terminated or
> crashes. Works nicely.

Of course. That's my point.
(except, maybe, the crashing part, when likely there is nobody to handle 
the cleanup)

>> Note also that I didn't say that references/pointers should be
>> dropped. I say that you don't need them everywhere. That's a
>> difference.
> 
> OK, so you need them _almost_ everywhere :-). I take your point.

No, you don't. I agree for references/pointers in polymorphic 
collections. That's not even close to "almost everywhere" for me, but 
your application domain may differ.

> 'Controlled' buys you a lot in Ada, but there are 2 problems
> 
>  (a) AFAIS (that is still my hypothesis, binding storage to scope is
>      not alway possible (esp. when doing GUIs and MVC and this
>      like). I cannot prove but from what I experienced I rather
>      convinced of it.

I don't follow this.

>  (b) AFAIR there are restrictions on _where_ I can define controlled
>      types. AFAIR that was a PITA.

That's a mess. I'm sorry to repeat that.

> But how does a program become less structured by removing the
> manual memory management? The GC is not magically transforming the
> program into spaghetti code ...

You get spathetti once you start adding finalizers - the spaghetti is 
then formed in both time (when something is invoked) and space (where 
the code is).

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/