Re: How come Ada isn't more popular?

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

Markus E Leypold wrote:

I will cut ad-persona ramblings and your suggestions about my 
competence, and try to restate major points.

>> I prefer solutions which enable me to hide implementation details from
>> clients (sotware engineering?). If clients have to treat different
> 
> I fail to see how using no GC helps you in that, whereas using GC as
> it is today hinders you.

You probably didn't read my previous posts in detail.
I claimed that mainstream GCed languages put so much faith in the GC 
concept that they drop scoped lifetime altogether. *This* hinders me 
from solving my problems in a uniform way.
I'm not happier with "no GC" and having GC is irrelevant to my problems.
What is relevant to my problems is scoped lifetime and this is missing 
from mainstream GCed languages. Got the point?

>> So why people claim that GC-oriented languages are general-purpose?
> 
> Because they can write all kinds of programs with them?

Assembly language has this property as well. Actually, computational 
completeness can be achieved with two instructions only, but I don't 
consider it as a valid argument for being general-purpose.

>> The point is that languages which are build
>> around GC tend to drop the proper support for other types of resources
>> altogether. 
> 
> As if manual managment could be called proper support in this respect ...

Then I will restate it again: the world is not partitioned between GC 
and manual management. As I've already pointed, you will not find manual 
management of anything in my regular code and since I'm also not using 
GC, then your view must be incomplete.

// warning: this is not Ada
{
     Session sql(oracle, "some-params");
     string name;
     sql << "select name from persons where id=7", into(name);
     cout << name << '\n';
}

Do you see *any* manual management of anything in the above? I stare at 
this code and I don't. Do you see GC here? I don't.
Then please stop building your arguments on the presumption that only 
these two options are possible.

Do you require from the user the understanding of implementation details 
of any of the above constructs? I don't.
We (software engineers) call it encapsulation.

> Big words, but given the choice between
> 
>  1) Manual ressource management
>  2) GC with (according to you) imperfect support for other kinds of ressources
>  3) The hypothetical system you propose should exist

The point is that you are not given only these choices.


> Heap(s) -- I even resent the plural here -- are not about scoped but
> about indeterminate lifetime. And a "compacted" heap has all the
> unpredictability (in timing) as that of a garbage collector and would
> provide garbage collection almost for free. 

Yes. My point is that compacting abilities are not restricted to GC.

> People don't know how GC works,
> don't know what it does

It does not matter. What does matter is that not having scoped lifetime 
doesn't work. If you want to sell GC without scoped lifetime, I won't 
buy it.

>>> 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.
> 
> There are, as I can see, no non-fragmenting (heap) allocators for
> unpredictable allocation patterns.

There are. Write on a piece of paper all the reasons that in conjunction 
lead to heap fragmentation and think how to get rid of at least one of 
them. That's actually easy.

> Apart from the fact that there are no nonfragmenting
> allocators being shipped with, e.g. Ada. So do it yourself. Wow: Avoid
> compacting GC, get more work, do it by hand. You can see why that
> doesn't attract me.

You see, the point is that in Ada or C++ I *can* and *know how* to 
improve anything I want based on the foundations that these languages 
give me (even if that means work), whereas in languages that have no 
support for scoped lifetime there is simply no foundation on which any 
improvements might be built on. Wow: Prevent people from achieving their 
goals, so they have less to do. You can see why that doesn't attract me.

>> Note that scoped lifetime does not preclude GC on some lower level.
> 
> You admit it, finally?

Admit what? Scoped lifetime does not preclude GC on some lower level. 
The lack of scoped lifetime sucks, no matter whether GC is provided or not.

> Unfortunately GC is no implementation detail, since you see wether
> there a free() or dispose() calls in the source.

You admit it, finally?

Then look again at the snipped I provided above. Do you see *any* free() 
or dispose() calls in the source? I don't. We call it encapsulation.

> Yes, but smart pointers where YOUR better answer to GC.

No. My answer is scoped lifetime. Look again at the snipped above, there 
are no smart pointers in sight.

Smart pointers are useful as a solution for resource management built on 
top of scoped lifetime in cases where the resource is not tied to a 
single scope. I use them, but *very* rarely.

> You were
> dissatisfied with GC.

I'm dissatified with languages that provide GC *instead of* scoped 
lifetime. The focus should be put on "addition", not "instead".

> File handles are in my view not
> supposed to be handled by GC since they are structurally and
> semantically different from memory. They should be closes explicitely.

Bingo. But do you explicitly operate on all file handles that your 
program manages? Then you must be using some extremeley low-level language.
Consider a class ConfigurationData (or whatever). Do you have to 
explicitly dispose of it? Hm... That depends on what ConfigurationData 
has *inside*. If it's bound to some file handle (say, using simple 
persistency scheme based on filesystem), then yes.
This means that your reasoning has to be transitively closed based on 
the relations between implementation details of all dependent entities.
Do you call it encapsulation?

Consider another complication. A team that is responsible for 
ConfigurationData ships the 1.0 version of the package with in-memory 
database as a backend. They specify the interface.
Some time later they ship 2.0 with files as backends. The specs didn't 
change (wow! that's what encapsulation is supposed to look like, no?), 
so according to software engineering practices you are not obliged to 
change anything in your code. Oops. Where's encapsulation?

> No. You just need to stick to the rules. Close your ***** filehandles
> manually. All the time.

Thank you for clearly describing this paradigm. No, I'm not convinced.

> If you want to be smart, though, it pays to think about the
> interaction with underlying system (the implementation).

I don't want to be smart. I want to be productive and have less bugs in 
my code. I noticed that scoped lifetime allows me to achieve this more 
effectively than without it.

> I didn't do that, so I can't defend against it. Perhaps your friend
> simply is not the Java software engineer he wants to be. I never did
> have that problem ... -- so can I stop now defending my approach to
> programming against errors other people have committed in another
> language because they didn't read the JDBC reference manual?

Should the user of ConfigurationData read the JDBC manual? Should he 
ever need to be aware that JDBC is used *somewhere there* deep in the 
bowels of ConfigurationData?

> Reusing code in another context without re-viewing it, was what cost
> the ESA that famous Ariane 5 launch.

Good point, but where's encapsulation here? What about decoupling 
implementation from specification?

> Reviews, reviews, reviews. Understand what you use!

Then maybe we should drop this decoupling altogether?

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