Re: How come Ada isn't more popular?

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/
.