Re: How come Ada isn't more popular?

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

Markus E Leypold wrote:

>> 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.
> 
> Model-View-Controller in GUIs. Especially trying to adapt that to GTKAda.

I will not repeat Dmitry's arguments here.

>> Java programmer wrote a loop where he opened database cursors,
[...]

> I'm not surprised. GC'ing ressources that are bounded doesn't spare
> you knowing about the way GC works.

Exactly. That's why I say that the solution is incomplete. If you have 
to think about the mechanics of some solution, then that solution is not 
entirely/properly automated.

> You're approach "I want it all, and if
> I can't have both (memory management AND general ressource collection)
> I don't want neither" is somewhat counterproductive. 

I find it counterproductive to apply different management strategies 
with regard to *implementation details* of different types.
I prefer solutions which enable me to hide implementation details from 
clients (sotware engineering?). If clients have to treat different types 
differently just because their implementation details differ, then it 
means that these implementation details leak out in the form of distinct 
handling methods. I want to treat String and DatabaseCursor in the same 
way - that's the prerequisite for being productive for me.

> But you might well continue to believe in your policy here.

Thanks. :-)

> I,
> personally, find that it brings me a big step nearer to salvation if I
> can have GC, even if I do only manual MM with it. After all: I don't
> have this much other (external) ressources to care about and if I do,
> it pays to have a careful look at their structure and then wrap some
> abstraction around them.

OK, I understand it. We just agree that GC is a valid solution for 
*some* class of computing problems.
So why people claim that GC-oriented languages are general-purpose?

> But your approach is, since somebody had problems
> misusing GC in a specific case

No, that's not the point. The point is that languages which are build 
around GC tend to drop the proper support for other types of resources 
altogether. It's not the particular programmer who misused GC in a 
specific case - it's language designers who closed themselves in the GC 
cage and cranked a language that fails to provide good support for wider 
class of problems.
As I've already said, the ideal would be to have both GC and scoped 
lifetime. The problem is that there is no reliable industry experience 
with such a mix, unless we treat Boehm's GC as one.

> As far as the usability of GC goes, it even helps with controlled
> objects
[...]
> I just make sure to close (e.g.) the filehandle and let the
> rest to the GC.

Of course. But then it's up to the designer of the type to decide how to 
treat each component of that type - it should be implementation detail. 
This decision should not be put on the shoulders of the final user, 
which is now the case in mainstream GC-oriented languages. This is what 
is broken.

>> There is nothing particular in scoped lifetime that would prohibit
>> compacting heaps and there is nothing particular in GC that guarantees
> 
> No. But without having 3/4ths of a GC anyway compaction is pretty
> pointless.

Why? If the goal of compaction is to avoid fragmentation, then what is 
pointless in having compacted heaps managed by scoped lifetime?

>> it. It's just the statistics based on popular implementations, not a
>> rule.
> 
> Sorry, that is nonsense. There are garbage collectors that are
> designed to be compacting.

So what? This is exactly the statistics I'm talking about, that does not 
prove that GC guarantees compacting or that the lack of GC prevents it.

> They are moving objects around. This is
> absolutely deterministic and not statistical.

By statistics I mean the number of language implementations on the 
market that choose to use compacting GC vs. the number of languages that 
use non-compacting heaps. :-)

 > Whereas manual
> allocation and deallocation as in Ada or C will fragment the heap and
> you have NO guarantee (only statistics) about the ratio of allocated
> (used) memory and presently unusable hole.

If that bothers you, then use non-fragmenting allocators.

> Hows that about
> reliability if you can't give space guarantees even if you know about
> the memory your algorithms need, since unfortunately you cannot
> perdict the exact sequence of allocations?

I use non-fragmenting allocator and I get my guarantees.

>> I can perfectly imagine compacting heaps managed by scoped lifetime.
> 
> Yes you can do that. Since you're following pointers than and reqrite
> them you might as well go the whole way and deollaocate unusable
> memory while you're at it.

