Re: How come Ada isn't more popular?

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

Markus E Leypold wrote:

>> And I stress again - GC is not the only solution for
>> manual memory management.
> 
> OK. I accept that for the moment. I'm just not convinced you can do
> everything you need with scope bound memory

Sure. But for the sake of discussion completeness, you might wish to 
throw an example of a situation where scoped lifetime will not make it.

>> Determinism in both timing and resource consumption?
> 
> Which brings me back to what I said repeatedly to other people: 
> 
>  (1) That this determinism is very often not a requirement (outside of
>      embdedded programming)

Java programmer wrote a loop where he opened database cursors, released 
in the cursor finalizer. All was working like a charm, unless put into 
production, when in one case the loop had to spin many more times than 
he ever cared to test. GC did not clean up the abandoned cursor objects 
fast enough and the number of unnecessarily opened cursors hit the 
server limit. That was the end of this application.

The fix was easy: write explicit close/dispose/dismiss/whatever at the 
end of the loop, so that effectively there was never more than one open 
cursor. In fact, this was *manual* resource management.

The above would be avoided altogether with scoped lifetime.

You are right that determinism is very often not a requirement. It is 
just the life that very often shows that the initial requirements were 
not complete.

>  (2) The determinism is shot anyway by using a heap, not by using
>      GC. Even better: GC can introduce detereminism in space
>      consumption by compacting the heap, which naive heaps with manual
>      MM don't do because of fragementation.

There is nothing particular in scoped lifetime that would prohibit 
compacting heaps and there is nothing particular in GC that guarantees 
it. It's just the statistics based on popular implementations, not a rule.
I can perfectly imagine compacting heaps managed by scoped lifetime.

>  (3) What is often needed are upper limits not determinism and thos
>      upper limits can be guaranteed with GC or with an appropriate
>      collector.

This refers to memory consumption only, whereas I clearly stated 
deterministic *time* as a second (first, actually) goal.

>>> 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.
> 
> I understand. But the Ada OO way is peculiar, but not unmanagable.

OK, I accept the word "peculiar". I only oppose "quite a clean concept" 
in your previous post. :-)

>> 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.
> 
> Still. Being able to add a Finalize means you need to have a tagged
> type. I see no alternative.

You might want to take a look at C++.

>>> 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?
> 
> I already say in another post: That is difficult to show with a toy
> system. It only shows in larger systems where you really can't / don't
> want to say in any give subsystem module how long a certain peice of
> data lives. So none of those can be burdened with deallocating it.

OK. What about refcounting with smart pointers?

>>> 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.
> 
> Yes, I see. But GNAT is also a political problem (see the role of
> AdaCore, formerly ACT), so (public) GNAT not getting things right
> might well not indicate a problem with reading the Ada standard, but
> in the release politics for public version. My hint: There is no
> incentive to release a high quality public version GNAT.

I get the message. Clear enough.

>> In other words, it's very nice that GC doesn't preclude me from doing
>> some stuff manually, but that's not enough.
> 
> I'm appalled: You don't want GC, but no, it doesn't do enough for you?

Exactly. It's not enough, because it doesn't solve the problem of 
resource management in a general way.

> Of yourse YMMV. but when I have it, it works really well for me.

I acknowledge that there might be some applications which are strictly 
memory-oriented. They are just not the ones I usually write.

>>> 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.
> 
> That's not quite true. Those tricks are building blocks to implement
> ressources that are automatically finalized when becoming
> unreachable. But it's up to the library author to write a complete
> implementation.

I don't understand. If the is no guarantee that the finalizer will be 
*ever* called, then what kind of building block it is?

>> A friend of mine spent long evenings recently hunting for database
>> connection leaks in a big Java application. That's telling something.
> 
> Well -- so he was naive and should have handled / understood that part
> of the system better.

Sure. In other words, be prepared that with GC you have to 
handle/understand some parts of the sytem better.

> A friend of mine spent half a month with finding
> problems with manual allocation/deallocation and sneaking heap
> corruption. Does that prove anything? I don't think so.

It does prove that your friend did not benefit from the language that 
provides scoped lifetime.

>>> 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.
> 
> This is no emulation, but how FP does "scope based". Without the
> necessity to add exception handling at the client side or without
> having to introduce tagged types / classes. Isn't THAT nice? :-)

Same thing with scoped lifetime, as implemented in C++. No need for 
exception handling (unless handling is actually meaninful), nor for 
changes in the interface. That's nice, I agree.
The difference is that in languages with scoped lifetime the lifetime 
management is a property of the type (and so applies to all instances), 
whereas the "FP-trick" above is a property of the use-side. Which one is 
more robust and less prone to bugs?

BTW - please show me an example involving 10 objects of different kinds. :-)

>>> 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.
> 
> No, but the structure of the argument is basically the same. The
> analogy should help to show why it is (IMHO) invalid.

Ok, but please elaborate on the above first, so I'm sure that it relates 
to my point.

>> 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. 
> 
> No. I've done the same in Ada w/o controlled objects, but using a
> generic procedure.
> 
>   procedure mark_data_records is new process_cache_with_lock( Operation => mark_record, ... );
> 
>   begin
>     mark_data_records(...);
>   end;
> 
> The client side has no burden with exceaption handling.

Could you explain this example a bit?

>> I agree for references/pointers in polymorphic
>> collections. That's not even close to "almost everywhere" for me, but
>> your application domain may differ.
> 
> Yes. it does, abviously. You might not be aware, but code destined for
> mere consumers (as opposed to embedded code and code destined as tools
> for other developers) has a large amount of GUI code in it.

Yes.

>>>  (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.
> 
> Yes. But does C++ do it better? The Ada restrictions AFAIK come from
> the necessity of separate linking and compilation (you must be able to
> relink w/o looking at the body) and C++ treats that against the
> ability to add finalizers everyhwere.

I don't understand. Adding a finalizer/destructor to the type that 
didn't have it before means changes in both specs and the body. 
Relinking is not enough.


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