Re: How come Ada isn't more popular?

[Ray Blaak <rAYblaaK@STRIPCAPStelus.net>]

Maciej Sobczak <no.spam@no.spam.com> writes:
> 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).

This is a fair criticism, actually. I am not sure what the state of the art is
with regards to expanding the concept of a garbage collector to a more general
resource manager, of which memory is only a particular kind of resource.

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

I do a lot of coding, and I simply do not find this to be such a prevelant
problem in practice. The most common case is to do with the closing of open
files in a finally block, but one only does the open in a few places and the
majority of the code is not concerned with cleanup at all.

The other common case is getting access to system drawing contexts that must
be explicitly disposed of. Again, one tends to get it only in a few places,
and the occurrences of explicit clean up are few.

Still, when I use C++ after using C# or Java, I find myself immediately taking
advantage of the scope-based destructors for these situations.

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

Yes, when you need scope based cleanup, proper controlled types are useful.
We will see how it goes.

Still, with the existence of proper closures in a language, one can get scope
clean up already. In the C# example below, I can define a file open/close
helper that let's the grunt-work cleanup be specified only once, such that I
pass an "action" closure to perform the actual work on an open file (think of
"delegate" as closure/lambda/procedure, etc.):

  string path = "C:/temp/someFile.xml";
  string xmlData = null;
  WithOpenFile
    (path, 
     delegate (TextReader reader) 
     {
       xmlData = reader.ReadToEnd(); // note we can modify the local variable
     });

where WithOpenFile is defined as:

  public delegate void FileReader(TextReader reader);

  public void WithOpenFile(string path, FileReader fileReader)
  {
    TextReader reader = new TextReader(path);
    try
    {
       fileReader(reader);
    }
    finally
    {
       reader.Close();
    }
  }
-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.