Yes. Note that scoped lifetime does not preclude GC on some lower level.
Scoped lifetime provides a hook for deterministic "good bye" action - 
there is nothing more to it. Even if that "good bye" action calls 
free/delete/whatever on some memory block, there is nothing that forces 
the runtime to return the given block of memory right back to the 
operating system. Actually, none of the self-respecting allocators do 
this systematically - instead they keep the memory around for a while in 
anticipation of future allocations. I have nothing against GC at this 
level, really (and I've seen such implementations - in fact, a fully 
standard-compliant implementation of the C language could provide 
*empty* free function and GC underneath; and fully conformant C++ 
implementation could just call destructors as a result of delete and 
leave the raw memory to GC).

What I'm against is a GC "paradigm" that prevents me from having 
deterministic "good bye" hooks for scoped lifetime. The problem is that 
most GC-oriented languages I'm aware of do have this "issue".

In other words, for me GC is acceptable as an implementation detail of 
the dynamic memory allocator. I don't care *how* the allocator deals 
with memory that I free in the same sense that I don't care *how* the 
operating system deals with files that I remove from the filesystem. 
What I care about are hooks and scoped lifetime is an obvious answer for 
this.

>>>  (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.
> 
> This refers to both, there are real time compatible GC
> algorithms.

I'm interested in what is their target audience. I would expect any 
decent RT system to *refrain* from using dynamic memory except in the 
initialization phase (so that the "mission phase" is performed with 
constant set of objects), in which case RT GC would be just an answer to 
the question that nobody asked.
Experts might wish to correct me and elaborate on this.

>> OK. What about refcounting with smart pointers?
> 
> (1) It ties lifetime to multiple scopes (instead of one)

With GC tracing pointers you have the same, just the tracing is hidden.

> (2) its not
> efficient

Why?

> (3) It stille doesn't work for the general case

Neither does GC, as seen in examples. :-)

>> I acknowledge that there might be some applications which are strictly
>> memory-oriented. They are just not the ones I usually write.
> 
> It also works for apps that are not "memory-oriented". I think you're
> missing that e.g. filehandles are really simpler and differently
> structured ressource from memory. A filehandle does not contain
> references to memory or other filehandle. Memory does. That vastly
> simplifies the problem of managing file handles indeed so much that
> I'm convinced that you don't need buitlin support for this.

Somehow this idea didn't work for database cursors, as already described.

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

So the implementation details of *some* types leak out in the sense that 
they force me to understand their internal mechanics. I don't want to.
I want to say this:

declare
     Sql : Session := Open_Session("some parameters");
     Str : String := "Hello";
begin
     -- ...
end;

instead of this:

declare
     Sql : Session := Open_Session("some parameters");
     Str : String := "Hello";
begin
     -- ...
     -- damn, I have to do *something* with *some* stuff here
end;

[about FP]
>> 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?
> 
> This is, forgive me, nonsense. I might want to use a file handle in a
> scoped way here and in a free floating way there.

What about readability and maintainability of such code?

> And no -- the FP way is not "more prone to bugs"

Unless you use a handle in a free floating way and find later that in 
production your code was called in a loop causing handles to pile up?
I have the practical example (already described) that this way of 
thinking can lead to failures. The programmer wanted to use a database 
cursor in a free floating way. That was fine. Later his code was used in 
a loop. Ah, yes - his code was used in a loop written by another 
programmer, so his judgement about whether it's OK to use anything in a 
free floating way was misguided from the very beginning.

> and as with
> George Bauhaus I simply refuse this kind of discussion (FUD and
> ContraFUD).

OK. We will just stay unconvinced. :-)

>> BTW - please show me an example involving 10 objects of different kinds. :-)
> 
> All at the same time?

Yes.

> Well -- bad programming.

I knew you would answer this. :-)


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