Re: How come Ada isn't more popular?

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

Relevant Pages

  • Re: How come Ada isnt more popular?
    ... I think the absence of manual memory management code actually furthers ... the rest of the language in such a way that GNAT didn't get it right ... fcuntional langauges you can do more against ressource leaks, ...
    (comp.lang.ada)
  • Re: Why do some people hate java?
    ... C++ templates can do some things that Java generics can not. ... memory is the only resource that must be managed. ... and other resources that are just as important to ... To the extent that the language ...
    (comp.lang.java.programmer)
  • Re: Article of interest: Python pros/cons for the enterprise
    ... due to the lack of deterministic destruction. ... Python you manage resources and the language manages memory. ...
    (comp.lang.python)
  • Re: OOP and memory management
    ... >> The are more resources that a single program must manage ... >> new programmers just means that they never get any experience ... >> all memory allocated must be deallocated. ... Read above where I said that the language ...
    (comp.programming)
  • Re: Another C# vs. VB question....
    ... C is much powerful, uses less memory, resources, and drive space. ... And currently C++ is the only language I know of which can mix native and managed code. ...
    (microsoft.public.vb.general.discussion)