TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date: Tue, 3 Dec 2002 20:45:22 +0100
Reply-To: Jacob Sparre Andersen <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <[log in to unmask]>
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
From: Jacob Sparre Andersen <[log in to unmask]>
Parts/Attachments: TEXT/PLAIN (87 lines)
I would like to start by saying that from what I can see
here in Copenhagen right now, Ada has a reasonably bright
and growing future (even though the government has cancelled
the Rømer sattelite project).  An aquaintance and I have
recently managed to start an Ada SIG in the local Linux User
Group, SSLUG, with (reasonably) regular meetings and
continously growing interest.  (but maybe it simply helps to
start from a low level)

Wojtek Narczynski wrote:

> Ada should be freed from its traditional, narrow domain of
> application.

Agreed.  Only a fraction of the participants in our Ada SIG
have primarily an interest in writing embedded software.

> Having said the above, here is my personal list of
> obstacles I've encountered trying to practice what I've
> preached above:
>
> 1. Containers (/Collections). Once you are done with
> Hello_World, and try to write some real software you
> really get stuck on this. There are dozens of libraries
> varying in scope and quality, but there is no standard,
> not even a clear leader. The variety is often killing
> reuse efforts, because two pieces of software use
> different container code, and won't interoperate. Every
> self-respecting company / developer has a homegrown
> solution.

It's worse than that.  I find it hard to decide which of the
container/ADT classes I have access to I should use, so it
is not the same one every time.  ;-)  - or maybe :-(

> 2. Interface to underlying operating system, especially
> socket programming. There is FLORIST for POSIX binding but
> the most important part - socket connectivity - has big
> warning that it is by no means complete / stable. You have
> to use GNAT.Os_Lib and GNAT.Sockets that do good job for
> that, but are not standard. Plus there are at least three
> other libraries.

Maybe one (or some) of us should sit down and make the
FLORIST sockets work.  As it is right now, I manage quite
fine with AdaSockets, but I can certainly see the point in
using POSIX sockets instead.

> 3. Openness. I've got the impression that there are
> millions of lines of code that could be open sourced.

Yes.  But how much of it is interesting?  I have around 6 Mb
of home-grown Ada code, which I can publish under an Open
Source license.  But how many people would be interested in
software for processing 3D particle tracks?  Or yet another
Ada pretty-printer (which isn't very good btw)?  Or software
for creating fractal LEGO landscapes?  (well, that one has
actually been published)  Or a simulation of a double-slit
experiment?  (sold that one, so there was some interest)

I wouldn't mind making all my own Ada code available under
an Open Source license, but I am not sure the benefit is
large enough to make the time I would have to spend on it
worthwhile.

> 4. Little Ada education at the universites.

I can certainly agree on that.  But what can we do about it?
(I will not be working at a university for the next two
years, and I am a physicist, not a computer scientist or
software engineer)

> I am sure Ada can sell well, becuase reliability of
> software can sell. People have had enough of BSODs of
> different sorts already. I am positive that there are
> enough people capable of understanding, for example, why
> it is important not to use int for storing day count. This
> is not that hard after all.

Some people are as far as I can see slowly getting the
point.

Jacob
-- 
SSLUG's julekalender - hver dag fra den 1. til den 24. december
   http://www.sslug.dk/julekalender/

ATOM RSS1 RSS2