Re: How come Ada isn't more popular?

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

Markus E Leypold wrote:

[I agree with what you say on historical perspective on language 
transitions and the probabilistic effects that languages have on 
newbies, so this part was cut.]

> If you just do f(s.c_str()) and f _is_ properly behaved, that is, only
> reads from the pointer or does a strdup(), everything is fine, but, I
> note, not thread safe. I wouldn't exclude the possibility that the
> resulting race condition is hidden in a nice number of C++ programs
> out there.

If you have a race condition because of some thread is modifying a 
string object *while* some other thread is using it, then you have a 
heavy design problem. This is absolutely not related to interfacing with C.

> Your solution is thread safe, if the strings package is (which it
> wasn't in the past).

Strings package cannot make it any better, because the granularity of 
thread-safety results from the program logic, not from the package 
interface. String is too low-level (it's a general utility) to be 
thread-safe in any useful sense. That's why: a) it should not be 
thread-safe on its own, b) you still have a design problem.

Interestingly, Ada doesn't make it any better. Neithe does Java. You 
always need to coordinate threads/tasks/whatever on some higher 
conceptual level than primitive string operations.


[about closures]

>> You can have it by refcounting function frames (and preserving some
>> determinism of destructors). GC is not needed for full closures, as
>> far as I perceive it (with all my misconceptions behind ;-) ).
> 
> Yes, one could do it like that. Ref-counting is rumoured to be
> inefficient

Which relates to cascading destructors, not to function frames.

> but if you don't have too many closure that might just
> work.

If you have too many closures, then well, you have too many closures. :-)

We've been talking not only about performance, but also about 
readability and maintenance. ;-)

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

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.

> 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.
Today manual memory management is a low-level thingy that you don't have 
to care about, unless you *really* want to (and then it's really good 
that you can get it). And as I've already pointed out, in my regular 
programming manual memory management is a rarity.

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. The 
problem is that few programs rely on only memory and in a typical case 
there are lots of resources that are not memory oriented and they have 
to be managed, somehow. When GC is a shiny center of the language, those 
other kinds of resources suffer from not having appropriate support. In 
practical terms, you don't have manual management of memory, but you 
have *instead* manual management of *everything else* and the result is 
either code bloat or more bugs (or both, typically).

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. The result is clean, short and uniform code, which 
is even immune to extensions in the implementation of any class. Think 
about adding a non-memory resource to a class that was up to now only 
memory oriented - if it requires any modification on the client side, 
like adding tons of finally blocks and calls to 
close/dispose/dismiss/etc. methods *everywhere*, then in such a language 
the term "encapsulation" is a joke.

An ideal solution seems to be a mix of both (GC and automatic objects), 
but I think that the industry needs a few generations of failed attempts 
to get this mix right. We're not yet there.


>> OO is about encapsulation and polymorphism, these don't need
>> references everywhere.
> 
> Yes, but -- you want to keep, say, a list of Shape(s). Those can be
> Triangle(s), Circle(s) etc, which are all derived from class
> Shape. How do you store this list? An array of Shape'Class is out of
> question because of the different allocation requirements for the
> descendants of Shape(s).

Why should I bother?

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.


> I've decided, if I want to deliver any interesting functionality to
> the end user, my resources (developer time) are limited, I have to
> leave everything I can to automation (i.e. compilers, garbage
> collectors, even libraries), to be able to reach my lofty goals.

I also leave everything I can to automation. It's spelled 
[Limited_]Controlled in Ada and automatic storage duration in C++.
I cannot imagine reaching my lofty goals otherwise. ;-)

> The point is to know when to optimise, not to do it
> always.

I didn't even mention the word "optimization". I'm taling about structure.

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