Re: The future of Ada is at risk

[Agyaras <agyaras@kerekerdoe.hu>]

In article <1199452391.7932.27.camel@K72>,
 Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> wrote:

> > I can confirm this. E.g. it is a major headache to get the GNAT compiler 
> > working under Mac OS X.
> 
> What do you think of http://www.macada.org/ ?

Yes, I know the site, and have downloaded the FSF gcc4.3 version from 
there ( both PPC and Intel). The problem is that this gcc sometimes 
cannot compile packages the "official" Apple gcc can. So one has to 
switch back and forth, using gcc4.3 for Ada work and the Apple gcc for 
other work (e.g. C++). This is probably Apple's fault though.

> >  AdaCore stopped distributing GNAT/GPS (GPL) for 
> > the Mac.
> 
> Huh? It is still there (the 2006 edition)
That is PowerPC only, based on gcc 3.4, with incomplete Ada2005 support. 
It would be nice to have GPS for Intel Macs, gcc4.2 at least, with 
complete Ada2005 support. I tried to compile GPS from the Linux sources 
(2007 edition) on the Mac and it turned to be very time-consuming, 
because GPS needs lots of libraries that in turn needed more 
libraries... finally I gave up, after I asked on this newsgroup and 
people told me that it was really difficult to do... but maybe the good 
folks at AdaCore have the proper setup and the know-how to do it.

> , and support for the
> later Intel based Macs is officially announced on the AdaCore
> supported platforms page.
I was perhaps not clear on this: I am missing the **GPL** editions of 
GNAT **and** the GPS IDE for a number of platforms. In 2007 the GPL-ed 
GNAT+GPS packages are available for Windows and 32-bit/64-bit Linux 
only. I cannot afford the license costs.

> >  There has never been a GNAT/GPS package for Solaris AFAIK. 
> > etc.etc.
> 
> Huh? Please, have a look. It is still there.
Sorry, I meant the **GPL** editions (see above).

IMHO it is absolutely necessary to provide freely available compilers 
and IDEs for as many platforms as possible to make a language popular. 
People should have the opportunity to "give Ada a spin" free of charge, 
even if they live outside the Intel X86/Windows/Linux galaxy.

GPS is great for learning Ada because you can "look" into the sources of 
the spec files of the standard library. It helped me a lot when I was 
learning the containers: John Barnes' otherwise excellent Ada2005 book 
is sometimes a bit tight-lipped on how these work.

> >  she needs simple but powerful string handling, 
> 
> I don't see how simple but powerful string handling
> is missing with GNAT's SPITBOL support. [...]
> Even the String packages are full of useful algorithms and
> data structures, even though there is no general character
> type in Ada.

The problem for many people starts earlier. Consider these two programs:-

-- Ada (221 chars)
with Ada.Strings.Unbounded, Ada.Text_IO.Unbounded_IO;
use Ada.Strings.Unbounded, Ada.Text_IO.Unbounded_IO;

procedure str is
   Strg: Unbounded_String := To_Unbounded_String("ergonomy");
begin
   Put_Line(Strg);
end str;

// C++ (148 chars)
#include <string>
#include <iostream>
using namespace std;

int main(int argc, char *argv[])
{
    string Strg("ergonomy");
    cout<<Strg<<endl;
}

The fact that the type of the string constant "ergonomy" is String 
requires the (semantically unnecessary) conversion To_Unbounded_String() 
in the Ada version. This is what I meant by clumsiness, not even 
mentioning the separate I/O library necessary to print this string 
afterwards. You don't really want to go through all these hoops just to 
print a string...

I think that the default string type should be the unbounded string, 
just like in C++, for ergonomic reasons. (Fixed strings may be needed in 
special cases. But the bounded string type family, where you have to 
convert from a 70-char string type to a 71-char string type, is an 
abomination and should be forgotten quickly.) And there should be only 
one I/O library, not dozens, otherwise programming ergonomics suffers, 
and that frightens people away. We should keep in mind that CPU time is 
cheaper than "brain time", so let the computer suffer a bit more 
instead. :-)

Talking about safety and ergonomics: how do you tell which Ada 
subprograms raise which exceptions? Well, you cannot. The Java designers 
got this absolutely right: the method signatures can contain a throws() 
clause. Either you catch an exception or let it propagate and the 
compiler complains if you omit the throws() in the latter case. It would 
be nice if the Ada2005 standard could be amended with a similar 
mechanism. If it can be done in Java, then it certainly could be done in 
Ada! :-)

"Make computers work so that humans won't have to"

A

-- 
"Non est volentis, neque currentis, sed miserentis Dei"