is Ada dying?

is Ada dying?

[Ralph M�ritz]

I'm just starting out learning Ada, but it seems Ada is dying. From what I 
can see very few people use Ada, out of about 15 000 projects on 
Sourceforge only 32 are written in Ada! I think that's sad, and now that 
Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold 
in store? Is it worthwhile learning a language nobody appreciates or uses?

Re: is Ada dying?

[martin.m.dowie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

"Ralph M�ritz" <ralph@work.co.za> wrote in message
news:Xns9133DBAF0AD71ralphworkcoza@196.25.240.158...
> I'm just starting out learning Ada, but it seems Ada is dying. From what I
> can see very few people use Ada, out of about 15 000 projects on
> Sourceforge only 32 are written in Ada! I think that's sad, and now that
> Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold
> in store? Is it worthwhile learning a language nobody appreciates or uses?

The evidence from the UK is that Ada use is increasing. Check out articles
in
www.cw360.com and www.jobserve.co.uk has about 5 times as many jobs
for Ada as it did around March/April 2000 (when I was last looking for
work :-)

Re: is Ada dying?

[robert]

In article <Oe2w7.34294$jE3.3798156@news6-win.server.ntlworld.com>,
"martin.m.dowie" says...
 
>The evidence from the UK is that Ada use is increasing. Check out articles
>in
>www.cw360.com and www.jobserve.co.uk has about 5 times as many jobs
>for Ada as it did around March/April 2000 (when I was last looking for
>work :-)
>

thanks for the links.

they all seem to be military projects, with the additional requirment of
having security clearance. 

The problem is that you have to jump over hoops to get to work in Ada, while
with Java and C/C++, jobs are so much easier to find, not military, and non
of this security clearance requirments on top of it.

Yes, Ada is a better language, but finding work in Java and C++ is so
much simpler and easier (and you do not have to work on a bomb to code in
them).

Untill Ada becomes more used in commerical places, it will never become
popular. I know many programmers who would code in Ada, but turned off
by the environment it is used in, and the rigidity of the whole Ada 
culture where it is used.

 

Re: is Ada dying?

[Ted Dennison]

In article <9pqfub02cho@drn.newsguy.com>, robert@* says...
>
>Yes, Ada is a better language, but finding work in Java and C++ is so
>much simpler and easier (and you do not have to work on a bomb to code in
>them).

Getting fast food jobs appears to be relatively easy too, according to a quick
scan of the local classifieds. Perhaps this whole programming thing is a waste
of time...
:-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Ted Dennison]

In article <9pqfub02cho@drn.newsguy.com>, robert@* says...
>much simpler and easier (and you do not have to work on a bomb to code in
>them).

BTW: I *never* worked on any weapon system in 13 years of Ada development. I did
turn *down* one job offer in part due to the fact that it was for bombs. So they
are indeed out there. Of course people don't talk about that kind of work much,
but the impression I get is that Ada is mostly used to help *save* lives. For
example, it is used a lot in the commercial aviation industry; in air traffic
control, nuclear power plant control, passenger train switching, etc. I believe
its also has a fair presence in bio-medical devices. 

I suppose people are free to use any crappy fly-by-night language that strikes
their fancy for most work. But if *lives* are at stake, you want to use Ada.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Reinert Korsnes]

Ted Dennison wrote:

> In article <9pqfub02cho@drn.newsguy.com>, robert@* says...
>>much simpler and easier (and you do not have to work on a bomb to code in
>>them).
> 
> BTW: I *never* worked on any weapon system in 13 years of Ada development.
> I did turn *down* one job offer in part due to the fact that it was for
> bombs. So they are indeed out there. Of course people don't talk about
> that kind of work much, but the impression I get is that Ada is mostly
> used to help *save* lives. For example, it is used a lot in the commercial

Sometimes,  to make bombs precise and relyable can save life ?
At least combined with effective information service/treatment.
And smart bombs can be small ?

At least, I believe,  massive destruction bombs to grill cities
do not need to be precise :-)

reinert

> aviation industry; in air traffic control, nuclear power plant control,
> passenger train switching, etc. I believe its also has a fair presence in
> bio-medical devices.
> 
> I suppose people are free to use any crappy fly-by-night language that
> strikes their fancy for most work. But if *lives* are at stake, you want
> to use Ada.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
> 
> No trees were killed in the sending of this message.
> However a large number of electrons were terribly inconvenienced.
> 

-- 
http://home.chello.no/~rkorsnes

Re: is Ada dying?

[John McCabe]

On Sun, 7 Oct 2001 20:42:08 +0100, "martin.m.dowie"
<martin.m.dowie@ntlworld.com> wrote:

>The evidence from the UK is that Ada use is increasing. Check out articles
>in
>www.cw360.com and www.jobserve.co.uk has about 5 times as many jobs
>for Ada as it did around March/April 2000 (when I was last looking for
>work :-)

Have you considered that perhaps there are simply 5 times more
agencies trying to find candidates for one job? If you look closely at
many of the Ada jobs on Jobserve they are for:

Farnborough:   BAE Systems
               IBM Global Services
Camberley:     Aerosystems International (AeI)
Frimley:       BAE Systems
               Easams
Portsmouth:    BAE Systems (including Waterlooville)
               DERA (QinetiQ?)
Wells:         Thales
Bristol:       BAE Systems
Borehamwood:   Easams
Stanmore:      BAE Systems
Hastings:      Computing Devices
Rochester:     BAE Systems
Wharton:       BAE Systems
Isle Of Wight: BAE Systems
New Malden:    Thales

So there are a few companies looking for Ada staff:

BAE Systems
Computing Devices
Thales
AeI
Easams (possibly now BAE)
DERA (possibly now QinetiQ)

A lot of the jobs available at these companies are jobs on (defence)
projects that have been running for a number of years, and on projects
that are just upgrades of current products. The evidence I have seen
is that there are very few, if any at all, new projects coming up that
are using Ada. This is one of the reasons I have 'deserted' to find a
job using a language that I believe has more of a future (well,
possibly - at least it's more likely to lead into other languages
based on this one that have a future).

It's unfortunate really but I don't really see a future in Ada,
although I would recommend learning it because it helps to enforce a
sense of discipline required for programming in teams.

Re: is Ada dying?

[martin.m.dowie]

"John McCabe" <john.mccabe@emrad.com.nospam> wrote in message
news:3bc16680.2581922@news.demon.co.uk...
> On Sun, 7 Oct 2001 20:42:08 +0100, "martin.m.dowie"
> <martin.m.dowie@ntlworld.com> wrote:
>
> >The evidence from the UK is that Ada use is increasing. Check out
articles
> >in
> >www.cw360.com and www.jobserve.co.uk has about 5 times as many jobs
> >for Ada as it did around March/April 2000 (when I was last looking for
> >work :-)
>
> Have you considered that perhaps there are simply 5 times more
> agencies trying to find candidates for one job? If you look closely at
> many of the Ada jobs on Jobserve they are for:

Yes, I have, my sporatic job survey if full of potential holes. My
one potentially saving grace is that the same assumptions are made
about each language I sampled. Totally unscientific and I wouldn't
suggest otherwise - but I'm sure there are definately more Ada jobs
out there this year than last.

The www.cw360.com survey is, I suspect, much more reliable and
they too have noticed the same trends (i.e. Ada up 40% every quarter
for the last year, C++ about 50% down, Java about 40% down -
working from memory here...).

The other interesting skill is C# which seems to be gaining and approaching
the level of Ada adverts already, at the expense of C++ it would seem.

Hopefully, a few "Ada for .NET" compilers will appear!


> Bristol:       BAE Systems
Aerosystems too.

> Borehamwood:   Easams

Most likely ALSTOM


> A lot of the jobs available at these companies are jobs on (defence)
> projects that have been running for a number of years, and on projects
> that are just upgrades of current products. The evidence I have seen
> is that there are very few, if any at all, new projects coming up that
> are using Ada. This is one of the reasons I have 'deserted' to find a
> job using a language that I believe has more of a future (well,
> possibly - at least it's more likely to lead into other languages
> based on this one that have a future).
>
> It's unfortunate really but I don't really see a future in Ada,
> although I would recommend learning it because it helps to enforce a
> sense of discipline required for programming in teams.

Well, some of the biggest projects coming up in the UK defence are
actually going to expand on their use of Ada from previous projects
and these are the sort of projects that will keep you employed for the
rest of your working life (assuming your 20+ years old), if you play
your cards right. So, I wouldn't worry about that tooo much about
the future. :-)

Why do you consider getting security clearance such a big drag? Once
you have it you get it renewed every few year after filling in the same
form. Unless you have something hid of course?... ;-)

Re: is Ada dying?

[John McCabe]

On Mon, 8 Oct 2001 22:53:22 +0100, "martin.m.dowie"
<martin.m.dowie@ntlworld.com> wrote:

>Yes, I have, my sporatic job survey if full of potential holes. My
>one potentially saving grace is that the same assumptions are made
>about each language I sampled.

Good point.

>The www.cw360.com survey is, I suspect, much more reliable and
>they too have noticed the same trends (i.e. Ada up 40% every quarter
>for the last year, C++ about 50% down, Java about 40% down -
>working from memory here...).

I seem to remember a survey in Computer Contractor or something like
that (may have been Computing, the BCS mag) that said Ada demand was
up. Again, although demand may be up, it may just be because supply
has dropped. Occam's still in demand in various places, but nobody
wants to do it, so it remains in demand!

>> Borehamwood:   Easams
>
>Most likely ALSTOM

May be - I'm not sure what happened to Easams with the GEC-Marconi/BAe
merger/takeover.

>Well, some of the biggest projects coming up in the UK defence are
>actually going to expand on their use of Ada from previous projects
>and these are the sort of projects that will keep you employed for the
>rest of your working life (assuming your 20+ years old), if you play
>your cards right. So, I wouldn't worry about that tooo much about
>the future. :-)

Yes but who wants to spend 20 years on one project - certainly not me!
I want to be in a position to move around when I get bored with what
I'm currently doing, and Ada really isn't going to afford me that
opportunity.

>Why do you consider getting security clearance such a big drag? Once
>you have it you get it renewed every few year after filling in the same
>form. Unless you have something hid of course?... ;-)

I don't find security clearance a problem personally - mine's just
been renewed (I believe they do a maximum 3 years for contractors and
10 years for permie staff), but apparently it expires after 6 months
in a non-secure environment. It is then a fag to get it redone because
you have to start from scratch. This probably accounts for some of the
demand for Ada contractors because many of the companies using Ada
need to get staff in quickly and they can't afford the wait until
security clearance is sorted out for currently insecure :-) people. I
have known people to have started on restricted projects without
security clearance being completed though.

Re: is Ada dying?

[Martin Dowie]

> I seem to remember a survey in Computer Contractor or something like
> that (may have been Computing, the BCS mag) that said Ada demand was
> up. Again, although demand may be up, it may just be because supply
> has dropped. Occam's still in demand in various places, but nobody
> wants to do it, so it remains in demand!

One thing that is never very well documented is that there are
City of London instituation who use Ada, I wonder if its popularity
is growing in that market? I understand that Reuter news agency also
use Ada, but I don't have any links to confirm this...


> >> Borehamwood:   Easams
> >
> >Most likely ALSTOM
>
> May be - I'm not sure what happened to Easams with the GEC-Marconi/BAe
> merger/takeover.

I think they are still around but if you don't want to work on 'bombs'
then ALSTOM use Ada for their railway systems, but again, big engineering
porjects, not 'bank-o-mat' stuff.



> Yes but who wants to spend 20 years on one project - certainly not me!
> I want to be in a position to move around when I get bored with what
> I'm currently doing, and Ada really isn't going to afford me that
> opportunity.

Well, after 7 years as a contractor, for various reasons (mostly family),
I'm now a permie again, but I do miss the jobbing around aspect from
time to time...

In that 7 years though I never had to take an enforced break between
contracts. There was always work and security was always done swiftly
enough. Once you are cleared it is fairly quick in coming through a
subsequent time, I found.



> I don't find security clearance a problem personally - mine's just
> been renewed (I believe they do a maximum 3 years for contractors and
> 10 years for permie staff), but apparently it expires after 6 months
> in a non-secure environment. It is then a fag to get it redone because

On this you have mean misinformed, the 'holder' of your clearance can
'forward' it for at least a year after leaving their employment (I've had
to do this once after working on non-secure stuff).

Re: is Ada dying?

[John McCabe]

On Tue, 9 Oct 2001 10:12:35 +0100, "Martin Dowie"
<martin.dowie@nospam.baesystems.com> wrote:

>One thing that is never very well documented is that there are
>City of London instituation who use Ada, I wonder if its popularity
>is growing in that market? I understand that Reuter news agency also
>use Ada, but I don't have any links to confirm this...

Reuters have used it for a while in the west country I believe. As for
the City of London, there have been adverts recently for experienced
Ada/C++ staff to work in the city on a SmartCard project. I haven't
been convinced that they are actually using Ada though, possibly they
just want people who have been exposed to the disciplines of using Ada
in order to produce a better quality C++ product.

>> May be - I'm not sure what happened to Easams with the GEC-Marconi/BAe
>> merger/takeover.

>I think they are still around but if you don't want to work on 'bombs'
>then ALSTOM use Ada for their railway systems, but again, big engineering
>porjects, not 'bank-o-mat' stuff.

That's right - I know of someone who was working on the Docklands
Railway using Ada, but I can't remember who it was now!

>Well, after 7 years as a contractor, for various reasons (mostly family),
>I'm now a permie again, but I do miss the jobbing around aspect from
>time to time...

I'm now permie after 4 years as a contractor.

>In that 7 years though I never had to take an enforced break between
>contracts.

Me either, but I got fed up working on the same types of projects all
the time.

>There was always work and security was always done swiftly
>enough. Once you are cleared it is fairly quick in coming through a
>subsequent time, I found.

I haven't seen a problem, but then mine has never lapsed. I've seen
people with lapsed security clearance having problems. One of the
problems as a contractor is, if it lapses, you have to persuade an
agent or some other such organisation to renew it!

>On this you have mean misinformed, the 'holder' of your clearance can
>'forward' it for at least a year after leaving their employment (I've had
>to do this once after working on non-secure stuff).

Were you working on a non-secure site? I got the impression it
remained valid as long as the site was listed as secure, even if you
weren't working on a secure project.

Re: is Ada dying?

[Martin Dowie]

> Reuters have used it for a while in the west country I believe. As for
> the City of London, there have been adverts recently for experienced
> Ada/C++ staff to work in the city on a SmartCard project. I haven't
> been convinced that they are actually using Ada though, possibly they
> just want people who have been exposed to the disciplines of using Ada
> in order to produce a better quality C++ product.

Don't know about that one, but there were advert for 'Ada only' engineers
last year.


> That's right - I know of someone who was working on the Docklands
> Railway using Ada, but I can't remember who it was now!

Not JF from Welwyn Garden City per chance?


> Me either, but I got fed up working on the same types of projects all
> the time.

That's a shame, while I pretty much exclusively worked in defence,
the projects I worked on were all very different, with very different
workplace cultures. As is my new place of work.


> Were you working on a non-secure site? I got the impression it
> remained valid as long as the site was listed as secure, even if you
> weren't working on a secure project.

I think it was non-secure, certainly there were no security guards! :-)

Re: is Ada dying?

[Peter Amey]

John McCabe wrote:

[snip]

> Reuters have used it for a while in the west country I believe. As for
> the City of London, there have been adverts recently for experienced
> Ada/C++ staff to work in the city on a SmartCard project. I haven't
> been convinced that they are actually using Ada though, possibly they
> just want people who have been exposed to the disciplines of using Ada
> in order to produce a better quality C++ product.
> 

It really is Ada; actually some of it is also SPARK.  Interesting
project too.

Peter

Re: is Ada dying?

[Marin David Condic]

You can see from participation in this newsgroup that there must be some
increase in interest in Ada. The number of posts seems to keep gradually
climbing. Maybe more hobbyists? Maybe additional university classes using
Ada? Maybe a few more companies doing serious work in Ada? Maybe a lot of
things. I wouldn't doubt that there is *some* increased interest in Ada -
how much being a hard to determine number.

We're definitely not as big a market as C++ or Java, but that doesn't make
it non-existent. The biggest problem is geography. There are some major
projects/development efforts that exist in Ada, but not in every community.
If you want to work in Ada and don't care where you live, you can probably
find a good job relatively easily. If you insist on living in some
particular location you may find Ada jobs in that arena are asymptotically
approaching zero.

But the best thing to do is to create a job you love to do. Working on Ada
projects at home that have some potential for commercial success is one way
to do that. If it flies, you have a job you love to do. It also helps create
a bigger environment for Ada, so even if it doesn't become a commercial
success, it may inspire other commercial successes and increase the
liklihood of Ada jobs being available.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"John McCabe" <john.mccabe@emrad.com.nospam> wrote in message
news:3bc2b008.1326667@news.demon.co.uk...
>
> I seem to remember a survey in Computer Contractor or something like
> that (may have been Computing, the BCS mag) that said Ada demand was
> up. Again, although demand may be up, it may just be because supply
> has dropped. Occam's still in demand in various places, but nobody
> wants to do it, so it remains in demand!
>

Re: is Ada dying?

[John McCabe]

On Tue, 9 Oct 2001 10:51:35 -0400, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

>You can see from participation in this newsgroup that there must be some
>increase in interest in Ada. The number of posts seems to keep gradually
>climbing. Maybe more hobbyists? Maybe additional university classes using
>Ada? Maybe a few more companies doing serious work in Ada? Maybe a lot of
>things. I wouldn't doubt that there is *some* increased interest in Ada -
>how much being a hard to determine number.

Another issue that could increase the number of postings to this group
is simply increased knowledge that it's there! From work, for example,
I have seldom been able to post to comp.lang.ada because I have been
working on a secure network with no internet access.

>We're definitely not as big a market as C++ or Java, but that doesn't make
>it non-existent.

Yes - one other significant difference appears to be enthusiasm on
this newsgroup - there are some very knowlegeable people and important
ones in terms of the language definition and compilers that provide
valuable responses to questions. I had a look at a couple of the C
based language's newsgroups and couldn't really say the same for them.

Re: is Ada dying?

[Ted Dennison]

In article <6gpw7.42573$jE3.4985089@news6-win.server.ntlworld.com>,
martin.m.dowie says...
>Why do you consider getting security clearance such a big drag? Once
>you have it you get it renewed every few year after filling in the same
>form. Unless you have something hid of course?... ;-)

They are fairly expensive for your company to acquire for you too, which makes
you much more valuable as a potential employee than someone who doesn't have
one.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Marin David Condic]

Well, there are certainly lots of us who have to use other languages in
order to make a living, but that doesn't mean that we can't be working
towards building a better future for Ada. Don't "desert" the cause! :-)
Let's find some ways of moving the mission forward and perhaps creating a
better market out there for Ada developers. That way we can all be doing
jobs we enjoy rather than just jobs we tolerate.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"John McCabe" <john.mccabe@emrad.com.nospam> wrote in message
news:3bc16680.2581922@news.demon.co.uk...
>
> A lot of the jobs available at these companies are jobs on (defence)
> projects that have been running for a number of years, and on projects
> that are just upgrades of current products. The evidence I have seen
> is that there are very few, if any at all, new projects coming up that
> are using Ada. This is one of the reasons I have 'deserted' to find a
> job using a language that I believe has more of a future (well,
> possibly - at least it's more likely to lead into other languages
> based on this one that have a future).
>
> It's unfortunate really but I don't really see a future in Ada,
> although I would recommend learning it because it helps to enforce a
> sense of discipline required for programming in teams.
>
>

Re: is Ada dying?

[John McCabe]

On Tue, 9 Oct 2001 10:40:06 -0400, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

>Well, there are certainly lots of us who have to use other languages in
>order to make a living, but that doesn't mean that we can't be working
>towards building a better future for Ada. Don't "desert" the cause! :-)

If I was 'deserting' the cause I probably wouldn't continue to look at
this newsgroup, and I wouldn't have asked ACT if they had, or were
thinking of having an Ada Compiler for Windows CE (incidentally I
still haven't heard anything from sales@gnat.com and it's now been
well over 2 weeks).

Unfortunately however learning C++, DSP32C Assembler and Windows CE,
all at the same time is a very steep learning curve for me so I can't
really afford to put any effort into Ada.

Re: is Ada dying?

[Stephen Leake]

john.mccabe@emrad.com.nospam (John McCabe) writes:

> If I was 'deserting' the cause I probably wouldn't continue to look at
> this newsgroup, and I wouldn't have asked ACT if they had, or were
> thinking of having an Ada Compiler for Windows CE (incidentally I
> still haven't heard anything from sales@gnat.com and it's now been
> well over 2 weeks).

Send an email again. Email is _not_ one hundred percent reliable, and
some of the ACT computers had trouble on Sept 11.

-- 
-- Stephe

Re: is Ada dying?

[John McCabe]

On 10 Oct 2001 13:45:28 -0400, Stephen Leake
<stephen.a.leake.1@gsfc.nasa.gov> wrote:

>john.mccabe@emrad.com.nospam (John McCabe) writes:
>
>> If I was 'deserting' the cause I probably wouldn't continue to look at
>> this newsgroup, and I wouldn't have asked ACT if they had, or were
>> thinking of having an Ada Compiler for Windows CE (incidentally I
>> still haven't heard anything from sales@gnat.com and it's now been
>> well over 2 weeks).
>
>Send an email again. Email is _not_ one hundred percent reliable, and
>some of the ACT computers had trouble on Sept 11.

It was 24th September.

Re: is Ada dying?

[Jeffrey Carter]

"Ralph M�ritz" wrote:
> 
> I'm just starting out learning Ada, but it seems Ada is dying. From what I
> can see very few people use Ada, out of about 15 000 projects on
> Sourceforge only 32 are written in Ada!

Is COBOL dying? Of 27,615 projects on Sourceforge, zero use COBOL, yet
COBOL is the most commonly used language in the world. Just because it's
not the current fad language or the language of choice for hackers does
not mean a language is dead.

Ada is the international language of choice when software quality is the
prime concern, such as safety-critical systems. It will not be
disappearing any time soon.

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail

Re: is Ada dying?

[Ralph M�ritz]

Jeffrey Carter <jrcarter@acm.org> wrote in
news:3BC0B670.4B68D8DC@acm.org: 

<snip>
 
> Is COBOL dying? Of 27,615 projects on Sourceforge, zero use COBOL, yet
> COBOL is the most commonly used language in the world. Just because
> it's not the current fad language or the language of choice for hackers
> does not mean a language is dead.
> 
> Ada is the international language of choice when software quality is
> the prime concern, such as safety-critical systems. It will not be
> disappearing any time soon.
> 

Hmm, ok point taken. I suppose I shouldn't have judged so hastily.

Re: is Ada dying?

[Poul-Erik Andreasen]

Jeffrey Carter wrote:
> 
> "Ralph M�ritz" wrote:
> >
> > I'm just starting out learning Ada, but it seems Ada is dying. From what I
> > can see very few people use Ada, out of about 15 000 projects on
> > Sourceforge only 32 are written in Ada!
> 
> Is COBOL dying? Of 27,615 projects on Sourceforge, zero use COBOL, yet
> COBOL is the most commonly used language in the world. 

Messured how? Bit moved? Installed programs? Whatever?  


-- 
-
Poul-Erik Andreasen
Hvis du mangler nogen til noget eller du kan noget for nogen.
http://linux-freelance.pea.dk

Re: is Ada dying?

[Lutz Donnerhacke]

* Poul-Erik Andreasen wrote:
>Jeffrey Carter wrote:
>> Is COBOL dying? Of 27,615 projects on Sourceforge, zero use COBOL, yet
>> COBOL is the most commonly used language in the world. 
>
>Messured how? Bit moved? Installed programs? Whatever?  

The W2K task force of the German gouvernment came to the conclusion, that
80% of all important data is processed by software older than 25 years.

Re: is Ada dying?

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

In article <3BC23B9F.3B025363@pea.dk>, Poul-Erik Andreasen says...
>
>Jeffrey Carter wrote:
>> 
>> "Ralph M�ritz" wrote:
>> >
>> > I'm just starting out learning Ada, but it seems Ada is dying. From what I
>> > can see very few people use Ada, out of about 15 000 projects on
>> > Sourceforge only 32 are written in Ada!
>> 
>> Is COBOL dying? Of 27,615 projects on Sourceforge, zero use COBOL, yet
>> COBOL is the most commonly used language in the world. 
>
>Messured how? Bit moved? Installed programs? Whatever?  

I found this in a Cobol FAQ a while back. Sadly, I've lost the link. I think the
info is around a two or three years old.

---
Although developed more than 3 decades ago, COBOL is still one of the most
widely used computer languages. The investment in COBOL by government and
industry is significant.

Here are some statistics to put it in perspective:
* COBOL is used in *60-70 percent* of business applications.
* There are *80-100 billion* lines of COBOL code in active use.
* *Two billion* new lines of COBOL code are developed each year.
* *One million* programmers use COBOL.
---


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Robert*]

In article <05Dw7.21484$ev2.29726@www.newsranger.com>, Ted says...
>
 
>Here are some statistics to put it in perspective:
>* COBOL is used in *60-70 percent* of business applications.
>* There are *80-100 billion* lines of COBOL code in active use.
>* *Two billion* new lines of COBOL code are developed each year.
>* *One million* programmers use COBOL.
>---
 
Ada makes a perfect replacment for COBOL.

If we can target COBOL programmers (instead of the C/C++/Java ones), we
will win in the end.

I find it very strange that Ada is not used much in business applications, and
more strange it is not used much in financial applications. people will actually
use C to divid numbers and compute decimals and not Ada. very strange world 
we live in.

Re: is Ada dying?

[James Rogers]

"Robert*@" wrote:
> 
> In article <05Dw7.21484$ev2.29726@www.newsranger.com>, Ted says...
> >
> 
> >Here are some statistics to put it in perspective:
> >* COBOL is used in *60-70 percent* of business applications.
> >* There are *80-100 billion* lines of COBOL code in active use.
> >* *Two billion* new lines of COBOL code are developed each year.
> >* *One million* programmers use COBOL.
> >---
> 
> Ada makes a perfect replacment for COBOL.
> 
> If we can target COBOL programmers (instead of the C/C++/Java ones), we
> will win in the end.
> 
> I find it very strange that Ada is not used much in business applications, and
> more strange it is not used much in financial applications. people will actually
> use C to divid numbers and compute decimals and not Ada. very strange world
> we live in.

I have always thought that a company's accounting system was
mission critical. Safety and correctness must be the higest priorities
for those systems. Ada should certainly be considered in those
cases.

The biggest problem is that traditional IT departments have never
even heard of Ada. It is not one of the technologies common to
their mainframe environment.

Jim Rogers
Colorado Springs, Colorado USA

Re: is Ada dying?

[Al Christians]

"Robert*@" wrote:
> 
> Ada makes a perfect replacment for COBOL.
> 
> If we can target COBOL programmers (instead of the C/C++/Java ones), 
> we will win in the end.

Might need some kind of mainframe Ada for big IBM machines running
the OS's that big commercial IBM mainframe shops usually use to
run their COBOL applications. 

> 
> I find it very strange that Ada is not used much in business 
> applications, and more strange it is not used much in financial 
> applications. people will actually use C to divid numbers and compute 
> decimals and not Ada. very strange world we live in.

Very strange world, indeed.  A few years back, when I tried to use
the COBOL interface package that came with one Ada 95 compiler,
I found that it didn't work.  When I tried to figure out why, I found
that the source code for the packed decimal features was broken as 
designed,  and that it probably couldn't have worked at all to provide 
any interface to packed decimal data.  This was not a brand new 
product, and the interface features are frequently mentioned among the
major advantages of Ada.  But maybe they don't get a lot of use.  
Maybe they don't get any use.  IDK.


Al

Re: is Ada dying?

[Pat Rogers]

"Al Christians" <achrist@easystreet.com> wrote in message
news:3BC35E74.E9C77736@easystreet.com...
> "Robert*@" wrote:
> >
> > Ada makes a perfect replacment for COBOL.
> >
> > If we can target COBOL programmers (instead of the C/C++/Java ones),
> > we will win in the end.
>
> Might need some kind of mainframe Ada for big IBM machines running
> the OS's that big commercial IBM mainframe shops usually use to
> run their COBOL applications.

Isn't the Realia compiler PC based?  I suspect the big-iron bias is not
current.

Re: is Ada dying?

[Warren W. Gay VE3WWG]

Al Christians wrote:

> "Robert*@" wrote:
...

> Very strange world, indeed.  A few years back, when I tried to use
> the COBOL interface package that came with one Ada 95 compiler,
> I found that it didn't work.  When I tried to figure out why, I found
> that the source code for the packed decimal features was broken as 
> designed,  and that it probably couldn't have worked at all to provide 
> any interface to packed decimal data.  This was not a brand new 
> product, and the interface features are frequently mentioned among the
> major advantages of Ada.  But maybe they don't get a lot of use.  
> Maybe they don't get any use.  IDK.


Indeed, one of the very important aspects of business programming is to

be able to accurately compute in DECIMAL numbers and to format them with
picture strings. Poor Ada support for these two very basic things, hurts
its applicability to business.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: is Ada dying?

[Warren W. Gay VE3WWG]

Robert*@ wrote:

> In article <05Dw7.21484$ev2.29726@www.newsranger.com>, Ted says...
>>Here are some statistics to put it in perspective:
>>* COBOL is used in *60-70 percent* of business applications.
>>* There are *80-100 billion* lines of COBOL code in active use.
>>* *Two billion* new lines of COBOL code are developed each year.
>>* *One million* programmers use COBOL.
>>---
> Ada makes a perfect replacment for COBOL.
> 
> If we can target COBOL programmers (instead of the C/C++/Java ones), we
> will win in the end.
> 
> I find it very strange that Ada is not used much in business applications, and
> more strange it is not used much in financial applications. people will actually
> use C to divid numbers and compute decimals and not Ada. very strange world 
> we live in.


I for one, would like to see that change. One feature that would help, (as I

posted earlier), would be garbage collection. The language also needs a
simple to use database "binding", and a similar score for GUI forms. A good
IDE would go a long way in this direction, but I think there is also a
good argument for an interpreted Ada "subsystem" for business/SOHO use.

The important issues for business use is that you need to keep things as
simple as possible, so that programmers can focus on the business processes
instead of the science(s).
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: is Ada dying?

[Robert*]

In article <3BC47F2A.3050005@home.com>, "Warren says...
>
 
>
>The important issues for business use is that you need to keep things as
>simple as possible, so that programmers can focus on the business processes
>instead of the science(s).
 
Yes, I know what you mean. I once worked on a C project for a business
application. They had this one large C file where all sort of functions 
in it, (the file must have been 10,000 lines long). I asked why? a programmer
told me that it is simpler to use one file to keep any function they need, 
easier and simpler to find this way. 

Re: is Ada dying?

[David Botton]

Ada is still heavily used and its use is increasing. Currently its use for
projects that would fit in to a category suitable for Sourceforge is on the
rise but clearly not yet on the same level as Java or C++.

If you are basing your decisions on what to learn by what is popular, you
are seriously restricting your ability to achieve even with what is popular.

David Botton

----- Original Message -----
From: "Ralph M�ritz" <ralph@work.co.za>


> I'm just starting out learning Ada, but it seems Ada is dying. From what I
> can see very few people use Ada, out of about 15 000 projects on
> Sourceforge only 32 are written in Ada!

Re: is Ada dying?

[Richard Riehle]

David Botton wrote:

> Ada is still heavily used and its use is increasing.

David,

You are probably in as good a position as anyone to know this
for a fact.  However, it would be quite useful if there were some
statistics to support this statement.

Are there any indications from activity on your web site that might
indicate a rise in interest in Ada?  Are there inquiries from specific
companies that can be cited?   What new projects can we point to
that might suggest an increase in Ada usage?   Does ACT have any
statistics that could be presented, by industry, by country,
by application?

I once worked for a man whose favorite expression was, "Numbers
are your friends."   Here is a clear case where numbers could be
helpful to everyone interested in the progress of Ada in industry.

Richard Riehle

Re: is Ada dying?

[David Botton]

Avg Request Per Month:

1998 - 3,198
1999 - 71,420
2000 - 186, 797
2001 - 250,403

These stats for AdaPower certainly also reflect the larger presence AdaPower
has had on the web over time as well and not solely and increase of interest
in Ada.

In just the last few years we have seen a number of major open source
projects a quick look through AdaPower's reuse page, SourceForge, and ACT
libre pages show an increase in the number of projects.

I certainly have seen a lot of interest in my projects GNATCOM and GWindows
and I am sure many others here can say the same about their projects.

I believe that there will be an upswing in interest over the next few years
as more powerful tools and libraries are quickly becoming available.

I also think that the irration exuberance consumers have had for software
products is coming to an end and concerns for security and quality are
setting in. With that will come an interest in better tools and languages
and looking beyond the C family of languages.

David Botton

Re: is Ada dying?

[Robert*]

 
Ada as a language is good. Better than C/C++ or Java.

What Ada needs is a standard or at least a psudo-standard set of
auxilary packages that come well documented (HTML) and ready to plug in
and use (similar to that Java huge standard library).

Untill this happens, Ada will remain a good language, few admirars, little 
used and nothing more.

I am taking about packages for doing all sort of usefull pratical things,
like those found in Java packages. 

ACT has been doing a good job of Adding usefull packages to its GNAT
package, but it is still very much too little compared to what Java has,
and with no way to for others to help add to it.

With Ada, the case now is that if you want a package to do something, you
go and do some search on the web, find some bits and pieces of code, download,
try to build, and see if that will work or not.   With Java, I download the
JDK, and everything is there. Well documented, and ready to use. 
 
Having a central single place to get things from is a Good Thing (tm). Examples
of such things

http://www.sunfreeware.com/   <--- Want any solaris package? go here
http://java.sun.com    <---  Want the JDK? go here
http://www.gnu.org/software/java/  <--- Want the GNU java collection? go here
http://www.gjt.org/  <--- want the Giant Java tree collection? go here

etc..

Anyway, my point is that, Ada needs such a centalized, single place, to get
standard usefull packages from. 

 

Re: is Ada dying?

[James Rogers]

"Robert*@" wrote:
> 
> 
> Ada as a language is good. Better than C/C++ or Java.
> 
> What Ada needs is a standard or at least a psudo-standard set of
> auxilary packages that come well documented (HTML) and ready to plug in
> and use (similar to that Java huge standard library).
> 
> Untill this happens, Ada will remain a good language, few admirars, little
> used and nothing more.
> 
> I am taking about packages for doing all sort of usefull pratical things,
> like those found in Java packages.

I love the standard Java API classes. They are poorly documented.
Their algorithms are completely undocumented. You only hope they do
what you think they will. No worrys though. If a class is found to 
be dangerous it can always be deprecated in a later release.

> ACT has been doing a good job of Adding usefull packages to its GNAT
> package, but it is still very much too little compared to what Java has,
> and with no way to for others to help add to it.
> 
> With Ada, the case now is that if you want a package to do something, you
> go and do some search on the web, find some bits and pieces of code, download,
> try to build, and see if that will work or not.   With Java, I download the
> JDK, and everything is there. Well documented, and ready to use.
> 
> Having a central single place to get things from is a Good Thing (tm). Examples
> of such things
> 
> http://www.sunfreeware.com/   <--- Want any solaris package? go here
> http://java.sun.com    <---  Want the JDK? go here
> http://www.gnu.org/software/java/  <--- Want the GNU java collection? go here
> http://www.gjt.org/  <--- want the Giant Java tree collection? go here
> 
> etc..

Wait a minute while I count my fingers and toes. It looks to me like 
this is a list of more than one place to find everything. Am I 
missing something here?

This looks a lot like finding the Ada package you want. You still
need to know the single right place to go amongst what appears to be
an abundance of single right places.

> Anyway, my point is that, Ada needs such a centalized, single place, to get
> standard usefull packages from.

Given what you describe above, I would say that Ada already has that.

It also has a standard, which Java does not. Most of the Java stuff
is in a single place because the language belongs to one company.
Java is whatever Sun says it is. Given the changes in the language
from Java 1.0 to Java 1.1 to JDK 1.2 to JSDK 1.3 to the almost
released JSE 1.4, I wonder which language you use when you say you
use Java. Don't forget that you need standard patches to do some of
the more useful stuff. For instance, you must patch the JSE 1.3
with JSEE 1.3 to be able to use Enterprise Java Bean technology.
This means that your client's Java Runtime Environment must
have the compatible libraries also. A big part of your Java system
is shipped to your customers as the Java Runtime Environment.
This presents you with serious compatibility and upgrade issues.

Re: is Ada dying?

[Navid Azimi]

James,

Robert is right in many aspects. Ada is *much* more difficult to learn
(resources/information/etc) than Java. I have done both recently and I found
the amount of help available (may it be newsgroups/faq/websites) for Java is
much more than Ada.

Now if Ada was able to pull everything together into one big central
site/package it would help a lot of people, not to mention people who are
trying to learn Ada.

I tried to learn Ada a few months ago, and I couldn't even get a straight
answer to what type of compiler exists. Not one person would give me a right
answer, and to this day, I still don't know.

I found a compiler on the www.adapower.com but it was soo poorly documented
I had no clue how to run it. I couldn't find any examples of quick programs
(hello world) to see how the syntax was, nor was I able to do anything
friendly with it.

I didn't need a huge-tutorial. I know how to program. I just wanted some
quick points about how to compile/run, how the code (syntax) looks like, and
the few *basic* commands, such as: output, loops, functions. Yet, it was soo
tedious that I have given up. I still am on this newsgroup regulargly
because I enjoy reading Qs and As...

- K

PS. Maybe someone can even help me with my probs =)

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3BC1305D.1C6910C@worldnet.att.net...
> "Robert*@" wrote:
> >
> >
> > Ada as a language is good. Better than C/C++ or Java.
> >
> > What Ada needs is a standard or at least a psudo-standard set of
> > auxilary packages that come well documented (HTML) and ready to plug in
> > and use (similar to that Java huge standard library).
> >
> > Untill this happens, Ada will remain a good language, few admirars,
little
> > used and nothing more.
> >
> > I am taking about packages for doing all sort of usefull pratical
things,
> > like those found in Java packages.
>
> I love the standard Java API classes. They are poorly documented.
> Their algorithms are completely undocumented. You only hope they do
> what you think they will. No worrys though. If a class is found to
> be dangerous it can always be deprecated in a later release.
>
> > ACT has been doing a good job of Adding usefull packages to its GNAT
> > package, but it is still very much too little compared to what Java has,
> > and with no way to for others to help add to it.
> >
> > With Ada, the case now is that if you want a package to do something,
you
> > go and do some search on the web, find some bits and pieces of code,
download,
> > try to build, and see if that will work or not.   With Java, I download
the
> > JDK, and everything is there. Well documented, and ready to use.
> >
> > Having a central single place to get things from is a Good Thing (tm).
Examples
> > of such things
> >
> > http://www.sunfreeware.com/   <--- Want any solaris package? go here
> > http://java.sun.com    <---  Want the JDK? go here
> > http://www.gnu.org/software/java/  <--- Want the GNU java collection? go
here
> > http://www.gjt.org/  <--- want the Giant Java tree collection? go here
> >
> > etc..
>
> Wait a minute while I count my fingers and toes. It looks to me like
> this is a list of more than one place to find everything. Am I
> missing something here?
>
> This looks a lot like finding the Ada package you want. You still
> need to know the single right place to go amongst what appears to be
> an abundance of single right places.
>
> > Anyway, my point is that, Ada needs such a centalized, single place, to
get
> > standard usefull packages from.
>
> Given what you describe above, I would say that Ada already has that.
>
> It also has a standard, which Java does not. Most of the Java stuff
> is in a single place because the language belongs to one company.
> Java is whatever Sun says it is. Given the changes in the language
> from Java 1.0 to Java 1.1 to JDK 1.2 to JSDK 1.3 to the almost
> released JSE 1.4, I wonder which language you use when you say you
> use Java. Don't forget that you need standard patches to do some of
> the more useful stuff. For instance, you must patch the JSE 1.3
> with JSEE 1.3 to be able to use Enterprise Java Bean technology.
> This means that your client's Java Runtime Environment must
> have the compatible libraries also. A big part of your Java system
> is shipped to your customers as the Java Runtime Environment.
> This presents you with serious compatibility and upgrade issues.

Re: is Ada dying?

[Preben Randhol]

On Sun, 7 Oct 2001 22:42:01 -0700, Navid Azimi wrote:
> I tried to learn Ada a few months ago, and I couldn't even get a straight
> answer to what type of compiler exists. Not one person would give me a right
> answer, and to this day, I still don't know.

I assume you use Windows since you post with Outlook:

GNAT for Windows can be found here: http://home.trouwweb.nl/Jerry/

> I found a compiler on the www.adapower.com but it was soo poorly documented
> I had no clue how to run it. I couldn't find any examples of quick programs
> (hello world) to see how the syntax was, nor was I able to do anything
> friendly with it.

Which compiler was this. Cannot be GNAT which is very well documented
   (at least if one reads the docs).

> I didn't need a huge-tutorial. I know how to program. I just wanted some
> quick points about how to compile/run, how the code (syntax) looks like, and
> the few *basic* commands, such as: output, loops, functions. Yet, it was soo
> tedious that I have given up. I still am on this newsgroup regulargly
> because I enjoy reading Qs and As...

http://www.adapower.com/learn/

Did you ever look at:

http://adahome.com/Tutorials/Lovelace/lovelace.htm

or

http://goanna.cs.rmit.edu.au/~dale/ada/aln.html

now there is a whole book on-line:

http://www.it.bton.ac.uk/staff/je/adacraft/

Preben Randhol

Re: is Ada dying?

[Ted Dennison]

In article <slrn9s2o6u.kp3.randhol+abuse@kiuk0156.chembio.ntnu.no>, Preben
Randhol says...
>
>On Sun, 7 Oct 2001 22:42:01 -0700, Navid Azimi wrote:
>> I tried to learn Ada a few months ago, and I couldn't even get a straight
>> answer to what type of compiler exists. Not one person would give me a right
>> answer, and to this day, I still don't know.
>
>I assume you use Windows since you post with Outlook:
>
>GNAT for Windows can be found here: http://home.trouwweb.nl/Jerry/

As to the documentation issue Navid mentioned, Gnat does come with both an HTML
user's Reference Manual and User's Guide. It also come with a copy of the Ada
LRM and a MS Help book for the Win32 bindings. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[John English]

Navid Azimi wrote:
> I tried to learn Ada a few months ago, and I couldn't even get a straight
> answer to what type of compiler exists. Not one person would give me a right
> answer, and to this day, I still don't know.
> 
> I found a compiler on the www.adapower.com but it was soo poorly documented
> I had no clue how to run it. I couldn't find any examples of quick programs
> (hello world) to see how the syntax was, nor was I able to do anything
> friendly with it.

Try http://burks.bton.ac.uk/burks/language/ada/ for a selection of
Ada compilers, development tools, tutorial material, reference manuals,
software libraries and source code examples, all freely available.
The site includes links to the home sites of all the included material.

Is this a straight enough answer? :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: is Ada dying?

[James Rogers]

Navid Azimi wrote:
> 
> James,
> 
> Robert is right in many aspects. Ada is *much* more difficult to learn
> (resources/information/etc) than Java. I have done both recently and I found
> the amount of help available (may it be newsgroups/faq/websites) for Java is
> much more than Ada.
> 
> Now if Ada was able to pull everything together into one big central
> site/package it would help a lot of people, not to mention people who are
> trying to learn Ada.
> 
> I tried to learn Ada a few months ago, and I couldn't even get a straight
> answer to what type of compiler exists. Not one person would give me a right
> answer, and to this day, I still don't know.
> 
> I found a compiler on the www.adapower.com but it was soo poorly documented
> I had no clue how to run it. I couldn't find any examples of quick programs
> (hello world) to see how the syntax was, nor was I able to do anything
> friendly with it.
> 
> I didn't need a huge-tutorial. I know how to program. I just wanted some
> quick points about how to compile/run, how the code (syntax) looks like, and
> the few *basic* commands, such as: output, loops, functions. Yet, it was soo
> tedious that I have given up. I still am on this newsgroup regulargly
> because I enjoy reading Qs and As...
> 

The AdaPower web site has links to several compilers. I have used
both the free Ada compilers available (Aonix and GNAT). Both come
with documentation on how to use the compiler.

The GNAT compiler also comes with a set of example programs and
a make file. You can at least read the make file to learn how to
use the compiler.

You claim that nobody could tell you what type of compiler exists.
Who did you ask? Most of the regular participants in this group
can answer that question. You found the AdaPower web site. You could
have found the answer there also.

How did you determine that the answers to your questions were wrong?
Could it be that you did not understand the answers?

Jim Rogers
Colorado Springs, Colorado USA

Re: is Ada dying?

[Ted Dennison]

In article <9prebb$1on$1@news.service.uci.edu>, Navid Azimi says...
>I tried to learn Ada a few months ago, and I couldn't even get a straight
>answer to what type of compiler exists. Not one person would give me a right
>answer, and to this day, I still don't know.

I looked back over those old threads, and I have to admit that some of the
messages went off on tangents. But that is to be expected here on Usenet. Some
of the answers seemed to have good info in them. If you ask a question, and our
answers leave you still confused, or you try to follow the advice, but get lost
somewhere, you really should ask further questions.

My personal advice for getting started would be to install the Windows version
of Gnat, and use whatever text editor you prefer. If you are a complete
beginner, and thus don't even *have* a favorite text editor, you'd probably be
best off using Notepad until you get your feet under you. Learning a programming
editor, the language, and a language environment, and programming in general,
all at the same time would be a bit much to ask of anyone. But if you want to go
whole-hog, the best editor for Gnat is Emacs. Links to both should be on my
webpage.

Seriously: Go try to make a "Hello world" program, and check back in here for
help whenever you get stuck on a step.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Robert*]

In article <3BC1305D.1C6910C@worldnet.att.net>, James says...
>
 
>I love the standard Java API classes. They are poorly documented.
>Their algorithms are completely undocumented. You only hope they do
>what you think they will. No worrys though. If a class is found to 
>be dangerous it can always be deprecated in a later release.
>

The Java classes are well documented. Much better than anything Ada has
actually.

As for the algorithms, why would you want to know the inner algorithm
for how a class or a method is implemented? The whole idea is to use 
it as a black box. Does the Ada RM describe the algorithm for the
unbounded string?

I find that I can much easier find a class in java to do something, than
I can find a function in Ada to do something.  Have you looked at the 
Java class libraries books by Patrick Chan and Rosanna Lee?  Each
class and almost each method comes with a usage example. There is nothing
like the above for Ada (or for almost anyother language actually). 
 
>>Having a central single place to get things from is a Good Thing (tm). Examples
>> of such things
>> 
>> http://www.sunfreeware.com/   <--- Want any solaris package? go here
>> http://java.sun.com    <---  Want the JDK? go here
>> http://www.gnu.org/software/java/  <--- Want the GNU java collection? go here
>> http://www.gjt.org/  <--- want the Giant Java tree collection? go here
>> 
>> etc..
>

>Wait a minute while I count my fingers and toes. It looks to me like 
>this is a list of more than one place to find everything. Am I 
>missing something here?
>

Yes, you are missing something. 

>This looks a lot like finding the Ada package you want.

No it is not. Show me an Ada site that is like java.sun.com. I know it
is not fair for Ada to ask for this, given that even C++ does not have
anything like that site, and C++ is much more used than Ada.
 
>
>Given what you describe above, I would say that Ada already has that.
>

If you think the current state of Ada packages and libraries is good
enough, I am happy for you. I am not arguing with you, I am only giving
an advice to the Ada community to help. 
 
>It also has a standard, which Java does not.

Java has a standard, it is just not an ansi nor iso. But who cares. If you
think having an iso or ansi stamp on the language will suddenly make it
popular, then I am afraid you are completly wrong. Show me the 
VB standard out there, yet millions use VB to this day. 


> Most of the Java stuff
>is in a single place because the language belongs to one company.

Programmers do not care. Programmers want support, good documentations,
good packages from one cetralized and managed place. What you call that,
is not important. The last thing I worry about with Java is that it is
controlled by Sun. 

>Java is whatever Sun says it is. Given the changes in the language
>from Java 1.0 to Java 1.1 to JDK 1.2 to JSDK 1.3 to the almost
>released JSE 1.4, I wonder which language you use when you say you
>use Java. 

I think your arguments are very week. Java has improvments being 
added to it all the time. More packages and more libraries. You seem
to think this is bad. I say, a language that does not grow and improve,
and adopt to the technolgy, will die for lack of use and interest. Note
also, most of the additions to java are in the libraries, not the 
language anc certinally not in the JVM.  Generic are being now
added to Java, and will be part of JDK 1.5.  It is a good thing.


>Don't forget that you need standard patches to do some of
>the more useful stuff. For instance, you must patch the JSE 1.3
>with JSEE 1.3 to be able to use Enterprise Java Bean technology.

No you dont. I use J2EE 1.3 on JDK 1.3 just of the box.

>This means that your client's Java Runtime Environment must
>have the compatible libraries also. A big part of your Java system
>is shipped to your customers as the Java Runtime Environment.
>This presents you with serious compatibility and upgrade issues.

I have no idea where you are comming on with all of the above. Millions
of programmers use Java all the time and each day, yet you seem to have
a problem with it.

This is not an Ada vs Java thing. If Ada programmers try to put Java
down, they are going at it the wrong way. Ada community should learn from
what makes Java popular and try to do those things for Ada.

Re: is Ada dying?

[James Rogers]

"Robert*@" wrote:
> 
> The Java classes are well documented. Much better than anything Ada has
> actually.

The Java classes are documented about as well as an Ada package
specification documents an Ada package. I am speaking of the HTML
API documentation generated from javadoc.

Of course there are textbooks which expand on that documentation,
just as there are Ada textbooks which expand on the information
contained in the standard package specifications.

> 
> As for the algorithms, why would you want to know the inner algorithm
> for how a class or a method is implemented? The whole idea is to use
> it as a black box. Does the Ada RM describe the algorithm for the
> unbounded string?

Pure black box usage is dangerous. It is particularly so with the
Java standard classes. You might make the mistake of using the String
class for string editing. A clear understanding of the String class
shows it to be very inefficient for string editing. The StringBuffer
class is intended for string editing. What is the difference between
the two? In many applications with a lot of string editing, the
performance increases by a factor of up to 5 using the StringBuffer
class.

> 
> I find that I can much easier find a class in java to do something, than
> I can find a function in Ada to do something.  Have you looked at the
> Java class libraries books by Patrick Chan and Rosanna Lee?  Each
> class and almost each method comes with a usage example. There is nothing
> like the above for Ada (or for almost anyother language actually).

The javadoc tool is very useful. It localizes the documentation of
the standard Java classes. The same can be said for the Ada RM.

It is true that Java has more standard classes than Ada has
standard packages. It is also true that all those standard Java
classes are available to Ada compilers targeted at the jvm.

> >>Having a central single place to get things from is a Good Thing (tm). Examples
> >> of such things
> >>
> >> http://www.sunfreeware.com/   <--- Want any solaris package? go here
> >> http://java.sun.com    <---  Want the JDK? go here
> >> http://www.gnu.org/software/java/  <--- Want the GNU java collection? go here
> >> http://www.gjt.org/  <--- want the Giant Java tree collection? go here
> >>
> >> etc..
> >
> 
> >Wait a minute while I count my fingers and toes. It looks to me like
> >this is a list of more than one place to find everything. Am I
> >missing something here?
> >
> 
> Yes, you are missing something.

Yes I am missing the concept that a list of four sites followed by
"etc.." is exactly one. This is a feature of Java I have always 
found distasteful. The Java white papers, and subsequent Java
supporters, have often made statements which are contrary to the
normal usage of English. The example above declares that four or
more sites is a single location. This is pure nonsense.

The Java white paper uses a lot of unsupported buzz words to
describe Java. Some of my favorite are "simple" and "high 
performance". Java is not a simple language. There are thousands
of standard classes to learn. Java is not high performance.
It is simply faster than a dial-up network connection.

What I am missing is an honest and accurate use of the English
language.

> 
> >This looks a lot like finding the Ada package you want.
> 
> No it is not. Show me an Ada site that is like java.sun.com. I know it
> is not fair for Ada to ask for this, given that even C++ does not have
> anything like that site, and C++ is much more used than Ada.

Well, I would say that adapower.com is pretty close. In fact, I
believe adapower.com is a better starting point in a search for
Ada information than java.sun.com is for Java information. There
are relatively few links to non-Sun sites on java.sun.com.

> >
> >Given what you describe above, I would say that Ada already has that.
> >
> 
> If you think the current state of Ada packages and libraries is good
> enough, I am happy for you. I am not arguing with you, I am only giving
> an advice to the Ada community to help.

You are now changing the subject. The statement I responded to 
indicated that all Java information could be found in one place.
The statement included a list of four places. I still do not agree
that one equals four. 

The current state of Ada standard packages is very good. It is 
not as extensive as the set of Java standard classes. 
Quality and quantity are not the same thing.

For instance, Java provides several GUI packages useable in
applets. The classes in the java.awt package hierarchy are
useable in most browsers. The javax.swing classes are supposed to
be useable in all browsers, but browser support for these
classes varies. Note that applets (and servlets) also require you
to learn another language, namely HTML. If you want to move to
a more modern web server approach you can use JSP's, which
require you to learn XML.

The biggest problem with browser support of java applets is the
differences in HTML required to support the Swing classes.

> >It also has a standard, which Java does not.
> 
> Java has a standard, it is just not an ansi nor iso. But who cares. If you
> think having an iso or ansi stamp on the language will suddenly make it
> popular, then I am afraid you are completly wrong. Show me the
> VB standard out there, yet millions use VB to this day.

This is more Sun propaganda. Sun has a history of avoiding formal
standards. They like to play in the arena of "defacto" standards.
This means that they can produce a product and publish an API
document for it. Once done, they call the product a standard.

Only Sun can decide what is Java and what is not. Only 
Microsoft can decide what is VB and what is not. This is the
antithesis of open source. This is also forcing those using
these tools to put complete trust in Sun and Microsoft. You 
have no input to the new features for the language. You only
have the ability to report language defects if you pay for
that privilege.

> > Most of the Java stuff
> >is in a single place because the language belongs to one company.
> 
> Programmers do not care. Programmers want support, good documentations,
> good packages from one cetralized and managed place. What you call that,
> is not important. The last thing I worry about with Java is that it is
> controlled by Sun.

Yes, but those downloading the free tools do not "get support".
They must buy support, just as they must for other languages.

> 
> >Java is whatever Sun says it is. Given the changes in the language
> >from Java 1.0 to Java 1.1 to JDK 1.2 to JSDK 1.3 to the almost
> >released JSE 1.4, I wonder which language you use when you say you
> >use Java.
> 
> I think your arguments are very week. Java has improvments being
> added to it all the time. More packages and more libraries. You seem
> to think this is bad. I say, a language that does not grow and improve,
> and adopt to the technolgy, will die for lack of use and interest. Note
> also, most of the additions to java are in the libraries, not the
> language anc certinally not in the JVM.  Generic are being now
> added to Java, and will be part of JDK 1.5.  It is a good thing.

Generics may or may not be a good thing in Java. Interestingly,
they will have a definite Ada flavor, rather than a C++ flavor.
This is due in part to the fact that Norman Cohen has been 
actively involved in the definition and development of Java
generics.

I expect JDK 1.5 to be released some time in 2002. In terms
of generics this will allow Java to catch up to Ada after a mere
20 years.

Note that up to this point Java supporters have been claiming 
that generics are unnecessary. They believed their 
inheritance model subsumed all requirements for generics. Could it
be that they were wrong? There must be some reason for adding
generics to JDK 1.5.

This is more evidence to me that Java is a language desparately
working to live up to its press releases. For seven years Java
has claimed the flexibility and extensibility provided by
generics without having generics. Now they are adding generics
to provide what is best provided by generics.

Similarly, Java has staunchly declared no need for a separation
of specification and implementation. There have been several
exceptions to this rule. You MUST create a Java interface to
call a C library from Java. You MUST create a Java interface
to create and deploy Enterprise Java Beans. You MUST
create an interface to use the Java event model.

Such redifinitions of the language make programming in Java
an adventure in learning.

> 
> >Don't forget that you need standard patches to do some of
> >the more useful stuff. For instance, you must patch the JSE 1.3
> >with JSEE 1.3 to be able to use Enterprise Java Bean technology.
> 
> No you dont. I use J2EE 1.3 on JDK 1.3 just of the box.

Look at the java.sun.com web site. You will find that the
J2SE 1.3 download is separate from the J2SEE 1.3 download.
You must first download J2SE 1.3, followed by J2SEE 1.3 if
you want to use Enterprise Java Beans. You cannot simply download
one or the other.

> 
> >This means that your client's Java Runtime Environment must
> >have the compatible libraries also. A big part of your Java system
> >is shipped to your customers as the Java Runtime Environment.
> >This presents you with serious compatibility and upgrade issues.
> 
> I have no idea where you are comming on with all of the above. Millions
> of programmers use Java all the time and each day, yet you seem to have
> a problem with it.

I have nothing against the use of Java in its appropriate domaines.
I do have issues with the way the Java community has misappropriated
the English language. Many people use Java thinking they 
understand what is meant by that language. For instance, one local
manager decided to re-write all his Cobol programs in Java.
This meant retraining his entire IT staff. After making the 
decision he asked the question "What will be my performance
improvement?" Unfortunately the answer to that is about -30%.

Jim Rogers
Colorado Springs, Colorado USA

Re: is Ada dying?

[Robert*]

In article <3BC1C7E3.46046096@worldnet.att.net>, James says...
>
 
> A clear understanding of the String class
>shows it to be very inefficient for string editing. The StringBuffer
>class is intended for string editing. 

I am sorry, but this is well known and documented everwhere that to
use StringBuffer instead of String if one intends to makes lots of 
changes and editing on the content of the buffer. Anyone who has been
programming in Java for one week knows this. 

page 1285, "The java class libraries", right at the top of the page:

"The String class is used to create immutable string objects. Each
time you make an update to a string, a new String object is created.
A more efficient way to deal with these updates is to store a string in
a StringBuffer...."

So, what is it again you said about badly documented Java classes?? I suggest
you get a copy of the Java class libraries books if you intend to do any
serious java programing.

>
>The javadoc tool is very useful. It localizes the documentation of
>the standard Java classes. The same can be said for the Ada RM.
>

Not the same. I generate javadocs for all my java classes as part of
the build process. There is no javadoc like tool for Ada. period. In Ada,
if you want to find what is the API of a package, you have to open the
spec and read it. No one in Java does this, they simply read the HTML
auto generated docs. Much better presented, easier to follow, etc...
 

>The Java white paper uses a lot of unsupported buzz words to
>describe Java. Some of my favorite are "simple" and "high 
>performance". Java is not a simple language. There are thousands
>of standard classes to learn. 

You are confusing the language itself, from the libraries.

Java the language is certinly simple, at least simpler than C++ which it
is replacing. Having a huge library is a Good Thing (TM), and it have
nothing to do with the language itself. Use the classes you need, do not
use those you do not need. Having huge libraries means code reuse and faster
development process.

>Java is not high performance.
>It is simply faster than a dial-up network connection.

Java these days is very fast, there are many places on the net that shows
Java performance getting close or better than C/C++ for some applications.
If you are interested I can show you the links, but any search on the net
can find you these sites. The performance thing is a weak argument these
days when it comes to java.

>The current state of Ada standard packages is very good. It is 
>not as extensive as the set of Java standard classes. 
>Quality and quantity are not the same thing.
>

Ok, so lets sit here and wait for this high "quality" Ada packages that
allow me to send an email using Ada or process an XML document or play
a midi file, and by the time this standard high quality Ada package come 
along, no one will be left using Ada to use it.

>This is more Sun propaganda.

I do not work for Sun. 

> Sun has a history of avoiding formal
>standards. 

You are still not getting the point. "official" Standards do not mean 
anything. 

VB has no official standard, VC++ for years did things the way MS wanted, 
Java has no "official" standard, DELPHI has no "official" standard, and
I do not think perl has an "official" standard, etc... Ada had both an
ansi and iso standard since 95.  Now if having an official stamp of a 
standard is important, you would think Ada will be the most widley used
language becuase of this stamp. 

 

Re: is Ada dying?

[Martin Dowie]

> >Java is not high performance.
> >It is simply faster than a dial-up network connection.
>
> Java these days is very fast, there are many places on the net that shows
> Java performance getting close or better than C/C++ for some applications.
> If you are interested I can show you the links, but any search on the net
> can find you these sites. The performance thing is a weak argument these
> days when it comes to java.

Do you have links on embedded, real-time Java performance? I've been
searching periodically for a while but with little success. Actually,
no success. :-(

Re: is Ada dying?

[Robert*]

In article <3bc1e836$1@pull.gecm.com>, "Martin says...
>
 
>
>Do you have links on embedded, real-time Java performance? I've been
>searching periodically for a while but with little success. Actually,
>no success. :-(
>
 
I doubt you will find anything on Java performance for embedded real-time. Java
standard for this is still being worked out now. (but I am do not know much
on this, so I could be wrong). 

There are many links though on Java for real-time:
http://java.sun.com/people/billf/real-time/index.html
http://java.sun.com/docs/books/realtime/
http://java.sun.com/pr/1999/03/pr990301-03.html
http://java.sun.com/features/1998/11/realtime.html
http://java.sun.com/products/embeddedjava/real-time.html
http://java.sun.com/features/2001/04/embed.html

and hundreds more....

Re: is Ada dying?

[minyard]

"Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:

> > >Java is not high performance.
> > >It is simply faster than a dial-up network connection.
> >
> > Java these days is very fast, there are many places on the net that shows
> > Java performance getting close or better than C/C++ for some applications.
> > If you are interested I can show you the links, but any search on the net
> > can find you these sites. The performance thing is a weak argument these
> > days when it comes to java.
> 
> Do you have links on embedded, real-time Java performance? I've been
> searching periodically for a while but with little success. Actually,
> no success. :-(

Since I have some experience in this, I'll give my answer.

Real-time does NOT mean fast.  Real-time means guaranteed performance,
like "I can stop the robot arm +/- 100us", or "the air bag will
inflate between 1 and 1.5ms from impact".  True real-time systems tend
to have worse performance than non-real-time systems because providing
the guarantees requires system overhead.  As for performance, Java is
fast approaching C/C++.  Some tests we did on some platforms had C++
and Java within a few percent on just about everything.

Much theoretical work has been done on Java hard real-time
performance, I have a copy of the spec, and it looks reasonable.  You
could build a moderately hard real-time system in Java, if you are
willing to jump through all the right hoops.  But the hoops are
actually rather significant.

The main problem, though, is not with Java itself.  If you use any
third-party libraries, they will almost certainly violate your
real-time constraints.  So you can't use any third-party stuff in your
system, or if you do, it has to be carefully isolated from the rest of
your system.  We used several third-party libraries in our system.
They all were extremely sloppy with memory management; they threw tons
of garbage needlessly.  Plus, because of the slack Java package/class
usage rules, Java software tends to be a "big glob of software", you
generally cannot extract just the parts of the code you need because
everything uses everything else.  Because of lazy initialization
rules, it would be easy for hitting a new path in the code to cause a
mass initialization event.

So the bottom line, IMHO, is that it's not worth it to do hard
real-time in Java.  The big advantage of Java is all the stuff that
comes along with it, but you really can't use that stuff in a
real-time application.  To get true real-time in Java, you have to
manage your own memory and segment your application.  You have to be
very careful with garbage generation.  But if that's the case, why not
write the real-time portion in another language and interface it with
Java?

Note that soft real-time is a different story.  You can probably
implement a soft real-time system in Java if you are willing to do
some work.  Before what I was working on was cancelled, we had a
reasonable system working, and I knew of others that had at least
limited success.  But I know of no practical written material on this
subject, and I doubt any exists, because it's kind of a black art
right now.  And we did a lot of customization to our chosen compiler
to help us meet our goals, including a custom GC and some careful
analysis on how the libraries worked.  So it's still not easy, but it
might be better than using C/C++ due to Java's improved safety.  I
have a lot of knowledge on the subject, but in essence it's only
theoretical because we never actually delivered a product.

But then, I'd rather use Ada.  It has all the safety advantages of
Java (and more) without the baggage of GC, lack of call-by-reference,
etc.  But non-technical reasons often take precedence.  We did a
language analysis on the project in question.  Ada won by a
significant margin, but we chose Java anyway.

-Corey

Re: is Ada dying?

[martin.m.dowie]

<minyard@acm.org> wrote in message news:m3itdp5vi5.fsf@wf-rch.cirr.com...
> "Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:
>
> > Do you have links on embedded, real-time Java performance? I've been
> > searching periodically for a while but with little success. Actually,
> > no success. :-(
>
> Since I have some experience in this, I'll give my answer.
>
> Real-time does NOT mean fast.  Real-time means guaranteed performance,

Absolutely, but unfortunately, for the systems I'm interested in I need
both! :-(

Re: is Ada dying?

[Richard Riehle]

"martin.m.dowie" wrote:

> <minyard@acm.org> wrote in message news:m3itdp5vi5.fsf@wf-rch.cirr.com...
> > "Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:
>
> >
> > Real-time does NOT mean fast.  Real-time means guaranteed performance,
>
> Absolutely, but unfortunately, for the systems I'm interested in I need
> both! :-(

Some practictioners believe it is unfortunate that we include the word
"time" in real-time.  Often, time is not the central issue. Event-occurrence
relative to event-response is probably more important.  That is,  the
question
to ask is whether the system can respond to and handle an event before the
next
event occurs. While it is true that one can measure latency in some
fractional
time, the real concern is whether the system can trap the events, process
them, and
produce the necessary feedback and control information generated from
that processing so it can be incorporated in the processing of the next
event.
It is conventional  to measure this with microseconds, etc., but excessive
focus on time in real-time  concurrent processes may sometimes lead to
designs
that produce race conditions and other entertaining obscurities in
real-time systems.

Richard Riehle

Re: is Ada dying?

[James Rogers]

"Robert*@" wrote:
> 
> In article <3BC1C7E3.46046096@worldnet.att.net>, James says...
> >
> page 1285, "The java class libraries", right at the top of the page:
> 
> "The String class is used to create immutable string objects. Each
> time you make an update to a string, a new String object is created.
> A more efficient way to deal with these updates is to store a string in
> a StringBuffer...."
> 
> So, what is it again you said about badly documented Java classes?? I suggest
> you get a copy of the Java class libraries books if you intend to do any
> serious java programing.

Look at the word "immutable". It is technically correct. At the
same time it is not a commonly used word. The result is that many
new Java users do not understand this statement. Understanding
usually comes after discovering by experience that the String class
is best used for constant strings.

The trap still exists, however. The JNI compatibility types
provide no mapping to a StringBuffer class. The jstring type maps
to java.lang.String. Thus, if you want to communicate string data
between C and Java, you must use the expected compatibility type on
the C side, and then, surprise, you must convert the String
object to a StringBuffer object. Failure to do so will result in
the above documented performance problems.

> 
> >
> >The javadoc tool is very useful. It localizes the documentation of
> >the standard Java classes. The same can be said for the Ada RM.
> >
> 
> Not the same. I generate javadocs for all my java classes as part of
> the build process. There is no javadoc like tool for Ada. period. In Ada,
> if you want to find what is the API of a package, you have to open the
> spec and read it. No one in Java does this, they simply read the HTML
> auto generated docs. Much better presented, easier to follow, etc...

No one in Java does this because it cannot be done. Java has no
equivalent to the Ada package specification. Java had to develop
a separate solution.

> 
> 
> >The Java white paper uses a lot of unsupported buzz words to
> >describe Java. Some of my favorite are "simple" and "high
> >performance". Java is not a simple language. There are thousands
> >of standard classes to learn.
> 
> You are confusing the language itself, from the libraries.

Not at all. Either the standard libraries are part of the language,
or the language has no built in ability to perform string processing.
The language is a combination of its syntax and its standard libraries.

> Java the language is certinly simple, at least simpler than C++ which it
> is replacing. Having a huge library is a Good Thing (TM), and it have
> nothing to do with the language itself. Use the classes you need, do not
> use those you do not need. Having huge libraries means code reuse and faster
> development process.

The huge library has everything to do with the language.
Would you or anyone else use Java without those libraries? I 
think not.

> >Java is not high performance.
> >It is simply faster than a dial-up network connection.
> 
> Java these days is very fast, there are many places on the net that shows
> Java performance getting close or better than C/C++ for some applications.

Sun has been able to produce some examples of high performance Java
programs. This is a good, but not necessarily significant development.
Benchmarking systems and language implementations is always subject to
careful optimization and manipulation.

I can tell you that I have produced simple benchmarks that show
Java's real time performance and control to be terrible compared to
Ada on a Win98 computer. The Java sleep method on that operating
system is grossly inaccurate. When sleeping for 1000 milliseconds,
Java is seen to sleep anywhere from 900 to 1100 milliseconds.
On the same machine, running the same algorithm, an Ada program
always delays between 1000 and 1001 milliseconds.

> >The current state of Ada standard packages is very good. It is
> >not as extensive as the set of Java standard classes.
> >Quality and quantity are not the same thing.
> >
> 
> Ok, so lets sit here and wait for this high "quality" Ada packages that
> allow me to send an email using Ada or process an XML document or play
> a midi file, and by the time this standard high quality Ada package come
> along, no one will be left using Ada to use it.

Are you saying that the Ada packages are low quality, or are you
saying you do not find the packages you want? Those are two
clearly different issues. Again, this is a confusion of quality
and quantity.

What about the Java libraries for interfacing to Cobol and 
Fortran? Where are they? 

I looked for a fixed number class in Java. The closest I could
find was the TypeCode class in the org.omg.CORBA package.
This class only allows you to deal with fixed point types passed
to Java through CORBA.

> 
> >This is more Sun propaganda.
> 
> I do not work for Sun.
> 
> > Sun has a history of avoiding formal
> >standards.
>
> You are still not getting the point. "official" Standards do not mean
> anything.

I disagree. "Official" standards mean a lot. It is the 
"unofficial" standards that do not mean anything.

> VB has no official standard, VC++ for years did things the way MS wanted,
> Java has no "official" standard, DELPHI has no "official" standard, and
> I do not think perl has an "official" standard, etc... Ada had both an
> ansi and iso standard since 95.  Now if having an official stamp of a
> standard is important, you would think Ada will be the most widley used
> language becuase of this stamp.

Importance has nothing to do with marketing.
Popularity in business more often is a result of marketing than
technical issues.

C used to be the fad language. After that came C++, followed quickly
by VB. In the 1990's Java became the fad language to compete with VB.
Java's marketing advantage was that it is not tied to a single
vendor's operating system. VB is still very popular, but is still
limited to Microsoft operating systems. VB has also undergone
significant changes, with the clear intention that it will be 
used across operating systems with the predicted proliferation of
.NET technology.

Jim Rogers
Colorado Springs, Colorado USA

Re: is Ada dying?

[David Starner]

On Mon, 08 Oct 2001 18:17:16 GMT, James Rogers <jimmaureenrogers@worldnet.att.net> wrote:
> Look at the word "immutable". It is technically correct. At the
> same time it is not a commonly used word. The result is that many
> new Java users do not understand this statement. 

"im" - not; "mutable" - capable of mutating/changing. Is it really that
hard a word that it needs to be dumbed-down for the average programmer?

> Understanding
> usually comes after discovering by experience that the String class
> is best used for constant strings.

Experiance _is_ the best teacher. No matter what you say, some people
aren't going to pick up some things until they experiance them.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: is Ada dying?

[AG]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9pss2i$8201@news.cis.okstate.edu...
> On Mon, 08 Oct 2001 18:17:16 GMT, James Rogers
<jimmaureenrogers@worldnet.att.net> wrote:
> > Look at the word "immutable". It is technically correct. At the
> > same time it is not a commonly used word. The result is that many
> > new Java users do not understand this statement.
>
> "im" - not; "mutable" - capable of mutating/changing. Is it really that
> hard a word that it needs to be dumbed-down for the average programmer?

Well, please note [tongue firmly in cheek] that no one claimed that a new
Java user
is equivalent to an average programmer as far as understanding of the above
statement goes... So how about dumbing it down to the level of a new (or
would-be)
Java user, let them chew on that and let the programmers get on with what
they do?

Re: is Ada dying?

[Stephen Leake]

Robert*@ <Robert_member@newsguy.com> writes:

> In article <3BC1C7E3.46046096@worldnet.att.net>, James says...
> >
> <snip> 
> >
> >The javadoc tool is very useful. It localizes the documentation of
> >the standard Java classes. The same can be said for the Ada RM.
> >
> 
> Not the same. I generate javadocs for all my java classes as part of
> the build process. There is no javadoc like tool for Ada. period. 

Yes, there is. It is called 'gnathtml', and it comes with GNAT. For an
example of its output, see
http://users.erols.com/leakstan/Stephe/Ada/Windex_Packages/index.htm 

Now you know ...

And yes, it does not do _exactly_ the same thing javadoc does. That's
because Ada is inherently more readable than java, partly because of
the separation of specs and bodies.

> In Ada, if you want to find what is the API of a package, you have
> to open the spec and read it. No one in Java does this, they simply
> read the HTML auto generated docs. Much better presented, easier to
> follow, etc...

Well, I can open the Ada spec in the same editor that I'm writing my
application in. Moving my hand _all_ the way over to the mouse, and
clicking thru directories to find the .html I need; that's _hard_!

Seriously, _my_ definition of a well written Ada spec is that it is
easy to read. An automated tool doesn't write good comments for you. I
much prefer reading Ada in Emacs to reading the html output of either
gnathtml or javadoc.

> <snip>
> 
> You are still not getting the point. "official" Standards do not mean 
> anything. 
> 
> VB has no official standard, VC++ for years did things the way MS wanted, 
> Java has no "official" standard, DELPHI has no "official" standard, and
> I do not think perl has an "official" standard, etc... Ada had both an
> ansi and iso standard since 95.  Now if having an official stamp of a 
> standard is important, you would think Ada will be the most widley used
> language becuase of this stamp. 

Popularity is _not_ the point of a standard. Having an ISO Ada
standard, and a maintained conformance suite, means that I can find an
Ada compiler for my wizzy new workstation, and recompile my code from
10 years ago, with no compile-time or run-time errors, or run-time
behavior changes. That you cannot do with Borland, Sun or Microsoft
tools.

The 10 year requirement is not reasonable in all projects; for
projects that need it, it is overwhelming, and Ada is a good choice.

-- 
-- Stephe

Re: is Ada dying?

[Robert*]

In article <ueloekkd4.fsf@gsfc.nasa.gov>, Stephen says...
 
 >
>Yes, there is. It is called 'gnathtml', and it comes with GNAT. For an
>example of its output, see
>http://users.erols.com/leakstan/Stephe/Ada/Windex_Packages/index.htm 
>
>Now you know ...
>

thanks, I did not know about gnathtml.

btw, there seems to be a bug somewhere, I am getting many broken links.

for example,  if you go to

http://users.erols.com/leakstan/Stephe/Ada/Windex_Packages/index.htm

and click on the links on the page, they fail. for example, I click on the
"interface" link (first one in the page) and I get

The requested URL /leakstan/Stephe/Ada/Windex_Packages/interfac__ads.htm was not
found on this server.
 
There are many such broken links. why is that?

I wonder if there is a website that has the whole GNAT libraries done using
gnathtml?

Re: is Ada dying?

[tmoran]

>for example,  if you go to
>
>http://users.erols.com/leakstan/Stephe/Ada/Windex_Packages/index.htm
>
>and click on the links on the page, they fail. for example, I click on the
>"interface" link (first one in the page) and I get
>
>The requested URL /leakstan/Stephe/Ada/Windex_Packages/interfac__ads.htm was not
>found on this server.
  When I go there it shows frames with first letters of things.  No
"interface".  When I click on "I" it shows "interfaces_more.ads" and
a click there shows a package spec.  What browser are you using?
  BTW, for another example of html docs of Ada programs created partly
automatically, by an Ada program, you can take a look at
http://members.home.com/twmoran/H1.htm
(You'll definitely get broken links there because that was just a test
with an early version of the Claw documentation.)

Re: is Ada dying?

[Robert*]

In article <w1vw7.17806$IY3.12294332@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>

>>for example,  if you go to
>>
>>http://users.erols.com/leakstan/Stephe/Ada/Windex_Packages/index.htm
>>
>>and click on the links on the page, they fail. for example, I click on the
>>"interface" link (first one in the page) and I get
>>
>>The requested URL /leakstan/Stephe/Ada/Windex_Packages/interfac__ads.htm was not
>>found on this server.


>  When I go there it shows frames with first letters of things.  No
>"interface".  When I click on "I" it shows "interfaces_more.ads" and
>a click there shows a package spec.  What browser are you using?
>  BTW, for another example of html docs of Ada programs created partly
>automatically, by an Ada program, you can take a look at
>http://members.home.com/twmoran/H1.htm
>(You'll definitely get broken links there because that was just a test
>with an early version of the Claw documentation.)


I think what happens is that the links does lead me to different locations,
but the URL at top of the browser remained the same, so I was in a different
windows, and I shows you the URL I had when I got the errors.

Ok, let me show you how to get the errors.
1. Go the URL above.
2. click in the 'W' link
3. Click in the first link, 'windex-bitmaps-io.ads'
4. Click on 'windex' link (the first in the page'
5. click in the 'Version' link right near the top.

You'll get the error. Notice during all this time, the URL did not change.

Many more broken links like this all over the document. You just have
to try moving around it and you'll see.

Re: is Ada dying?

[tmoran]

>Ok, let me show you how to get the errors.
>1. Go the URL above.
  Ah.  Running
finder users.erols.com/leakstan/Stephe/Ada
(see www.adapower.com/os/finder.html) indeed shows a bunch of such 404s.

Re: is Ada dying?

[Stephen Leake]

Robert*@ <Robert_member@newsguy.com> writes:

> thanks, I did not know about gnathtml.

You're welcome.

> btw, there seems to be a bug somewhere, I am getting many broken
> links. for example,  if you go to
> 
> http://users.erols.com/leakstan/Stephe/Ada/Windex_Packages/index.htm

One problem with gnathmtl is that is uses frames. Note that the above
link takes you to the top "index" listing, _not_ to a particular file.

> and click on the links on the page, they fail. for example, I click
> on the "interface" link (first one in the page) and I get
>
> 
> The requested URL
> /leakstan/Stephe/Ada/Windex_Packages/interfac__ads.htm was not found
> on this server.
>  
> There are many such broken links. why is that?

If I click on [w] in the Files pane, and then scroll down to
windex.ads, then there is a link to "interface", which does fail.

This is because "Interface" is a standard Ada package, and not
included in this web page. Of course, this is a bug in gnathtml; it
should not include links to files that it knows do not exist.

There are links that do work; try the file "windex.bitmaps.io.ads".
Clicking on any of the types will take you to the type definition. 

Clicking on the function names tries to take you to the body; I did
not post those files to save space. This is a switch in gnathtml, so
it should know better than to put in those links.

I see now that there are many links that don't work. Thanks for
pointing this out. I'll submit a bug report to ACT.

As I said, I don't really like this style of code reading. I put it on
the web page so people could get a feel for my code without
downloading all of it.

> I wonder if there is a website that has the whole GNAT libraries done using
> gnathtml?

Don't know of one; maybe AdaPower has space for it?

-- 
-- Stephe

Re: is Ada dying?

[James Rogers]

Stephen Leake wrote:
> 
> Robert*@ <Robert_member@newsguy.com> writes:
> 
> > thanks, I did not know about gnathtml.
> 
> You're welcome.
> 
> > btw, there seems to be a bug somewhere, I am getting many broken
> > links. for example,  if you go to
> >
> > http://users.erols.com/leakstan/Stephe/Ada/Windex_Packages/index.htm
> 
> One problem with gnathmtl is that is uses frames. Note that the above
> link takes you to the top "index" listing, _not_ to a particular file.

This is one of the areas where gnathtml is very similar to javadoc.

Javadoc also uses frames.

Jim Rogers
Colorado Springs, Colorado USA

Re: is Ada dying?

[Dalen Kruse]

"Robert*@" wrote:

> Not the same. I generate javadocs for all my java classes as part of
> the build process. There is no javadoc like tool for Ada. period.

Really?  Take a look at this:

https://sourceforge.net/projects/adadoc/

It's even one of those 33 Ada projects on SourceForge!

Dalen

Re: is Ada dying?

[Robert*]

In article <3BC204BD.E7CE5D24@lmco.com>, Dalen says...
>
>
>
>"Robert*@" wrote:
>
>> Not the same. I generate javadocs for all my java classes as part of
>> the build process. There is no javadoc like tool for Ada. period.
>

>Really?  Take a look at this:
>
>https://sourceforge.net/projects/adadoc/
>
>It's even one of those 33 Ada projects on SourceForge!
>
 
thanks. I downloaded the 1.01 source and build it.

It is however giving output all in French. (even the help is in
French)

Using Javadoc I do not have to know French to use it :)

Re: is Ada dying?

[Larry Kilgallen]

In article <9ptr6l01a79@drn.newsguy.com>, Robert*@ <Robert_member@newsguy.com> writes:

> thanks. I downloaded the 1.01 source and build it.
> 
> It is however giving output all in French. (even the help is in
> French)
> 
> Using Javadoc I do not have to know French to use it :)

Really ?  Does Javadoc automatically translate ?  What if you _wanted_
the information in French ?  Or, to pick a language of current interest,
Arabic ?

Although I don't know French either, if a program in which I was
interested were documented in French I would judge that someone who
spoke French had interests akin to mine, not that the document production
tool was inferior to another.

Re: is Ada dying?

[Marin David Condic]

There's always Babelfish at http://world.altavista.com/

Not a perfect answer, but if you just need to get enough of a document
translated to be able to figure out how to run a program, this might help.

Obviously, for the English speaking world, a program that is documented in
English and produces output in English would be more successful.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:+Fwta8Yln8Ey@eisner.encompasserve.org...
> In article <9ptr6l01a79@drn.newsguy.com>, Robert*@
<Robert_member@newsguy.com> writes:
>
> > thanks. I downloaded the 1.01 source and build it.
> >
> > It is however giving output all in French. (even the help is in
> > French)
> >
> > Using Javadoc I do not have to know French to use it :)
>
> Really ?  Does Javadoc automatically translate ?  What if you _wanted_
> the information in French ?  Or, to pick a language of current interest,
> Arabic ?
>
> Although I don't know French either, if a program in which I was
> interested were documented in French I would judge that someone who
> spoke French had interests akin to mine, not that the document production
> tool was inferior to another.

Re: translations [OT]

[Wes Groleau]

Marin David Condic wrote:
> There's always Babelfish at http://world.altavista.com/

Go to http://spanish.about.com
Click translations in the left navbar
Click online translations.

I checked all of these with a sample of
English into Spanish.

At least one was better than babelfish.
Intertran was MUCH worse.  Of course,
that's no guarantee that French to English
will work out the same, but if the choice
of language doesn't change the method....

See also
   http://freepages.computers.rootsweb.com/~wgroleau/idiot.html

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: is Ada dying?

[Florian Weimer]

Robert*@ <Robert_member@newsguy.com> writes:

> There is no javadoc like tool for Ada. period.

This is not true.  Many people have implemented similar tools using
ASIS, but I think most of them are rather project-specific and have
not been released to the public (yet).

Re: is Ada dying?

[John English]

"Robert*@" wrote:
> Java the language is certinly simple, at least simpler than C++ which it
> is replacing. Having a huge library is a Good Thing (TM), and it have
> nothing to do with the language itself. Use the classes you need, do not
> use those you do not need. Having huge libraries means code reuse and faster
> development process.

Smalltalk and Forth are both syntactically simpler languages than Java,
both with large APIs. That doesn't make them better than Java.

Huge libraries means you need a huge memory, and a permanently-handy
API reference. You have to remember the names of the classes (which
were invented arbitrarily, usually sensibly but not always), the names
of the methods (again, not always sensible) and the order and types
of the parameters. Case sensitivity doesn't help (and a sure-fire Good
Thing would be a compiler that suggested RuntimeException in its error
message if you typed RunTimeException, or Hashtable if you typed HashTable,
or HashMap if you typed Hashmap).

At least language features are usually informed by some rationale and
the need to define a rational syntax which makes life bearable for both
compiler writer and user.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: is Ada dying?

[Robert*]

In article <3BC2F035.FB6AA434@brighton.ac.uk>, John says...
>
 
>
>Smalltalk and Forth are both syntactically simpler languages than Java,
>both with large APIs. That doesn't make them better than Java.
>

Yes. being just simple language does not mean it is better.

>Huge libraries means you need a huge memory,

No it does not mean that at all. Do you really think the JVM loads into
memory all the classes in its path??

> and a permanently-handy API reference. 

I am confused.  

Are you saying a small standard library which does almost nothing, is 
better becuase then the programmer does not have to have an API handy
to remember anything?

what kind of logic is this? 

so I assume the language you will design will have only 'PUT' and 'GET' in
it, this way no programmer will ever need a manual to use it (and of course
no one will use the language becuase in the real world programmers need to 
do more things).





 

Re: is Ada dying?

[Pascal Obry]

Robert*@ <Robert_member@newsguy.com> writes:

> In article <3BC2F035.FB6AA434@brighton.ac.uk>, John says...
> >
> >Huge libraries means you need a huge memory,
> 
> No it does not mean that at all. Do you really think the JVM loads into
> memory all the classes in its path??

I think John was talking about human memory and not computer memory.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: is Ada dying?

[John English]

"Robert*@" wrote:
> 
> In article <3BC2F035.FB6AA434@brighton.ac.uk>, John says...
> >
> >Huge libraries means you need a huge memory,
> 
> No it does not mean that at all. Do you really think the JVM loads into
> memory all the classes in its path??

The problem is not the computer's memory -- it was *my* memory I was
referring to!

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: is Ada dying?

[John English]

"Robert*@" wrote:
> 
> In article <3BC2F035.FB6AA434@brighton.ac.uk>, John says...
> > and a permanently-handy API reference.
> 
> I am confused.
> 
> Are you saying a small standard library which does almost nothing, is
> better becuase then the programmer does not have to have an API handy
> to remember anything?
> 
> what kind of logic is this?
> 
> so I assume the language you will design will have only 'PUT' and 'GET' in
> it, this way no programmer will ever need a manual to use it (and of course
> no one will use the language becuase in the real world programmers need to
> do more things).

No, what I'm saying is that shunting linguistic features (e.g. tasking)
into the API increases the memory burden -- linguistic features need
a linguistic rationale, whereas with API design you're at the whim of
the API designer. You know there's a class containing a method, but
your knowledge of the language helps not at all to remember the name
of the class or the name of the method or the types and ordering of
the parameters. So e.g. slicing a string by writing str.substr(5,4)
is less clear IMHO that str(5..9) -- you have to remember that the
method is called "substr", not "subString" or "slice" or whatever,
and that the first parameter is a zero-based index, and that the
second is a length rather than another index. And you can't then
apply the same technique to another class like Vector, you have
to learn a different method name and set of parameters. You lose
orthogonality, basically.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: is Ada dying?

[Robert*]

Anyone interested in some Ada and Java introspection, this paper
is excellent:

Multilanguage Programming on the JVM:
The Ada 95 Benefits
Franco Gasperoni
gasperon@act-europe.fr
ACT Europe
www.act-europe.com
Gary Dismukes
dismukes@gnat.com
Ada Core Technologies
www.gnat.com


It gives a number of examples in Java, and how they lead to problems and
how Ada prevents these problems and detects them.

It is really an eye opener.

Re: is Ada dying?

[Navid Azimi]

WOW!! I'm over whelmed the responses! Thank you folks! I will now start Ada
once again, to be able to fully understand it, and add it to my list of
programming languages....

Thanks a lot for all the feedback. I just wasn't getting this sort of
feedback a few months ago... which I guess is proof... Ada IS growing!!

Haha. Alright.

Thank you everyone.

- Navid


"Robert*@" <Robert_member@newsguy.com> wrote in message
news:9prp1a01sa0@drn.newsguy.com...
> Anyone interested in some Ada and Java introspection, this paper
> is excellent:
>
> Multilanguage Programming on the JVM:
> The Ada 95 Benefits
> Franco Gasperoni
> gasperon@act-europe.fr
> ACT Europe
> www.act-europe.com
> Gary Dismukes
> dismukes@gnat.com
> Ada Core Technologies
> www.gnat.com
>
>
> It gives a number of examples in Java, and how they lead to problems and
> how Ada prevents these problems and detects them.
>
> It is really an eye opener.
>

Re: is Ada dying?

[Preben Randhol]

On 8 Oct 2001 01:44:26 -0700, Robert* @ wrote:
> Anyone interested in some Ada and Java introspection, this paper
> is excellent:
> 
> Multilanguage Programming on the JVM:
> The Ada 95 Benefits
> Franco Gasperoni
> gasperon@act-europe.fr
> ACT Europe
> www.act-europe.com
> Gary Dismukes
> dismukes@gnat.com
> Ada Core Technologies
> www.gnat.com
> 
> 
> It gives a number of examples in Java, and how they lead to problems and
> how Ada prevents these problems and detects them.
> 
> It is really an eye opener.

Where can one find it?

Preben

Re: is Ada dying?

[Lutz Donnerhacke]

* Preben Randhol wrote:
>> Multilanguage Programming on the JVM:
>> The Ada 95 Benefits
>
>Where can one find it?

http://www.google.com/search?q=Multilanguage+Programming+on+the+JVM
Second link:
http://www.gnat.com/texts/papers/ada95-benefits-on-the-jvm.pdf

Does Ada programming cause brain disease?

Re: is Ada dying?

[Preben Randhol]

On Tue, 9 Oct 2001 10:00:03 +0000 (UTC), Lutz Donnerhacke wrote:
> * Preben Randhol wrote:
>>> Multilanguage Programming on the JVM:
>>> The Ada 95 Benefits
>>
>>Where can one find it?
> 
> http://www.google.com/search?q=Multilanguage+Programming+on+the+JVM
> Second link:
> http://www.gnat.com/texts/papers/ada95-benefits-on-the-jvm.pdf
> 
> Does Ada programming cause brain disease?

No, but it is quite common to post the URL if it is on the net. Why
should 100 persons start searching the net for the same article?

Preben

Re: is Ada dying?(Perhaps a CPAN network is in order?)

[McDoobie]

In article <9pr8gu0tnf@drn.newsguy.com>, Robert*@
<Robert_member@newsguy.com> wrote:

>  
> Ada as a language is good. Better than C/C++ or Java.
> 
> What Ada needs is a standard or at least a psudo-standard set of
> auxilary packages that come well documented (HTML) and ready to plug in
> and use (similar to that Java huge standard library).
> 
> Untill this happens, Ada will remain a good language, few admirars,
> little  used and nothing more.
> 
> I am taking about packages for doing all sort of usefull pratical
> things, like those found in Java packages. 
> 
> ACT has been doing a good job of Adding usefull packages to its GNAT
> package, but it is still very much too little compared to what Java has,
> and with no way to for others to help add to it.
> 
> With Ada, the case now is that if you want a package to do something,
> you go and do some search on the web, find some bits and pieces of code,
> download, try to build, and see if that will work or not.   With Java, I
> download the JDK, and everything is there. Well documented, and ready to
> use. 
>  
> Having a central single place to get things from is a Good Thing (tm).
> Examples of such things
> 
> http://www.sunfreeware.com/   <--- Want any solaris package? go here
> http://java.sun.com    <---  Want the JDK? go here
> http://www.gnu.org/software/java/  <--- Want the GNU java collection? go
> here http://www.gjt.org/  <--- want the Giant Java tree collection? go
> here
> 
> etc..
> 
> Anyway, my point is that, Ada needs such a centalized, single place, to
> get standard usefull packages from. 
> 
>  
> 

Perhaps a distribution system similar to Perl's CPAN is in order.

Agreed, Java does appear to have alot more libraries and documentation
than Ada. I wonder if this is because it actually does have more, or
because the Ada information is so scattered about the Internet that it
takes forever to find it.

I know a good search of DoD specs and standards turns up alot of
information. Also the  LRM and Rationale does a pretty exhaustive job of
explaining the language itself. The only weakness I see in this regard is
a lack of libraries.

Now that I'm finally getting a good handle on OOP and Ada programming, I
plan on writing and  contributing my own libs to the Ada world. Everything
from bindings to Enlightenment and OpenGL, to hooks into languages such as
Ruby, Python, and Icon. Problem is, this is alot of work, even in Ada95,
to get right. 

Perhaps if some of the gurus around here would like to team up and create
a CPAN like  repository, we could really make some headway in this area.
If you dont, I'll beat you to the punch. Only thing holding me back right
now is money. Being a UPS loading dock grunt with college bills to pay is
taking it's toll. Nevertheless, I enjoy using Ada, and as soon as I'm
caught up on the money issue, expect see me working on this issue quite
extensively.

With all that being said, what kind of libraries would you folks say are
most needed to encourage more widespread use and acceptance of Ada, and
preferably Ada95? 

Would a CPAN like repository work well?

Perhaps a version of CVS custom tailored to Ada95 programming practices
would help?

I dont know for sure. As I said...I'm just now finally getting the hang of
it.(Ada95)


Hope I dont sound stupid. ;->

McDoobie Chris (chris@dont.spam.me)

Re: is Ada dying?

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

In article <Xns9133DBAF0AD71ralphworkcoza@196.25.240.158>, "Ralph M�ritz" <ralph@work.co.za> writes:
> I'm just starting out learning Ada, but it seems Ada is dying. From what I 
> can see very few people use Ada, out of about 15 000 projects on 
> Sourceforge only 32 are written in Ada!

I have been using Ada for 13 years.

I have never seen "Sourceforge", although I have heard the name.

Re: is Ada dying?

[John English]

Larry Kilgallen wrote:
> 
> In article <Xns9133DBAF0AD71ralphworkcoza@196.25.240.158>, "Ralph M�ritz" <ralph@work.co.za> writes:
> > I'm just starting out learning Ada, but it seems Ada is dying. From what I
> > can see very few people use Ada, out of about 15 000 projects on
> > Sourceforge only 32 are written in Ada!
> 
> I have been using Ada for 13 years.
> 
> I have never seen "Sourceforge", although I have heard the name.

http://sourceforge.net/

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: is Ada dying?

[Preben Randhol]

On 7 Oct 2001 19:31:02 GMT, Ralph M�ritz wrote:
> I'm just starting out learning Ada, but it seems Ada is dying. From what I 
> can see very few people use Ada, out of about 15 000 projects on 
> Sourceforge only 32 are written in Ada! I think that's sad, and now that 
> Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold 
> in store? Is it worthwhile learning a language nobody appreciates or uses?
> 

I don't think it is stupid to learn Ada, even if there are fewer that
use it. If you want a very popular language you have VB. ;-) 

Even if Ada would die, though I cannot see that happening in any near
future, you will have a very nice experience and a different approach
to programming than if you only do C(++).

Also my experience is that Ada is so nice that it makes programming fun
again.  If you look at Sourceforge you will see that a far amount of the
projects are actually C. I mean people use C to build a desktop (sic)! (see
http://www.gnome.org/).

Learn Ada and enjoy it!


Preben

Re: is Ada dying?

[Michael Bode]

"Ralph M�ritz" <ralph@work.co.za> writes:

> I'm just starting out learning Ada, but it seems Ada is dying. From what I 
> can see very few people use Ada, out of about 15 000 projects on 
> Sourceforge only 32 are written in Ada! I think that's sad, and now that 
> Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold 
> in store? Is it worthwhile learning a language nobody appreciates or uses?

Maybe this excerpt from the Jargon File explains why hackers are not
mainly coding in Ada:
(having programmed in C[++] some time I personally think is a good
reason to give Ada a try)

 Ada n. 

A Pascal-descended language that has been made mandatory for
Department of Defense software projects by the Pentagon. Hackers are
nearly unanimous in observing that, technically, it is precisely what
one might expect given that kind of endorsement by fiat; designed by
committee, crockish, difficult to use, and overall a disastrous,
multi-billion-dollar boondoggle (one common description wss "The PL/I
of the 1980s"). Hackers find Ada's exception-handling and
inter-process communication features particularly hilarious. Ada
Lovelace (the daughter of Lord Byron who became the world's first
programmer while cooperating with Charles Babbage on the design of his
mechanical computing engines in the mid-1800s) would almost certainly
blanch at the use to which her name has latterly been put; the kindest
thing that has been said about it is that there is probably a good
small language screaming to get out from inside its vast, elephantine
bulk.

Re: is Ada dying?

[James Rogers]

Michael Bode wrote:
> 
> 
> Maybe this excerpt from the Jargon File explains why hackers are not
> mainly coding in Ada:
> (having programmed in C[++] some time I personally think is a good
> reason to give Ada a try)
> 
>  Ada n.
> 
> A Pascal-descended language that has been made mandatory for
> Department of Defense software projects by the Pentagon. Hackers are
> nearly unanimous in observing that, technically, it is precisely what
> one might expect given that kind of endorsement by fiat; designed by
> committee, crockish, difficult to use, and overall a disastrous,
> multi-billion-dollar boondoggle (one common description wss "The PL/I
> of the 1980s"). Hackers find Ada's exception-handling and
> inter-process communication features particularly hilarious. Ada
> Lovelace (the daughter of Lord Byron who became the world's first
> programmer while cooperating with Charles Babbage on the design of his
> mechanical computing engines in the mid-1800s) would almost certainly
> blanch at the use to which her name has latterly been put; the kindest
> thing that has been said about it is that there is probably a good
> small language screaming to get out from inside its vast, elephantine
> bulk.

Yes. Let's all use a language with common constructs like the
following:

float (*(*f)())();

This is "simple" C syntax for a pointer to a function returning a
pointer to a function returning a float.

The above example is obviously much more desireable than making
a program readable. :-)

The hackers mentioned above are nearly unanimous in seeing nothing
wrong with the above example. Note that C expressions are most
commonly parsed from the middle out, not left to right or right to
left.

This wonderful syntax is also valid in C++.

Jim Rogers
Colorado Springs, Colorado USA

Re: is Ada dying?

[Michael Bode]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:
 
> Yes. Let's all use a language with common constructs like the
> following:
> 
> float (*(*f)())();

If a program was hard to write it should be hard to read ;-)

Re: is Ada dying?

[Marin David Condic]

If C++ is a language that would be held up by these hackers as "superior" to
the Ada they define, I'd find that to be a *real* laugh! "Elephantine"?
"Crokish"? "Difficult to use"? (Thy name is C++! :-)

Ada may be a large language in comparison to some, but it is certainly
syntactically smaller than C++. And it at least has the advantage of
consistency and simplicity in its semantics. Try understanding all of the "I
before E except after C unless its an alternate Tuesday or Thrusday with a
full moon or a month with an R in it...." sort of peculiar rules that show
up in the semantics of C++. It is both "Elephantine" and "Organically Grown"
(probably in a petri dish starting with some malevolent spore or
demon-spawn! :-) If this is an example of what "hackers" like instead of
Ada, then please never call me a "hacker".

Quite frankly, many of the same criticisms apply to C - except for the
"Elephantine" part. I'll concede that C is small in comparison to Ada, but
otherwise it suffers from all the same criticisms one can level at C++.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3BC264B4.EBB8238@worldnet.att.net...
>
> Yes. Let's all use a language with common constructs like the
> following:
>
> float (*(*f)())();
>
> This is "simple" C syntax for a pointer to a function returning a
> pointer to a function returning a float.
>
> The above example is obviously much more desireable than making
> a program readable. :-)
>
> The hackers mentioned above are nearly unanimous in seeing nothing
> wrong with the above example. Note that C expressions are most
> commonly parsed from the middle out, not left to right or right to
> left.
>
> This wonderful syntax is also valid in C++.

Re: is Ada dying?

[Wes Groleau]

Marin David Condic wrote:
> up in the semantics of C++. It is both "Elephantine" and "Organically Grown"

Where Ada had a single architect (with a watchdog committee) rejecting
wishes
that would go against elegance and simplicity, C++ appears to have grown
by a
"_someone_ wants it, and if we reject anything, we'll lose out to perl"
philosophy.

> Quite frankly, many of the same criticisms apply to C - except for the
> "Elephantine" part. I'll concede that C is small in comparison to Ada, but
> otherwise it suffers from all the same criticisms one can level at C++.

Actually, since they like to complain that we have a "dearth of
libraries"
let them throw in their stdlib and C is MUCH bigger and MUCH less
organized.

Long ago, someone complained that

   Ada is like drugged elephants waltzing in molasses.

To which the response was

   C is like a blindfolded naked lambada on a greased mirror
   with razor blades in each hand.

With C++, is the mirror tilted?




This is a troll--don't feed it.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: is Ada dying?

[Hyman Rosen]

James Rogers wrote:

> Yes. Let's all use a language with common constructs like the
> following:
> 
> float (*(*f)())();
> 
> This is "simple" C syntax for a pointer to a function returning a
> pointer to a function returning a float.


I could go "nyah nyah" and point out that until Ada 95 came along,
Ada didn't have pointers to functions. And functions returning
pointers to functions aren't all that common, so you don't see too
many declarations like that in typical C or C++ code.

That being said, I must agree that the declaration syntax of C (and
therefore of C++) is a disasterous mistake, stemming from a misguided
design goal. The point of C's declaration syntax is to make the
declaration of a name mirror its use. That is, to actually retrieve
the ultimate float from f, you can write

	float an_f = (*(*f)())();

See? It's an idea, just not a good one.

Re: is Ada dying?

[Larry Kilgallen]

In article <3BDBC0DC.5080005@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> James Rogers wrote:
> 
>> Yes. Let's all use a language with common constructs like the
>> following:
>> 
>> float (*(*f)())();
>> 
>> This is "simple" C syntax for a pointer to a function returning a
>> pointer to a function returning a float.
> 
> 
> I could go "nyah nyah" and point out that until Ada 95 came along,
> Ada didn't have pointers to functions. And functions returning
> pointers to functions aren't all that common, so you don't see too
> many declarations like that in typical C or C++ code.

If they aren't that common, it shouldn't have mattered that Ada83
did not have them.

If they aren't that common, that should _increase_ the need for
clarity.

Re: is Ada dying?

[Brian Rogoff]

On 28 Oct 2001, Larry Kilgallen wrote:
> In article <3BDBC0DC.5080005@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> > James Rogers wrote:
> >
> >> Yes. Let's all use a language with common constructs like the
> >> following:
> >>
> >> float (*(*f)())();
> >>
> >> This is "simple" C syntax for a pointer to a function returning a
> >> pointer to a function returning a float.
> >
> >
> > I could go "nyah nyah" and point out that until Ada 95 came along,
> > Ada didn't have pointers to functions. And functions returning
> > pointers to functions aren't all that common, so you don't see too
> > many declarations like that in typical C or C++ code.
>
> If they aren't that common, it shouldn't have mattered that Ada83
> did not have them.

He said "functions returning pointers to functions" aren't all that
common. Ada 83 didn't have "pointers to functions". Those quoted strings
aren't equal. Pointers to functions are pretty common, though less so in
languages that are object obsessed.

In many modern, high level languages (neither C++ nor Ada is in that set)
the notion of pointer to function is low level, but functions themselves
are first class. When combined with block structure and lexical scope
this is a very powerful abstraction mechanism.

> If they aren't that common, that should _increase_ the need for
> clarity.

Well, no one in the C world defends the declaration syntax. Hysterical
raisins and all that...

-- Brian

Re: is Ada dying?

[Tony Gair]

No

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3BDBC0DC.5080005@mail.com...
> James Rogers wrote:
>
> > Yes. Let's all use a language with common constructs like the
> > following:
> >
> > float (*(*f)())();
> >
> > This is "simple" C syntax for a pointer to a function returning a
> > pointer to a function returning a float.
>
>
> I could go "nyah nyah" and point out that until Ada 95 came along,
> Ada didn't have pointers to functions. And functions returning
> pointers to functions aren't all that common, so you don't see too
> many declarations like that in typical C or C++ code.
>
> That being said, I must agree that the declaration syntax of C (and
> therefore of C++) is a disasterous mistake, stemming from a misguided
> design goal. The point of C's declaration syntax is to make the
> declaration of a name mirror its use. That is, to actually retrieve
> the ultimate float from f, you can write
>
> float an_f = (*(*f)())();
>
> See? It's an idea, just not a good one.
>
>

Re: is Ada dying?

[Ted Dennison]

In article <nierp9.sm1.ln@320025674319.dialin.t-online.de>, Michael Bode says...
>Maybe this excerpt from the Jargon File explains why hackers are not
>mainly coding in Ada:
>(having programmed in C[++] some time I personally think is a good
>reason to give Ada a try)

The Jargon file is maintained by a single rather opinionated person, who happens
to hold quite a few rather outlandish opinions. Politics aside (after the WTC
bombings he tried to seriously argue that everyone on airplanes should carry
firearms...), he holds some rather "unusual" opinions about software
engineering. Generally, anything that isn't C or Perl is crap, as far as he's
concerned.

He's actually a really smart guy, and can reach some very good and valid
conclusions, when he starts off from postulates that everyone can agree with.
But when he doesn't, you can find yourself off into some non-Euclidian logic
universe where 1 = 0. The problem is that its tough to judge whether he came a
reasonable postulates with any of his opinions in the Jargon file. So generally
you are much better off ignoring that file altogether and relying on FOLDOC
(http://www.foldoc.org ). Its entry for Ada includes the following:

Ada is often criticised, especially for its size and complexity, and this is
attributed to its having been designed by committee. In fact, both Ada 83 and
Ada 95 were designed by small design teams to be internally consistent and
tightly integrated. By contrast, two possible competitors, Fortran 90 and C++
have both become products designed by large and disparate volunteer committees.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Wes Groleau]

Ted Dennison wrote:
> The Jargon file is maintained by a single rather opinionated person, who happens

You're too kind.  Even some of the most die-hard C bigots are
smart enough not to go as far as he did in the Jargon File.

(In his defense, many JF entries are obviously tongue-in-cheek.
Maybe this one was just not so obvious.)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: is Ada dying?

[Ted Dennison]

In article <3BC3145F.2BA7543@sparc01.ftw.rsc.raytheon.com>, Wes Groleau says...
>Ted Dennison wrote:
>> The Jargon file is maintained by a single rather opinionated person, who happens
>
>You're too kind.  Even some of the most die-hard C bigots are
>smart enough not to go as far as he did in the Jargon File.

Only because C++ has proved most of their traditional anti-Ada arguments false.
But there are a few people out there who are not swayed by the march of events.
Call it bravery, stupidity, or just plain hard-headedness.

But I am kind because I have in the past found some of his other writings
well-reasoned and quite helpful in practice. The "Homesteading the Noonesphere"
essay is a must read for anyone considering starting a cooperative volunteer
project of any kind. You just have to realise that there are some opinions he
holds to almost religously, and you should stay away from his writings on those
subjects if you care about logic and getting to reasonable conclusions.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Florian Weimer]

"Ralph M�ritz" <ralph@work.co.za> writes:

> I'm just starting out learning Ada, but it seems Ada is dying. From what I 
> can see very few people use Ada, out of about 15 000 projects on 
> Sourceforge only 32 are written in Ada!

How many are written in COBOL or Fortran?  And these languages are
definitely not dying!

The SourceForge statistics are not even representative of the whole
free software community, and certainly do not reflect internal use.

> Is it worthwhile learning a language nobody appreciates or uses?

If the language helps to solve your problems, why not?

Re: is Ada dying?

[Robert*]

 
From:
 
Technical Report
CMU/SEI-92-TR-29
ESC-TR-92-029
Ada Adoption Handbook:
A Program Manager?s Guide
Version 2.0
William E. Hefley
John T. Foreman
Charles B. Engle, Jr.
John B. Goodenough
October 1992


(reproduced here without persmission from CMU, notice this is almost
10 years old report!)


Question: What are some of the inhibitors to adopting Ada?

Answer: The following inhibitors have been encountered in adopting Ada:

Compiler availability: 
========================
Most major processors in use today, ranging from 
specialized digital signal processors (DSP) to microprocessors to mainframe 
computers and super computers, have Ada compilers.

There were 501 totalvalidated Ada compilers on the official AJPO list 
(as of October 1992). This number has grown from 78 validated compilers in 
May 1987, and only 14 in early 1986. See Appendices A.2 and B.3 for online 
and  printed sources of the current listing. 

If no compiler is available for the selected hardware, see Section 7.2.1 
for an action plan and several alternative solutions.

Ada and embedded systems: The Ada language design team emphasized 
supporting modern software engineering practices; the result is a 
language with wide applicability in developing wellengineered,
quality software. In fact, Ada has been used successfully for MIS and 
Corporate Information Management (CIM) applications [87]. There are no 
technical reasons why Ada cannot be used successfully, and cost-effectively, 
for such applications [64, 87].

DoD policy and Ada: 
====================
Current DoD policy requires that Ada be used for new defense systems and for
major software upgrades of existing systems, where cost effective. See 
Section 3.2 for a brief description of the waiver process for efforts that 
cannot comply with the policy.

New technology: 
================
A new technology always introduces risks, but now that Ada has matured, 
the risks from adopting Ada have been significantly reduced. Recent studies 
have shown that, in organizations that have completed several Ada projects,
Ada can be at least as cost-effective, if not more so, as other languages 
that have traditionally been used for developing large, software-intensive 
systems [39, 193, 81].

Lack of knowledge: 
=====================
A lack of knowledge of software engineering and Ada can delay the transition 
to Ada. Software engineering has not yet attained the recognition or 
acceptance of other academic disciplines. Education in software engineering 
is not as available, comprehensive, or complete as in established engineering 
disciplines. An effective training program is a key part of developing an
organizations software engineering capability [147]. Ada training, 
supported by appropriate software engineering training, can assist an 
organization in improving that capability. DoD procurement process: 
The current procurement process may not be conducive to Ada adoption
and long-term software engineering improvement. A recent survey of Ada 
adoption indicates that lowest development cost still is the major award 
factor on DoD contracts, and that defense contractors
perceive the DoD as unwilling to trade lower life-cycle cost for greater 
development cost [49].

Early perceptions: 
===================
In the face of criticisms of early, and thus immature, Ada implementations, 
there has been little advertising of successful Ada efforts, such as those 
described in [87, 94] or the Experiencetrack of the TRI-Ada conferences 
[108, 97, 38], and little concerted effort to gather, analyze, and distribute 
objective data about the economic impact of Ada on the software engineering
discipline. The early bad press has left a legacy because of weaknesses of 
early implementations and the experiences of early Ada projects.

Language issues: 
==================
Real and perceived language limitations have hampered the adoption of Ada.
The Ada Joint Program Office (AJPO) has emphasized a strict validation 
process that has yielded hundreds of validated compilers. Great progress has
been made in Ada compiler technology, including the development of 
optimizing compilers for many processors. Clearly, the image of Ada 
implementations having poor performance and quality is much outdated; 
projects should evaluate Ada implementations in light of their specific
requirements.

Re: is Ada dying?

[John McCabe]

On 8 Oct 2001 00:38:15 -0700, Robert*@ <Robert_member@newsguy.com>
wrote:

> 
>From:
> 
>Technical Report
>CMU/SEI-92-TR-29
>ESC-TR-92-029
>Ada Adoption Handbook:
>A Program Manager?s Guide
>Version 2.0
>William E. Hefley
>John T. Foreman
>Charles B. Engle, Jr.
>John B. Goodenough
>October 1992
>
>
>(reproduced here without persmission from CMU, notice this is almost
>10 years old report!)

10 years is a long time in software - a report of this nature cannot
be relied upon now, particularly as it was written long before Ada 95
became available. Something similar listing the number of Ada 95
compilers available would be use. You have to consider for example
that, at the very least, TLD Systems and Meridian never produced an
Ada 95 compiler (despite TLD's affiliation with ACT) and, as far as I
know, neither even are (capable of) marketing an Ada 83 compiler
anymore. Furthermore Tartan (now part of TI) appear to have ceased any
development of their compilers.

So, while this report says that numbers of compilers have risen since
1987 etc, what has happened since 1992? www.adaic.org lists the
following vendors as having certified Ada 95 compilers:

ACT
Aonix
Averstar
Conccurrent Computer Corporation
DDC-I
Green Hills
Irvine Compiler Corporation
OC Systems
Rational
RR Software

For Ada 83 you have all of the above except ACT plus:

Active Engineering Technologies
Aitech Defense Systems
Alenia Aeritalia & Selenia S.p.A (DACS? - ex-DDC-I?)
Convex
Control Data
Cray Research
DESC (formerly ICL)
DEC
EDS-Scicon
Encore
GSE Gesellschaft fur Software Engineering mbH (Meridian)
Green Valley (!)
HP (Apparently now TSP -> Aonix)
IBM (now OC Systems)
Intel
MIPS (now Rational, Green Hills and DDC-I)
Multiprocessor Toolsmiths, Inc
NEC
Proprietary Software Systems
Rockwell International Corporation
SKY Computers, Inc
STN ATLAS Elektronik GmbH
Siemens Nixdorf Informationssysteme AG
Silicon Graphics
Software Leverage, Inc.
Stratus Computer Inc
Sun Microsystems
TLD Systems, Ltd
Tartan Inc (incl TI)
U.S. Air Force
Wang Laboratories, Inc

(Sorry - didn't expect the list to be so long!!!)

So the question that needs to be asked is whether you really want to
promote Ada 83, as there is such a long list of compilers for it
(despite the fact I would be surprised if you could source many of
them anymore), or promote Ada 95 which has clearly seen far less
commercial investment in supporting products.

John

Re: is Ada dying?

[Richard Riehle]

John McCabe wrote:

> On 8 Oct 2001 00:38:15 -0700, Robert*@ <Robert_member@newsguy.com>
> wrote:

John gives a list of Ada 83 compilers below.  Someone might read this as
an indication that there are fewer compilers for Ada 95 than Ada 83.  What

has happened is quite different.

Many of the compilers shown were developed in-house by companies who
needed a "checkbox" compiler.   I have been told by the senior management
of a couple of these companies that the only reason for having a validated

Ada compiler is so they could respond to an RFP by checking off the
box labled, "Validated Ada."    Many of these compilers were designed
on top of other compilers, leveraging someone else's technology.  If one
were to carefully examine the source of these in-house compilers, it
would soon become clear that only a few compilers were actually in
place, and those targeted to a wide number of computers.  Often, the
compiler was licensed so the hardware manufacturer could label it
with their own proprietary name.

What has happened with Ada 95 is a more realistic organization of the
compiler industry.  Some compiler publishers have consolidated, hardware
manufacturers have seen the folly of trying to be experts in Ada compiler
development, the pricing structures have changed, and those who were
simply unprofitable failed to make the transition to Ada 95.

One other detail needs to be noted.   When Ada was a mandated language
instead of an optional one for DoD projects,  some compiler publishers
saw the mandate as an opportunity to charge outrageous licensing fees
for their compilers.   Also, since they could get these fees from the DoD,

they had little incentive to seriously address the commercial market where

those kinds of fees were unacceptable.  With a few exceptions, these
compiler
publishers have been forced to adjust their licensing fees to more
realistically
reflect the choice now available to DoD software developers.

Richard Riehle



> So, while this report says that numbers of compilers have risen since
> 1987 etc, what has happened since 1992? www.adaic.org lists the
> following vendors as having certified Ada 95 compilers:
>
> ACT
> Aonix
> Averstar
> Conccurrent Computer Corporation
> DDC-I
> Green Hills
> Irvine Compiler Corporation
> OC Systems
> Rational
> RR Software
>
> For Ada 83 you have all of the above except ACT plus:
>
> Active Engineering Technologies
> Aitech Defense Systems
> Alenia Aeritalia & Selenia S.p.A (DACS? - ex-DDC-I?)
> Convex
> Control Data
> Cray Research
> DESC (formerly ICL)
> DEC
> EDS-Scicon
> Encore
> GSE Gesellschaft fur Software Engineering mbH (Meridian)
> Green Valley (!)
> HP (Apparently now TSP -> Aonix)
> IBM (now OC Systems)
> Intel
> MIPS (now Rational, Green Hills and DDC-I)
> Multiprocessor Toolsmiths, Inc
> NEC
> Proprietary Software Systems
> Rockwell International Corporation
> SKY Computers, Inc
> STN ATLAS Elektronik GmbH
> Siemens Nixdorf Informationssysteme AG
> Silicon Graphics
> Software Leverage, Inc.
> Stratus Computer Inc
> Sun Microsystems
> TLD Systems, Ltd
> Tartan Inc (incl TI)
> U.S. Air Force
> Wang Laboratories, Inc
>
> (Sorry - didn't expect the list to be so long!!!)
>
> So the question that needs to be asked is whether you really want to
> promote Ada 83, as there is such a long list of compilers for it
> (despite the fact I would be surprised if you could source many of
> them anymore), or promote Ada 95 which has clearly seen far less
> commercial investment in supporting products.
>
> John

Re: is Ada dying?

[John McCabe]

On Mon, 08 Oct 2001 13:25:38 -0700, Richard Riehle
<richard@adaworks.com> wrote:

>John McCabe wrote:
>
>> On 8 Oct 2001 00:38:15 -0700, Robert*@ <Robert_member@newsguy.com>
>> wrote:
>
>John gives a list of Ada 83 compilers below.  Someone might read this as
>an indication that there are fewer compilers for Ada 95 than Ada 83.  What
>has happened is quite different.

Find me an Ada 95 compiler for a Mil-Std-1750A target then?

I'm sure much of what you have said is true but, as far as I've seen,
other than porting GNAT technology, there is little support for lesser
known processors.

Re: is Ada dying?

[Gary Scott]

But Jovial is alive and well for 1750A...and it's served us well for 30
years or so.

John McCabe wrote:
> 
> On Mon, 08 Oct 2001 13:25:38 -0700, Richard Riehle
> <richard@adaworks.com> wrote:
> 
> >John McCabe wrote:
> >
> >> On 8 Oct 2001 00:38:15 -0700, Robert*@ <Robert_member@newsguy.com>
> >> wrote:
> >
> >John gives a list of Ada 83 compilers below.  Someone might read this as
> >an indication that there are fewer compilers for Ada 95 than Ada 83.  What
> >has happened is quite different.
> 
> Find me an Ada 95 compiler for a Mil-Std-1750A target then?
> 
> I'm sure much of what you have said is true but, as far as I've seen,
> other than porting GNAT technology, there is little support for lesser
> known processors.

Re: is Ada dying?

[John McCabe]

On Tue, 09 Oct 2001 10:10:44 -0500, Gary Scott
<Gary.L.Scott@lmtas.lmco.com> wrote:

>But Jovial is alive and well for 1750A...and it's served us well for 30
>years or so.

There's a huge market for that, isn't there! I know the UK Air Traffic
Control system in West Drayton has significant quantities of Jovial in
it, so why are NERC using Ada?

Re: is Ada dying?

[Gary Scott]

John McCabe wrote:
> 
> On Tue, 09 Oct 2001 10:10:44 -0500, Gary Scott
> <Gary.L.Scott@lmtas.lmco.com> wrote:
> 
> >But Jovial is alive and well for 1750A...and it's served us well for 30
> >years or so.
> 
> There's a huge market for that, isn't there! I know the UK Air Traffic
> Control system in West Drayton has significant quantities of Jovial in
> it, so why are NERC using Ada?

F-16 is still mostly Jovial.  Newer systems were moving toward Ada, now
moving toward C before even getting to production (some
configurations)...

-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: is Ada dying?

[Ted Dennison]

In article <3BCE32B2.96CE83C5@flash.net>, Gary Scott says...
>
>F-16 is still mostly Jovial.  Newer systems were moving toward Ada, now
>moving toward C before even getting to production (some
>configurations)...


As long as they are moving backwards, why don't they skip a few steps and stay
with Jovial?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Wes Groleau]

Ted Dennison wrote:
> As long as they are moving backwards, why don't they skip a few steps and stay
> with Jovial?

Are you implying that Jovial is older than C, or that Jovial is worse
than C?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: is Ada dying?

[Ted Dennison]

In article <3BCEFCED.1A5E7EE1@sparc01.ftw.rsc.raytheon.com>, Wes Groleau says...
>
>
>
>Ted Dennison wrote:
>> As long as they are moving backwards, why don't they skip a few steps and 
>> stay with Jovial?
>
>Are you implying that Jovial is older than C, or that Jovial is worse
>than C?

I was talking about age. I don't know enough about the language to speak for
"quality".

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Marin David Condic]

IMHO, Jovial is of somewhat better quality than C for embedded work - It
provides better control over the representation of things and was intended
for use in embedded computing. It is also not quite so cryptic in its
syntax. Generally, there isn't really a whole lot of difference between the
two languages in some technological sense - they both provide about the same
level of features and have roughly the same kinds of strengths/weaknesses.
Of the two, I think I'd prefer to program in Jovial, so a step from C to
Jovial might be a marginal improvement. But that's just my own preference
without any science behind it.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:qHEz7.34364$ev2.41804@www.newsranger.com...
> In article <3BCEFCED.1A5E7EE1@sparc01.ftw.rsc.raytheon.com>, Wes Groleau
says...
>
> I was talking about age. I don't know enough about the language to speak
for
> "quality".
>

Re: is Ada dying?

[Gary Scott]

Ted Dennison wrote:
> 
> In article <3BCE32B2.96CE83C5@flash.net>, Gary Scott says...
> >
> >F-16 is still mostly Jovial.  Newer systems were moving toward Ada, now
> >moving toward C before even getting to production (some
> >configurations)...
> 
> As long as they are moving backwards, why don't they skip a few steps and stay
> with Jovial?
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
> 
> No trees were killed in the sending of this message.
> However a large number of electrons were terribly inconvenienced.

Suits me since the superior avionics architecture (e.g. distributed
processors, less likely to suffer catastrophic damage in event of a hit,
can change one function without monkeying with unrelated functions) is
primarily Jovial.  Also, although I work both arenas, the Jovial code is
much more stable, easier to change without introducing intractable
errors, etc. than the Ada versions (so far).  Only problems are related
to insufficient memory size and processor throughput.  But I'm resigned
to the inevitable that it will only get worse in the future.
-- 


Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: is Ada dying?

[Richard Riehle]

John McCabe wrote:

> Find me an Ada 95 compiler for a Mil-Std-1750A target then?

Alas, there seems to be none.  TLD was going to develop one, but
TLD seems to have vanished.    DDC-I is probably our last hope
for a 1750A compiler, but I don't think they have announced one,
so far.

To be fair, many believe the 1750A is a dead processor.  While this
may not be true, it seems the 1983 Ada standard serves quite well
for the kinds of programs being written for 1750A.  In my limited
experience with this processor (one project only),  the programs
don't use tasking, don't use access types, and often use only a
subset of the full range of language capabilities.   There is no
need for inheritance, dynamic binding, or most other features
found in Ada 95.   Those with experience on a larger number
of 1750A projects may have a different view.

Richard Riehle

Re: is Ada dying?

[John McCabe]

On Tue, 09 Oct 2001 22:03:37 -0700, Richard Riehle
<richard@adaworks.com> wrote:

>> Find me an Ada 95 compiler for a Mil-Std-1750A target then?
>
>Alas, there seems to be none.  TLD was going to develop one, but
>TLD seems to have vanished.

Yes, they have - as the Irvine Compiler Corporation found to their
cost by the sound of it - TLD apparently licensed ICC technology.

I've used the TLD compiler a few times and can honestly say I was not
impressed.

>DDC-I is probably our last hope
>for a 1750A compiler, but I don't think they have announced one,
>so far.

I haven't heard recently. They did an Ada83 one, and it was assumed
that the ANDF technology they were supposed to be using for Ada 95
would mean Ada 95 would be possible for the 1750.

>To be fair, many believe the 1750A is a dead processor.

Under normal circumstances I believe the 1750A would have been dead
years ago but, as it is one of very few processors available in
Radiation Hardened form (at least it was around 4 years ago), its life
appeared to have been extended and it was (is?) used extensively in
the European space industry.

>While this
>may not be true, it seems the 1983 Ada standard serves quite well
>for the kinds of programs being written for 1750A.  In my limited
>experience with this processor (one project only),  the programs
>don't use tasking, don't use access types, and often use only a
>subset of the full range of language capabilities.   There is no
>need for inheritance, dynamic binding, or most other features
>found in Ada 95.   Those with experience on a larger number
>of 1750A projects may have a different view.

I don't see any reason why the 1750A should not be suitable for Ada 95
(except those built were all exceptionally slow compared to modern
processors). For Ada 83 the fact that tasking wasn't used was often
more a criticism on the speed of the processor and the compiler
technology available at the time. The Ada Tasking Co-Processor (ATAC)
was a piece of hardware designed to enhance the 1750's tasking
capabilities, and operated as a kind of co-processor. I believe TLD
added support to their compiler for the ATAC with funding supplied by
ESA.

Re: is Ada dying?

[Stephen Leake]

john.mccabe@emrad.com.nospam (John McCabe) writes:

> On Tue, 09 Oct 2001 22:03:37 -0700, Richard Riehle
> <richard@adaworks.com> wrote:
> 
> >> Find me an Ada 95 compiler for a Mil-Std-1750A target then?
> >
> >Alas, there seems to be none.  TLD was going to develop one, but
> >TLD seems to have vanished.

http://www.xgc.com/ has a port of GNAT to 1750. I haven't tried it, but it
sounds good!


-- 
-- Stephe

Re: is Ada dying?

[John McCabe]

On 10 Oct 2001 13:41:07 -0400, Stephen Leake
<stephen.a.leake.1@gsfc.nasa.gov> wrote:

>john.mccabe@emrad.com.nospam (John McCabe) writes:
>
>> On Tue, 09 Oct 2001 22:03:37 -0700, Richard Riehle
>> <richard@adaworks.com> wrote:
>> 
>> >> Find me an Ada 95 compiler for a Mil-Std-1750A target then?
>> >
>> >Alas, there seems to be none.  TLD was going to develop one, but
>> >TLD seems to have vanished.
>
>http://www.xgc.com/ has a port of GNAT to 1750. I haven't tried it, but it
>sounds good!

Interesting - my only concern is:

"This compiler supports the same Ada 95 mission-critical subset as
ERC32 Ada"

Sounds like it's not a full implementation. I'll check it out though
(not that I use Mil-Std-1750s any more, or even Ada!).

Re: is Ada dying?

[Marin David Condic]

I did one in Ada83 that used tasking. It was a rather limited amount of
tasking consisting of just a set of loops to execute things at various
intervals, but it was a tasking app on a 1750a. We had only very limited
rendesvous just to enable lower priority loops to start and didn't use any
of the more sophisticated techniques for sharing data between threads
(parameter passing, etc) because we couldn't stand the processor overhead.
It wasn't easy and we ended up running at near capacity, so I'd obviously
recommend that faster, bigger processors get used for apps, but IIRC, the
tasking executive overhead was only about 7% of our processor time, so I
wouldn't rule it out as unadvisable.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3BC3D6A9.DF42F428@adaworks.com...
>
> To be fair, many believe the 1750A is a dead processor.  While this
> may not be true, it seems the 1983 Ada standard serves quite well
> for the kinds of programs being written for 1750A.  In my limited
> experience with this processor (one project only),  the programs
> don't use tasking, don't use access types, and often use only a
> subset of the full range of language capabilities.   There is no
> need for inheritance, dynamic binding, or most other features
> found in Ada 95.   Those with experience on a larger number
> of 1750A projects may have a different view.
>

Re: is Ada dying?

[John McCabe]

On Wed, 10 Oct 2001 09:38:07 -0400, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

I'm sure I discussed this with you a lonog time ago, but what version
of the processor did you use?

>I did one in Ada83 that used tasking. It was a rather limited amount of
>tasking consisting of just a set of loops to execute things at various
>intervals, but it was a tasking app on a 1750a. We had only very limited
>rendesvous just to enable lower priority loops to start and didn't use any
>of the more sophisticated techniques for sharing data between threads
>(parameter passing, etc) because we couldn't stand the processor overhead.
>It wasn't easy and we ended up running at near capacity, so I'd obviously
>recommend that faster, bigger processors get used for apps, but IIRC, the
>tasking executive overhead was only about 7% of our processor time, so I
>wouldn't rule it out as unadvisable.

Ada on the 1750a (was Re: is Ada dying?)

[Marin David Condic]

"Version of the processor"? Dunno. Not sure what you are asking. We were
using a RAD-Hard Plessey chip and the time frame was mid-to-late 90's that
the project was ongoing. This was just about the time that Plessey was
seriously threatening to stop making the RAD-hard 1750a. (I think they
finally did, but it was after our project had been shut down. Some guy named
"Captain Willard" came sailing up the river on a patrol boat and shut down
the whole operation... Very strange... :-)

The compiler (in case anyone was wondering) was the XD-Ada compiler hosted
on DEC machines. We evaluated a number of 1750a-target compilers and this
one produced the best code (and pay REAL close attention here!!!) FOR THE
APPLICATION WE HAD. (All the compilers were good at some things and poor at
others and for the kinds of high-use algorithms we had, XD did the best
job.) Avionics-quality compilers are rare and valuable things!

If I had it to do all over again, I doubt we would really need anything that
was in Ada95 - except for the possible maturity level of the language
meaning better implementation of some features. *Maybe* we could have made
use of Protected objects to eliminate the handful of hand-coded semaphores
we built to shield some shared data. I would also have liked to see if we
could have used the "delay until" construct to do our time scheduling rather
than having disabled all the clocks & using a 1.024ms interrupt to drive the
whole thing. Modular types would have saved us a little trouble too. Much
beyond that, I don't think Ada95 would have offered us significant new
features.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"John McCabe" <john.mccabe@emrad.com.nospam> wrote in message
news:3bc55b1a.3036135@news.demon.co.uk...
> On Wed, 10 Oct 2001 09:38:07 -0400, "Marin David Condic"
> <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
>
> I'm sure I discussed this with you a lonog time ago, but what version
> of the processor did you use?
>

Re: Ada on the 1750a (was Re: is Ada dying?)

[John McCabe]

On Thu, 11 Oct 2001 09:53:42 -0400, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

>"Version of the processor"? Dunno. Not sure what you are asking. We were
>using a RAD-Hard Plessey chip and the time frame was mid-to-late 90's that
>the project was ongoing.

That'll be the GPS MA31750 then (which is what I was asking). It is
the same processor I was using last time. I was just wondering whether
you'd gone down the road of dumping the GPS (well, GEC-Plessey
Semiconductors to us, I guess just Plessey to you) in favour of
something like the Performance Semiconductors implementation which was
a bit faster. We used the MA31750(H) I think - rated at 1.3MIPS at
10MHz. We were only allowed to run it at 9MHz though.

> This was just about the time that Plessey was
>seriously threatening to stop making the RAD-hard 1750a. (I think they
>finally did, but it was after our project had been shut down. Some guy named
>"Captain Willard" came sailing up the river on a patrol boat and shut down
>the whole operation... Very strange... :-)

:-) They *were* talking about producing a Rad-Hard ARM processor last I heard.

Re: is Ada dying?

[Ted Dennison]

In article <9prl5701m0v@drn.newsguy.com>, Robert*@ says...
>Technical Report
>CMU/SEI-92-TR-29
>ESC-TR-92-029
>Ada Adoption Handbook:
>A Program Manager?s Guide
>October 1992

Note that any information in here would have been about Ada83. For the most
part, the contents happen to be relevant anyway, but the data in the compiler
availability section was talking about the state of Ada83 compilers back in
'92...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Stephen Leake]

"Ralph M�ritz" <ralph@work.co.za> writes:

> I'm just starting out learning Ada, but it seems Ada is dying. From what I 
> can see very few people use Ada, out of about 15 000 projects on 
> Sourceforge only 32 are written in Ada! I think that's sad, and now that 
> Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold 
> in store? Is it worthwhile learning a language nobody appreciates or uses?

To say something is "dying", you need to state a trend, not a single
data point.

How many projects on Sourceforge were in Ada last year? Two years ago?

I'll bet there were fewer!

Better; what is the ratio of new projects in Ada to new projects in
other languages? Or defunct projects?

(I actually have no idea how to find out this information, or I'd do
it myself).

-- 
-- Stephe

Re: is Ada dying?

[Robert Dewar]

"Ralph M?itz" <ralph@work.co.za> wrote in message news:<Xns9133DBAF0AD71ralphworkcoza@196.25.240.158>...
> I'm just starting out learning Ada, but it seems Ada is dying. From what I 
> can see very few people use Ada, out of about 15 000 projects on 
> Sourceforge only 32 are written in Ada! I think that's sad, and now that 
> Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold 
> in store? Is it worthwhile learning a language nobody appreciates or uses?


Isn't it odd in this field that if a technology is not
dominant (by number of applications), then it is considered
dead (examples, Pascal, PL/1, OS/2 ... all of which are
alive and used for many important applications). The trade
press has even announced that Java is dead on the client
side, and no doubt given Microsoft's decision to exclude
Java from XP, will pronounce it completely dead. Sometimes
people even decide that widely used technologies are dead.
I once heard a high up official in the DoD tell me that
no one outside the DoD used COBOL any more (that statement
was made over a year ago!)

The U.S. DoD is not "dropping Ada", to think this is as
wrong as to think that everyone in the DoD was using Ada
during the mandate. The actual fact is that, not at all
surprisingly, some people in the DoD like Ada, and fight
to do as much as possible in Ada, and some people in the
DoD dislike it, and fight to do as much as possible in
some other language (C++ or even Java).

Ada is certainly not dead, and use of Ada will continue
for a long time. Will usage increase or decrease? Hard
to say. Here at Ada Core Technologies, we see a steady
increase in use. This can of course be due to three factors

  a) people updating from Ada 83 to Ada 95
  b) people shifting from other Ada technologies to GNAT
  c) new projects being started in Ada

We certainly know some projects that are in category c, but
it is hard to know what the division between these three is. In any
case, regardless of what other vendors do, ACT
expects to be supporting Ada for a long time to come, and
to continue to do active development and enhancements to
the GNAT technology (we already have a long list of
enhancements that have been made for version 3.15). As
you know from our web site, 3.14 also had a long list of
enhancements (and we expect to see 3.14 public versions
out soon for selected targets).

If you want to learn a dominant technology that is very
widely used, I would suggest Visual Basic or COBOL, there
is a big demand for people in both areas, and these are
still among the most widely used languages. But if you
want to learn Ada, you will find that

a) You acquire skills and knowledge that are useful not
only in Ada, but in other arenas.

b) There are definitely jobs for competent Ada programmers.


Robert Dewar
Ada Core Technologies

Re: is Ada dying?

[David Starner]

On 8 Oct 2001 08:02:52 -0700, Robert Dewar <dewar@gnat.com> wrote:
> Isn't it odd in this field that if a technology is not
> dominant (by number of applications), then it is considered
> dead (examples, Pascal, PL/1, OS/2 ... all of which are
> alive and used for many important applications). 

However, there is a certain point where a technology is at least dying.
OS/2, for example, has one implementation, another version of which will
never be released, so saith IBM. I think that qualifies as moribund
without doubt.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: is Ada dying?

[Vincent Marciante]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9psq8m$9ic1@news.cis.okstate.edu...
<snip>
> However, there is a certain point where a technology is at least dying.
> OS/2, for example, has one implementation, another version of which will
> never be released, so saith IBM. I think that qualifies as moribund
> without doubt.

Doubt it!  www.eComStation.com is an OS/2 client with an SMP option
available for about $100 more.  It comes with _two_ office suites, a bunch
of other software and _IS_ being actively developed.   (Also, the new
installer
lets you boot directly from CD - no harddisk at all is necessary!)

Vincent Marciante

> --
> David Starner - dstarner98@aasaa.ofe.org
> Pointless website: http://dvdeug.dhis.org
> "I saw a daemon stare into my face, and an angel touch my breast; each
> one softly calls my name . . . the daemon scares me less."
> - "Disciple", Stuart Davis

Re: is Ada dying?

[chris.danx]

"Ralph M�ritz" <ralph@work.co.za> wrote in message
news:Xns9133DBAF0AD71ralphworkcoza@196.25.240.158...
> I'm just starting out learning Ada, but it seems Ada is dying. From what I
> can see very few people use Ada, out of about 15 000 projects on
> Sourceforge only 32 are written in Ada!

Make that 33.  There is a project to develop a cross platform technology
known as the Andromeda GUI project.  It's meant to be source level
compatible and is to be written in a variety of languages of which Ada is
one.  The idea grew from a discussion on alt.os.development, with developers
wanting to do minimal porting of apps to their kernels.  i.e. develop on
windows, unix etc but transfer it to their OSes without changing a single
line.  It's very early in it's design and there are only two developers at
present.

> I think that's sad, and now that
> Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold
> in store? Is it worthwhile learning a language nobody appreciates or uses?

They teach it at a few uni's now.  Don't know how if its uptake is more than
before; might be interesting to find out.


Chris

p.s. GUI is probably wrong.  It will include more than just a universal gui
(after all Gtk+ does a good job already), like file IO, etc.

Re: is Ada dying?

[Gary Scott]

"chris.danx" wrote:
> 
> "Ralph M�ritz" <ralph@work.co.za> wrote in message
> news:Xns9133DBAF0AD71ralphworkcoza@196.25.240.158...
> > I'm just starting out learning Ada, but it seems Ada is dying. From what I
> > can see very few people use Ada, out of about 15 000 projects on
> > Sourceforge only 32 are written in Ada!
> 
> Make that 33.  There is a project to develop a cross platform technology
> known as the Andromeda GUI project.  It's meant to be source level
> compatible and is to be written in a variety of languages of which Ada is
> one.  The idea grew from a discussion on alt.os.development, with developers
> wanting to do minimal porting of apps to their kernels.  i.e. develop on
> windows, unix etc but transfer it to their OSes without changing a single
> line.  It's very early in it's design and there are only two developers at
> present.

Reinventing the wheel...see GINO and Winteracter...

> 
> > I think that's sad, and now that
> > Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold
> > in store? Is it worthwhile learning a language nobody appreciates or uses?
> 
> They teach it at a few uni's now.  Don't know how if its uptake is more than
> before; might be interesting to find out.
> 
> Chris
> 
> p.s. GUI is probably wrong.  It will include more than just a universal gui
> (after all Gtk+ does a good job already), like file IO, etc.

Re: is Ada dying?

[chris.danx]

"Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
news:3BC20533.F2F0E29@lmtas.lmco.com...
>
>
> "chris.danx" wrote:
> >
> > "Ralph M�ritz" <ralph@work.co.za> wrote in message
> > news:Xns9133DBAF0AD71ralphworkcoza@196.25.240.158...
> > > I'm just starting out learning Ada, but it seems Ada is dying. From
what I
> > > can see very few people use Ada, out of about 15 000 projects on
> > > Sourceforge only 32 are written in Ada!
> >
> > Make that 33.  There is a project to develop a cross platform technology
> > known as the Andromeda GUI project.  It's meant to be source level
> > compatible and is to be written in a variety of languages of which Ada
is
> > one.  The idea grew from a discussion on alt.os.development, with
developers
> > wanting to do minimal porting of apps to their kernels.  i.e. develop on
> > windows, unix etc but transfer it to their OSes without changing a
single
> > line.  It's very early in it's design and there are only two developers
at
> > present.
>
> Reinventing the wheel...see GINO and Winteracter...

GINO?  Where's that?  I just tried a search but ended up with a load of
links to italian blokes (not suprisingly).

Winteracter is fortan, right?  Andromeda is meant to be a language
indepedant standard with implementations in Ada and C to begin with.  It is
meant to ease the burden on OS developers should they choose to provide an
implementation.  It's graphical component will be based upon OpenGL because
a large variety of cards support OpenGL, making it easier on the developer
(assuming (s)he can develop a driver for their OS, which is a different
issue altogether).

Wait is GINO fortran-based too?  Some of the searches for GINO gui came up
fortran.  That's no good, it's not language independant.  You'd have to
write a binding for it.

The project was only mentioned because there's sure to be an experimental
implementation for windows written in Ada (and one in C to see how well the
rules work) before the objective is achieved.

Chris

p.s. is it sufficient for pragma Linker_Options ("ogl32.dll") to be added to
the bindings supplied with Glut, to get it to work on windows?

Re: is Ada dying?

[Gary Scott]

Hi,

"chris.danx" wrote:
> 
> "Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
> news:3BC20533.F2F0E29@lmtas.lmco.com...
> >
> >
> > "chris.danx" wrote:
> > >
> > > "Ralph M�ritz" <ralph@work.co.za> wrote in message
> > > news:Xns9133DBAF0AD71ralphworkcoza@196.25.240.158...
> > > > I'm just starting out learning Ada, but it seems Ada is dying. From
> what I
> > > > can see very few people use Ada, out of about 15 000 projects on
> > > > Sourceforge only 32 are written in Ada!
> > >
> > > Make that 33.  There is a project to develop a cross platform technology
> > > known as the Andromeda GUI project.  It's meant to be source level
> > > compatible and is to be written in a variety of languages of which Ada
> is
> > > one.  The idea grew from a discussion on alt.os.development, with
> developers
> > > wanting to do minimal porting of apps to their kernels.  i.e. develop on
> > > windows, unix etc but transfer it to their OSes without changing a
> single
> > > line.  It's very early in it's design and there are only two developers
> at
> > > present.
> >
> > Reinventing the wheel...see GINO and Winteracter...
> 
> GINO?  Where's that?  I just tried a search but ended up with a load of
> links to italian blokes (not suprisingly).
> 
> Winteracter is fortan, right?  Andromeda is meant to be a language
> indepedant standard with implementations in Ada and C to begin with.  

"implementations in Ada and C"...effectively tailored language bindings.

It is
> meant to ease the burden on OS developers should they choose to provide an
> implementation.  It's graphical component will be based upon OpenGL because
> a large variety of cards support OpenGL, making it easier on the developer
> (assuming (s)he can develop a driver for their OS, which is a different
> issue altogether).
> 
> Wait is GINO fortran-based too?  Some of the searches for GINO gui came up
> fortran.  That's no good, it's not language independant.  You'd have to
> write a binding for it.

It provides both C and Fortran APIs and there should be little or no
difficulty interfacing to Ada.  It's a product that is over 30 years
old.  Current versions are integrated with OPENGL. When asked, the
vendor indicated a willingness to provide Ada bindings, if only there
were a large enough business base to support it. 

Any API would need (or at least ideally provide) a language specific
binding.  That's a main problem with Win32. It's so C-centric, that you
must perform unnatural contortions to program in any other language.

> 
> The project was only mentioned because there's sure to be an experimental
> implementation for windows written in Ada (and one in C to see how well the
> rules work) before the objective is achieved.
> 
> Chris
> 
> p.s. is it sufficient for pragma Linker_Options ("ogl32.dll") to be added to
> the bindings supplied with Glut, to get it to work on windows?

Re: is Ada dying?

[John English]

"chris.danx" wrote:
> 
> "Ralph M�ritz" <ralph@work.co.za> wrote in message
> news:Xns9133DBAF0AD71ralphworkcoza@196.25.240.158...
> > I think that's sad, and now that
> > Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold
> > in store? Is it worthwhile learning a language nobody appreciates or uses?
> 
> They teach it at a few uni's now.  Don't know how if its uptake is more than
> before; might be interesting to find out.

Several have switched to Java. Reasons include lack of beginner's texts
(which are all out of print because the market is too small because no-one
teaches it anymore...) and, more importantly, lack of standard libraries
for GUI development, networking, and data collections. Although there
are plenty around, none of them are *standard*, so the perception is that
Ada can't do these things.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: is Ada dying?

[chris.danx]

"John English" <je@brighton.ac.uk> wrote in message
news:3BC30674.BA88AAB6@brighton.ac.uk...
> "chris.danx" wrote:
> >
> > "Ralph M�ritz" <ralph@work.co.za> wrote in message
> > news:Xns9133DBAF0AD71ralphworkcoza@196.25.240.158...
> > > I think that's sad, and now that
> > > Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future
hold
> > > in store? Is it worthwhile learning a language nobody appreciates or
uses?
> >
> > They teach it at a few uni's now.  Don't know how if its uptake is more
than
> > before; might be interesting to find out.
>
> Several have switched to Java.

I don't want to start another Ada vs. x barny* but I'd of thought Java is
not good enough yet to teach students even if it is popular (they teach Java
in the higher levels of the courses at our uni, though thankfully I'm
nowhere near that yet).  It's too immature.  I programmed in Java for a
while about 3 years ago (before Ada) and now I couldn't fathom it's
libraries (changing 1.1 from 1.2).  They keep changing everything and you
really need to devote yourself to it, which I don't think you can do for any
language when teaching it.  I mean if you teach them to use some classes
then you'll need to say to them "wait... the class has changed slightly (or
drastically)! now do this" if you intend them to have any chance of getting
a job.  This is exactly the reason why I choose not to program in Java
unless forced to do so.  It's not stable enough *yet* (and soon it won't
matter, with JGNAT and AppletMagic being available).

[ * Those barnies really annoy me.  What's the point in it all? Don't you
know it make's ppl look silly and put's ppl off you and possibly your
language? ]

>  Reasons include lack of beginner's texts
> (which are all out of print because the market is too small because no-one
> teaches it anymore...

Is that what happened to your book?  A bigger company swallowed your
publisher and decided it's a minority language in the class and so chose not
publish Ada intro books?  If so, that's not very nice at all.

The market for Ada books is wierd.  Last year our lecturer said that the
handout notes were actually part of a book a few of them had written about
Ada but they decided not to publish because the market for introductory
texts for Ada was saturated (too many books circulating already).  It's
interesting now that it's been deemed too small a market for intro texts.
Maybe that's what he meant, and I misunderstood him.

[
Have you thought about using JEWL in a book, John?  It seems that most ppl
nowadays think if it's not got some kind of GUI in it, then it's old and
useless.  JEWL is simple enough that it could be used in introductory Ada
courses/books to give it a better look (many uni's use NT for first year so
the current windows aimed implementation wouldn't really be a problem).  I
know that the CS department here used the Win32 binding that came with GNAT
to build a set of packages which displayed a room in which simple commands
to navigate the room full of obsticles.  They used this throughout the
introductory course (instead of the text based stuff) and switched to
AdaGraph for some more complex graphics work.  It looks like it worked a
treat (just going on some non-geek opinions -- ppl who've never done any
programming or CS before they hit the course).  JEWL is simple enough to use
to introduce Ada and yet complex enough for some more substantial topics.
Just a thought.
]

> ) and, more importantly, lack of standard libraries
> for GUI development, networking, and data collections. Although there
> are plenty around, none of them are *standard*, so the perception is that
> Ada can't do these things.

That's a real shame.  I don't know about networking or data collections
(don't use such things) for Ada but the GUI development tools for Ada are
real nice -- namely GtkAda and Gwindows.  [ The only problem I have with
them is they're tied to GNAT quite tightly or appear to be.  If a new
compiler comes a long at least one of those toolkits will need some porting,
until it does or develops alternatives I don't think it has any chance
against GNAT].

Do any of the aforementioned GUI technologies work with Aonix or do you have
to purchase CLAW or something?


Chris
--

p.s. please unconfuse me...  I like GNAT but it's license confuses me.  What
exactly does it allow of a developer?  While I'm not interested in
developing closed source apps, (I like open source too much) I don't really
know the stance of GNAT on this.  I know it's GPL-ish itself but what about
the apps you produce?  The same goes for GWindows, I think it's the same
license or similar?  Small companies might not be able to afford a
commercial GNAT license, so what does the public version allow?

I know it's slightly OT but it's important since I don't want to spread
misinformation or put my foot in it (so to speak).

p.p.s. Sorry for the long post, some of these issues and questions came up
when discussing the suggested need for a cheap alternative to GNAT.

Re: is Ada dying?

[Marin David Condic]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]

Well, its a fair criticism if other languages have some sort of de facto
"standard" library of GUI & system stuff that makes it more practical for
teaching and application implementation. Yes, lots of libraries exist but
that is, in a way, a negative. If there was just one dominant library - or
maybe one dominant library per platform - that provided the functionality
that people get from things like Java or the MFC, then it makes it easier to
develop teaching materials and applications that go beyond a CLI. That's a
non-trivial issue. It would help Ada a lot to have a library that did GUI
work & provided system services and was adopted by the vendors as the Right
Thing To Do. Throw in some interactive GUI builders & documentation and that
about covers the iorst hole.

Yes, the pieces are there - lots of different choices. No single dominant
technology though, so it makes things confusing to the uninitiate and hard
to target with value-added products.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"John English" <je@brighton.ac.uk> wrote in message
news:3BC30674.BA88AAB6@brighton.ac.uk...
> "chris.danx" wrote:
> >
> > "Ralph M�ritz" <ralph@work.co.za> wrote in message
> > news:Xns9133DBAF0AD71ralphworkcoza@196.25.240.158...
> > > I think that's sad, and now that
> > > Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future
hold
> > > in store? Is it worthwhile learning a language nobody appreciates or
uses?
> >
> > They teach it at a few uni's now.  Don't know how if its uptake is more
than
> > before; might be interesting to find out.
>
> Several have switched to Java. Reasons include lack of beginner's texts
> (which are all out of print because the market is too small because no-one
> teaches it anymore...) and, more importantly, lack of standard libraries
> for GUI development, networking, and data collections. Although there
> are plenty around, none of them are *standard*, so the perception is that
> Ada can't do these things.
>
> -----------------------------------------------------------------
>  John English              | mailto:je@brighton.ac.uk
>  Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
>  Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
>  University of Brighton    |    -- see http://burks.bton.ac.uk
> -----------------------------------------------------------------

Re: is Ada dying?

[Ehud Lamm]

John English <je@brighton.ac.uk> wrote in message
news:3BC30674.BA88AAB6@brighton.ac.uk...
> Several have switched to Java. Reasons include lack of beginner's texts
> (which are all out of print because the market is too small because no-one
> teaches it anymore...) and, more importantly, lack of standard libraries
> for GUI development, networking, and data collections. Although there
> are plenty around, none of them are *standard*, so the perception is that
> Ada can't do these things.

Not to mention that students want to learn Java, and are quite upset when
made to learn Ada ("Why should we learn Ada,  nobody is using it?!!")

I think that adding Collections to the standard library would be a big help.
I find it sad that when I want to explain what Collections are, I print
stuff from the Java docs ;-(

Ehud Lamm

Re: is Ada dying?

[webwarrior]

Ehud Lamm wrote:

> 
> John English <je@brighton.ac.uk> wrote in message
> news:3BC30674.BA88AAB6@brighton.ac.uk...
>> Several have switched to Java. Reasons include lack of beginner's texts
>> (which are all out of print because the market is too small because
>> no-one teaches it anymore...) and, more importantly, lack of standard
>> libraries for GUI development, networking, and data collections. Although
>> there are plenty around, none of them are *standard*, so the perception
>> is that Ada can't do these things.
> 
> Not to mention that students want to learn Java, and are quite upset when
> made to learn Ada ("Why should we learn Ada,  nobody is using it?!!")
> 
> I think that adding Collections to the standard library would be a big
> help. I find it sad that when I want to explain what Collections are, I
> print stuff from the Java docs ;-(
> 
> Ehud Lamm
> 
> 
> 
> 
computer science students still have to learn ada in their first year 
programming course at the swiss federal institute of technology. so ada 
doesn't seem to die too quickly ;-) and they really gave us looots of 
reasons why to learn ada and not java first
-- 
http://www.webwarrior.ch

Re: is Ada dying?

[Ehud Lamm]

<webwarrior@webwarrior.ch> wrote in message
news:9q42jo$lu8$1@news1.sunrise.ch...

> computer science students still have to learn ada in their first year
> programming course at the swiss federal institute of technology. so ada
> doesn't seem to die too quickly ;-) and they really gave us looots of
> reasons why to learn ada and not java first
> --


Good to hear.
I can think of many good reasons myself...
(In fact I even think that using Pascal is better than using Java as a first
language).

Ehud Lamm

Re: is Ada dying?

[John McCabe]

On Sat, 13 Oct 2001 12:36:29 +0200, "Ehud Lamm"
<mslamm@mscc.huji.ac.il> wrote:


>(In fact I even think that using Pascal is better than using Java as a first
>language).

Of course it is - Pascal was designed as a teaching language, Java
wasn't designed.

Re: is Ada dying?

[Robert*]

In article <3bca9c74.1660187@news.demon.co.uk>, john.mccabe@emrad.com.nospam
says...
> 

>
>Of course it is - Pascal was designed as a teaching language, Java
>wasn't designed.


hi John,

did you mean to cut off the sentense above as is, i.e. did you mean to
say that java was not designed, period, or that it was not designed
to be a teaching language?

I think that software is becomming a more component based, where 
most programmers know how to use those pieces of software as a black
box, and so many do not learn the more basic things in programming, 
like data structures and records (in Java, programmers do not even 
know what a record is :). These things are not learned well. Java 
programmers do not even know too well about enumeration and parameters 
passing mehanism, but know how to create an object or extend one and 
use an interface.

speaking of records. in true OO, the concept of a record does not exist
really. All what you have is an object, which contains attributes (state
information). So, I can sort of understand when a java programmer ask me
what is a record? 








 

Re: is Ada dying?

[John McCabe]

On 15 Oct 2001 03:24:09 -0700, Robert*@ <Robert_member@newsguy.com>
wrote:


>>Of course it is - Pascal was designed as a teaching language, Java
>>wasn't designed.

>did you mean to cut off the sentense above as is,

Yes

> i.e. did you mean to say that java was not designed, period, or that
> it was not designed to be a teaching language?

The former.

>I think that software is becomming a more component based, where 
>most programmers know how to use those pieces of software as a black
>box,

Admittedly that is something that is lacking in Pascal, i.e. the
concept of encapsulation which is more commonly associated with
separate compilation. Modula-2 may be a better example.

>and so many do not learn the more basic things in programming, 
>like data structures and records (in Java, programmers do not even 
>know what a record is :). These things are not learned well. Java 
>programmers do not even know too well about enumeration and parameters 
>passing mehanism, but know how to create an object or extend one and 
>use an interface.

Enumeration types are an almost mandatory feature of any language that
can claim to be safe but, even then, it depends on the implementation.
Ada's definition of Enumeration types, and their use as array and loop
bounds is excellent - the C++ version is vaguely useful, but not all
that good relying too much on history. The fact that Java does not
even have Enumeration types is, to me, a serious defect.

>speaking of records. in true OO, the concept of a record does not exist
>really. All what you have is an object, which contains attributes (state
>information). So, I can sort of understand when a java programmer ask me
>what is a record? 

I can understand that and, often, a record can be replaced by a Class
with no behavioural aspects (i.e. no methods). The problem is that the
overhead (possibly just in syntax) of a class can be a nuisance and
confuse the issue and, certainly in Java, there is no way to define
the representation of elements in a Class (unlike Ada with its very
powerful representation clauses). To me this shows a great difference
in the target audience of the languages, and their history.

Re: is Ada dying?

[Robert*]

In article <3bcb08bc.29380186@news.demon.co.uk>, john.mccabe@emrad.com.nospam
says...
 

>I can understand that and, often, a record can be replaced by a Class
>with no behavioural aspects (i.e. no methods). The problem is that the
>overhead (possibly just in syntax) of a class can be a nuisance and
>confuse the issue and, certainly in Java, there is no way to define
>the representation of elements in a Class (unlike Ada with its very
>powerful representation clauses). To me this shows a great difference
>in the target audience of the languages, and their history.


yes. In Java, if you have an empty class it will have a size of 24 bytes.
a class which has nothing but an 'int' in it, is 32 bytes. A class with
nothing in it but one String reference (null) is 50 bytes. So an 
object ref byitself uses 26 bytes overhead.

So, you see, Java add a 'tag' information next to each field in the class
(this is used by the reflection facility of the language, i.e. there is
a field in the class that describes each other field). This tag field can
be 4 bytes byitself (per field, for primitive fields) or more for class
reference fields. (you need more info to describe a class than a primitive
field).

so it is clear you can't use Java as is to map it to a C or Ada type
struct or record  becuase of this overhead. 

that is why Java has serialization as a way to write the object out to disk
and read it back and reconstruct it in memory as it was. Serliazation is
also used to ship the object as is over the network as stream of bytes, and
deserliazed on the other end to reconstruct it.

This also ofcourse means that Java use for same sort of applications where
ada representation clause is needed will be not practical to say the
least, but I do not see Java being used for those types of applications
(java programmers will look funny at you if you start talking about
representation of records and stuff like this).

Re: is Ada dying?

[minyard]

Robert*@ <Robert_member@newsguy.com> writes:

> In article <3bcb08bc.29380186@news.demon.co.uk>, john.mccabe@emrad.com.nospam
> says...
>  
> 
> >I can understand that and, often, a record can be replaced by a Class
> >with no behavioural aspects (i.e. no methods). The problem is that the
> >overhead (possibly just in syntax) of a class can be a nuisance and
> >confuse the issue and, certainly in Java, there is no way to define
> >the representation of elements in a Class (unlike Ada with its very
> >powerful representation clauses). To me this shows a great difference
> >in the target audience of the languages, and their history.
> 
> 
> yes. In Java, if you have an empty class it will have a size of 24 bytes.
> a class which has nothing but an 'int' in it, is 32 bytes. A class with
> nothing in it but one String reference (null) is 50 bytes. So an 
> object ref byitself uses 26 bytes overhead.

This is implementation and processor dependent.  I assume you are
talking about some specific version of Sun's JVM.  I'm also not sure
how you measured this, but some measurement techniques can be quite
inaccurate (as the first time you allocate something it may allocate
other stuff, there is sometimes varying GC overhead, etc.).

In GCJ, with the most current version, object overhead is one pointer.
That's probably the best you can do.  It also happens to lay this out
exactly like a C++ class, and method calls between C++ and Java (both
directions) can be done directly.

> This also ofcourse means that Java use for same sort of applications where
> ada representation clause is needed will be not practical to say the
> least, but I do not see Java being used for those types of applications
> (java programmers will look funny at you if you start talking about
> representation of records and stuff like this).

The design goals of Java were diametrically opposed to any type of
representation clause, since it was designed for extreme portability
and for security.  Saying Java wasn't designed is a little over the
top.  It wasn't formally designed in an open process, but the
designers definately had design goals, wrote them down, and debated
them.  You may not like their process or goals, but it was designed.
For instance, they had a definate reason (that was debated by the
designers) for not including an enumeration type - lack of
extensibility in subclasses.

-Corey

Re: is Ada dying?

[Wes Groleau]

minyard@acm.org wrote:
> 
> Robert*@ <Robert_member@newsguy.com> writes:
> > yes. In Java, if you have an empty class it will have a size of 24 bytes.
> > a class which has nothing but an 'int' in it, is 32 bytes. A class with
> > nothing in it but one String reference (null) is 50 bytes. So an
> > object ref byitself uses 26 bytes overhead.
> 
> This is implementation and processor dependent.  I assume you are
> talking about some specific version of Sun's JVM.  I'm also not sure

The class file format for different JVMs is different?  I don't think
so.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: is Ada dying?

[minyard]

Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> writes:

> minyard@acm.org wrote:
> > 
> > Robert*@ <Robert_member@newsguy.com> writes:
> > > yes. In Java, if you have an empty class it will have a size of 24 bytes.
> > > a class which has nothing but an 'int' in it, is 32 bytes. A class with
> > > nothing in it but one String reference (null) is 50 bytes. So an
> > > object ref byitself uses 26 bytes overhead.
> > 
> > This is implementation and processor dependent.  I assume you are
> > talking about some specific version of Sun's JVM.  I'm also not sure
> 
> The class file format for different JVMs is different?  I don't think
> so.

The class file format has nothing to do with the internal
representation of the data.  That's one of the major design goals of
Java.  It obviously can't take less space than the actual data, but
that's not the case here.  The 24 bytes of overhead (on a 32-bit
processor) in a Sun JVM is, I believe:

  1) A reference to the object's class
  2) A piece of synchronization data
  3) A piece of data for finalization

None of that need be part of the class data itself.  In the newest
versions of GCJ, 2) and 3) above are kept in hash tables and not
directly in the object.  It would be hard to extract 1) from the
object; that's why I said the minimum overhead for an object is a
single pointer.

Plus, the JVM is free to follow whatever packing or organization rules
it wants.  It can pack the data backwards from declaration, align it
any way it likes, keep it in multiple separate pieces of data, or
whatever.

-Corey

Re: is Ada dying?

[John McCabe]

On 15 Oct 2001 13:03:22 -0700, Robert*@ <Robert_member@newsguy.com>
wrote:

>This also ofcourse means that Java use for same sort of applications where
>ada representation clause is needed will be not practical to say the
>least, but I do not see Java being used for those types of applications
>(java programmers will look funny at you if you start talking about
>representation of records and stuff like this).

I've tried using it that way, and it is pretty impractical!

Re: is Ada dying?

[Wes Groleau]

"Robert*@" wrote:
> information). So, I can sort of understand when a java programmer ask me
> what is a record?

I answer, "It's a class with no methods."  :-)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: is Ada dying?

[Ted Dennison]

In article <3BCB3C54.BD79160C@sparc01.ftw.rsc.raytheon.com>, Wes Groleau says...
>
>
>
>"Robert*@" wrote:
>> information). So, I can sort of understand when a java programmer ask me
>> what is a record?
>
>I answer, "It's a class with no methods."  :-)

No *dispatching* methods, perhaps.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Israel Raj T]

On 15 Oct 2001 03:24:09 -0700, Robert*@ <Robert_member@newsguy.com>
wrote:

>In article <3bca9c74.1660187@news.demon.co.uk>, john.mccabe@emrad.com.nospam
>>Of course it is - Pascal was designed as a teaching language, Java
>>wasn't designed.

Most of the better comp.sci courses use a functional ( haskell  or ml
at Cambridge and Oxford ) or semifunctional ( scheme at mit) as a
first language for their undergraduates.

 However, Stanford ( perhaps the best practical comp.sci dept in the
world ) seem to use a mixture of c++ , java and c.

Re: is Ada dying?

[John McCabe]

On Wed, 17 Oct 2001 15:05:15 GMT, Israel Raj T
<israelrt@optushome.com.au> wrote:

>On 15 Oct 2001 03:24:09 -0700, Robert*@ <Robert_member@newsguy.com>
>wrote:
>
>>In article <3bca9c74.1660187@news.demon.co.uk>, john.mccabe@emrad.com.nospam
>>>Of course it is - Pascal was designed as a teaching language, Java
>>>wasn't designed.
>
>Most of the better comp.sci courses use a functional ( haskell  or ml
>at Cambridge and Oxford ) or semifunctional ( scheme at mit) as a
>first language for their undergraduates.
>
> However, Stanford ( perhaps the best practical comp.sci dept in the
>world ) seem to use a mixture of c++ , java and c.
>

I thought both ml and scheme were AI type languages. I remember that
Brunel in West London taught ml as part of the AI module of a Digital
Systems MSc. Scheme I thought was a similar concept to Lisp, which is
often touted as AI based.

Re: is Ada dying?

[Brian Rogoff]

On Wed, 17 Oct 2001, John McCabe wrote:
> On Wed, 17 Oct 2001 15:05:15 GMT, Israel Raj T
> <israelrt@optushome.com.au> wrote:
> >On 15 Oct 2001 03:24:09 -0700, Robert*@ <Robert_member@newsguy.com>
> >wrote:
> >>In article <3bca9c74.1660187@news.demon.co.uk>, john.mccabe@emrad.com.nospam
> >>>Of course it is - Pascal was designed as a teaching language, Java
> >>>wasn't designed.
> >
> >Most of the better comp.sci courses use a functional ( haskell  or ml
> >at Cambridge and Oxford ) or semifunctional ( scheme at mit) as a
> >first language for their undergraduates.
> >
> > However, Stanford ( perhaps the best practical comp.sci dept in the
> >world )

Perhaps it isn't "the best practical comp.sci dept in the world".

> > seem to use a mixture of c++ , java and c.

When I was there the programming languages course was focused on ML. It is
true that C/C++ were used heavily in computer graphics and OS courses, and
Fortran was still widely used in scientific computing and engineering.

> I thought both ml and scheme were AI type languages.

What is an "AI type language"? Is Ada a "guided missile type language"?
Errr, no pejorative intended in the latter, I'm a big fan of advanced
weapons.

Scheme is a dialect of Lisp developed at MIT. It's original claim to fame
is that it uses lexical scoping instead of that horrible dynamic scoping
from the original Lisps (which still survives in elisp BTW). Nowadays,
there are a ton of different variants of Scheme since the core language is
too small to be widely useful, but Scheme is used quite widely outside of
the AI field.

ML was originally the meta-language of a theorem prover developed by Robin
Milner (so it can stand for either Meta-Language or Milner's Language :)
and it's claim to fame is it's static type system. In contrast to Ada,
ML style static typing doesn't require much explicit annotation (ideally
none!) and the typing algorithm just figures out the type of a program
fragment; so you get many of the perceived benefits of both static and
dynamic typing. Later, ML got a very nice module system which should make
Ada refugees happy.

Nowadays there are two main dialects of ML: SML and OCaml. They are used
widely outside of AI too, but the focus appears to be on "compiler like"
programs. I use and like OCaml quite a bit.

-- Brian

Re: is Ada dying?

[Larry Kilgallen]

In article <20011017103412.E21205-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes:

> What is an "AI type language"? Is Ada a "guided missile type language"?

Actually, Ada programs are _less_ likely to blow up in operation.

Re: is Ada dying?

[Marin David Condic]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:NkWNOzXpm2c8@eisner.encompasserve.org...
> In article <20011017103412.E21205-100000@shell5.ba.best.com>, Brian Rogoff
<bpr@shell5.ba.best.com> writes:
>
> > What is an "AI type language"? Is Ada a "guided missile type language"?
>
> Actually, Ada programs are _less_ likely to blow up in operation.

But if it is a "guided missile type" project, not blowing up would be a
failure! :-)

Q: What is the difference between C++ programmers and Ada programmers?

A: Ada programmers write code that blows up *on*purpose*.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Pat Rogers]

"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9pvv3t$ves$1@news.huji.ac.il...

<snip>

> I think that adding Collections to the standard library would be a big
help.
> I find it sad that when I want to explain what Collections are, I print
> stuff from the Java docs ;-(

This is an issue that has troubled me for some time.

Many of us have developed libraries of reusable components over the years.
It is a great way to learn a language.  We all have things we like about
them.  Some are extensive and well done.  However, we would all clearly
benefit by agreeing to make one of them the de facto standard.  (Formal
standardization is desirable too, IMHO.)

I propose the Booch Components be that standard.  If there is a better suite
I haven't seen it and I've seen many of them.  However, there may very well
be a better collection of components.  Let's discuss them.

Whatever we choose, an incomplete list of steps required include:

    Start using them instead of our individual in-house favorites.  That's
the hard part.

    Have a community-wide decision to adopt them, so that the above can
happen.  Unless a significant number of people publicly agree to adopt them
there will be few individuals willing to make the change.


Thoughts?

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: why not

[Ted Dennison]

In article <Bggx7.314$KN5.148429887@newssvr11.news.prodigy.com>, Pat Rogers
says...
>
>I propose the Booch Components be that standard.  If there is a better suite
>I haven't seen it and I've seen many of them.  However, there may very well
>be a better collection of components.  Let's discuss them.

I agree with the need, and the Booch Components are probably the best available
starting point. My first thought was to make this exact same post. However, the
current implementation of Booch has not really been designed with real-time
needs in mind. For instance, many of the "bounded" structures, which one would
naievely assume don't perform dynamic allocations, do in fact perform dynamic
allocations, sometimes even during lookups.

The STL does seem to have been designed with a fair bit of thought into being
implementable in real-time environements (using the appropriate structures of
course). I'd like to see at least that same level of thought go into anything
which we would enshrine into the Ada standard.

I don't mean to rag on the current Booch maintainer. We all should be thankful
that someone signed up to do the job, and he has been doing a good one.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[minyard]

Ted Dennison<dennison@telepath.com> writes:

> In article <Bggx7.314$KN5.148429887@newssvr11.news.prodigy.com>, Pat Rogers
> says...
> >
> >I propose the Booch Components be that standard.  If there is a better suite
> >I haven't seen it and I've seen many of them.  However, there may very well
> >be a better collection of components.  Let's discuss them.
> 
> I agree with the need, and the Booch Components are probably the best available
> starting point. My first thought was to make this exact same post. However, the
> current implementation of Booch has not really been designed with real-time
> needs in mind. For instance, many of the "bounded" structures, which one would
> naievely assume don't perform dynamic allocations, do in fact perform dynamic
> allocations, sometimes even during lookups.

Have you looked at my set of components?  It's at http://adasl.sf.net.
I was pretty careful to not do do heap stuff in my bounded containers,
and all the containers have storage-managed versions.

I'd be interested to hear what people thought of it; I'm pretty sure
that people use it but I haven't gotten much feedback on it.

-Corey

Re: why not

[Marc A. Criley]

minyard@acm.org wrote:
> 
> Ted Dennison<dennison@telepath.com> writes:
> 
> > In article <Bggx7.314$KN5.148429887@newssvr11.news.prodigy.com>, Pat Rogers
> > says...
> > >
> > >I propose the Booch Components be that standard.  If there is a better suite
> > >I haven't seen it and I've seen many of them.  However, there may very well
> > >be a better collection of components.  Let's discuss them.
> >
> > I agree with the need, and the Booch Components are probably the best available
> > starting point. My first thought was to make this exact same post. However, the
> > current implementation of Booch has not really been designed with real-time
> > needs in mind. For instance, many of the "bounded" structures, which one would
> > naievely assume don't perform dynamic allocations, do in fact perform dynamic
> > allocations, sometimes even during lookups.
> 
> Have you looked at my set of components?  It's at http://adasl.sf.net.
> I was pretty careful to not do do heap stuff in my bounded containers,
> and all the containers have storage-managed versions.
> 
> I'd be interested to hear what people thought of it; I'm pretty sure
> that people use it but I haven't gotten much feedback on it.

Here's some feedback:  I use the ASL components exclusively in all the
Ada software I write for myself, I brought them into a Lockheed Martin
system on which I worked for awhile, and you can be assured they'll be
showing up in another product that will be started in the near future.

Can't say enough good things about Corey's work :-)

I have no problem with the Booch components, and extensively used the
Ada 83 versions at Link Flight Simulation.  The long gestation period of
the Ada 95 versions is why I went looking elsewhere--I needed components
and the specific Booch components weren't available at that time, so I
found and went with the ASL.

Been a satisfied user ever since.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: why not

[Ted Dennison]

In article <m3n12y17do.fsf@wf-rch.cirr.com>, minyard@acm.org says...
>Have you looked at my set of components?  It's at http://adasl.sf.net.
>I was pretty careful to not do do heap stuff in my bounded containers,
>and all the containers have storage-managed versions.

I think I looked at it about 3 years ago, but not since. I'm sure its much
better now.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Harri J Haataja]

minyard@acm.org wrote:
>
>Have you looked at my set of components?  It's at http://adasl.sf.net.
>I was pretty careful to not do do heap stuff in my bounded containers,
>and all the containers have storage-managed versions.
>
>I'd be interested to hear what people thought of it; I'm pretty sure
>that people use it but I haven't gotten much feedback on it.

It doesn't seem to appear on freshmeat.net which is The place most
people go to find Free software (and more). A lot of people dont want to
wade though all those planning-stage or dead projects that populate
sf.net.

It always seems strange to me when people ask "Where can I find a
compiler" or something like that. If there's a big enough Free one,
that's where it'll be. It wouldn't hurt adding it (or anything you can
get in there you've written in ADA ofcourse).

-- 
Seagoon: Will my aeroplane need a hangar?
Crun:    It'd lose its shape hanging on a nail, you know.
	-- T.A.Milligan & L.Stephens 10 Jan 1957

Re: why not

[Harri J Haataja]

Harri J Haataja wrote:
>minyard@acm.org wrote:
>>Have you looked at my set of components?  It's at http://adasl.sf.net.
>>I was pretty careful to not do do heap stuff in my bounded containers,
>>and all the containers have storage-managed versions.
>>
>>I'd be interested to hear what people thought of it; I'm pretty sure
>>that people use it but I haven't gotten much feedback on it.
>
>It doesn't seem to appear on freshmeat.net which is The place most
>people go to find Free software (and more). A lot of people dont want to
>wade though all those planning-stage or dead projects that populate
>sf.net.
>
>It always seems strange to me when people ask "Where can I find a
>compiler" or something like that. If there's a big enough Free one,
>that's where it'll be. It wouldn't hurt adding it (or anything you can
>get in there you've written in ADA ofcourse).

Damn, it seems my shift is a BIT sticky ;)

-- 
Seagoon: Will my aeroplane need a hangar?
Crun:    It'd lose its shape hanging on a nail, you know.
	-- T.A.Milligan & L.Stephens 10 Jan 1957

Re: why not

[Simon Wright]

Ted Dennison<dennison@telepath.com> writes:

> I agree with the need, and the Booch Components are probably the
> best available starting point. My first thought was to make this
> exact same post. However, the current implementation of Booch has
> not really been designed with real-time needs in mind. For instance,
> many of the "bounded" structures, which one would naievely assume
> don't perform dynamic allocations, do in fact perform dynamic
> allocations, sometimes even during lookups.

Since I'm currently engaged in a real (VxWorks) project which is
hoping to use the BCs, I've come to appreciate Ted's point. The
present release does no dynamic allocations at all for bounded
structures (well, if it does, it's a bug).

Re: why not

[Ted Dennison]

In article <x7vk7y1j4p9.fsf@smaug.pushface.org>, Simon Wright says...
>
>hoping to use the BCs, I've come to appreciate Ted's point. The
>present release does no dynamic allocations at all for bounded
>structures (well, if it does, it's a bug).

I'm very glad to hear that. The proper attitude is far more important than
whether its perfect yet. 

I'd say it'd also be nice if there were no "suprise" dynamic allocations in the
unbounded ones either (eg: during lookups). That would allow for use in
situations where heap manipulation is OK during startup and shutdown, but not
during runtime. But getting the bounded ones clean is more important.

My main concern for a standard Ada component library is that it be carefully
designed so that as much of it as possible is usable in real-time apps, without
sacrificing capability that would be useful for other apps.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Simon Wright]

Ted Dennison<dennison@telepath.com> writes:

> I'd say it'd also be nice if there were no "suprise" dynamic
> allocations in the unbounded ones either (eg: during lookups). That
> would allow for use in situations where heap manipulation is OK
> during startup and shutdown, but not during runtime. But getting the
> bounded ones clean is more important.

If by "lookup" you mean "iteration" then I took your message on board
about that as well. Iterators used to use heap allocation with
reference counting; now they're all allocated on the stack.

This did involve a rather repellent conversion to allow a function to
convert the address of a (tagged) container parameter to a
pointer-to-writable-container. Down and dirty in the private
part. And, if I remember right, one of the problems that stopped the
BCs compiling with JGNAT ..

Re: why not

[Ted Dennison]

In article <x7vitdkhvge.fsf@smaug.pushface.org>, Simon Wright says...
>
>This did involve a rather repellent conversion to allow a function to
>convert the address of a (tagged) container parameter to a
>pointer-to-writable-container. Down and dirty in the private
>part. And, if I remember right, one of the problems that stopped the
>BCs compiling with JGNAT ..

Well, that's probably understandable since in Java practicly everything (or
nothing, depending on how you look at it) is a pointer. Trying to avoid heap
allocations in that environment is almost missing the point.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

I looked over the Booch Components several years ago and have not revisited
them since. Perhaps they have evolved some since then so my comments may not
be appropriate.

One big weakness I found in them was a general lack of documentation. If
*any* set of data-structury-ADT-ish stuff is to be adopted as a de-facto
standard (presumably, tacked on with compiler distributions, etc.) it would
need some documentation that explains the behavior and proper use of the
classes/packages. You can't dump a library on a newbie and say "Here: Read
the code and figure it out for yourself..." It need not be a textbook, but
some minimal level of a user's manual needs to be there.

Demo/Test programs - it had some when I looked it over. I thought they could
stand to be a little more thorough and possibly illustrative of proper
usage - build a document that hyperlinks to example & test code?

It ought to be noted that something like the Booch components are not going
to be suitable for all applications. If they rely on dynamic memory, they
may be unsuitable for any sort of realtime work. If they rely on fixed
memory, they may not be suitable for very dynamic workstation apps. If they
provide both implementations, they may be "too big" and/or offer too many
choices to the user. IOW, they cannot be all things to all users and hence
it should be clear as to what the intended usage is.

One thing that may be important is to consider how they might be extended to
include new features should the need become apparent. Could this serve as
the basis for a more general library of components rather than just a
data-structure library? (Bundle into it things like an OS interface, network
support, math libraries, etc.?)

Also, one of the things I found very useful in the MFC was the ability to
"serialize" an object. The same thing is possible in Ada95 with streams. It
would be A Good Thing if the Booch components provided Load/Store operations
from/to a Stream file.

Licensing is another issue. Some people love the GPL, but others may not
want to contaminate their code with that. What license is the Booch
Components currently under and does it allow unfettered use in everything
from "Open Source" (whatever that means currently) to totally proprietary -
maybe even classified - applications?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:Bggx7.314$KN5.148429887@newssvr11.news.prodigy.com...
> "Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
> news:9pvv3t$ves$1@news.huji.ac.il...
>
> <snip>
>
> > I think that adding Collections to the standard library would be a big
> help.
> > I find it sad that when I want to explain what Collections are, I print
> > stuff from the Java docs ;-(
>
> This is an issue that has troubled me for some time.
>
> Many of us have developed libraries of reusable components over the years.
> It is a great way to learn a language.  We all have things we like about
> them.  Some are extensive and well done.  However, we would all clearly
> benefit by agreeing to make one of them the de facto standard.  (Formal
> standardization is desirable too, IMHO.)
>
> I propose the Booch Components be that standard.  If there is a better
suite
> I haven't seen it and I've seen many of them.  However, there may very
well
> be a better collection of components.  Let's discuss them.
>
> Whatever we choose, an incomplete list of steps required include:
>
>     Start using them instead of our individual in-house favorites.  That's
> the hard part.
>
>     Have a community-wide decision to adopt them, so that the above can
> happen.  Unless a significant number of people publicly agree to adopt
them
> there will be few individuals willing to make the change.
>
>
> Thoughts?
>
> ---
> Patrick Rogers                       Consulting and Training in:
> http://www.classwide.com          Real-Time/OO Languages
> progers@classwide.com               Hard Deadline Schedulability Analysis
> (281)648-3165                                 Software Fault Tolerance
>
>

Re: why not

[Ted Dennison]

In article <9q49fc$nh3$1@nh.pace.co.uk>, Marin David Condic says...
>It ought to be noted that something like the Booch components are not going
>to be suitable for all applications. If they rely on dynamic memory, they
>may be unsuitable for any sort of realtime work. If they rely on fixed
>memory, they may not be suitable for very dynamic workstation apps. If they

They actually provide both. For each container there's a "bounded" and an
"unbounded" version. However, I found to my dismay that the algorithms for
dealing with the "bounded" versions are not always heap-free.

>include new features should the need become apparent. Could this serve as
>the basis for a more general library of components rather than just a
>data-structure library? (Bundle into it things like an OS interface, network

Booch is intended to be a container library. Nothing more, nothing less.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:_gix7.24513$ev2.32605@www.newsranger.com...
> In article <9q49fc$nh3$1@nh.pace.co.uk>, Marin David Condic says...
> >It ought to be noted that something like the Booch components are not
going
> >to be suitable for all applications. If they rely on dynamic memory, they
> >may be unsuitable for any sort of realtime work. If they rely on fixed
> >memory, they may not be suitable for very dynamic workstation apps. If
they
>
> They actually provide both. For each container there's a "bounded" and an
> "unbounded" version. However, I found to my dismay that the algorithms for
> dealing with the "bounded" versions are not always heap-free.

Can you be more specific?  Which one(s)?  For example I just looked at the
bounded queue package and don't see any.  A quick "grep" shows none for the
bounded components but it was quick-and-dirty.

Re: why not

[Ted Dennison]

In article <b9ix7.322$xi.158479523@newssvr11.news.prodigy.com>, Pat Rogers
says...
>
>Can you be more specific?  Which one(s)?  For example I just looked at the
>bounded queue package and don't see any.  A quick "grep" shows none for the
>bounded components but it was quick-and-dirty.

I had trouble with iterators inside of maps dynamicly creating and destroying
objects during an iteration of the map a couple of years ago. I fixed(hacked) it
myself for the bounded map I was using and dully submitted my changes to Simon
for consideration. Its only a guess that some of the other bounded structures do
the same thing, but I know I only looked at (and submitted a fix for) the
bounded maps. Personally I don't think I'd trust it again in real-time without a
careful examination of the source code for all the calls I plan on using (which
can get quite hairy, considering we are talking about multilevel generic
instantiations, with other generics as paramters).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:13jx7.24593$ev2.33014@www.newsranger.com...
> In article <b9ix7.322$xi.158479523@newssvr11.news.prodigy.com>, Pat Rogers
> says...
> >
> >Can you be more specific?  Which one(s)?  For example I just looked at
the
> >bounded queue package and don't see any.  A quick "grep" shows none for
the
> >bounded components but it was quick-and-dirty.
>
> I had trouble with iterators inside of maps dynamicly creating and
destroying
> objects during an iteration of the map a couple of years ago. I
fixed(hacked) it
> myself for the bounded map I was using and dully submitted my changes to
Simon
> for consideration. Its only a guess that some of the other bounded
structures do
> the same thing, but I know I only looked at (and submitted a fix for) the
> bounded maps.

OK, thanks for the pointer (no pun intended:).

> Personally I don't think I'd trust it again in real-time without a
> careful examination of the source code for all the calls I plan on using
(which
> can get quite hairy, considering we are talking about multilevel generic
> instantiations, with other generics as paramters).

For real-time apps that's good advice for any reusable library.

Re: why not

[Ted Dennison]

In article <OQix7.333$hz1.163695682@newssvr11.news.prodigy.com>, Pat Rogers
says...
>
>> Personally I don't think I'd trust it again in real-time without a
>> careful examination of the source code for all the calls I plan on using
>(which
>> can get quite hairy, considering we are talking about multilevel generic
>> instantiations, with other generics as paramters).
>
>For real-time apps that's good advice for any reusable library.

True, and the fact that the sources are available and compiled along with
everything else makes this much easier than it is with many other facilities.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Marin David Condic]

Well, yes. But is it laid out in such a way that one could start hanging
different branches off of it that served different functions? IOW, if it is
rooted at some package, could other packages be hung below the root to do
things like, say, OS services? And would those OS Services be able to take
advantage of the Booch containers as needed?

I'm just thinking of future expansions that might be desirable. I'm not
looking to change the Booch Components themselves - other than possibly
whatever structural layout might be needed to make room for other things
under the same umbrella.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:_gix7.24513$ev2.32605@www.newsranger.com...
> Booch is intended to be a container library. Nothing more, nothing less.

Re: why not

[Ted Dennison]

In article <9q4cdj$ouf$1@nh.pace.co.uk>, Marin David Condic says...
>
>Well, yes. But is it laid out in such a way that one could start hanging
>different branches off of it that served different functions? IOW, if it is
>rooted at some package, could other packages be hung below the root to do
>things like, say, OS services? And would those OS Services be able to take
>advantage of the Booch containers as needed?

They are generics, so I would think the best and proper way to make use of them
from an OS Services library would be to put that library in its own package
hierarchy and simply instantiate the appropriate containers when needed.

They use a particular style where generic packages are often children of other
generic packages so that one has to instantiate the parent and then instantiate
the child off of the parent (sometimes with other generics packages "mixed in"
as generic parameters). I'd think you'd want to keep them together as a unit,
and put any other non-component packages in another (perhaps sibling) package
hierarchy.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9q49fc$nh3$1@nh.pace.co.uk...
> I looked over the Booch Components several years ago and have not
revisited
> them since. Perhaps they have evolved some since then so my comments may
not
> be appropriate.

Quite a lot of work has been done (by Simon) over the years.  (That is an
understatement!)

> One big weakness I found in them was a general lack of documentation. If
> *any* set of data-structury-ADT-ish stuff is to be adopted as a de-facto
> standard (presumably, tacked on with compiler distributions, etc.) it
would
> need some documentation that explains the behavior and proper use of the
> classes/packages. You can't dump a library on a newbie and say "Here: Read
> the code and figure it out for yourself..." It need not be a textbook, but
> some minimal level of a user's manual needs to be there.

Absolutely agree.


> Demo/Test programs - it had some when I looked it over. I thought they
could
> stand to be a little more thorough and possibly illustrative of proper
> usage - build a document that hyperlinks to example & test code?

Sure.

> It ought to be noted that something like the Booch components are not
going
> to be suitable for all applications. If they rely on dynamic memory, they
> may be unsuitable for any sort of realtime work. If they rely on fixed
> memory, they may not be suitable for very dynamic workstation apps. If
they
> provide both implementations, they may be "too big" and/or offer too many
> choices to the user. IOW, they cannot be all things to all users and hence
> it should be clear as to what the intended usage is.

Yes, that's true, but at least the storage management is an explicit part of
the abstraction when allocations are involved -- one has to specify the pool
to instantiate those components.  For predictable storage allocation one
would use, for example, a fixed-block pool.  Barnes' book has one, and I
show one in my Real-Time Ada course, so they aren't hard to get.  Better yet
would be to add it to the existing BC pool managers already available.  I'll
see if Simon is open to that.


> One thing that may be important is to consider how they might be extended
to
> include new features should the need become apparent. Could this serve as
> the basis for a more general library of components rather than just a
> data-structure library? (Bundle into it things like an OS interface,
network
> support, math libraries, etc.?)

I would think it should be a separate part of an overall library.  For now,
standardizing on a collections library would be a *big* step forward.

> Also, one of the things I found very useful in the MFC was the ability to
> "serialize" an object. The same thing is possible in Ada95 with streams.
It
> would be A Good Thing if the Booch components provided Load/Store
operations
> from/to a Stream file.

That's the kind of thing I would hope to see added (along with
documentation, for example) once the components become widely adopted and
available for extension by the general community.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: why not

[Ted Dennison]

In article <dhix7.325$0w.159342742@newssvr11.news.prodigy.com>, Pat Rogers
says...
>> One big weakness I found in them was a general lack of documentation. If
>> *any* set of data-structury-ADT-ish stuff is to be adopted as a de-facto
>> standard (presumably, tacked on with compiler distributions, etc.) it
>Absolutely agree.

I believe he has recently added some documentation and examples. I was asked to
look it over, since I had suggested this was a deficiency in the past, but
haven't been able to find the time to do so. I'm sure he'd love to have some
constructive criticism and/or help in this matter.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Simon Wright]

"Pat Rogers" <progers@classwide.com> writes:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9q49fc$nh3$1@nh.pace.co.uk...

> > It ought to be noted that something like the Booch components are not going
> > to be suitable for all applications. If they rely on dynamic memory, they
> > may be unsuitable for any sort of realtime work. If they rely on fixed
> > memory, they may not be suitable for very dynamic workstation apps. If they
> > provide both implementations, they may be "too big" and/or offer too many
> > choices to the user. IOW, they cannot be all things to all users and hence
> > it should be clear as to what the intended usage is.
> 
> Yes, that's true, but at least the storage management is an explicit
> part of the abstraction when allocations are involved -- one has to
> specify the pool to instantiate those components.  For predictable
> storage allocation one would use, for example, a fixed-block pool.
> Barnes' book has one, and I show one in my Real-Time Ada course, so
> they aren't hard to get.  Better yet would be to add it to the
> existing BC pool managers already available.  I'll see if Simon is
> open to that.

Absolutely.

I managed to find some pathological allocation patterns with the Pool
that Pat contrbuted to the BCs recently, things like removing every
other element, so as ever one would have to look at the actual
requirement.

The BCs have a middle form (Dynamic) between the two extrmenes
mentioned so far (Bounded & Unbounded), as ever performance varies
with usage (and I think I've not actually implemented the C++
faithfully here; but since this form looks like a poor person's
Storage Pool, perhaps I won't worry too much).

The next release of the BCs will use Storage Pools like

   generic
      Storage : in out System.Storage_Pools.Root_Storage_Pool'Class;
   package BC.Containers.Collections.Unbounded is

so really you can use any storage pool you like.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Robert*]

In article <9q49fc$nh3$1@nh.pace.co.uk>, "Marin says...
>
 
>One big weakness I found in them was a general lack of documentation.

is the book about booch components in Ada not usefull for this? I do not
have the book in front me, but it could be this one, but not sure:


Software Components With Ada : Structures, Tools, and Subsystems (The
Benjamin/Cummings Series in Ada and Software Engineering)
by Grady Booch

it is a black cover one, and it describes in details all of booch components
with code (ada83).

I have it somewhere.


 

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

I was thinking along the lines where there were some sort of hypertext
document that let you click on a package name & get a description of what it
does, how to use it (in a general sense) and see links to documentation to
specific subprograms, etc. Something that could be used as a reference &
user's manual for this specific implementation of the Booch Components. I
don't think that Grady Booch's original book documents this specific
realization of the components since the book came first. (IOW, names may
have changed some, features added, etc. You really need a document that is
updated as the code changes over time.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Robert*@" <Robert_member@newsguy.com> wrote in message
news:9q4dnk017fg@drn.newsguy.com...
> In article <9q49fc$nh3$1@nh.pace.co.uk>, "Marin says...
> >
>
> >One big weakness I found in them was a general lack of documentation.
>
> is the book about booch components in Ada not usefull for this? I do not
> have the book in front me, but it could be this one, but not sure:
>
>
> Software Components With Ada : Structures, Tools, and Subsystems (The
> Benjamin/Cummings Series in Ada and Software Engineering)
> by Grady Booch
>
> it is a black cover one, and it describes in details all of booch
components
> with code (ada83).
>
> I have it somewhere.
>
>
>
>

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9q4fr6$qj5$1@nh.pace.co.uk...
> I was thinking along the lines where there were some sort of hypertext
> document that let you click on a package name & get a description of what
it
> does, how to use it (in a general sense) and see links to documentation to
> specific subprograms, etc. Something that could be used as a reference &
> user's manual for this specific implementation of the Booch Components.

Sounds good.

> I don't think that Grady Booch's original book documents this specific
> realization of the components since the book came first. (IOW, names may
> have changed some, features added, etc. You really need a document that is
> updated as the code changes over time.)

The Ada 95 version has a very different design.  It is more like the C++
version. One of the things that always galled me was that the C++ bigots
derided Ada by claiming that the C++ version was so much better (smaller,
etc.) because C++ was a better language -- when in fact it had a different
architecture (based in part on lessons learned from the Ada83 version).

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

Well, one other issue that I think is kind of important:

If some version of the Booch Components were sufficiently massaged to the
point of being acceptable as a de-facto standard, would any of the Ada
vendors be willing to pick them up and bundle them into their distributions?

I imagine that there might be a number of people who would be willing to do
some amount of work on the Booch Components (or any other suitable library)
with respect to making it into an industrial grade product. However, it
really doesn't do much good unless it shows up with the compiler. If it
comes down to downloading it separately, you'll have what youv'e got now:
Dozens of available libraries of stuff with no one library being the
dominant technology. It was helpful that the Win32Ada bindings got
distributed with some of the PC compilers and it pretty much became a
standard that everyone adhered to. Something similar would help an ADT
library become a standard.

If the compiler vendors (or at least *some* of them) refuse to get on board
with the Booch Components (or any other library - for any reasons - good or
bad) then this is all just a bunch of pretty talk and blue-sky ideas.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:ajjx7.343$Fl2.166882460@newssvr11.news.prodigy.com...
>
> Sounds good.
>

Re: why not

[Ted Dennison]

In article <9q4m4t$t4n$1@nh.pace.co.uk>, Marin David Condic says...
>
>If some version of the Booch Components were sufficiently massaged to the
>point of being acceptable as a de-facto standard, would any of the Ada
>vendors be willing to pick them up and bundle them into their distributions?

I suspect so. I already consider it a sort of demi-requirement that my compilers
properly compile Booch. Given that they use nested generics and classes, this
isn't as trivial a requirement as it might sound.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Marin David Condic]

Being able to compile them and being willing to distribute them are two
different things. I could imagine lots of business reasons why a vendor
might say "thanks, but no thanks" to the suggestion that they bundle someone
else's software in with their compiler distribution.

Observation: The Booch Components have been available on the Net for some
time now and IIRC, they were available under a license very similar to (if
not identical to) the one used for the Gnat runtime code. (IOW, no big legal
restrictions to prevent a vendor from using them.) Yet in all that time, how
many vendors have packaged the BCs with their compiler? By my count, that
number would look amazingly a lot like "zero" (correct my count if you know
of one that does...). Why not? They're "available". They "add value". They
"cost nothing". Since I don't believe the vendors are either a) Stupid or b)
Ignorant (of the existence of the BCs.) I've got to believe there is some
reason they don't already do this. (Quality? Implied willingness to support?
Implied endorsement? Insufficient components/documentation? Waiting for a
winner to emerge? Product distinction? Not Invented Here?)

That is why I think it would be valuable to hear the vendor's opinions on
what is required of some potential component library. Get three or four
vendors willing to say "If you guys build something like this.... we'll
distribute it with the compiler..." and then you've really got something.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:E_lx7.24944$ev2.33842@www.newsranger.com...
>
> I suspect so. I already consider it a sort of demi-requirement that my
compilers
> properly compile Booch. Given that they use nested generics and classes,
this
> isn't as trivial a requirement as it might sound.
>

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9q4rel$23p$1@nh.pace.co.uk...
> Being able to compile them and being willing to distribute them are two
> different things. I could imagine lots of business reasons why a vendor
> might say "thanks, but no thanks" to the suggestion that they bundle
someone
> else's software in with their compiler distribution.
>
> Observation: The Booch Components have been available on the Net for some
> time now and IIRC, they were available under a license very similar to (if
> not identical to) the one used for the Gnat runtime code. (IOW, no big
legal
> restrictions to prevent a vendor from using them.) Yet in all that time,
how
> many vendors have packaged the BCs with their compiler? By my count, that
> number would look amazingly a lot like "zero" (correct my count if you
know
> of one that does...). Why not? They're "available". They "add value". They
> "cost nothing". Since I don't believe the vendors are either a) Stupid or
b)
> Ignorant (of the existence of the BCs.) I've got to believe there is some
> reason they don't already do this. (Quality? Implied willingness to
support?
> Implied endorsement? Insufficient components/documentation? Waiting for a
> winner to emerge? Product distinction? Not Invented Here?)

Occam's Razor says it is probably because nobody has asked them to do so.
(And I'm assuming that is because they are already available off the Net.)


> That is why I think it would be valuable to hear the vendor's opinions on
> what is required of some potential component library. Get three or four
> vendors willing to say "If you guys build something like this.... we'll
> distribute it with the compiler..." and then you've really got something.

Sounds like a question to put to the ARA...

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

It could very well be that customers have not been clamoring for a component
library. It could be that if anyone has mentioned it, the assumption is "we
have to build one ourselves and we have bigger fish to fry". Maybe customers
handle this for themselves. Who knows?

I think there is a big advantage to including it with the compiler
distribution in some semi-integrated manner. (id est, it is tested to
compile and run with that particular compiler and documents make it easy and
obvious to find.) After all, lots of new users of Ada may not be aware of
the existence of such products or know enough to be able to use them
effectively. Better to have it right there and ready to go. Existing Ada
users may be able to manage it for themselves, but they're the ones already
sold on it.

Maybe the ARA is the right place to start instigating. However, I suspect
that a number of the members do read this group and are aware of this and
similar discussions in the past. It would be nice to get a little casual
feedback on the idea to decide if it is worth persuing more rigorously.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:Bxqx7.411$JZ6.118851739@newssvr12.news.prodigy.com...
>
> Occam's Razor says it is probably because nobody has asked them to do so.
> (And I'm assuming that is because they are already available off the Net.)
>
>
> > That is why I think it would be valuable to hear the vendor's opinions
on
> > what is required of some potential component library. Get three or four
> > vendors willing to say "If you guys build something like this.... we'll
> > distribute it with the compiler..." and then you've really got
something.
>
> Sounds like a question to put to the ARA...
>
>

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9q6qk1$38a$1@nh.pace.co.uk...
> It could very well be that customers have not been clamoring for a
component
> library. It could be that if anyone has mentioned it, the assumption is
"we
> have to build one ourselves and we have bigger fish to fry". Maybe
customers
> handle this for themselves. Who knows?
>
> I think there is a big advantage to including it with the compiler
> distribution in some semi-integrated manner. (id est, it is tested to
> compile and run with that particular compiler and documents make it easy
and
> obvious to find.) After all, lots of new users of Ada may not be aware of
> the existence of such products or know enough to be able to use them
> effectively. Better to have it right there and ready to go. Existing Ada
> users may be able to manage it for themselves, but they're the ones
already
> sold on it.

Agreed.

> Maybe the ARA is the right place to start instigating. However, I suspect
> that a number of the members do read this group and are aware of this and
> similar discussions in the past. It would be nice to get a little casual
> feedback on the idea to decide if it is worth persuing more rigorously.

I've started asking, anyway.

Re: why not

[Ted Dennison]

In article <9q6qk1$38a$1@nh.pace.co.uk>, Marin David Condic says...
>I think there is a big advantage to including it with the compiler
>distribution in some semi-integrated manner. (id est, it is tested to

Perhaps you could take some initiative on this stuff, and start making
integrated Gnat distrubutions with Emacs, GLIDE, a few config tweaks, the booch
components, and GTKAda. You could call it "Marin's Blend Gnat". :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Marin David Condic]

Hmmmmm........ "Marin's Blend Gnat".......

How about "Marin and Ted's Big Adventure"?

:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:%CCx7.26049$ev2.34630@www.newsranger.com...
>
> Perhaps you could take some initiative on this stuff, and start making
> integrated Gnat distrubutions with Emacs, GLIDE, a few config tweaks, the
booch
> components, and GTKAda. You could call it "Marin's Blend Gnat". :-)
>

Re: why not

[Ted Dennison]

In article <9q4rel$23p$1@nh.pace.co.uk>, Marin David Condic says...
>restrictions to prevent a vendor from using them.) Yet in all that time, how
>many vendors have packaged the BCs with their compiler? By my count, that
>number would look amazingly a lot like "zero" (correct my count if you know
..
>Ignorant (of the existence of the BCs.) I've got to believe there is some
>reason they don't already do this. (Quality? Implied willingness to support?
>Implied endorsement? Insufficient components/documentation? Waiting for a
>winner to emerge? Product distinction? Not Invented Here?)

More likely, they didn't want to have to worry about support calls relating to
it.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Simon Wright]

Robert*@ <Robert_member@newsguy.com> writes:

> is the book about booch components in Ada not usefull for this? I do not
> have the book in front me, but it could be this one, but not sure:
> 
> Software Components With Ada : Structures, Tools, and Subsystems (The
> Benjamin/Cummings Series in Ada and Software Engineering)
> by Grady Booch
> 
> it is a black cover one, and it describes in details all of booch components
> with code (ada83).

Afraid not, that's the Ada83 one, very little resemblance beyond the
author's name.

You can get the 83 components at Adapower, BTW.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Pascal Obry]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I looked over the Booch Components several years ago and have not revisited
> them since. Perhaps they have evolved some since then so my comments may not
> be appropriate.
> 
> One big weakness I found in them was a general lack of documentation. If

I agree too. But note that the Booch components are Open Source. The work to
put up this library is certainly a big one... Why not just contribute to the
documentation part of the project ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

As a former member of the apparently defunct Ada Standard Component Library
Working Group (and one who actually developed a working component for same)
I'm not against the notion of contributing effort to a project I think is
worth while.

That said, I won't be sucked into A Fool's Errand(tm). :-) Unless there were
some reasonable consensus that the BCs (or another library) were the
appropriate starting point and unless one or more vendors were willing to
get behind it, I don't think investing any significant amount of time into
it is a good idea. The BCs have been there for a while and have not achieved
any sort of "market dominance", so it is unclear that they should become the
de facto standard. No compiler vendors are distributing them with their
compiler - maybe they know something we don't? I don't think any proposed
library is going to become dominant or even be of much use unless some of
the vendors will support it.

Let's see how it develops....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:uofnerojv.fsf@wanadoo.fr...
> I agree too. But note that the Booch components are Open Source. The work
to
> put up this library is certainly a big one... Why not just contribute to
the
> documentation part of the project ?
>

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Pascal Obry]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> As a former member of the apparently defunct Ada Standard Component Library
> Working Group (and one who actually developed a working component for same)
> I'm not against the notion of contributing effort to a project I think is
> worth while.

I know, so you are certainly a good candidate to help on similar projects :)

> 
> That said, I won't be sucked into A Fool's Errand(tm). :-) Unless there were
> some reasonable consensus that the BCs (or another library) were the
> appropriate starting point and unless one or more vendors were willing to
> get behind it, I don't think investing any significant amount of time into
> it is a good idea. The BCs have been there for a while and have not achieved
> any sort of "market dominance", so it is unclear that they should become the
> de facto standard. No compiler vendors are distributing them with their
> compiler - maybe they know something we don't? I don't think any proposed
> library is going to become dominant or even be of much use unless some of
> the vendors will support it.

Well this is a bit the chicken and egg problem ! Without proper documentation
the BC could never gets more attention... You seem to want to plan every thing
in advance... I think the open projects are more a kind of game-of-life, you
launch somehting it eventually die or live ! The point is that more effort is
put on a project and more chance there is for it to survive.

Just my 2 cents,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

I understand the chicken/egg problem, and can sympathize. I wouldn't demand
planning everything in advance - just seeing some reasonable level of
interest by players who would be significant to a project's success. An
analogy would be getting a "letter of intent" from a buyer that you could
take to a bank to gain financing to enable you to produce the product that
they have expressed the intent to purchase.

As an ACM/SIGAda member, I'd think this organization would be the proper
forum for developing a usable component library (out of existing parts or
from bottom-dead-center). No reason the ASCLWG couldn't be resurrected in
some form to do the job.  ASIS was developed in a similar way.

My concern is that such a project needs two things: A reasonably clear
mission and some level of committment from compiler vendors. I'd want to see
the vendors drive the effort by stating what they would and would not find
acceptable. If you cannot find at least one vendor to get on board and
commit to distributing the end product (and possibly provide some resources
& support of their own?) then what you've got is an old maid looking for a
suitor.

Like I said in other posts - the BC's have been out there for a while now.
They have not found a widespread acceptance amongst either the vendors or
the user community at large - or we wouldn't even be discussing this now.
Are the BC's the right answer? Maybe - but I'd want to see some evidence
that they wouldn't be rejected out of hand by everyone before investing any
significant energy in improving them.

BTW: I just went to Adapower and looked over the BC page. There is some
level of documentation there. The source code is there. There are release
notes and zip files and all that good stuff. What more would you see as
needing to be done to make them an acceptable baseline for a component
library?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:uk7y1sxv3.fsf@wanadoo.fr...
>
> Well this is a bit the chicken and egg problem ! Without proper
documentation
> the BC could never gets more attention... You seem to want to plan every
thing
> in advance... I think the open projects are more a kind of game-of-life,
you
> launch somehting it eventually die or live ! The point is that more effort
is
> put on a project and more chance there is for it to survive.
>

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[mitch]

In article <9q534p$5cg$1@nh.pace.co.uk>, "Marin says...
>
 
>
>As an ACM/SIGAda member, I'd think this organization would be the proper
>forum for developing a usable component library (out of existing parts or
>from bottom-dead-center).

 
Oh no, not another design by a committe thing. This just reinforces the
view that Ada was indeed designed by a committe.

The Java collection was designed by one guy at Sun. No committe was needed
to all agree on everything. C++ templates was also designed by one guy. 
I think software that is designed by one or at most 2 people, is in 
general better than software designed by a large group of people.
 
May be 20 years from now Ada will have a standard library for collections,
but I won't hold my breath :)  

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

Well, languages end up inherently "designed by committee" because they have
a community of users who start calling for extensions and changes. (C++ and
Java don't get influenced by everybody saying "I want feature XYZ..."?)

It need not be a "design by committee" deal - it may just be building an
appropriate adaptation of one person's design. (That's kind of what we're
talking about with the BCs.) I understand the weaknesses of getting a
committee involved - not the least of which is endless talk and no end
result. But one advantage is that if there are a reasonably clear set of
requirements and sufficient progress on agreeing on a series of
specifications, you have a number of people who will be willing to do the
work to produce the end result.

Key is having some half-way reasonable level of agreement as to what to go
off and build. If you get a quarum that says "If you build this, I'll use
it..." or "If you build this, I'll distribute it..." then at least you've
got some "market research" as to what sort of end product needs to be there.
A committee is one way of getting that sort of research.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"mitch@NOSPAM" <mitch_member@newsguy.com> wrote in message
news:9q5fkk0ra0@drn.newsguy.com...
>
>
> Oh no, not another design by a committe thing. This just reinforces the
> view that Ada was indeed designed by a committe.
>
> The Java collection was designed by one guy at Sun. No committe was needed
> to all agree on everything. C++ templates was also designed by one guy.
> I think software that is designed by one or at most 2 people, is in
> general better than software designed by a large group of people.
>
> May be 20 years from now Ada will have a standard library for collections,
> but I won't hold my breath :)
>

Re: why not

[Ted Dennison]

In article <9q6r5f$3hc$1@nh.pace.co.uk>, Marin David Condic says...
>It need not be a "design by committee" deal - it may just be building an

"Requirement by committe" I think is a bit more what Marin was shooting for.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Like I said in other posts - the BC's have been out there for a while now.
> They have not found a widespread acceptance amongst either the vendors or
> the user community at large - or we wouldn't even be discussing this now.

I know of 3 projects, soon 4, that have used the BCs. Ted's was one,
my current one another. There may well be more, I usually just hear
about the bugs^H^H^H^Hproblems.

-- 
Simon Wright                         Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                     Voice: +44(0)23 9270 1778
Integrated Systems Division                  FAX: +44(0)23 9270 1800

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marc A. Criley]

Pascal Obry wrote:
> 
> Well this is a bit the chicken and egg problem ! Without proper documentation
> the BC could never gets more attention... 

As a shameless promoter of Corey Minyard's Ada Structured Library
(http://adasl.sourceforge.net), I would like to point out that useful
documentation accompanies this collection.  The documentation is
sufficient such that when using these components, I usually find what I
need to know in the docs rather than having to look at the code.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Simon Wright]

Pascal Obry <p.obry@wanadoo.fr> writes:

> Well this is a bit the chicken and egg problem ! Without proper
> documentation the BC could never gets more attention...

What there is is strongly based on the C++ documentation (which made
it into a commercial product, I think you can buy them from Rogue
Wave).

-- 
Simon Wright                         Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                     Voice: +44(0)23 9270 1778
Integrated Systems Division                  FAX: +44(0)23 9270 1800

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Licensing is another issue. Some people love the GPL, but others may
> not want to contaminate their code with that. What license is the
> Booch Components currently under and does it allow unfettered use in
> everything from "Open Source" (whatever that means currently) to
> totally proprietary - maybe even classified - applications?

  http://www.pushface.org/components/bc/ACL

I would prefer the GMGPL, myself, but it's a major task to change
everywhere!

Given my background I'd be unlikely to try to prevent their use in
military applications. Or do you think there's something about the GPL
or other OS licenses which would prevent their use in _classified_
applications?

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

Well, just in general the government doesn't like to use anything they can't
"own". End of the day, they can take whatever they want, slap a "classified"
sticker on it and tell everyone to shut up about it. (They have all the
guns, you know. :-) But given some of the implications of the GPL (Having to
GPL the code derived from it? Having to release source to anyone you give a
binary to? Does that include NATO?) I could easily imagine some contract
officer insisting that this was too much trouble and its better to build it
from the ground up and not have any question about the government's right to
lock it all up any way they see fit.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vhet5j4g9.fsf@smaug.pushface.org...
>
> Given my background I'd be unlikely to try to prevent their use in
> military applications. Or do you think there's something about the GPL
> or other OS licenses which would prevent their use in _classified_
> applications?

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Jeffrey Carter]

Pat Rogers wrote:
> 
> Many of us have developed libraries of reusable components over the years.
> It is a great way to learn a language.  We all have things we like about
> them.  Some are extensive and well done.  However, we would all clearly
> benefit by agreeing to make one of them the de facto standard.  (Formal
> standardization is desirable too, IMHO.)
> 
> I propose the Booch Components be that standard.  If there is a better suite
> I haven't seen it and I've seen many of them.  However, there may very well
> be a better collection of components.  Let's discuss them.

I have serious reservations about the BCs. They are based on theory
rather than practical use. Booch developed his taxonomy which determines
what components exist. Does the developer really need to choose from 21
(or whatever the number is now) different queues? In my experience, the
answer is no. Both bounded and unbounded variants are needed, with both
protected and unprotected variants of each (the unprotected variants are
primarily for creating structures of structures, which the BCs did not
permit the last time I looked at them). Within the protected forms, a
blocking variant is needed. That gives 6 variants of queues, which my
experience shows are useful over 90% of the time. They also provide the
building blocks if you really need a lesser used variant.

A similar thing arises from the partitioning of operations into
modifiers and selectors. Everyone is used to pushing things onto a stack
and popping things off. But popping something off a stack involves both
modifying the stack and selecting a value from the stack. Theory says
this is a No-No, so we'll separate them into Pop, the modifier, and Top,
the selector. Of course, in practical use, every call to Top is
immediately followed by a call to Pop, indicating that the real
operation on the abstraction combines these 2 theoretical operations.

The GRACE components from EVB also distinguished between constructors
and modifiers. This resulted in what should have been simple code such
as

loop
   exit when End Of File;

   Read Item from File;
   Append Item to List;
end loop;

turning into

loop
   exit when End Of File;

   Read Item from File;

   if List is Empty then
      Construct List from Item;
   else
      Append Item to List;
   end if;
end loop;

unnecessarily complicating what should be simple code (of course, in
this small example it doesn't look too bad).

Thus, I suggest using components derived from practical considerations
rather than theoretical ones. Ten pragmatic Ada points to those who can
guess which ones I prefer.

-- 
Jeffrey Carter

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

Its a good point that possibly the Booch Components are "overkill". I
understand this in many respects. I've always wondered about the necessity
of having stacks and queues at all. A reasonable implementation of a
bi-directional list pretty much covers all those bases and in practical use
will handle 99.44% of everything you need in the way of linked data
structures.

The MFC has two data structures that get used with much regularity. Lists
and Maps. (O.K. I guess we could debate just what constitutes a data
structure and then debate what parts of the MFC might qualify, but I'd
rather not.) If there were similar Ada structures, I'd imagine this would
cover most of the things that show up in practical use. You'd probably want
versions that were task-safe and those that were not. Throw on top static vs
dynamic allocation and you've got 8 variants of data structures. Would that
be enough to handle most *practical* programming problems? IMHO, probably.

However, there is something to be said for adopting the Booch Components
as-is. A) Its already in existence. B) It has a recognizable name and
heritage. C) It has a textbook available that helps explain it. D) Even an
imperfect standard is better than (d1) no standard at all and/or (d2) an
endless debate about which of many existing or possible container libraries
should be adopted.

If the BCs supply - or can be made to supply - Lists & Maps in
static/dynamic and task-safe/monoprogrammed variants, then maybe its worth
adopting. All the rest can be viewed as interesting intellectual exercises
that may or may not find much practical use, but are along for the ride
anyway. There's no technical penalty for not using what you don't need,
right?

I'd like to hear from one or more compiler vendors concerning what
requirements they would have for any component library that they'd be
willing to distribute with their product.  If there isn't a single vendor
willing to distribute *anything* as a candidate for an Ada Standard
Component Library, then this is all a profound, if not sinful, waste of
time.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3BC5D730.DA950CC7@boeing.com...
>
> I have serious reservations about the BCs. They are based on theory
> rather than practical use. Booch developed his taxonomy which determines
> what components exist. Does the developer really need to choose from 21
> (or whatever the number is now) different queues? In my experience, the
> answer is no. Both bounded and unbounded variants are needed, with both
> protected and unprotected variants of each (the unprotected variants are
> primarily for creating structures of structures, which the BCs did not
> permit the last time I looked at them). Within the protected forms, a
> blocking variant is needed. That gives 6 variants of queues, which my
> experience shows are useful over 90% of the time. They also provide the
> building blocks if you really need a lesser used variant.
>
> A similar thing arises from the partitioning of operations into
> modifiers and selectors. Everyone is used to pushing things onto a stack
> and popping things off. But popping something off a stack involves both
> modifying the stack and selecting a value from the stack. Theory says
> this is a No-No, so we'll separate them into Pop, the modifier, and Top,
> the selector. Of course, in practical use, every call to Top is
> immediately followed by a call to Pop, indicating that the real
> operation on the abstraction combines these 2 theoretical operations.
>
> The GRACE components from EVB also distinguished between constructors
> and modifiers. This resulted in what should have been simple code such
> as
>
> loop
>    exit when End Of File;
>
>    Read Item from File;
>    Append Item to List;
> end loop;
>
> turning into
>
> loop
>    exit when End Of File;
>
>    Read Item from File;
>
>    if List is Empty then
>       Construct List from Item;
>    else
>       Append Item to List;
>    end if;
> end loop;
>
> unnecessarily complicating what should be simple code (of course, in
> this small example it doesn't look too bad).
>
> Thus, I suggest using components derived from practical considerations
> rather than theoretical ones. Ten pragmatic Ada points to those who can
> guess which ones I prefer.
>
> --
> Jeffrey Carter

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Lutz Donnerhacke]

* Marin David Condic wrote:
>Its a good point that possibly the Booch Components are "overkill". I
>understand this in many respects. I've always wondered about the necessity
>of having stacks and queues at all. A reasonable implementation of a
>bi-directional list pretty much covers all those bases and in practical use
>will handle 99.44% of everything you need in the way of linked data
>structures.

My personal problem with serveral existing libs is, that they assume to much
on the components they decorate. So it's difficult to built a extensible
hash of unconstraint task types. That's why I did some work on mixins (do
not even think on using them).

OTOH most of programmers I spoke to do not like the fairly adaptable
libraries because they are confused by the huge amount of options. So the
recode there own libs, because they are faster to develop and verify them,
than understanding the library. Of course, that's just another instance of
the Not Invented Here Syndom, the most common open source disease.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Jean-Marc Bourguet]

Lutz Donnerhacke wrote:
> OTOH most of programmers I spoke to do not like the fairly adaptable
> libraries because they are confused by the huge amount of options. So the
> recode there own libs, because they are faster to develop and verify them,
> than understanding the library. Of course, that's just another instance of
> the Not Invented Here Syndom, the most common open source disease.

If redevelopping something else is quicker (especially when you include
the verification as you do) than using a library, that's a sure sign
that
the library is not targetted to your problem, not an occurence of NIHS.
You have this syndrom when you redevelop something and that takes more
ressource than reusing something else.

A+
-- Jean-Marc

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Lutz Donnerhacke]

* Jean-Marc Bourguet wrote:
>Lutz Donnerhacke wrote:
>> OTOH most of programmers I spoke to do not like the fairly adaptable
>> libraries because they are confused by the huge amount of options. So
>> the recode there own libs, because they are faster to develop and
>> verify them, than understanding the library. Of course, that's just
>> another instance of the Not Invented Here Syndom, the most common open
>> source disease.
>
>If redevelopping something else is quicker (especially when you include
>the verification as you do) than using a library, that's a sure sign that
>the library is not targetted to your problem, not an occurence of NIHS.
>You have this syndrom when you redevelop something and that takes more
>ressource than reusing something else.

This is correct only if your apply a pure rational view. Unfortunly serveral
programmers can't sleep when using a forein - not standard - library.
Including myself.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

People regularly use the standard function libraries supplied with C. They
also regularly use the standard libraries provided by Ada. I think there
might be a different perception of a library that comes along with most/all
compilers versus one that is downloaded off the net.

People might presume that something that comes with the compiler is of
better quality and more likely to be portable. You get some library off the
net and you don't know if it will work with all compilers in all
environments and you might wonder about its reliability and quality. One
might also start presuming that a library distributed with a compiler is
something they can call their vendor and complain about and get something
done to fix it. Downloading it from some website free of charge might lead
people to assume they are on their own and no bug fixes will ever come
unless they do it themselves.

(Side bar: How many times have we seen posts from Ada newbies talking about
C/C++ ways of doing things and ultimately they are presuming that some
function they are used to using is part of the language? It may only be a
function that came with one specific compiler or maybe an OS call, but they
*think* it is a standard C/C++ feature. Our arguing against that ignorance
may be noble, but it might be better to simply work with it. If a number of
vendors provided some common component library with their distributions,
you'd have folks going "No. Look. In Ada I can do XYZ and in your language
you can't!!!")

It isn't right or fair - its just the way things are. Compilers may come
with crappy libraries and Netware might be rock-solid, but it is a matter of
perception. And as an old friend of mine was fond of saying "Perception *is*
Reality!"

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrn9sdbi9.k4.lutz@taranis.iks-jena.de...
>
> This is correct only if your apply a pure rational view. Unfortunly
serveral
> programmers can't sleep when using a forein - not standard - library.
> Including myself.

Re: why not

[Ted Dennison]

In article <3BC6ACC8.23EF21BC@free.fr>, Jean-Marc Bourguet says...
>
>Lutz Donnerhacke wrote:
>> OTOH most of programmers I spoke to do not like the fairly adaptable
>> libraries because they are confused by the huge amount of options. So the
>> recode there own libs, because they are faster to develop and verify them,
>> than understanding the library. Of course, that's just another instance of
>> the Not Invented Here Syndom, the most common open source disease.
>
>If redevelopping something else is quicker (especially when you include
>the verification as you do) than using a library, that's a sure sign
>that
>the library is not targetted to your problem, not an occurence of NIHS.
>You have this syndrom when you redevelop something and that takes more
>ressource than reusing something else.

Well, its not *quite* that. Its just that a simple list is fairly easy to code
and test (perhaps 6 hours or so). The result should be fairly fast too, as it
won't have any more capability than you need. On the other side, it takes a fair
bit of study to figure out how to properly instantiate a Booch component.  It
isn't a simple generic. You have to find the proper package first, which
involves deciphering the naming scheme, and the package hierarchy. That can take
two hours or more for the uninitiated. Then you have to figure out that you have
to instantiate a grandparent package, then take that instantiation and use it to
instantiate a the parent package, then take that instantiation and use it to
instantiate a child. This isn't something most Ada programmers regularly have to
deal with, and it can be quite confusing first. Most beginners waste lots of
time trying to instantiate the child generics from the generic package instead
of from the instantiation of it. To make matters worse, there are sometimes
other generics you are supposed to instantiate so that you can use them as
parameters into other generic instantiations. To top it all off, you may *still*
need to test the result to make sure it does what you need it to do.

On the plus side, once you figure this mess out, it will be *way* quiker to do
it a second time. So its really an issue of if you want to invest a bit extra
time up front thwacking your head against a wall figuring out Booch, in order to
be able to save yourself extra time the *next* time you need a component.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Well, its not *quite* that. Its just that a simple list is fairly easy to code
> and test (perhaps 6 hours or so). The result should be fairly fast too, as it
> won't have any more capability than you need. On the other side, it takes a fair
> bit of study to figure out how to properly instantiate a Booch component.  It
> isn't a simple generic. You have to find the proper package first, which
> involves deciphering the naming scheme, and the package hierarchy. That can take
> two hours or more for the uninitiated. Then you have to figure out that you have
> to instantiate a grandparent package, then take that instantiation and use it to
> instantiate a the parent package, then take that instantiation and use it to
> instantiate a child. This isn't something most Ada programmers regularly have to
> deal with, and it can be quite confusing first. Most beginners waste lots of
> time trying to instantiate the child generics from the generic package instead
> of from the instantiation of it. To make matters worse, there are sometimes
> other generics you are supposed to instantiate so that you can use them as
> parameters into other generic instantiations. To top it all off, you may *still*
> need to test the result to make sure it does what you need it to do.

This is an excellent argument *against* the BCs. Maybe in C++ the
implicit instantiation alleviates this, or maybe C++ people are
masochists, but in Ada it's unacceptable for a library to be so
complicated that it takes hours to find and instantiate a list, and even
then not be sure you've got what you need without testing.

Indeed, this smacks of the C culture, in which unnecessarily complex
things are embraced, because those who can understand them are praised
as gurus. I've always felt that it was stupid to waste my time on such
things when simpler alternatives exist. I have a similar attitude
towards component libraries.

-- 
Jeffrey Carter

Re: why not

[Ted Dennison]

In article <3BC71F54.1FFE78FA@boeing.com>, Jeffrey Carter says...
>
>This is an excellent argument *against* the BCs. Maybe in C++ the
>implicit instantiation alleviates this, or maybe C++ people are

In C++ it look like this problem is largely eliminated by the fact that most of
the templates have lots of sensible default paramters. It also appears that they
have some kind of type content-equivalence thingy going on where templates are
concerned, where Ada is forced to use child packages or package parameters to
ensure that types match up. But I'm still playing around with C++ templates and
haven't quite figured out what's going on there yet.

One thing I can say is that the specs (.h files) for the STL are damn near
unreadable to this novice's eyes. Its at least as bad, if not worse, than the
Ada Booch stuff. It could just be that C++ folks are used to running to some
reference to figure out how stuff works, rather than diving into the sources
like Ada folks can (usually) do.

>masochists, but in Ada it's unacceptable for a library to be so
>complicated that it takes hours to find and instantiate a list, and even
>then not be sure you've got what you need without testing.

Again, this is for the *first* time you try to use something. You don't even
need to do that, if you can find someone else's instantiation code to clone.
After that, its just a matter of making the proper "magic incantation" to
instantiate your generics, and you are good to go. 

I think its also valuable as an Ada generics technique lesson, in the same way
that the Gnat SPITBOL packages can be as an operator overloading lesson. The
OpenToken project actually makes use of this same technique (the former that is,
althogh there is operator overloading too). However, I tried to provide a user
guide with extensive examples for how to instantiate and use it (and lots of
reassurance in the hairier parts).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Again, this is for the *first* time you try to use something. You don't even
> need to do that, if you can find someone else's instantiation code to clone.
> After that, its just a matter of making the proper "magic incantation" to
> instantiate your generics, and you are good to go.

Again, magic incantations may be OK if you're a C++ hacker, but we Ada
software engineers avoid them. Since the same effect can be obtained
without investing hours of effort or parroting magic incantations using
other component libraries, I can see no justification for this level of
complexity.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: why not

[Ted Dennison]

In article <3BC7AD82.2A0CCCD4@acm.org>, Jeffrey Carter says...
>
>Ted Dennison wrote:
>> 
>> Again, this is for the *first* time you try to use something. You don't even
>> need to do that, if you can find someone else's instantiation code to clone.
>> After that, its just a matter of making the proper "magic incantation" to
>> instantiate your generics, and you are good to go.
>
>Again, magic incantations may be OK if you're a C++ hacker, but we Ada
>software engineers avoid them. Since the same effect can be obtained
>without investing hours of effort or parroting magic incantations using
>other component libraries, I can see no justification for this level of
>complexity.

Well, as I said, the OpenToken stuff has the same issue. I think *anything* that
uses a hierarchy of generic packages has the same issue. So in effect, you are
saying that there is no justification for anything that uses the Ada capability
of creating hierarchies of generic packages. You may have a point, but this
feature does allow you to do some awfully nifty stuff. I don't think I'm quite
ready to remove it from my toolkit just yet.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Stephen Leake]

Jeffrey Carter <jrcarter@acm.org> writes:

> Ted Dennison wrote:
> > 
> > Again, this is for the *first* time you try to use something. You don't even
> > need to do that, if you can find someone else's instantiation code to clone.
> > After that, its just a matter of making the proper "magic incantation" to
> > instantiate your generics, and you are good to go.
> 
> Again, magic incantations may be OK if you're a C++ hacker, but we Ada
> software engineers avoid them. Since the same effect can be obtained
> without investing hours of effort or parroting magic incantations using
> other component libraries, I can see no justification for this level of
> complexity.

My Ada library also seems overly complex at first, compared to the C++
STL. But on closer examination, you realize that it supports things
that C++ doesn't. C++ has no limited types, it has no distinction
between abstract and concrete types, or between tagged and non-tagged
types, as template parameters. C++ does not have arrays as primitive
types. Ada has all of these. Thus any generic library that supports
_all_ of Ada will be more complex than the "equivalent" C++ library.

It is easy to write a list package that will accept an Item_Type of
Integer, or any non-tagged, non-private, non-limited, non-abstract
type. Allowing it to accept an Item_Type with any combination of those
attributes is much harder, but well worth it!

Things should be as simple as possible, but no simpler.

-- 
-- Stephe

Re: why not

[Marin David Condic]

I would again make the appeal that this would constitute "A Good Start" and
would satisfy a really large percentage of the practical usage. So long as
the requirements identify the plain vanilla case and that much is agreed on,
implemented and accepted as the de facto "standard" we could all all the
exceptional cases as it becomes apparent that they are needed/useful.

Just so long as the structure of the component library lends itself to
adding the extensions, it would be fine to start with a smaller set just to
get it going.

BTW: Has anybody inquired with ACT, Aonix, RR, et alia, to determine if they
would have any interest in distributing a component library of any sort? Any
vendors reading this who would care to comment?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:usncjtzix.fsf@gsfc.nasa.gov...
>
> It is easy to write a list package that will accept an Item_Type of
> Integer, or any non-tagged, non-private, non-limited, non-abstract
> type. Allowing it to accept an Item_Type with any combination of those
> attributes is much harder, but well worth it!
>

Re: why not

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9qhiqr$af0$1@nh.pace.co.uk...
> I would again make the appeal that this would constitute "A Good Start"
and
> would satisfy a really large percentage of the practical usage. So long as
> the requirements identify the plain vanilla case and that much is agreed
on,
> implemented and accepted as the de facto "standard" we could all all the
> exceptional cases as it becomes apparent that they are needed/useful.
>
> Just so long as the structure of the component library lends itself to
> adding the extensions, it would be fine to start with a smaller set just
to
> get it going.

I would argue that the BC's are fine for all the above, they exist already,
and they work.


> BTW: Has anybody inquired with ACT, Aonix, RR, et alia, to determine if
they
> would have any interest in distributing a component library of any sort?

I'm pursuing this, and wil post when I find something out.

> Any vendors reading this who would care to comment?

Team Ada may be the way to go.  I'll post there next.


--
---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: why not

[Marin David Condic]

Note that I have no strenuous objections to the Booch Components. As you
observe, they already exist and they already work. My only possible
objection might be that of "simplicity". If a component library is to help
attract garden variety programmers to Ada, then there needs to be a simple,
direct way to obtain - say - a list of integers or a map of strings/records.
(Think in terms of "I need to read in and pile up an unknown amount of
Integers to look at later..." or "I need a table of employee names that get
me employee records..." That has got to be easy to do for a relative newbie
to Ada or the component library is just going to be some esoteric,
intellectual exercise that isn't going to get used much beyond its biggest
fans.)

If the BCs can be made to do the above things readily and how to do it is
documented reasonably well, then I would think we can get there from here.

This question remains: Would there be at least one - hopefully several -
compiler vendors that would accept the BCs as a pseudo-standard library and
bundle them with their compiler? If so, what, if anything, would they want
to see done to them to make them more acceptable?

Hopefully, your queries with vendors & TeamAda will yield some answers. It
would be good to see some acceptance of the idea as I'm sure it would lead
to more willing involvement by volunteers...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:K1Zy7.12219$hT5.3979715684@newssvr30.news.prodigy.com...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9qhiqr$af0$1@nh.pace.co.uk...
> > I would again make the appeal that this would constitute "A Good Start"
> and
> > would satisfy a really large percentage of the practical usage. So long
as
> > the requirements identify the plain vanilla case and that much is agreed
> on,
> > implemented and accepted as the de facto "standard" we could all all the
> > exceptional cases as it becomes apparent that they are needed/useful.
> >
> > Just so long as the structure of the component library lends itself to
> > adding the extensions, it would be fine to start with a smaller set just
> to
> > get it going.
>
> I would argue that the BC's are fine for all the above, they exist
already,
> and they work.
>
>
> > BTW: Has anybody inquired with ACT, Aonix, RR, et alia, to determine if
> they
> > would have any interest in distributing a component library of any sort?
>
> I'm pursuing this, and wil post when I find something out.
>
> > Any vendors reading this who would care to comment?
>
> Team Ada may be the way to go.  I'll post there next.
>
>
> --
> ---
> Patrick Rogers                       Consulting and Training in:
> http://www.classwide.com          Real-Time/OO Languages
> progers@classwide.com               Hard Deadline Schedulability Analysis
> (281)648-3165                                 Software Fault Tolerance
>
>

Re: why not

[Marin David Condic]

BTW: Did I ask this before? Do the Booch Components do some form of
serialization? Loading/Storing from/to files is one other thing I would
think ought to be a requirement.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:K1Zy7.12219$hT5.3979715684@newssvr30.news.prodigy.com...
>
> I would argue that the BC's are fine for all the above, they exist
already,
> and they work.
>

Re: why not

[Pat Rogers]

"Pat Rogers" <progers@classwide.com> wrote in message
news:K1Zy7.12219$hT5.3979715684@newssvr30.news.prodigy.com...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9qhiqr$af0$1@nh.pace.co.uk...
> > I would again make the appeal that this would constitute "A Good Start"
and
> > would satisfy a really large percentage of the practical usage. So long
as
> > the requirements identify the plain vanilla case and that much is agreed
on,
> > implemented and accepted as the de facto "standard" we could all all the
> > exceptional cases as it becomes apparent that they are needed/useful.
> >
> > Just so long as the structure of the component library lends itself to
> > adding the extensions, it would be fine to start with a smaller set just
to
> > get it going.
>
> I would argue that the BC's are fine for all the above, they exist
already,
> and they work.
>
>
> > BTW: Has anybody inquired with ACT, Aonix, RR, et alia, to determine if
they
> > would have any interest in distributing a component library of any sort?
>
> I'm pursuing this, and wil post when I find something out.
>
> > Any vendors reading this who would care to comment?
>
> Team Ada may be the way to go.  I'll post there next.

I've received no answers to a post to Team Ada, so I conclude that either 1)
the vendors do not have much interest, or 2) they don't follow team Ada.

I do know that there is an justifiable unwillingness by at least one vendor
to distribute unsupported software of any kind or origin.

Re: why not

[Marin David Condic]

Well, that's a bit of a disappointment.

While I understand a reluctance to distribute someone else's software -
especially if it is unsupported - you have to wonder how any sort of
standard utilities are supposed to make it into the language with that sort
of policy. Its too hard - and probably undesirable - to try to get some
specifications into the ARM. The vendors may all have their own utilities
they are trying to hawk, but that leaves the end user adopting something
that ties them to a vendor. Is there no possible mechanism by which one or
more vendors could agree to include some component library? (A rising tide
lifts all boats would be my argument to favor that. Making Ada more useful
would help increase the size of the pie to compete over.)

How exactly did STL get into C++?

How exactly did ASIS gain any acceptance and is this a model by which a
component library could get into the picture?

Is this a case of Ada once again getting too stodgy, too demanding, too
rigid, too formal, too theoretical and once again conceding ground to other
languages that seem to be more able to adapt to user's needs?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:1nDC7.180$6S7.92255364@newssvr11.news.prodigy.com...
>
> I've received no answers to a post to Team Ada, so I conclude that either
1)
> the vendors do not have much interest, or 2) they don't follow team Ada.
>
> I do know that there is an justifiable unwillingness by at least one
vendor
> to distribute unsupported software of any kind or origin.
>

Re: why not

[Barry Kelly]

In article <9rjsak$bp3$1@nh.pace.co.uk>
	"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>
wrote:

> How exactly did STL get into C++?

Stepanov wrote a generic library (initially in Ada 83, IIRC), then
wrote a new one for C++. Somebody (I can't remember who exactly) asked
if he'd considered trying to get it accepted as a standard library
addition proposal. It was late in the standardization cycle; he got
support of many of the key members, and he rewrote the documentation
to get it up to standardese standard, as it were.

The story is someplace on the net; doubtless a little searching will
turn it up.

-- Barry

Re: why not

[Marin David Condic]

Well, that creates a clue as to how it might get done in Ada. However, I've
heard here in the past objections from compiler vendors to adding this sort
of library to the ARM as a part of the standard. Part of the problem is
specifying the behavior in sufficient detail to make it verifiable. There is
also a certain amount of inflexibility once it gets into the standard.

I suppose some library could be identified and submitted to the appropriate
keepers-of-the-standard, but that would obviously require a long time before
it ever got in there. I'd think it would be easier if a few vendors were to
state their willingness to adopt some TBD library that met some TBD minimal
requirements and then let an informal committee (under SIGAda?) identify or
develop something that met those requirements. Keep it simple & minimal so
that it constitutes A Good Start & the vendors are free to accept/reject it
for any reasons they like.

Would the Ada community prefer to see it as a part of the ARM and wait until
Ada0x for it to be realized? Would the Ada0x committee be willing to
consider it? I would opt for something informal at first and see if it had
sufficient utility to earn a place in the standard. There's a lot less risk
that way.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Barry Kelly" <dynagen@eircom.net> wrote in message
news:jbfstt097fvrrqmrl0kuscmbl57neg8imf@4ax.com...
>
> Stepanov wrote a generic library (initially in Ada 83, IIRC), then
> wrote a new one for C++. Somebody (I can't remember who exactly) asked
> if he'd considered trying to get it accepted as a standard library
> addition proposal. It was late in the standardization cycle; he got
> support of many of the key members, and he rewrote the documentation
> to get it up to standardese standard, as it were.
>
> The story is someplace on the net; doubtless a little searching will
> turn it up.
>

Re: why not

[Pascal Obry]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Well, that creates a clue as to how it might get done in Ada. However, I've
> heard here in the past objections from compiler vendors to adding this sort
> of library to the ARM as a part of the standard. Part of the problem is
> specifying the behavior in sufficient detail to make it verifiable. There is
> also a certain amount of inflexibility once it gets into the standard.

Well this was maybe because Ada83 had no annexes. Now that we have annexes in
Ada95 I think this is quite different. Just put this stuff into an annexes.

I really think that this kind of libraries should be a part of Ada95. If some
peoples object about verifiability then I think that this annexes could be
named Unchecked_And_Very_Dangerous_Library :)

Most part of the application domain where Ada is designed to be used just do
not ask for verifiabilily.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: why not

[Marin David Condic]

I would shed about as many tears over it making its way into an annex as I
did over Ada.Strings... making it into an annex. However, I imagine that
process would be a bit cumbersome and less likely to happen. I can't
begrudge the vendors objecting to something that is poorly defined and/or
difficult to verify being in the standard since this could cause them lots
of trouble getting their compilers validated. That's why I'd accept
something as an informal, de-facto standard rather than an ARM annex. IOW,
if there is some pile of source that they can simply adopt and it is what it
is with no guarantees about behavior, it makes a start at something that
might eventually be formally standardized.

If you look at something like C, you notice how there were originally no
"standard" libraries of useful functions for things like strings, etc. Its
just that most implementations shipped with these function libraries in some
form - often not entirely compatible. Yet there they were. People used them.
Eventually, they got to be such common fixtures that ANSI C ended up
including them.

Granted, C has a much more "sloppy" history with respect to standards and
verification, but it *did* enable some creative inovations to work their way
into the language. I don't see anything wrong with one or more vendors
providing something equivalent in Ada and, if it gains some acceptance &
standardization, eventually getting it into an annex.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:ud735kqak.fsf@wanadoo.fr...
>
> Well this was maybe because Ada83 had no annexes. Now that we have annexes
in
> Ada95 I think this is quite different. Just put this stuff into an
annexes.
>
> I really think that this kind of libraries should be a part of Ada95. If
some
> peoples object about verifiability then I think that this annexes could be
> named Unchecked_And_Very_Dangerous_Library :)
>
> Most part of the application domain where Ada is designed to be used just
do
> not ask for verifiabilily.
>

Re: why not

[Darren New]

Marin David Condic wrote:
> Part of the problem is
> specifying the behavior in sufficient detail to make it verifiable.

That's what ADTs are supposed to be for. (Not ADT's in the computer
programming sense. ADTs in the "Abstract Data Type" sense, the
mathematical sense.)

It's not hard. It's just that most programmers think ADTs have (say)
implementations and such.

> There is
> also a certain amount of inflexibility once it gets into the standard.

I thought that was the point, yes? Inflexible == you can rely on it not
changing?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: why not

[Marin David Condic]

"Darren New" <dnew@san.rr.com> wrote in message
news:3BDEF0FE.B55FED9E@san.rr.com...
> Marin David Condic wrote:
> > Part of the problem is
> > specifying the behavior in sufficient detail to make it verifiable.
>
> That's what ADTs are supposed to be for. (Not ADT's in the computer
> programming sense. ADTs in the "Abstract Data Type" sense, the
> mathematical sense.)
>
> It's not hard. It's just that most programmers think ADTs have (say)
> implementations and such.
>

Perhaps. But not all things in the known universe are ADTs. Some TBD
collection of utilities to be added to Ada might be useful, but not
mathematically verifiable, or at all simple to write a detailed enough
standard for that it can be readily verified by some means. (Think for
example what it might mean if part of your collection of tools were to
connect up to the OS for some kinds of services? OS Services might vary
enough that it would be difficult to demonstrate that you are in compliance
with the spirit and/or letter of the law.) I'm not saying it can't be done.
Look over Ada.Strings... - it has a reasonably detailed description that can
apparently be verified. But getting to that point might not be a simple
matter.

Its an objection I have heard here from vendors in the past. It might be
some disguised version of "That's a lot of work and I don't want to spend
time and company resources doing that...", but if it is objected to for any
reason, it isn't going to make it into an implementation. Hence, you need
some kind of buy-in from the implementors.

> > There is
> > also a certain amount of inflexibility once it gets into the standard.
>
> I thought that was the point, yes? Inflexible == you can rely on it not
> changing?
>
Yes, but..... Until you have a collection of code (or at least interfaces)
that have maybe built up some experience with usability, you aren't sure if
this is quite what the world wants. While extensions might be easily cobbled
in by the casual coder (extending the packages, changing the interfaces,
etc...) its kind of hard to go back to the standard and say "See that
chapter? Let's gut it and start over..." I think until you have a collection
of stuff that has a little bit of practical usage behind it, it might be
best to avoid enshrining it in a standard where changes are really hard to
make.

Like I said, I'm not against the idea of it worming its way into an annex in
the fullness of time, but I think it would be a good idea to build up some
informal semi-standard first just to let it have a little time to evolve.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: why not

[Darren New]

Marin David Condic wrote:
> Perhaps. But not all things in the known universe are ADTs. 

Yes, but I thought we were talking about collection classes.

> Yes, but..... Until you have a collection of code (or at least interfaces)
> that have maybe built up some experience with usability, you aren't sure if
> this is quite what the world wants. 

True. But for something like collection classes, maps and lists and
stuff like that, I think there's a fair amount of experience as to what
kinds of functionality folks want. Avoiding reinventing the same thing
over and over is part of the reason for such a package, implying that
folks have done this over and over.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: why not

[Marin David Condic]

Well, we aren't exactly seeing a huge consensus here about what people want,
right? :-)

I just think it would be easier to start with something that is informally
used in lots of places before proposing a change to the Ada standard with
something with which there is potentially little experience.

I think you'll find the compiler vendors are the ones who would raise
objections to a container library as an appendix. Maybe I shouldn't try to
state their case for them, but prior discussions seemed to go in the
direction that it would be hard to write a verifiable standard and that the
language standard wasn't the proper place for it.

Since apparently C++ has succeeded in including a similar library in its
standard, I wouldn't think the task is either impossible or totally
undesirable. I'd just favor a more gradual approach.

But if you want to crusade to get the Booch Components or some other
collection of containers adopted as an appendix to the ARM, I won't try to
stop you. I'd just bet against it unless there had already been some sort of
reasonably widespread adoption by the vendors. (Look at Ada.Numerics. That
got in because just about all compilers had *some* kind of numerics library
providing *some* common features. It thus made sense to have a standard
interface to what was already going on. Do we have any evidence of compilers
being supplied with *any* container packages? If a few were, then you'd have
a case for adoption as part of the language standard.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Darren New" <dnew@san.rr.com> wrote in message
news:3BDF1F13.4B99361C@san.rr.com...
> Marin David Condic wrote:
> > Yes, but..... Until you have a collection of code (or at least
interfaces)
> > that have maybe built up some experience with usability, you aren't sure
if
> > this is quite what the world wants.
>
> True. But for something like collection classes, maps and lists and
> stuff like that, I think there's a fair amount of experience as to what
> kinds of functionality folks want. Avoiding reinventing the same thing
> over and over is part of the reason for such a package, implying that
> folks have done this over and over.
>

Re: why not

[Hyman Rosen]

Marin David Condic wrote:

> Since apparently C++ has succeeded in including a similar library in its
> standard, I wouldn't think the task is either impossible or totally
> undesirable. I'd just favor a more gradual approach.


It's difficult for non-experts in C++ to realize just how inspired the STL
really is. When the C++ standardization committee was presented with the
concept, I think they were completely bowled over. It wasn't just that they
decided to adopt the library as part of the standard. The construction of
the STL requires a great deal of support from the template system, so the
adoption of the STL required careful specification in the rest of the
Standard so that things would work as expected. And STL algorithms can work
with raw pointers as easily as they work with more complicated container
iterators. And member templates fit in neatly as well in many places.

Scott Meyers writes in _Effective STL_ that he everywhere encountered C++
programmers who were determined to use STL despite buggy implementations
and buggy compilers.


I think that the equivalent library for Ada has yet to be written, because
if it existed, there wouldn't be much argument about whether it should be
adopted.

Re: why not

[David Botton]

I think that the Ada culture is different than the C++ culture. We wouldn't
be determined to use a library with buggy implementations :-)

For that reason something like STL (which I am a heavy user of for many
years) which in its very design is prone to buggy implementations, difficult
to maintain and easily misused by programmers will likely never be
standardized as part of Ada.

David Botton

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3BDF8C59.5020108@mail.com...

> Scott Meyers writes in _Effective STL_ that he everywhere encountered C++
> programmers who were determined to use STL despite buggy implementations
> and buggy compilers.
>
>
> I think that the equivalent library for Ada has yet to be written, because
> if it existed, there wouldn't be much argument about whether it should be
> adopted.
>

Re: why not

[Matthew Heaney]

"David Botton" <David@Botton.com> wrote in message
news:tu014vtnua0j60@corp.supernews.com...
> For that reason something like STL (which I am a heavy user of for many
> years) which in its very design is prone to buggy implementations,
difficult
> to maintain and easily misused by programmers will likely never be
> standardized as part of Ada.

Ada needs as part of its standard library a minimal set of data structures.
It doesn't have to be as elaborate as the STL.  At a minimum something like
an STL list, parameterized with an item type that is nonlimited and
definite.  I wouldn't even miss the algorithm part of the STL -- but we do
need the data structures.

I agree with David that there is a culture difference between Ada and C++.
For example, in C++ I can do this:

void f()
{
   typedef std::list<int> intlist_t;

   intlist_t::iterator iter;

   {
      intlist_t intlist;
      intlist.push_front(0);
      ...
      iter = intlist.begin();
   }

   int i = *iter;  //ouch!
}

Among C++ programmers, you would probably just be told "don't do this"
(which is OK by me -- I happen to like the STL).  But in the Ada culture we
would try to design a component such that this scenario couldn't happen (or
at least have a run-time error of some kind).

So it's not clear that components exactly like the STL would ever be adopted
by the standards commitee.

An Ada STL would probably look something like this:

procedure Op is
   List : aliased Integer_Lists.List_Type;
begin
   ...
   declare
      Iter : Integer_Lists.Iterator_Type (List'Access);
   begin
      ...
   end;
...
end Op;

Re: why not

[Marin David Condic]

Perhaps you would agree with my proposal that a first cut at a standard
component library could start with some basic form of Lists and Maps? I'd
like to see an informal adoption of a handful of packages that let the user
make lists (sorted? unsorted?) of basic data types (things like Integers,
Strings, plain vanilla records, ...) and Maps of similar items. If that made
it into the standard eventually, I wouldn't be unhappy about it, but if we
got a consensus going that at least this much should be included as
something most Ada implementations support, I think we'd have something
there.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Matthew Heaney" <mheaney@on2.com> wrote in message
news:tu07apsr9hcp78@corp.supernews.com...
>
> Ada needs as part of its standard library a minimal set of data
structures.
> It doesn't have to be as elaborate as the STL.  At a minimum something
like
> an STL list, parameterized with an item type that is nonlimited and
> definite.  I wouldn't even miss the algorithm part of the STL -- but we do
> need the data structures.
>

Re: why not

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9rp9bk$6m9$1@nh.pace.co.uk...
> Perhaps you would agree with my proposal that a first cut at a standard
> component library could start with some basic form of Lists and Maps?

We could start with an unbounded, doubly-linked list, a la STL std::list.

>  I'd
> like to see an informal adoption of a handful of packages that let the
user
> make lists (sorted? unsorted?) of basic data types (things like Integers,
> Strings, plain vanilla records, ...) and Maps of similar items.

The element type that is nonlimited and definite.  (Type String all by
itself would NOT be supported, because that type is unconstrained.)

The container itself doesn't do sorting.  (I assume there would be a
separate algorithms package, that operates on iterators.  That influences
what iterator types look like.)

Here's one idea:

generic
   type Element_Type is private;
   with function "=" (L, R : Element_Type) return Boolean is <>;
package Ada.Lists_Unbounded is

   type List_Type is private;

   procedure Push_Front (List : in out List_Type; Element : in
Element_Type);

   procedure Push_Back (List : in out List_Type; Element : in Element_Type);

   procedure Clear (List : in out List_Type);
...
   type Iterator_Type (List : access List_Type) is limited private;

   type Constant_Iterator_Type (List : access constant List_Type) is limited
private;

   type Reverse_Iterator_Type (List : access List_Type) is limited private;

   type Constant_Reverse_Iterator_Type (List : access constant List_Type) is
limited private;
...
end;

You have to decide whether the List_Type is limited or nonlimited.  The
latter implies that List_Type must privately derives from Controlled.

You have to decide whether the List_Type will automatically Clear itself
when its lifetime ends.  Your answer would influence whether List_Type is
Controlled.

The decision to be Controlled influences where the generic may be
instantiated (say, only a library scope).

Note that not automatically reclaiming memory by the list itself isn't such
a bad thing, because you can include another component in the library to do
this, like this:

generic
   type Container_Type (<>) is limited private;
   with procedure Clear (Container : in out Container_Type) is <>;
package Container_Control is

   type Control_Type (Container : access Container_Type) is limited private;
...
end;

declare
   List : aliased List_Type;
   Control : Control_Type (List'Access);
begin
   ... use list
end;

When the scope ends, Control is finalized, and during its Finalization it
calls Clear (Container).

Not making the container types controlled will make them more efficient, but
introduce the possibility for memory leaks (if the client doesn't also use a
helper type, as above).

Of course the containers should NOT be task safe.  Threading behavior can be
handled by the client himself, by combining a sequential container type with
other language primitives.  This is consistent with how the rest of the
predefined library has been designed.

Re: why not

[Ted Dennison]

In article <tu0i54ndv2q94d@corp.supernews.com>, Matthew Heaney says...
>"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
>message news:9rp9bk$6m9$1@nh.pace.co.uk...
>> Perhaps you would agree with my proposal that a first cut at a standard
>> component library could start with some basic form of Lists and Maps?
>The container itself doesn't do sorting.  (I assume there would be a
>separate algorithms package, that operates on iterators.  That influences
>what iterator types look like.)

How can you make sorting separate, when you don't know (and don't have access
to) the internal structure of the collection? A Map might be implemented as a
linked list, or as some sort of binary tree. At the least, your collection will
need some kind of "swap" or "insert_in_the_middle" operation to support this.
Well...I supose if you use the right algorithm and representations, you could
progressively build a new sorted collection from an old unsorted one, then
replace the old one with the new one.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Matthew Heaney]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:PMdE7.8703$xS6.11455@www.newsranger.com...
> In article <tu0i54ndv2q94d@corp.supernews.com>, Matthew Heaney says...
> >The container itself doesn't do sorting.  (I assume there would be a
> >separate algorithms package, that operates on iterators.  That influences
> >what iterator types look like.)
>
> How can you make sorting separate, when you don't know (and don't have
access
> to) the internal structure of the collection?

That's what the STL does.  Algorithms operate on an abstract "sequence",
specified via iterators.  Algorithms don't operate on container objects
directly.

> A Map might be implemented as a
> linked list, or as some sort of binary tree.

The STL uses red-black trees.

> At the least, your collection will
> need some kind of "swap" or "insert_in_the_middle" operation to support
this.

These are iterator operations.

Re: why not

[Marin David Condic]

I agree. Sorting needs to be inside of the data structure - not done
externally. However, it isn't clear if the container should always be
sortable or not. For example, if it is implemented as a generic and the
parameter is private, you don't have the operations one would need on an
ordinal type to do the sorting. (Too bad Ada didn't provide generic
parameters of "Ordinal" and "Scalar" so you could presume the existence of
comparison or arithmetic operators. Hmmmmm.....) If you bring in "<" and "="
as function parameters, you can then insert/sort in ascending/descending
order as required - but now you impose that requirement on all things that
might be stored in the container. What if the items being stored are not
ordinal? Or you have no need of sorting?

You probably need two flavors of list there - one that accepts a private
type with no ordinal operations and one that has ordinal operations. Then
you need a flavor of unsorted lists that take limited types and have an
imported assignment operation. Then you need them in static vs dynamic
colors. Then you need them in protected and unprotected genders. Then you
need them......... (No wonder they aren't already in the standard! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:PMdE7.8703$xS6.11455@www.newsranger.com...
> In article <tu0i54ndv2q94d@corp.supernews.com>, Matthew Heaney says...
>
> How can you make sorting separate, when you don't know (and don't have
access
> to) the internal structure of the collection? A Map might be implemented
as a
> linked list, or as some sort of binary tree. At the least, your collection
will
> need some kind of "swap" or "insert_in_the_middle" operation to support
this.
> Well...I supose if you use the right algorithm and representations, you
could
> progressively build a new sorted collection from an old unsorted one, then
> replace the old one with the new one.
>

Re: why not

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9rrtkt$bum$1@nh.pace.co.uk...
> I agree. Sorting needs to be inside of the data structure - not done
> externally.

Not necessarily.  Sorting can done by a separate sort algorithm that
operates on items via iterators.  Or it can be a generic child function (see
below).


> However, it isn't clear if the container should always be
> sortable or not.

"Containers" are never sortable.  "Sequences" are, assuming the element type
has a comparison operator.  But see the example below.

> For example, if it is implemented as a generic and the
> parameter is private, you don't have the operations one would need on an
> ordinal type to do the sorting.

This is the conversion Mark L and I had on CLA a couple of days ago.

If the sort operation is part of the container itself, then you just import
the operator(s) you need as a child function:

generic
   type Element_Type is private;
--with function "=" (L, R : Element_Type) return Boolean is <>; --maybe
--with function Is_Equal (L, R : Element_Type) return Boolean is
"="; --maybe
package Lists is
   type List_Type is limited private;
... no, there is no sort op here!
end;

generic
   with function "<" (L, R : Element_Type) return Boolean is <>;
procedure Lists.Generic_Sort (List : in out List_Type);

No, do NOT import comparison operators in the formal part of  the list
package.  Import the necessary operators from a generic child function.



> (Too bad Ada didn't provide generic
> parameters of "Ordinal" and "Scalar" so you could presume the existence of
> comparison or arithmetic operators. Hmmmmm.....) If you bring in "<" and
"="
> as function parameters, you can then insert/sort in ascending/descending
> order as required - but now you impose that requirement on all things that
> might be stored in the container. What if the items being stored are not
> ordinal? Or you have no need of sorting?

No.  If you want to sort the container, then you can instantiate the generic
child function separately.

> You probably need two flavors of list there - one that accepts a private
> type with no ordinal operations and one that has ordinal operations.

No.

> Then
> you need a flavor of unsorted lists that take limited types and have an
> imported assignment operation.

Support of the limited element types is deferred pending discovery of
characteristics of container types that have nonlimited and definite
elements.

> Then you need them in static vs dynamic
> colors.

Don't know what you mean.

> Then you need them in protected and unprotected genders. Then you
> need them......... (No wonder they aren't already in the standard! :-)

No.  The library prescribes only unprotected ("sequential" ) forms.  It's up
to the developer to add concurrency semantics himself, using other
primitives already in the language.  Just like Text_IO.   Just like
Discrete_Random.

Re: why not

[Ehud Lamm]

Matthew Heaney <mheaney@on2.com> wrote in message
news:tu3223ruonn210@corp.supernews.com...
> Not necessarily.  Sorting can done by a separate sort algorithm that
> operates on items via iterators.  Or it can be a generic child function

I suggested this design but nobody seemed to really like it.
At the very least the algorithms should be in a collective child package.
Many users don't need them, and this helps control the complexity and
learning curve.

Ehud

Re: why not

[Ted Dennison]

In article <9sml2i$q9b$1@news.huji.ac.il>, Ehud Lamm says...
>
>I suggested this design but nobody seemed to really like it.
>At the very least the algorithms should be in a collective child package.
>Many users don't need them, and this helps control the complexity and
>learning curve.

I thought it was a bad idea just because any such child package would have to be
instantiated from the parent package (that's the way generic children work), and
there seemed to be agreement that that was a Bad Thing. Plus the "parent"
package is hardly so big that it requires splitting up.

However, if its a rarely-using thing (advanced users only), perhaps it isn't so
bad to have it somewhere else. Plus Sort is *already* a generic. I'm still not
sure about the advisability of moving Sort though. I don't really see what it
hurts where it is, and I don't like the idea of a lot of single routine child
packages, or of one "extra stuff that you don't need often" child package. (To
me "algorithms" is about as general as "stuff"). I like my packages to have at
least a small amount of weight to them (more than 2 routines or so), and to have
strong cohesion.

In particular, I don't see "Sort" being much more than 10-40 SLOC. I could be
wrong, as no-one's started work on an implementation yet.

What precisely would you propose to include in "Algorithms" (or "stuff")?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Marin David Condic]

Depends on if its Stuff That Sucks, or Stuff Thats Cool. :-)

I'd agree that "Algorithms" sounds just about like "Stuff" - here's this bag
for all the unrelated things we couldn't find a place for. However, there
are often things that may have nothing more in common than they operate on
some particular data structure. Maybe it just needs to be lived with.... Or
have a Big Giant Package Spec that defines every conceivable operation on a
data structure.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:olTH7.21844$xS6.33537@www.newsranger.com...
> hurts where it is, and I don't like the idea of a lot of single routine
child
> packages, or of one "extra stuff that you don't need often" child package.
(To
> me "algorithms" is about as general as "stuff"). I like my packages to
have at

Re: why not

[Jeffrey Carter]

Ted Dennison wrote:
> 
> In particular, I don't see "Sort" being much more than 10-40 SLOC. I could be
> wrong, as no-one's started work on an implementation yet.

PragmARC.List_Unbounded_Unprotected contains a merge sort on a list.
It's about 110 physical lines, including lots of blank lines.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail

Re: why not

[Ted Dennison]

In article <3BF08874.BB5E904B@acm.org>, Jeffrey Carter says...
>
>Ted Dennison wrote:
>> 
>> In particular, I don't see "Sort" being much more than 10-40 SLOC. I could be
>> wrong, as no-one's started work on an implementation yet.
>
>PragmARC.List_Unbounded_Unprotected contains a merge sort on a list.
>It's about 110 physical lines, including lots of blank lines.

Well...I may very well *be* wrong on this then. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Hyman Rosen]

Marin David Condic wrote:

> Sorting needs to be inside of the data structure - not done
> externally.


Not necessarily. In the C++ STL, for example, sort algorithms
work on ranges, specified by the usual half-open interval using
a pair of iterators. But the iterators must be random-access
(pointer abstractions - you can add an integer to them to get
another valid one, and the difference of two is the number of
elements in the interval), so you can sort within vectors,
deques, strings, and plain arrays, but not within lists or maps.

Trying to sort with the wrong kind of iterators fails to compile,
so you don't get the usual unsafe crashes.

There are also algorithms which require a sorted range, and in
that case you can, for example, use iterators into a map, since
the map is implicitly sorted.

Re: why not

[Hyman Rosen]

Matthew Heaney wrote:

> Among C++ programmers, you would probably just be told "don't do this"
> (which is OK by me -- I happen to like the STL).  But in the Ada culture we
> would try to design a component such that this scenario couldn't happen (or
> at least have a run-time error of some kind).
> 
> So it's not clear that components exactly like the STL would ever be adopted
> by the standards commitee.

In fact, there are "safe STL" implementations which would catch such errors.
You specify at compile time whether the checking code should be enabled.
The checking actually goes a little further, to implement "concept checks".
That is, since C++ template type parameters don't offer the ability to specify
requirements on the type, concept checkers do this. They can catch errors at
compile time, and are implemented by various template tricks that true C++
fans adore and which would probably drive true Ada fans up a wall :-)

Of course, the C++ default mode is unsafe :-)

Anyway, that's what I was getting at. The STL is perfect for C++. If there was
a library that was perfect for Ada, you would know it, and everyone would be
champing at the bit to standardize it.

Re: why not

[Ted Dennison]

In article <tu07apsr9hcp78@corp.supernews.com>, Matthew Heaney says...
>Ada needs as part of its standard library a minimal set of data structures.
>It doesn't have to be as elaborate as the STL.  At a minimum something like
>an STL list, parameterized with an item type that is nonlimited and
>definite.  I wouldn't even miss the algorithm part of the STL -- but we do
>need the data structures.

I certianly don't think we need STL's "vector", as that's essentially just a
bounds-checked array, which Ada already has. (OK, it auto resizes too, but I
don't like that feature anyway).

However, Maps should probably be in there too. That's what caused my last
project to use Booch.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Ehud Lamm]

As far as I recall from reading an interview with Stepanov, Stroustup was
personally involved in trying to get consensus for the STL, when many on the
standard board were afraid of the magnitude of the changes.

Ehud

Re: why not

[Darren New]

Marin David Condic wrote:
> Well, we aren't exactly seeing a huge consensus here about what people want,
> right? :-)

I think everyone is pretty much agreeing that what's needed are lists
and maps, both task safe and efficient versions. The rest is just
details. ;-)

> I just think it would be easier to start with something that is informally
> used in lots of places before proposing a change to the Ada standard with
> something with which there is potentially little experience.

No question. But then it's harder to precisely specify what the behavior
is without saying "it behaves like this implementation."
 
> I think you'll find the compiler vendors are the ones who would raise
> objections to a container library as an appendix. Maybe I shouldn't try to
> state their case for them, but prior discussions seemed to go in the
> direction that it would be hard to write a verifiable standard and that the
> language standard wasn't the proper place for it.

Right. And my point was that for simple data structures, it's really not
that hard if you use the appropriate tools, like ADTs. It's very easy,
for example, to specify what a sort routine does, without looking at the
implementation at all.

Just as performance is difficult to describe unless you know about
Big-Oh notation, verifiability is difficult unless you know about the
mathematical tools that let you do verification. Even things like
specifying tasks isn't all that difficult. Verifying it in complex
situations can be harder, sure.

> Since apparently C++ has succeeded in including a similar library in its
> standard, I wouldn't think the task is either impossible or totally
> undesirable. I'd just favor a more gradual approach.

But have they succeeded? It took years before any of the STL
implementations were compatible and correct, IIRC.
 
> But if you want to crusade to get the Booch Components or some other
> collection of containers adopted as an appendix to the ARM, I won't try to
> stop you.

Me, personally, I'd like to have container classes that are simpler,
since I'm only up to doing simple stuff so far with Ada. Other folks do
wild and wooly complex deep-magic stuff with Ada, and then make it blow
up. ;-) I'm not sure it would be easy to write one library that works
well for both, just because of how complex Ada is.

As far as what the spec looks like, I'd like to see the collection
classes defined as ADTs, with restrictions on the order statistics of
the implementations. Kind of like the AT&T C++ libraries. Personally,
I'd also think that a couple of relatively simple structures (like, an
Unbounded_Array paralleling Unbounded_String, some sort of efficient
Map, some sort of sorted/sortable relational-database-like table
allowing one to sort on multiple columns, select multiple rows, etc)
would be a good start for collection units.

A set of units for some general stuff like logging and configuration and
inter-process synchronization would be helpful. Stuff to manage
directory manipulations (scanning for files in a directory, deleting
files, creating directories, setting permissions, etc) would be good. 

I also think a nice internet library would be useful as well, at least
for me. Something to parse MIME and XML, something to handle sockets,
something for FTP and POP and SMTP and CGI and such, something for
TLS/SSL. I think I've seen pretty much all of this out there, except
maybe the MIME parser.

Of course, all this would need to be at least mostly-portable and
supported, but most of all available in a fairly centralized place where
it's easy to find.

Maybe this kind of resource is already out there and I just have either
not really found it or I've not looked at it long enough or it just
needs a slightly better index or something. (I know about adapower,
thanks ;-)

Anyway, I guess I'll stop babbling now.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: why not

[Matthew Heaney]

"Darren New" <dnew@san.rr.com> wrote in message
news:3BE03E54.57E0E6C8@san.rr.com...
> Marin David Condic wrote:
> > Well, we aren't exactly seeing a huge consensus here about what people
want,
> > right? :-)
>
> I think everyone is pretty much agreeing that what's needed are lists
> and maps, both task safe and efficient versions. The rest is just
> details. ;-)

We certainly do NOT agree that data structures should be "task safe."  If a
user needs a data structure to work in the presence of multiple threads,
then he needs to build those semantics himself using other primitives
provided by the language.  This is completely consistent with how Text_IO
and Numerics.Discrete_Random (for example) are defined.

> No question. But then it's harder to precisely specify what the behavior
> is without saying "it behaves like this implementation."

You need to specify time and space semantics for any abstraction.  This is a
solved problem.

> > Since apparently C++ has succeeded in including a similar library in its
> > standard, I wouldn't think the task is either impossible or totally
> > undesirable. I'd just favor a more gradual approach.
>
> But have they succeeded? It took years before any of the STL
> implementations were compatible and correct, IIRC.

FUD.  Of course they succeeded.  C++ is vastly simpler to use now that the
STL is part of the standard.

Re: why not

[Darren New]

Matthew Heaney wrote:
> > I think everyone is pretty much agreeing that what's needed are lists
> > and maps, both task safe and efficient versions. The rest is just
> > details. ;-)
> 
> We certainly do NOT agree that data structures should be "task safe."

Sorry. I meant to say that versions that are task safe are needed in
addition to versions that are not task safe. Not that the only versions
should be task safe. And not that only one task-safe version is needed.

>  If a
> user needs a data structure to work in the presence of multiple threads,
> then he needs to build those semantics himself using other primitives
> provided by the language.

Well, I figured there'd be the unsafe version (the "efficient version"
above) and a safe version, like a protected wrapper for the unsafe
version. Of course, if something even more complex is needed, then sure,
it can be built.

> > No question. But then it's harder to precisely specify what the behavior
> > is without saying "it behaves like this implementation."
> 
> You need to specify time and space semantics for any abstraction.  This is a
> solved problem.

Right. It seems like you've misunderstood what I was trying to say. I
was simply saying that trying to specify the time, space, and result
semantics of the Booch components would be pointless if you can just
point at the implementation and say "do this." If you're going to make a
more abstract interface that can be implemented in a variety of ways,
it's easier to specify the time, space, and semantics of the operations
on a more simple interface than it is to try to deduce them from an
existant implementation as complex as Booch.

> > > Since apparently C++ has succeeded in including a similar library in its
> > > standard, I wouldn't think the task is either impossible or totally
> > > undesirable. I'd just favor a more gradual approach.
> >
> > But have they succeeded? It took years before any of the STL
> > implementations were compatible and correct, IIRC.
> 
> FUD.  Of course they succeeded.  C++ is vastly simpler to use now that the
> STL is part of the standard.

Um, I meant more like "how long did it take all the implementations of
STL to actually match the spec." Not that *now* it doesn't match, but
that just because it was in the standard for C++ didn't mean you could
rely on it. I.e., as another poster said, people were willing to use
buggy STLs, which they might not be willing to use in Ada.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: why not

[Marin David Condic]

Hypothetically speaking, you could take a library of utilities, specs *and*
bodies, and tack them onto the ARM and say "The following source code shall
be provided as part of the implementation of Ada..." and that pretty much
takes care of any sort of verification.  There are obvious problems with
this - such as not guaranteeing that any of it works at all and not
stipulating what sort of results should come out of it, but it *is* a kind
of standard.

If you look at the standard libraries of functions that come with ANSI C,
you notice that they aren't horribly well thought out and the definitions
are not terribly mathematically precise, but they *are* useful and they
generally *do* function as expected across a variety of implementations. It
got that way because implementations of C started sharing common libraries
of source code that gradually became accepted as being part of the
language - even though they weren't really part of "Standard C". One
compiler is out there with library source available. Other compiler projects
picked up on the libraries and either duplicated them or licensed them or
otherwise started sharing what was there. Pretty soon, everyone just expects
"strchr" and "malloc" and such to be there, just because every
implementation has them. ANSI C comes out and - Bam! - its been kicked up a
notch by requiring a set of standard libraries. Ada might be able to do the
same thing - albeit with a bit more rigor than we are used to seeing with C.

Assuming something is agreed upon as a desirable set of packages and some
implementation is available under favorable license terms and compiler
vendors start bundling it with their compiler, I don't see anything wrong
with saying "See that implementation over there? That constitutes the
standard..."

Of course I don't believe it has to be part of the ARM at all. I think it
would be just as useful and acceptable if there *was* an implementation that
was commonly included with most compilers. Maybe it should be driven by the
grass roots and maybe it should be driven by the vendors, but I don't think
it needs to start with the ARM.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Darren New" <dnew@san.rr.com> wrote in message
news:3BE05304.5AB6862D@san.rr.com...
> > > No question. But then it's harder to precisely specify what the
behavior
> > > is without saying "it behaves like this implementation."
> >
> > You need to specify time and space semantics for any abstraction.  This
is a
> > solved problem.
>
> Right. It seems like you've misunderstood what I was trying to say. I
> was simply saying that trying to specify the time, space, and result
> semantics of the Booch components would be pointless if you can just
> point at the implementation and say "do this." If you're going to make a
> more abstract interface that can be implemented in a variety of ways,
> it's easier to specify the time, space, and semantics of the operations
> on a more simple interface than it is to try to deduce them from an
> existant implementation as complex as Booch.
>

Re: why not

[Darren New]

Marin David Condic wrote:
> Of course I don't believe it has to be part of the ARM at all. I think it
> would be just as useful and acceptable if there *was* an implementation that
> was commonly included with most compilers. Maybe it should be driven by the
> grass roots and maybe it should be driven by the vendors, but I don't think
> it needs to start with the ARM.

What I'm not clear on, being an Ada newbie, is why it needs anything
more than this. That is, shouldn't something like a data type library be
exceedingly portable? Shouldn't one be able to write something like a
red-black tree in pure Ada without relying on anything
compiler-specific? I'm not sure why GNAT's regexp, for example, needs
the GNAT compiler. I haven't looked into it at all, but I can't imagine
what could possibly be in there, given that it's basically manipulation
of arrays of characters, yes?

So what am I missing? Why would a doubly-linked list need to come with a
compiler?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: why not

[Marin David Condic]

The idea here is that there are a bunch of available container libraries
that will provide - with varying levels of detail - things like lists, maps,
trees, etc. and why not lets all settle on using just one of them so it
becomes a kind of "convention" and makes it easier to use code written by
others, easier to teach Ada to newbies, provides extra facilities within the
language, etc. Sort of like C++ adopting STL and making it part of the
language, Ada could work towards something similar and thus (eventually)
arrive at a richer language.

Why would it need to come with a compiler? It doesn't really - there are a
bunch of them you can download right now that will be usable in a number of
environments. (Will they compile on all Ada compilers? Depends on how well
built they are and if the compiler in question maybe has bugs, right? You
can *always* make a given program dependent on things that are available in
only one implementation.) You can (and should) write a container library as
a compiler independent thing and I suspect most of the ones you'll encounter
will compile/run with most compilers. Until you get there and do it though,
you don't really know that this is true.

The reason for having it come with the compiler is to encourage users to use
one, common package. In Ada83, people developed their own string handling
utilities. In Ada95, there were some nice packages provided under
Ada.Strings... and new developments almost certainly use these packages
rather than various home grown answers. When you look at that code, you
pretty much know what is going on because you are already familiar with
Ada.Strings.<whatever>. You also continue to leverage Ada.Strings.<whatever>
and speed your development time by using a common package that everyone
knows about. If a collection of data-structurey-stuff was available to you
just by virtue of coming along with the compiler, chances are you'd leverage
it the same way. (In the standard or not - if it comes along with
some/most/all compilers, you'll probably want to use it rather than building
one of your own.)

How does a component library get some kind of widespread adoption? That's
obviously an open topic for discussion here! :-) Getting some general
agreement on what it should look like is a good place to start though.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Darren New" <dnew@san.rr.com> wrote in message
news:3BE1A1D5.A1DC08AE@san.rr.com...
>
> What I'm not clear on, being an Ada newbie, is why it needs anything
> more than this. That is, shouldn't something like a data type library be
> exceedingly portable? Shouldn't one be able to write something like a
> red-black tree in pure Ada without relying on anything
> compiler-specific? I'm not sure why GNAT's regexp, for example, needs
> the GNAT compiler. I haven't looked into it at all, but I can't imagine
> what could possibly be in there, given that it's basically manipulation
> of arrays of characters, yes?
>
> So what am I missing? Why would a doubly-linked list need to come with a
> compiler?
>

Re: why not

[Larry Hazel]

Marin David Condic wrote:
> 
> How does a component library get some kind of widespread adoption? That's
> obviously an open topic for discussion here! :-) Getting some general
> agreement on what it should look like is a good place to start though.
> 
The first thing you need is an attention grabbing name.  How about
Basic Engineering & Environment Resources (BEER for short)

Larry

Re: why not

[Marin David Condic]

Oh no! Its starting already! :-)

I used to have an associate who spent large amounts of time coming up with
acronyms for things on the project. Some of them were quite clever, but you
had to wonder about the amount of time consumed in coming up with them & the
tendency to come up with such twisted collections of words that it would
obfuscate the original idea. I got the feeling that his partitioning of a
system into subsystems was driven more by the fact that he could create a
clever acronym out of it than because it represented some logical breakdown
of the project. (Imagine block diagrams with "GRAPES" ---> "PRESS" --->
"WINE" kinds of relationships.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Hazel" <lhhazel@otelco.net> wrote in message
news:3BE1C98F.1EAD55D4@otelco.net...
> The first thing you need is an attention grabbing name.  How about
> Basic Engineering & Environment Resources (BEER for short)
>

Re: why not

[Ted Dennison]

In article <9rsidr$kio$1@nh.pace.co.uk>, Marin David Condic says...
>I used to have an associate who spent large amounts of time coming up with
>acronyms for things on the project. Some of them were quite clever, but you
>had to wonder about the amount of time consumed in coming up with them & the
>tendency to come up with such twisted collections of words that it would
>obfuscate the original idea. I got the feeling that his partitioning of a
>system into subsystems was driven more by the fact that he could create a
>clever acronym out of it than because it represented some logical breakdown
>of the project. (Imagine block diagrams with "GRAPES" ---> "PRESS" --->
>"WINE" kinds of relationships.)

On my first project we had a standard where every package name had to start with
a 4 letter ID, the first letter of which had to be the letter desginating which
subproject the file belonged to. Everyone thought this was really stupid, and
the common idiom was to immdediately rename the packages after "with"ing them to
remove the wart. Since there wansn't much respect for the facility ID, of course
everyone had fun with them. My group's designator was "C", so of course I came
up with packages that started with "CAPE" and "COWS". :-)

I had a friend in anther group whose designator was "W". Over a few beers one
day we decided to name the "interface packages" we had to create with each other
"CANT_Interface" and "WONT_Interface". :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Ted Dennison]

In article <tu0gfdn5h25i11@corp.supernews.com>, Matthew Heaney says...
>
>We certainly do NOT agree that data structures should be "task safe."  If a
>user needs a data structure to work in the presence of multiple threads,
>then he needs to build those semantics himself using other primitives
>provided by the language.  This is completely consistent with how Text_IO
>and Numerics.Discrete_Random (for example) are defined.

I'm not particularly happy that Text_IO works that way (its a tremendous source
of errors), but I think I have to agree. It'd be nice to have task safe
versions, but given the state of the rest of the standard Ada library, it would
probably be more consistent *not* to have them. However, an instantiation of the
facility should be task safe when *different* container objects are being used
(no globals).


>
>> No question. But then it's harder to precisely specify what the behavior
>> is without saying "it behaves like this implementation."
>
>You need to specify time and space semantics for any abstraction.  This is a
>solved problem.
>
>> > Since apparently C++ has succeeded in including a similar library in its
>> > standard, I wouldn't think the task is either impossible or totally
>> > undesirable. I'd just favor a more gradual approach.
>>
>> But have they succeeded? It took years before any of the STL
>> implementations were compatible and correct, IIRC.
>
>FUD.  Of course they succeeded.  C++ is vastly simpler to use now that the
>STL is part of the standard.
>
>
>
>

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Marin David Condic]

Well, O.K. Maybe we could agree that the Mark 1, Mod 0, Standard Issue,
Plain Vanilla version of the standard component library (the one that
constitutes A Good Start) could eliminate task safety as a requirement? The
reason would be that a) you could create thread-safe versions by wrapping
them in a protected type as an exercise for the student and/or b) a later
version could have a "task-safe" branch that duplicated the interfaces but
provided internal guarantees of task safety IFF there is any significant
need for it.

We might also eliminate as a Mark 1, Mod 0 requirement the need for
bounded/static implementations. I'd be happy to see a version that used
dynamic allocation because it would be suitable for most Workstation/PC
sorts of apps that had no realtime requirements. (A large subset of the
universe of all possible applications) Any sort of bounded/static
implementations could likewise be realized in a later version if there was
any significant interest.

One could imagine a tree that looked sort of like this:

ASCL.Containers.Unbounded
ASCL.Containers.Unbounded.Lists
ASCL.Containers.Unbounded.Lists.Sorted
ASCL.Containers.Unbounded.Maps
ASCL.Containers.Unbounded.Task_Safe
ASCL.Containers.Unbounded.Task_Safe.Lists
ASCL.Containers.Unbounded.Task_Safe.Lists.Sorted
ASCL.Containers.Unbounded.Task_Safe.Maps
ASCL.Containers.Bounded
ASCL.Containers.Bounded.Lists
ASCL.Containers.Bounded.Lists.Sorted
ASCL.Containers.Bounded.Maps
ASCL.Containers.Bounded.Task_Safe
ASCL.Containers.Bounded.Task_Safe.Lists
ASCL.Containers.Bounded.Task_Safe.Lists.Sorted
ASCL.Containers.Bounded.Task_Safe.Maps
ASCL.Other_Stuff_That_Might_Appear_Useful_Someday.....

Concentrating on the plain ASCL.Containers.Unbounded branch first (Ignore
Task_Safe) would get a useful subset of containers available. How would that
sound as a proposal? Ideas? Votes?

BTW: Please don't pick on the names. We can always agree on a set of names
later.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:Z_dE7.8725$xS6.11497@www.newsranger.com...
> I'm not particularly happy that Text_IO works that way (its a tremendous
source
> of errors), but I think I have to agree. It'd be nice to have task safe
> versions, but given the state of the rest of the standard Ada library, it
would
> probably be more consistent *not* to have them. However, an instantiation
of the
> facility should be task safe when *different* container objects are being
used
> (no globals).
>

Re: why not

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9rrush$ckt$1@nh.pace.co.uk...
> One could imagine a tree that looked sort of like this:
> ASCL.Containers.Unbounded.Lists

Let's start here.

Re: why not

[Marin David Condic]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:tu33v69r072706@corp.supernews.com...
>
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9rrush$ckt$1@nh.pace.co.uk...
> > One could imagine a tree that looked sort of like this:
> > ASCL.Containers.Unbounded.Lists
>
> Let's start here.
>

Fine with me.

Care to propose a spec while we're waiting to see if anyone else gets on
board?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: why not

[Darren New]

Marin David Condic wrote:
> Care to propose a spec while we're waiting to see if anyone else gets on
> board?

I'd be happy to be the sample Ada newbie but otherwise knowledgable
person trying to pick holes in it so it winds up being more
understandable. ;-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: why not

[Ted Dennison]

In article <tu33v69r072706@corp.supernews.com>, Matthew Heaney says...
>
>
>"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
>message news:9rrush$ckt$1@nh.pace.co.uk...
>> One could imagine a tree that looked sort of like this:
>> ASCL.Containers.Unbounded.Lists
>
>Let's start here.

(sigh). I hate to see this devolve into our usual naming war, but...

The name seems to have been picked to be consistent with how Ada.Strings was
named. That's a fine goal on its own, but I do *not* want to see the horrible
naming mistake that those packages made (Ada.Strings.Unbounded.Unbounded_String)
duplicated here for the sake of consistency (or for the sake of anything else).
Please, no redundant information in the names!

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Marin David Condic]

O.K. Then lets not. :-) You can try really hard to get me to care what the
packages get called. It just won't work. Propose a set of names you think
will work. Call them "Monique" and "Heather" and "Ivette" if you like. (That
ought to keep things interesting! :-) What matters is that there be some
general agreement on what features will be there. If we end up in agreement
about general features, maybe we can identify an existing set of utilities
that already cover this and we can live with whatever names they already
have. If it ends up that they've got to be written from the ground up, then
we can argue about the names then. (Get your suggestions in early and maybe
they win by default. :-)

My only concern with any names is that we have some ability to separate out
branches that satisfy different categories of tools. One ought to be able to
have some level of sublibraries under a general library of add-on tools.
Things like "These over here are ADT/Container/Vessel thingies and these
things over here are Math doodads and that stuff over there is a whole bunch
of OS interface thingamajigs." We ought to be able to expand the library to
cover things besides containers. What that may be is TBD for the moment, but
lets not make that difficult.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:jcjE7.9156$xS6.12795@www.newsranger.com...
>
> (sigh). I hate to see this devolve into our usual naming war, but...
>
> The name seems to have been picked to be consistent with how Ada.Strings
was
> named. That's a fine goal on its own, but I do *not* want to see the
horrible
> naming mistake that those packages made
(Ada.Strings.Unbounded.Unbounded_String)
> duplicated here for the sake of consistency (or for the sake of anything
else).
> Please, no redundant information in the names!
>

Re: why not

[Matthew Heaney]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:jcjE7.9156$xS6.12795@www.newsranger.com...
> (sigh). I hate to see this devolve into our usual naming war, but...
>
> The name seems to have been picked to be consistent with how Ada.Strings
was
> named. That's a fine goal on its own, but I do *not* want to see the
horrible
> naming mistake that those packages made
(Ada.Strings.Unbounded.Unbounded_String)
> duplicated here for the sake of consistency (or for the sake of anything
else).
> Please, no redundant information in the names!

The intent is that you use a use clause for the Ada.Strings.* packages.
That's the motivation for their naming convention.

Re: why not

[Jacob Sparre Andersen]

Marin:

[...]
> Concentrating on the plain ASCL.Containers.Unbounded branch first (Ignore
> Task_Safe) would get a useful subset of containers available. How would that
> sound as a proposal? Ideas? Votes?

Seems sensible.

Jacob
-- 
"Genes don't matter. It's all physics."

Re: why not

[Mark Biggar]

Darren New wrote:
> 
> Marin David Condic wrote:
> > Well, we aren't exactly seeing a huge consensus here about what people want,
> > right? :-)
> 
> I think everyone is pretty much agreeing that what's needed are lists
> and maps, both task safe and efficient versions. The rest is just
> details. ;-)

I not sure here.  I thing that a list type is too low level, the actual
ADT that you want is a Dequeue ADT not Double-linked List ADT.

Just like we already have bounded and unbounded strings, we should
have bounded and unbounded Dequeues.  The fact that the later
can be implemented as a Double-linked list is an implementation
detail.

--
Mark Biggar
mark.a.biggar@home.com

Re: why not

[Marin David Condic]

If by "Dequeue" you mean "Double Ended Queue", then I disagree. A Dequeue is
a special case of a double-linked list. Data may only enter/exit from the
ends. What if you want to insert data into the middle? Strictly speaking,
the only elements that should be visible in a Dequeue would be those at the
ends, so how do you scan the entire structure? Relax the definition? By
doing so, you just move closer and closer to a doubly-linked list.

That's why I would contend that a doubly-linked list would be a good basic
starting point. You can get all the behavior of a stack, queue, dequeue and
singly-linked list out of it just by ignoring features. You get some small
additional penalty of maintaining two links per node where on some
structures you'd only need one, but in my experience it is negligable in
most applications.

A doubly-linked list and a map would cover a huge percentage of the usual
data structure usages. Anything more could be discussed and added as a
perceived need arose.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Mark Biggar" <mark.a.biggar@home.com> wrote in message
news:3BE0F8AE.3B7E5C70@home.com...
>
> I not sure here.  I thing that a list type is too low level, the actual
> ADT that you want is a Dequeue ADT not Double-linked List ADT.
>
> Just like we already have bounded and unbounded strings, we should
> have bounded and unbounded Dequeues.  The fact that the later
> can be implemented as a Double-linked list is an implementation
> detail.

Re: why not

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9rroi6$9rs$1@nh.pace.co.uk...
> That's why I would contend that a doubly-linked list would be a good basic
> starting point.  You can get all the behavior of a stack, queue, dequeue
and
> singly-linked list out of it just by ignoring features.

Yes.  A client can build a stack or a queue or a dequeue from the simpler
list primitive.

> You get some small
> additional penalty of maintaining two links per node where on some
> structures you'd only need one, but in my experience it is negligable in
> most applications.

If you need to traverse backwards, you need a doubly-linked list.

Of course, the STL has std::slist, which is a singly-linked list.  There
wouldn't be any harm in including that in the library too.

> A doubly-linked list and a map would cover a huge percentage of the usual
> data structure usages. Anything more could be discussed and added as a
> perceived need arose.

Yes.

Re: why not

[Marin David Condic]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:tu2t7oiig3e9d9@corp.supernews.com...
>
> If you need to traverse backwards, you need a doubly-linked list.
>
Obviously. Just an observation that a singly linked list would save the
overhead of extra pointers and many structures (stacks, single-ended-queues)
might benefit from the lack of the extra pointer. However, in most
instances, I'd think that the extra pointer overhead would be small enough
that you might just as well have it there plus all the operations you
*don't* need for a simple stack, just because then you've got a single
package that does the whole job.


> Of course, the STL has std::slist, which is a singly-linked list.  There
> wouldn't be any harm in including that in the library too.
>
Yes there would. Start working through all the combinations of stuff that
are being proposed:

(((Single List/Double List) * (Sorted/Unsorted)) + Map) *
(Bounded/Unbounded) * (Task Safe/Task Unsafe)

Thats 20 variants right there. We can easily envision other variants such as
Private/Limited-Private or Inherited/Generic. That's 80. The problem is to
get the number of variants down to some manageable level that covers some
reasonable amount of turf and will satisfy the largest possible body of
users. Too many variants makes it a) complex and b) unlikely to be realized.

That's why I would suggest limiting the first cut to a Double List
(Sorted/Unsorted) & Map of Unbounded, Task Unsafe variety. That gets you
down to 3 key packages that would probably cover a large percentage of the
uses.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: why not

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9rrvvh$d16$1@nh.pace.co.uk...
> "Matthew Heaney" <mheaney@on2.com> wrote in message
> news:tu2t7oiig3e9d9@corp.supernews.com...
> Yes there would. Start working through all the combinations of stuff that
> are being proposed:
>
> (((Single List/Double List) * (Sorted/Unsorted)) + Map) *
> (Bounded/Unbounded) * (Task Safe/Task Unsafe)
>
> Thats 20 variants right there.

No.  These are variants you invented.

There is no such thing as a "sorted" vs "unsorted" list.

There is no such thing as a "task safe" vs "task unsafe" list.

Something tells me you don't really understand the STL.  There is *one*
algorithm for sorting, and it works for any kind of container.

> We can easily envision other variants such as
> Private/Limited-Private or Inherited/Generic. That's 80. The problem is to
> get the number of variants down to some manageable level that covers some
> reasonable amount of turf and will satisfy the largest possible body of
> users. Too many variants makes it a) complex and b) unlikely to be
realized.

Then don't do it that way.  I certainly don't intend to!

> That's why I would suggest limiting the first cut to a Double List
> (Sorted/Unsorted) & Map of Unbounded, Task Unsafe variety. That gets you
> down to 3 key packages that would probably cover a large percentage of the
> uses.

I said start with one: doubly-linked unbounded list.

Re: why not

[Marin David Condic]

I don't remember saying I was trying to duplicate STL. (I don't recall
claiming I knew anything at all about STL - other than being aware of its
existence. :-) I don't know that duplicating STL is anybody's goal with a
component library for Ada.

This started as a discussion of the notion of adopting the Booch Components
as a de facto "standard" component library. Objections have been voiced.
Other libraries have been suggested. The notion of developing one from
bottom-up has been suggested. Clarifying requirements seems to be a running
theme. How much of a "standard" it should be is part of the discussion. How
to get it adopted (grassroots? vendors? Ada0x committee?) is also a factor.
Mostly it seems to be about tossing out possible ideas for what would be a
good "standard" set of components.

Are you proposing that a component library for Ada should be modeled on the
STL?

BTW: I would think that having just one algorithm for sorting might impose a
lot of overhead on things that weren't well suited to the algorithm. I don't
see any problem with saying, for example, a Map is "sorted" by its very
nature as elements enter into it and how it accomplishes that is an
implementation detail for the Map package. Similarly, one can imagine some
flavor of a list as an inherently sorted entity and how it gets its elements
into order is best left to the particular implementation. (If its underlying
implementation is an array, you do one thing - if its a linked list, you do
another.)


MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Matthew Heaney" <mheaney@on2.com> wrote in message
news:tu374frvic9ebb@corp.supernews.com...
>
> Something tells me you don't really understand the STL.  There is *one*
> algorithm for sorting, and it works for any kind of container.
>

Re: why not

[Ted Dennison]

In article <9rs7r3$gch$1@nh.pace.co.uk>, Marin David Condic says...
>Are you proposing that a component library for Ada should be modeled on the
>STL?

One of the main objections to the BC's was that it was way too complicated to
use, compared with what the STL does for C users. So I think there has developed
sort of a requirement that it isn't significantly tougher to use than the STL,
or significantly less useful than it. Thus we should use the STL as a
yard-stick, but not nessecarily as a model.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Hyman Rosen]

Matthew Heaney wrote:

> Something tells me you don't really understand the STL.  There is *one*
> algorithm for sorting, and it works for any kind of container.

No it doesn't. It requires random-access iterators, so you can't sort
a list.

Also, there's no such thing in Standard C++ as std::slist.

Re: why not

[Darren New]

Marin David Condic wrote:
> (((Single List/Double List) * (Sorted/Unsorted)) + Map) *
> (Bounded/Unbounded) * (Task Safe/Task Unsafe)

Actually, a map wherein one can iterate over the map in the sort-order
of the keys is also very helpful. I.e., an "ISAM" file type semantics,
where you have random access by key, plus a "here's a key, what's the
next one" kind of operation. 

I also think that a linked list with an "insert into the right place"
and a "sort this whole list" would probably suffice to satisfy both
sorted and unsorted lists. I.e., you maintain a sorted list by keeping
it sorted as you change it, rather than by having a different kind of
list.

Just some thoughts...

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: why not

[Marin David Condic]

"Darren New" <dnew@san.rr.com> wrote in message
news:3BE1A30D.23A6068A@san.rr.com...
>
> Actually, a map wherein one can iterate over the map in the sort-order
> of the keys is also very helpful. I.e., an "ISAM" file type semantics,
> where you have random access by key, plus a "here's a key, what's the
> next one" kind of operation.
>
Great minds think alike! :-)

My notion of Maps is basically that - something similar to an ISAM or
indexed file - only it lives in memory. You should be able to look things up
from a key or iterate over the list of elements in key order.

Look at the MFC for their Map class and you'll see that I didn't exactly
invent it. :-)


> I also think that a linked list with an "insert into the right place"
> and a "sort this whole list" would probably suffice to satisfy both
> sorted and unsorted lists. I.e., you maintain a sorted list by keeping
> it sorted as you change it, rather than by having a different kind of
> list.
>
I'm with you here. I want a kind of a list I can use to just pile up a bunch
of things and get them back later in no particular order. (The ability to
create stacks and queues, basically.) I also want a kind of a list I can
hand things to and say "You store this any way you like - but I'll be
expecting to scan over them in sorted order..." and/or "Heres a bunch of
things to store. Now - go be a good little list and sort them for me."

You can clearly build both kinds of lists into a one-size-fits-all package,
but I think it might be better to separate out ordered vs unordered things
because I don't want to have to do any extra work just to pile up unordered
things. However, if a one-size-fits-all package is the way it eventually
ends up (and possibly with lots of smart creative people figuring out how to
not impose extra work where it isn't needed) I wouldn't likely run off to
C++ in disgust.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: why not

[Matthew Heaney]

"Darren New" <dnew@san.rr.com> wrote in message
news:3BE1A30D.23A6068A@san.rr.com...
> Marin David Condic wrote:
> > (((Single List/Double List) * (Sorted/Unsorted)) + Map) *
> > (Bounded/Unbounded) * (Task Safe/Task Unsafe)
>
> Actually, a map wherein one can iterate over the map in the sort-order
> of the keys is also very helpful. I.e., an "ISAM" file type semantics,
> where you have random access by key, plus a "here's a key, what's the
> next one" kind of operation.

I wrote an Indexed_IO package and another Index_Sequential_IO package.  Both
are available on the adapower web site.

<http://www.adapower.com/>

> I also think that a linked list with an "insert into the right place"
> and a "sort this whole list" would probably suffice to satisfy both
> sorted and unsorted lists. I.e., you maintain a sorted list by keeping
> it sorted as you change it, rather than by having a different kind of
> list.

More or less, yes.

Re: why not

[Matthew Heaney]

"Mark Biggar" <mark.a.biggar@home.com> wrote in message
news:3BE0F8AE.3B7E5C70@home.com...
> I not sure here.  I thing that a list type is too low level, the actual
> ADT that you want is a Dequeue ADT not Double-linked List ADT.

No, the thing I want is a doubly-linked list, which is a superset of the
behavior of a double-ended queue.  (Specifically, you can insert in the
middle.)

(You have to be careful, because your use of the term "dequeue" is
potentially ambiguous.  The STL includes a component called a "deque" which
is a list-like abstraction that allows random access.  I am assuming you
meant "double-ended queue.")

> Just like we already have bounded and unbounded strings, we should
> have bounded and unbounded Dequeues.

Yes.  Most data structures should have bounded and unbounded forms.

> The fact that the later
> can be implemented as a Double-linked list is an implementation
> detail.

No.  A doubly-linked list has very specific time and space semantics.  This
is not a hidden detail, it is a public feature of the component.  The time
and space semantics are the very reason you choose one component instead of
another.

Re: why not

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9rjsak$bp3$1@nh.pace.co.uk...
> Well, that's a bit of a disappointment.

There is still some hope that the vendors will support it -- they probably
have not seen the question on Team Ada.  I will attempt to contact them
individually, particulary the ones I know personally.

> While I understand a reluctance to distribute someone else's software -
> especially if it is unsupported - you have to wonder how any sort of
> standard utilities are supposed to make it into the language with that
sort
> of policy. Its too hard - and probably undesirable - to try to get some
> specifications into the ARM. The vendors may all have their own utilities
> they are trying to hawk, but that leaves the end user adopting something
> that ties them to a vendor.

To my knowledge there are no such components, and that is part of the
problem: a perceived lack of customer interest.   Overall, I believe that is
indeed the problem to be addressed -- the customers are not asking for it --
and that is why I am trying to generate some movement in the customer base.

I see the sequence of necessary events in the opposite order as do you: if
we want a common components library, and settled on one, and then started
asking for vendor "support", they would provide it.


--
---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Questions - Polimorphism/Dynamic Binding

[Eric Merritt]

Hello all,

I have basicaly two questions that I hope will be
fairly easy for you guys to answer.

1)

I started out in Java and C++ and recently found the
one true langauge (Ada95, lol). In any case, one thing
that I found very usefull in Java was the Interface. I
don't believe that Ada has this at all. I was
wondering if there is a way to impliment this type of
functionality in Ada (If required I can provide
examples). This also leads to my second question.

2)

If you have a tagged type and extend that type with a
new type. Then pass the new type to a procedure that
accepts its the new types parent, the original type.
Are procedures associated with the child type
(methods) that override it's parent types procedures
called in this instance, even though the procedure
that  this type is passed into is unaware of the new
child type and has not withed it's package?

I hope these questions have been somewhat understandable.

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: Questions - Polimorphism/Dynamic Binding

[David Botton]

> I don't believe that Ada has this at all. I was
> wondering if there is a way to implement this type of
> functionality in Ada

See http://www.adapower.com/lang/interface.html - Implementing Interfaces in
Ada by Ed Falis

> If you have a tagged type and extend that type with a
> new type. Then pass the new type to a procedure that
> accepts its the new types parent, the original type.
> Are procedures associated with the child type
> (methods) that override it's parent types procedures
> called in this instance, even though the procedure
> that  this type is passed into is unaware of the new
> child type and has not withed it's package?

It depends on how the method is called.

For example:

On_Pre_Create (Base_Window_Type'Class (Window), Style, ExStyle);

This will dispatch on the overridden method of the object in Window instead
of the Base_Window_Type's implementation.

In Ada, the caller determines the "virtual"ness of the call.

David Botton

Re: Questions - Polimorphism/Dynamic Binding

[Eric Merritt]

David,

--- David Botton <David@Botton.com> wrote:
> > I don't believe that Ada has this at all. I was
> > wondering if there is a way to implement this type
> of
> > functionality in Ada
> 
> See http://www.adapower.com/lang/interface.html -
> Implementing Interfaces in
> Ada by Ed Falis

Thank you, I apoligize for not looking more completly



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: Questions - Polimorphism/Dynamic Binding

[Matthew Heaney]

"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:mailman.1004456694.3472.comp.lang.ada@ada.eu.org...
> I started out in Java and C++ and recently found the
> one true langauge (Ada95, lol). In any case, one thing
> that I found very usefull in Java was the Interface. I
> don't believe that Ada has this at all. I was
> wondering if there is a way to impliment this type of
> functionality in Ada

Not directly.  For now the closest thing you can do is use the "multiple
views" idiom.  Suppose you have an "interface" type:

package P is

   type T is tagged limited null record;
   procedure Op (O : in out T) is abstract;

end P;

Now what we want is to have a tagged type that "conforms" to this interface.
One way to do this is like this (I haven't tried compiling this, but you'll
get the idea):

with P;
package Q is

   type T_Public;

   type TI is new P.T  (O : access T_Public) with null record;
   procedure Op (O : in out TI);

   type T_Public is abstract tagged limited record
      I : aliased TI;
   end record;

   type T is new T_Public with private;
   procedure Op2 (O : in T);
...
end Q;

This idea is that if you have an object of type T, then you can either view
it as a T, or use its (public) I component to view it as the interface type
P.T:

declare
   O : Q.T;
begin
   Op2 (O);  --view as a Q.T
   Op (O.I);  --view as "interface" P.T
end;

The interface part of T (its component I) can view the outer type through
its access discriminant.


> If you have a tagged type and extend that type with a
> new type.

package P is
   type T is limited null record;
   procedure Op (O : in out T);
end;

package P.C is
   type NT is new T with null record;
   procedure Op (O : in out NT);
end;


> Then pass the new type to a procedure that
> accepts its the new types parent, the original type.

Hmmm... Is the call static or dynamically bound?  Do you mean:

declare
   O : P.C.NT;
begin
   P.Op (O);  --?
end;

I don't think this will compile (this is a statically bound call), because
procedure P.Op takes type P.T, not P.C.NT.


> Are procedures associated with the child type
> (methods) that override it's parent types procedures
> called in this instance, even though the procedure
> that  this type is passed into is unaware of the new
> child type and has not withed it's package?

Not sure what you mean.  The correct procedure will always get called in a
dispatching (dynamically bound) call:

declare
   O : P.T'Class := P.C.NT'(null record);  --check my syntax
begin
   Op (O);  --try P.Op and P.C.Op and see how your compiler reacts
end;

Here, P.C.Op will get called, because O's tag has the value P.C.NT.  Or
where you expecting something else?

Re: Questions - Polimorphism/Dynamic Binding

[Eric Merritt]

Matthew,
 
> Not directly.  For now the closest thing you can do
> is use the "multiple
> views" idiom.  Suppose you have an "interface" type:
> 
> package P is
> 
>    type T is tagged limited null record;
>    procedure Op (O : in out T) is abstract;
> 
> end P;
> 
> Now what we want is to have a tagged type that
> "conforms" to this interface.
> One way to do this is like this (I haven't tried
> compiling this, but you'll
> get the idea):
> 
> with P;
> package Q is
> 
>    type T_Public;
> 
>    type TI is new P.T  (O : access T_Public) with
> null record;
>    procedure Op (O : in out TI);
> 
>    type T_Public is abstract tagged limited record
>       I : aliased TI;
>    end record;
> 
>    type T is new T_Public with private;
>    procedure Op2 (O : in T);
> ...
> end Q;
> 
> This idea is that if you have an object of type T,
> then you can either view
> it as a T, or use its (public) I component to view
> it as the interface type
> P.T:
> 
> declare
>    O : Q.T;
> begin
>    Op2 (O);  --view as a Q.T
>    Op (O.I);  --view as "interface" P.T
> end;
> 
> The interface part of T (its component I) can view
> the outer type through
> its access discriminant.

Good explaination but, there is one aspect that is
missing. One of the benifits of Java Interfaces is 
that it allows a form of quasi-multiple inheritance.
What I mean is that it will still allow you to inherit
from a root class and implement multiple interfaces.
In this case and interface almose becomes a kind of
agreement between the two bits of code the provider
agreeing to provide certain methods. I think this is
fairly easy to work around with a little forsight,
there is allways the delegation pattern for multiple
inheritance and that of course works in ada quite
well.

 


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: Questions - Polimorphism/Dynamic Binding

[Matthew Heaney]

"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:mailman.1004483142.1667.comp.lang.ada@ada.eu.org...
> Good explaination but, there is one aspect that is
> missing. One of the benifits of Java Interfaces is
> that it allows a form of quasi-multiple inheritance.
> What I mean is that it will still allow you to inherit
> from a root class and implement multiple interfaces.
> In this case and interface almose becomes a kind of
> agreement between the two bits of code the provider
> agreeing to provide certain methods.

How does my example fail to do this?

The whole point of an interface type is that you have some operation that
operates on any object that conforms to that interface, for example:

procedure Do_Something (O : in P.T'Class);  -- accepts the "interface" type
P.T

Using the schema I showed, you can call Do_Something on objects of Q.T:

declare
   O : Q.T;
begin
   Do_Something (O.I);
end;

No, you can't pass object O directly --you have to pass O.I-- but so what?
This is only a syntactic matter.  I'm still able to call Do_Something, which
is all I care about.

>  I think this is
> fairly easy to work around with a little forsight,
> there is allways the delegation pattern for multiple
> inheritance and that of course works in ada quite
> well.

The distinction between delegation and inheritance is not very important to
me.

Re: Questions - Polimorphism/Dynamic Binding

[Eric Merritt]

Matthew,

> How does my example fail to do this?

I hope I gave no offense, I am just trying to figure
this out, I very new to Ada though not to programming.

> 
> The whole point of an interface type is that you
> have some operation that
> operates on any object that conforms to that
> interface, for example:
 
> procedure Do_Something (O : in P.T'Class);  --
> accepts the "interface" type
> P.T
> 
> Using the schema I showed, you can call Do_Something
> on objects of Q.T:
> 
> declare
>    O : Q.T;
> begin
>    Do_Something (O.I);
> end;
> 
> No, you can't pass object O directly --you have to
> pass O.I-- but so what?
> This is only a syntactic matter.  I'm still able to
> call Do_Something, which
> is all I care about.

Once again, this may be a bit of a stupid question but
I need to get this strait in my mind. 
In this instance does O.I have access to O? Or more
specifically, how will the procedure Do_Something get
access to the object properties which are actually
stored in record O not O.I? Somehow I get the feeling
I am missing something fairly important here. Thank
you for your time.  


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: Questions - Polimorphism/Dynamic Binding

[Matthew Heaney]

"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:mailman.1004543264.20599.comp.lang.ada@ada.eu.org...
> > The whole point of an interface type is that you
> > have some operation that
> > operates on any object that conforms to that
> > interface, for example:
[original code snipped]

Actually, the original code wasn't quite correct.  I should have done this
(again, I haven't tried compiling this):

package P is

   type IT is abstract tagged limited null record;

   type IT_Class_Access is access all IT'Class;
   for IT_Class_Access'Storage_Size use 0;

   procedure Op (O : access IT) is abstract;

end P;

with P;
package Q is
   type T is limited private;

   function IT_View (O : access T) return P.IT_Class_Access;
...
private

   type IT_View_Type (T_Part : access T) is new P.IT with null record;
   procedure Op (O : access IT_View_Type);

   type T is
      limited record
         IT_View : aliased IT_View_Type (T'Access);
         ...
      end record;
end Q;

package body Q is
   function IT_View (O : access T) return P.IT_Class_Access is
   begin
      return O.IT_View'Access;
   end;

   procedure Op (O : access IT_View_Type) is
      T_Part : T renames O.T_Part.all;
   begin
      --do something to T_Part
   end;
end Q;

Now, suppose you have an operation that operates on objects that conform to
the interface type:

procedure Do_Something (O : access P.IT'Class);

Using this schema, we can pass objects of type Q.T to Do_Something:

declare
   O : aliased Q.T;
begin
   Do_Something (IT_View (O'Access));
end;



> Once again, this may be a bit of a stupid question but
> I need to get this strait in my mind.
> In this instance does O.I have access to O?

Yes, through its access discriminant.  The interface object, of type
IT_View_Type, binds to the "current instance" of type T.  The implementation
of Op (which takes an access to IT_View_Type parameter) can see rest of the
object through its descriminant (here, T_Part).  (This technique is not
unlike passing a "this" pointer to a ctor in C++.)

> Or more
> specifically, how will the procedure Do_Something get
> access to the object properties which are actually
> stored in record O not O.I? Somehow I get the feeling
> I am missing something fairly important here. Thank
> you for your time.

Well of course Do_Something doesn't know anything about Q.T -- it only knows
that the object conforms to the interface specified for type P.IT
(specifically, that it has an Op operation).  The implementation of
Do_Something would look something like:

procedure Do_Something (O : access P.IT'Class) is
begin
   ...
   Op (O);  --dispatches
   ...
end;

But perhaps you really meant how to implement Op?  See above.

Re: Questions - Polimorphism/Dynamic Binding

[Eric Merritt]

Matthew,

Thanks this makes much more sense.



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: why not

[Marin David Condic]

I would agree that what you describe are "sufficient" events, but not
"necessary" events. I'd go for that approach if some consensus starts to
form. Its just that you still have the problem of getting some kind of
agreement by a sufficiently large body of users that "Library X" is the way
to go. That's hard to do.

I'm of the opinion that if something just simply came with the compiler you
use, there'd be pressure to settle on that library rather than adopt one of
N possible other libraries. (Do C users go find other variations of
"strcmp", etc? Do Ada users go download alternatives to Ada.Strings..., etc?
There may be better libraries out there, but the pressure to go with what
comes with your compiler is pretty strong.)

It also gives Ada something immediately useful to your average student or
hacker that they might not get elsewhere. A nice collection of data
structures & other stuff is similar to having a built-in GUI interface -
extra leverage that gets you out the door quicker.

Maybe I'm just overly skeptical that folks will agree on one of the existing
libraries. Possibly there are enough users who would accept one of them even
if it isn't one of their first choices. A suggestion that might work is to
identify a list of possible candidates and take a straw poll just to see if
there is a favorite out there?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:LmzD7.3234$QX4.633344102@newssvr30.news.prodigy.com...
>
> I see the sequence of necessary events in the opposite order as do you: if
> we want a common components library, and settled on one, and then started
> asking for vendor "support", they would provide it.
>

Re: why not

[Ehud Lamm]

Pat Rogers <progers@classwide.com> wrote in message
news:LmzD7.3234$QX4.633344102@newssvr30.news.prodigy.com...
> I see the sequence of necessary events in the opposite order as do you: if
> we want a common components library, and settled on one, and then started
> asking for vendor "support", they would provide it.


That's how I saw the purpose of these discussions. But some feedback from
vendors and gurus would be nice...

Ehud

Re: why not

[Jeffrey Carter]

Marin David Condic wrote:
> 
> I agree. Sorting needs to be inside of the data structure - not done
> externally. However, it isn't clear if the container should always be
> sortable or not. For example, if it is implemented as a generic and the
> parameter is private, you don't have the operations one would need on an
> ordinal type to do the sorting. (Too bad Ada didn't provide generic
> parameters of "Ordinal" and "Scalar" so you could presume the existence of
> comparison or arithmetic operators. Hmmmmm.....) If you bring in "<" and "="
> as function parameters, you can then insert/sort in ascending/descending
> order as required - but now you impose that requirement on all things that
> might be stored in the container. What if the items being stored are not
> ordinal? Or you have no need of sorting?

This is hardly an issue. Look, for example, at
PragmARC.List_Unbounded_Unprotected. It imports a limited private formal
and an Assign procedure, and provides a generic Sort procedure that
imports "<". If you cannot define a meaningful "<" for your Element
type, or do not need sorting, you don't instantiate the Sort procedure.
Note that "=" is not needed for sorting.

-- 
Jeffrey Carter

Re: why not

[Larry Kilgallen]

In article <9rrvvh$d16$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> "Matthew Heaney" <mheaney@on2.com> wrote in message
> news:tu2t7oiig3e9d9@corp.supernews.com...
>>
>> If you need to traverse backwards, you need a doubly-linked list.
>>
> Obviously. Just an observation that a singly linked list would save the
> overhead of extra pointers and many structures (stacks, single-ended-queues)
> might benefit from the lack of the extra pointer. However, in most
> instances, I'd think that the extra pointer overhead would be small enough
> that you might just as well have it there plus all the operations you
> *don't* need for a simple stack, just because then you've got a single
> package that does the whole job.

Extra cycles should only occur on modification, right ?

Someone who was worried about space of an extra link would probably
write their own anyway.

Re: why not

[Eric Merritt]

Although I am really too new to Ada to provide help at
this point, I will say that you seem to be going in
the right direction. The Collections APIs that I am
familiar with, STL and Java Collections API, seem to
be in this general vein as well. Might I suggest an
iterator type for the lists. This should be fairly
simple and I always find them convenient, maybe that
is something I could actually do. In any case, it
would also probably not be a bad thing to be able to
get the keys and values from the maps as a list.
Please consider these as, perhaps clueless,
suggestions.



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: why not

[Jeffrey Carter]

Mark Biggar wrote:
> 
> I not sure here.  I thing that a list type is too low level, the actual
> ADT that you want is a Dequeue ADT not Double-linked List ADT.

No, I don't. Sometimes I want a list, with insert anywhere operations,
and sometimes I want a queue, with insertions limited to one end and
removals from the other, but I rarely want a dequeue.

-- 
Jeffrey Carter

Re: why not

[Marin David Condic]

Yeah. You'd have to do extra work on an insertion. Also, for very small data
items, the pointer overhead could be significant. Suppose you are stacking
up 32 bit integer data samples as they arrive. Having two 32 bit addresses
for each integer would be non-trivial if you are collecting a lot of
integers.

However, in my experience, you're either collecting up a relatively small
amount of data when compared to available memory or the data themselves are
significantly larger than the two pointers you'd need. In practice, I just
find it difficult to imagine or recall situations in which it would have
mattered much. They exist, but I think a doubly-linked-list would be
acceptable for the bulk of cases and tell everyone else to go pound sand.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:wxjM7LDNji1I@eisner.encompasserve.org...
>
> Extra cycles should only occur on modification, right ?
>
> Someone who was worried about space of an extra link would probably
> write their own anyway.

Re: why not

[Marin David Condic]

You can always create a package that is capable of handling sorting and then
depend on the caller simply to not do that if it isn't required or possible.
However, this IMHO means the creation of lots of parameters that needlessly
burden the caller with defining things that may not be at all necessary for
the simple cases. Simply making the type limited private forces the caller
to give you an assignment subprogram even if it only amounts to a ":=".  Is
that really necessary if all I want to do is pile up a bunch of employee
address records?

There are always compromises in design. One needs to trade off things like
simplicity for power or generality - or the other way around. It depends on
what the design objectives are. Since I favor getting *something* accepted
as a semi-standard, I'd live with the complexity if there was a growing
consensus that library X was the way to go. If the alternative is to
custom-grow one so that there will be a more general acceptance, I'd opt for
simplicity of use as a driving concern. Lots of parameters and options may
yield lots of power or generality, but I think it a) stands in the way of
getting it done and b) creates an interface that end users may find
inconvenient enough to avoid.

There are a million possible component libraries. Is it possible to get just
one accepted as a "standard"? Maybe not, if it requires 100% agreement among
all the potential users.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3BE18A23.BC921FA9@boeing.com...
>
> This is hardly an issue. Look, for example, at
> PragmARC.List_Unbounded_Unprotected. It imports a limited private formal
> and an Assign procedure, and provides a generic Sort procedure that
> imports "<". If you cannot define a meaningful "<" for your Element
> type, or do not need sorting, you don't instantiate the Sort procedure.
> Note that "=" is not needed for sorting.
>

Re: why not

[Ehud Lamm]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9rs3vn$em6$1@nh.pace.co.uk...
> There are a million possible component libraries. Is it possible to get
just
> one accepted as a "standard"? Maybe not, if it requires 100% agreement
among
> all the potential users.
>

Indeed. That's why 100% agrrement is not a good goal to strive for.
We need something usable, extendable, and most importantly understandable...

Ehud

Re: why not

[Marin David Condic]

Yeah, verrily and forsooth! :-) So long as we are all willing to accept the
fact that *whatever* results from this is not going to satisfy all of us
100%, perhaps we'll be willing to give a little and actually succeed in
getting something done.

Usable, Extendable and Comprehensible (without being a Rocket Scientist) are
noble goals and should be what we keep in mind as the discussion continues.
If it satisfies 80% of the common usages and makes it easy for the
programmer to use, we've really got something there. If it can be extended
easily to accommodate the other 20% of the cases, (And possibly provide for
the Incomprehensible stuff that many find useful & desirable) then we can
get to something more powerful at a later point.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9smloi$qkr$1@news.huji.ac.il...
>
> Indeed. That's why 100% agrrement is not a good goal to strive for.
> We need something usable, extendable, and most importantly
understandable...
>

Re: why not

[Ehud Lamm]

I think this is exactly what we are doing

Re: why not

[Ted Dennison]

In article <3BE18A23.BC921FA9@boeing.com>, Jeffrey Carter says...
>
>PragmARC.List_Unbounded_Unprotected. It imports a limited private formal
>and an Assign procedure, and provides a generic Sort procedure that
>imports "<". If you cannot define a meaningful "<" for your Element
>type, or do not need sorting, you don't instantiate the Sort procedure.
>Note that "=" is not needed for sorting.


I like that solution. The extra complexity is only there for people who want the
extra functionality.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Simon Wright]

"Matthew Heaney" <mheaney@on2.com> writes:

> We could start with an unbounded, doubly-linked list, a la STL
> std::list.

Why doubly-linked? surely that's implementation, what needs defining
is the operations.

Re: why not

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7v3d3x8w8c.fsf@smaug.pushface.org...
> "Matthew Heaney" <mheaney@on2.com> writes:
>
> > We could start with an unbounded, doubly-linked list, a la STL
> > std::list.
>
> Why doubly-linked? surely that's implementation, what needs defining
> is the operations.

I am assuming backwards-traversal is necessary.

Re: why not

[Simon Wright]

Ted Dennison<dennison@telepath.com> writes:

> How can you make sorting separate, when you don't know (and don't have access
> to) the internal structure of the collection?

By using private operations and implementing the sort in a child unit.

The problem there is that private operations can't be abstract, so you
can try to sort containers that don't in fact support it, and get a
Should_Have_Been_Overridden exception .. I am not very proud of this
feature.

>                                               A Map might be implemented as a
> linked list, or as some sort of binary tree.

Or in the case of the BCs using a hash table. That's why BC Maps can't
be sorted. Of course you could make a Collection of the keys and sort
that .. or use an Ordered Collection ..

Re: why not

[Simon Wright]

(I'm sorry if someone else has already said this; someone's newsreader
has completely trashed the threading here!)

Darren New <dnew@san.rr.com> writes:

> So what am I missing? Why would a doubly-linked list need to come
> with a compiler?

This thread started because we want the component library to come on
the compiler's installation disk, which means that the vendors have to
make some commitment to it (they _will_ get support calls). That'll be
a lot easier with a "standard".

Re: why not

[Simon Wright]

Ted Dennison<dennison@telepath.com> writes:

> One of the main objections to the BC's was that it was way too
> complicated to use, compared with what the STL does for C users.

Your objection was that it is difficult for beginners to "get" the
BCs, and I don't disagree. However, once you've done it a couple of
times it's not so bad.

I expect it takes a while to know what you're doing with the STL, too.

http://www.pushface.org/components/bc/case-study.html is meant to give
a brief intro.

Re: why not

[Ted Dennison]

In article <x7vu1wd7gcm.fsf@smaug.pushface.org>, Simon Wright says...
>
>Ted Dennison<dennison@telepath.com> writes:
>
>> One of the main objections to the BC's was that it was way too
>> complicated to use, compared with what the STL does for C users.
>
>Your objection was that it is difficult for beginners to "get" the
>BCs, and I don't disagree. However, once you've done it a couple of
>times it's not so bad.

I did state that, but not as an objection. I would actually kind of like to see
Booch in the standard, truth be known.

>I expect it takes a while to know what you're doing with the STL, too.

Perhaps, but it is quite easy to make yourself a STL list (or vector or
whatever) type and start using it without knowing precicely what is going on. It
just involves a single instantiation of one parameter (the element type) in one
template. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Darren New]

Ted Dennison wrote:
> I did state that, but not as an objection. I would actually kind of like to see
> Booch in the standard, truth be known.

Perhaps all it would take would be a good free Booch tutorial, or
improvement of whatever's already out there?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: why not

[Ted Dennison]

In article <usncjtzix.fsf@gsfc.nasa.gov>, Stephen Leake says...
>
>that C++ doesn't. C++ has no limited types, it has no distinction

Your point is quite valid, but this statement is not preciecly true. You can put
the copy constructor in the "private" part of a class to achieve the same
effect. They don't call it "limited", but its effectively the same thing.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Stephen Leake]

Ted Dennison<dennison@telepath.com> writes:

> In article <usncjtzix.fsf@gsfc.nasa.gov>, Stephen Leake says...
> >
> >that C++ doesn't. C++ has no limited types, it has no distinction
> 
> Your point is quite valid, but this statement is not preciecly true. You can put
> the copy constructor in the "private" part of a class to achieve the same
> effect. They don't call it "limited", but its effectively the same thing.

True. 

Which raises the question; can the containers in the STL be used with
such "limited" types? I suspect not.

And I _always_ forget to hide the constructor on child types, when I
am forced to write C++ :).

-- 
-- Stephe

Re: why not

[Ted Dennison]

In article <upu7ns7yj.fsf@gsfc.nasa.gov>, Stephen Leake says...
>
>Which raises the question; can the containers in the STL be used with
>such "limited" types? I suspect not.

You are correct. They have to copy the objects you give them into the container.
The work-around of course is to use pointers to the "limited" objects. You need
to do that anyway if you want to have a container of objects to dynamicly
dispatch on, which seems to be my usual case, so its no biggie.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: why not

[Jeffrey Carter]

Stephen Leake wrote:
> 
> It is easy to write a list package that will accept an Item_Type of
> Integer, or any non-tagged, non-private, non-limited, non-abstract
> type. Allowing it to accept an Item_Type with any combination of those
> attributes is much harder, but well worth it!
> 
> Things should be as simple as possible, but no simpler.

It is quite simple to write and use a list package that will accept an
Element of any definite type. See, for example,
PragmARC.List_Unbounded_Unprotected from the PragmAda Reusable
Components.

-- 
Jeffrey Carter

Re: why not

[Stephen Leake]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> Stephen Leake wrote:
> > 
> > It is easy to write a list package that will accept an Item_Type of
> > Integer, or any non-tagged, non-private, non-limited, non-abstract
> > type. Allowing it to accept an Item_Type with any combination of those
> > attributes is much harder, but well worth it!
> > 
> > Things should be as simple as possible, but no simpler.
> 
> It is quite simple to write and use a list package that will accept an
> Element of any definite type. See, for example,
> PragmARC.List_Unbounded_Unprotected from the PragmAda Reusable
> Components.

Yes, exactly. I was avoiding the term "definite" since it is a
"lanuage-lawyer" term. 

My packages support both definite and indefinite types; that is
harder. 

Which is better for a library?

-- 
-- Stephe

Re: why not

[Jeffrey Carter]

Stephen Leake wrote:
> 
> Jeffrey Carter <jeffrey.carter@boeing.com> writes:
> > It is quite simple to write and use a list package that will accept an
> > Element of any definite type. See, for example,
> > PragmARC.List_Unbounded_Unprotected from the PragmAda Reusable
> > Components.
> 
> Yes, exactly. I was avoiding the term "definite" since it is a
> "lanuage-lawyer" term.
> 
> My packages support both definite and indefinite types; that is
> harder.

Accepting an indefinite Element type is not difficult, but is unlikely
to result in an acceptable implementation for a bounded structure.

> 
> Which is better for a library?

Since I have never needed a structure to contain indefinite types, I
would say the one that can only handle definite types.

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail

Re: why not

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> BTW: Did I ask this before? Do the Booch Components do some form of
> serialization? Loading/Storing from/to files is one other thing I
> would think ought to be a requirement.

Mark Bond did a BSc project on this; see
http://www.pushface.org/components/bc/contrib/bond/

I haven't progressed this further. Personally I would probably do it
as an alternate form of storage management (which it clearly is).

Re: why not

[Marin David Condic]

Well, if there is some way to get 'Input and 'Output to work on the
structures, I'd consider that to be A Good Thing. That pretty much solves
the problem because you can use all the Stream stuff to get things into a
file or a pipeline if needed. If we're proposing requirements for a standard
component library, I'd offer support of 'Input & 'Output as one of them.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Simon Wright" <simon@pushface.org> wrote in message
news:x7v1yk067gl.fsf@smaug.pushface.org...
>
> Mark Bond did a BSc project on this; see
> http://www.pushface.org/components/bc/contrib/bond/
>
> I haven't progressed this further. Personally I would probably do it
> as an alternate form of storage management (which it clearly is).

Re: why not

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Well, if there is some way to get 'Input and 'Output to work on the
> structures, I'd consider that to be A Good Thing. That pretty much
> solves the problem because you can use all the Stream stuff to get
> things into a file or a pipeline if needed. If we're proposing
> requirements for a standard component library, I'd offer support of
> 'Input & 'Output as one of them.

Good point. That's the Right Way to do it.

It turns out that the Bounded forms will do this already.

Has anyone got code to manage 'Input, 'Output involving access types?

-- 
Simon Wright                         Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                     Voice: +44(0)23 9270 1778
Integrated Systems Division                  FAX: +44(0)23 9270 1800

Re: why not

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I'm of the opinion that if something just simply came with the
> compiler you use, there'd be pressure to settle on that library
> rather than adopt one of N possible other libraries. (Do C users go
> find other variations of "strcmp", etc? Do Ada users go download
> alternatives to Ada.Strings..., etc?  There may be better libraries
> out there, but the pressure to go with what comes with your compiler
> is pretty strong.)

I'd not have started supporting the BCs if there had been a standard
out there. I'd _probably_ not have done so if there'd been a
vendor-specific library for the compiler I was using (its being
open-source would have helped a lot).

A case in point: I have no problem using GNAT.Sockets since it's open,
it's not GNAT-specific (I think), it's fairly thin (so no great
surprises) and its use is likely to be localised in my application.

Re: why not

[Marin David Condic]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vzo68b8to.fsf@smaug.pushface.org...
>
> I'd not have started supporting the BCs if there had been a standard
> out there. I'd _probably_ not have done so if there'd been a
> vendor-specific library for the compiler I was using (its being
> open-source would have helped a lot).
>
I'm sure your support is appreciated, but I'm glad we see things similarly
with respect to having something come with the compiler. I might differ if
the answer were vendor-specific - but it depends on the job at hand. If you
don't perceive any future need to port, then go leverage everything the
vendor gives you to the hilt.

Even if the components are free for the cost of a download, its still better
if there is *one* "standard" set delivered with the compiler. If nothing
else, it makes it easier to write books about Ada that can presume their
existence. :-)


> A case in point: I have no problem using GNAT.Sockets since it's open,
> it's not GNAT-specific (I think), it's fairly thin (so no great
> surprises) and its use is likely to be localised in my application.

Other than the name being "GNAT" - I'd agree. If its open sourced and you
use it all over, you could at least pick the code up and move it to - say -
Aonix. But at least perceptually someone looking at "GNAT.Sockets" is likely
to presume it won't work elsewhere and it is unlikely that the guys at Aonix
are going to say: "Hey! Here's this cool sockets package. Why don't we glom
onto it and start shipping our compiler with it?" Now if you put a wrapper
around it called "ASCL.Sockets" you might overcome that problem.

I like the notion of being able to write a book about Ada and have a chapter
that says "Here's how you would do sockets programming in Ada..." and at
least have that chapter be correct *most* of the time. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: why not

[Hyman Rosen]

Jeffrey Carter wrote:

> This is an excellent argument *against* the BCs. Maybe in C++ the
> implicit instantiation alleviates this, or maybe C++ people are
> masochists, but in Ada it's unacceptable for a library to be so
> complicated that it takes hours to find and instantiate a list, and even
> then not be sure you've got what you need without testing.

C++:
////////////////////////////////////////////////////////////////
// Read a list of integers and write them in reverse order
#include <list>			// for list
#include <algorithm>		// for copy
#include <iostream>		// for cin and cout
#include <iterator>		// for ostream_iterator
#include <functional>		// for front_inserter
using namespace std;
int main()
{
	list<int> a_list;
	copy(istream_iterator<int>(cin), istream_iterator<int>(),
	     front_inserter(a_list));
	copy(a_list.begin(), a_list.end(),
	     ostream_iterator<int>(cout, "\n"));
}
/////////////////////////////////////////////////////////////////

Re: why not

[Simon Wright]

Ted Dennison<dennison@telepath.com> writes:

(discussing instantiating the BCs)

> On the plus side, once you figure this mess out, it will be *way*
> quiker to do it a second time. So its really an issue of if you want
> to invest a bit extra time up front thwacking your head against a
> wall figuring out Booch, in order to be able to save yourself extra
> time the *next* time you need a component.

I've been working on a utility to merge the various output files you
get from gcov with GNAT (still don't _quite_ understand why some files
get .da output and some don't). The declarations for the map that
keeps the merged view of whether or not a line has been/can be
executed are

   type Line_Kind is (Not_Executable, Executable);
   subtype Line_Number is Positive;

   type Line (Kind : Line_Kind := Not_Executable) is record
      Number : Line_Number;
      Text : Unbounded_String;
      case Kind is
         when Not_Executable => null;
         when Executable => Count : Natural := 0;
      end case;
   end record;

   package Abstract_Line_Containers is new BC.Containers (Line);

   function Hash (Key : Line_Number) return Natural;

   package Abstract_Line_Maps
   is new Abstract_Line_Containers.Maps (Key => Line_Number);
   package Line_Maps
   is new Abstract_Line_Maps.Unbounded
     (Hash => Hash,
      Buckets => 23,
      Storage => BC.Support.Standard_Storage.Pool);

(uses the 20011011 release, not yet in the wild) which isn't too bad I
think. Certainly doesn't qualify as "wild incantation" in my book. It
would be nice if it didn't have to be in a library-level package spec
..

Does the page at
http://www.pushface.org/components/bc/case-study.html#instantiation
help? (the version there has some errors and infelicities but the gist
is right)

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Marin David Condic]

Yeah verrily! Libraries that provide dozens of generic parameters, etc., in
an attempt to allow you to configure every possible option just get too
confusing to use easily. If I was building one from bottom dead center, I'd
pick a target usage (realtime, workstation apps, whatever) and make a simple
version that worked well for one set of uses. If it has any success, you can
always build similar, alternate implementations that provide different
options if you think there is any demand for it.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrn9sdahp.k4.lutz@taranis.iks-jena.de...
>
> OTOH most of programmers I spoke to do not like the fairly adaptable
> libraries because they are confused by the huge amount of options. So the
> recode there own libs, because they are faster to develop and verify them,
> than understanding the library. Of course, that's just another instance of
> the Not Invented Here Syndom, the most common open source disease.

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Wes Groleau]

Lutz Donnerhacke wrote:
> the Not Invented Here Syndom, the most common open source disease.

Too bad the National Institutes of Health don't have a treatment for it.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> If the BCs supply - or can be made to supply - Lists & Maps in
> static/dynamic and task-safe/monoprogrammed variants, then maybe its
> worth adopting.

Yep (but use Collections not Lists, BC Lists are weird)

-- 
Simon Wright                         Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                     Voice: +44(0)23 9270 1778
Integrated Systems Division                  FAX: +44(0)23 9270 1800

Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Simon Wright]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> I have serious reservations about the BCs. They are based on theory
> rather than practical use. Booch developed his taxonomy which
> determines what components exist. Does the developer really need to
> choose from 21 (or whatever the number is now) different queues? In
> my experience, the answer is no. Both bounded and unbounded variants
> are needed, with both protected and unprotected variants of each
> (the unprotected variants are primarily for creating structures of
> structures, which the BCs did not permit the last time I looked at
> them). Within the protected forms, a blocking variant is
> needed. That gives 6 variants of queues, which my experience shows
> are useful over 90% of the time. They also provide the building
> blocks if you really need a lesser used variant.
> 
> A similar thing arises from the partitioning of operations into
> modifiers and selectors. Everyone is used to pushing things onto a
> stack and popping things off. But popping something off a stack
> involves both modifying the stack and selecting a value from the
> stack. Theory says this is a No-No, so we'll separate them into Pop,
> the modifier, and Top, the selector. Of course, in practical use,
> every call to Top is immediately followed by a call to Pop,
> indicating that the real operation on the abstraction combines these
> 2 theoretical operations.

I think you have the Ada 83 BCs in mind, I don't recognise the beast
you're describing!

-- 
Simon Wright                         Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                     Voice: +44(0)23 9270 1778
Integrated Systems Division                  FAX: +44(0)23 9270 1800

Re: is Ada dying?

[Ehud Lamm]

Is Ada dying? Sure...


But very slowly :-)


Ehud Lamm

Re: is Ada dying?

[David Brown]

"Ralph Moritz" <ralph@work.co.za> wrote:

> I'm just starting out learning Ada, but it seems Ada is dying. From what I 
> can see very few people use Ada, out of about 15 000 projects on 
> Sourceforge only 32 are written in Ada! I think that's sad, and now that 
> Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold 
> in store? Is it worthwhile learning a language nobody appreciates or uses?

Not bad.  It was about a year ago that I asked sourceforge to add Ada as
a programming language.  At the time, only adump was an Ada project.  It
looks like others have made use of the language feature of sourceforge.

Remember, there is a lot of software being developed that isn't on
sourceforge, even lots of free or opensource software.

David Brown

Re: is Ada dying?

[Warren W. Gay VE3WWG]

David Brown wrote:

> "Ralph Moritz" <ralph@work.co.za> wrote:
>>I'm just starting out learning Ada, but it seems Ada is dying. From what I 
>>can see very few people use Ada, out of about 15 000 projects on 
>>Sourceforge only 32 are written in Ada! I think that's sad, and now that 
>>Ada's parents (the  U.S DoD) are dropping Ada 95 what does the future hold 
>>in store? Is it worthwhile learning a language nobody appreciates or uses?
> 
> Not bad.  It was about a year ago that I asked sourceforge to add Ada as
> a programming language.  At the time, only adump was an Ada project.  It
> looks like others have made use of the language feature of sourceforge.
> 
> Remember, there is a lot of software being developed that isn't on
> sourceforge, even lots of free or opensource software.
> 
> David Brown
 
Yes, not everyone uses the "source forge". See my link below, for another

project (AdaVox) that is in Ada95. Of course, there are many other sites,
with many more projects.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: is Ada dying?

[Ted Dennison]

In article <3BC5CE5A.9060500@home.com>, Warren W. Gay VE3WWG says...
>
>Yes, not everyone uses the "source forge". See my link below, for another
>
>project (AdaVox) that is in Ada95. Of course, there are many other sites,
>with many more projects.

Following my homepage link below, you should be able to find about 4 more that
aren't on SourceForge (although 2 are inactive).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: is Ada dying?

[Gautier Write-only-address]

>I'm just starting out learning Ada, but it seems Ada is dying.

Having started programming in Ada in 1996, I can tell you it
is far less dead now than five years ago.
If the US DoD is actually dropping Ada, maybe it is under
influence of the forces of evil ?...

________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: Do not answer to sender address, visit the Web site!
    Ne r�pondez pas � l'exp�diteur, visitez le site ouaibe!


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: is Ada dying?

[Preben Randhol]

On Sun, 07 Oct 2001 21:53:22 +0000, Gautier Write-only-address wrote:
> If the US DoD is actually dropping Ada, maybe it is under
> influence of the forces of evil ?...

If they drop it for C++ or another-put-your-pointer-where-you-want
language, I find it strange that they spend large amount of money to
make missiles that is supposed to hit accurately a target several 
hundreds miles away.

Let's just hope that Boeing is not going to change to C++ or VB for
their planes.

Preben Randhol

Re: is Ada dying?

[Gautier]

Preben Randhol:

> If they drop it for C++ or another-put-your-pointer-where-you-want
> language, I find it strange that they spend large amount of money to
> make missiles that is supposed to hit accurately a target several 
> hundreds miles away.
> 
> Let's just hope that Boeing is not going to change to C++ or VB for
> their planes.

If so, at least these planes can't be safely used as accurate missiles!

G.

Re: is Ada dying?

[David Botton]

----- Original Message ----- 
From: "Gautier Write-only-address" <gautier_niouzes@hotmail.com>

> If the US DoD is actually dropping Ada, maybe it is under
> influence of the forces of evil ?...

Microsoft? :-)

Re: is Ada dying?

[James Rogers]

David Botton wrote:
> 
> ----- Original Message -----
> From: "Gautier Write-only-address" <gautier_niouzes@hotmail.com>
> 
> > If the US DoD is actually dropping Ada, maybe it is under
> > influence of the forces of evil ?...
> 
> Microsoft? :-)

Microsoft and Sun :-)