Future with Ada

Future with Ada

[Michal Nowak]

Some month ago I discovered Ada and found it a greatest programming
language among the common programming laguages taught at universities
(Pascal, C++, Java and others). I started play with Ada a bit and
experienced  all benfits of using Ada (everyone here knows what they
are, so no need to write it).

During reading some posts here and looking through some job services
I found that Ada is not so widely used as C++ or Java nowadays.
I serioulsy think about catching a job in Ada after I finish my studies
(I'm on last year now). If to work as a programmer I would like to
write in Ada. I looked through some job offers at Ada Information
Clearinghouse. I did not browsed all, because I'm on dial-up connection,
but lots of them required at least 1-2 experience. I haven't found any
company in my country (Poland) who may need an Ada prorammer (especially
inexperianced newbie), so I cannot gain experience here.

It comes time to write my M. Sc. diploma and I am on a crossroads now.
I may use Java or Ada for it. I talked with my leading promotor and
told him, that I will prefer to use Ada. After explaining him all benefits
from using Ada he agreed with me. Considering facts given above I came to
two scenarios:
1. Use Ada for my M.Sc. diploma. This will allow me to gain some additional
experience in Ada (I know it does not count, but it is better to use it here
than nowhere).
2. Use Java or C++ for my diploma and use Ada for self-needed programs or
for pleasure. I will get more Java C++ experience here which will allow
me to catch better job at least my country.
It will be not commercial project, by it will be not typical student project
also. Doing it well from the beginnig to the end will help me to gain
some experience.

Of course the better scenario for me is the first one. Here comes my final
questions. Is there a possibility for inexperienced Ada programmer to
find a job? I suspect that there is, but where or how to seek it? Is
there a possibility to find somewhere such offers (for example job
services, which allow browsing offers sorted by years of experience
required)?

Thank you for your time,
regards,
Mike

-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Adrian Hoe]

You can contact me at my e-mail address and send me your resume. As
you still have a year to go, it will depend on if my company has
position at that time.

Nevertheless, we will KIV your resume.


Adrian Hoe



Michal Nowak <vinnie@inetia.pl> wrote in message news:<mailman.1005328653.20306.comp.lang.ada@ada.eu.org>...
> Some month ago I discovered Ada and found it a greatest programming
> language among the common programming laguages taught at universities
> (Pascal, C++, Java and others). I started play with Ada a bit and
> experienced  all benfits of using Ada (everyone here knows what they
> are, so no need to write it).
> 
> During reading some posts here and looking through some job services
> I found that Ada is not so widely used as C++ or Java nowadays.
> I serioulsy think about catching a job in Ada after I finish my studies
> (I'm on last year now). If to work as a programmer I would like to
> write in Ada. I looked through some job offers at Ada Information
> Clearinghouse. I did not browsed all, because I'm on dial-up connection,
> but lots of them required at least 1-2 experience. I haven't found any
> company in my country (Poland) who may need an Ada prorammer (especially
> inexperianced newbie), so I cannot gain experience here.
> 
> It comes time to write my M. Sc. diploma and I am on a crossroads now.
> I may use Java or Ada for it. I talked with my leading promotor and
> told him, that I will prefer to use Ada. After explaining him all benefits
> from using Ada he agreed with me. Considering facts given above I came to
> two scenarios:
> 1. Use Ada for my M.Sc. diploma. This will allow me to gain some additional
> experience in Ada (I know it does not count, but it is better to use it here
> than nowhere).
> 2. Use Java or C++ for my diploma and use Ada for self-needed programs or
> for pleasure. I will get more Java C++ experience here which will allow
> me to catch better job at least my country.
> It will be not commercial project, by it will be not typical student project
> also. Doing it well from the beginnig to the end will help me to gain
> some experience.
> 
> Of course the better scenario for me is the first one. Here comes my final
> questions. Is there a possibility for inexperienced Ada programmer to
> find a job? I suspect that there is, but where or how to seek it? Is
> there a possibility to find somewhere such offers (for example job
> services, which allow browsing offers sorted by years of experience
> required)?
> 
> Thank you for your time,
> regards,
> Mike
> 
> -----------------------------------------
>                              ____|
>                              \%/ |~~\
>   O                                  |
>  o>>        Mike Nowak               |
>  T                                   |
> / >       vinnie@inetia.pl           |
> http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Frode Tennebø]

On Friday 09 November 2001 18:59 Michal Nowak wrote:

> Some month ago I discovered Ada and found it a greatest programming
> language among the common programming laguages taught at universities
> (Pascal, C++, Java and others). I started play with Ada a bit and
> experienced  all benfits of using Ada (everyone here knows what they
> are, so no need to write it).

Good to hear that.

Here's my 2p with respect to hiering people. If _I_ were to employ 
_one_ person and had the choice between one with extensive coursing in 
C/C++ but little general informatics and one with perhaps only one 
course in several languages, _I_ would asume that the latter one is 
probably more adaptable and hence more suited for the needs of my 
company.

Think about what you want to do the next 

> Of course the better scenario for me is the first one. Here comes my
> final questions. Is there a possibility for inexperienced Ada
> programmer to find a job? 

I was inexperienced before I got my first position programming Ada. :)

> I suspect that there is, but where or how to
> seek it? 

Again, _I_ would rather have an inexperienced, versatile employee than 
a mastodont of a C/C++ programmer with years of programming.

Disclaimer: This is how _I_ would judge. I don't know wether the 
average employer would think likewise.

 -Frode
-- 
^ Frode Tenneb� | email: frode@tennebo.com | Frode@IRC ^
|  with Standard.Disclaimer; use Standard.Disclaimer;  |

Re: Future with Ada

[Ted Dennison]

In article <mailman.1005328653.20306.comp.lang.ada@ada.eu.org>, Michal Nowak
says...
>It comes time to write my M. Sc. diploma and I am on a crossroads now.
>I may use Java or Ada for it. I talked with my leading promotor and

Mae West said, "If I have to choose between two evils, I choose the one I
haven't tried before". :-)

The fact is, the more stuff on your Resume', the easier time you will have
finding your fist job.

>questions. Is there a possibility for inexperienced Ada programmer to
>find a job? I suspect that there is, but where or how to seek it? Is
>there a possibility to find somewhere such offers (for example job
>services, which allow browsing offers sorted by years of experience
>required)?

I don't do hiring, but my understanding is that there is a chronic shortage of
Ada developers (so bad in fact, that its hurting the language). However, you may
not be able to pick your location like you can with a skill that is ubiquitous
(like C++ or burger-flipping). The flip side of that is that employers will be
more willing to pay for reloation. But that's not such a big deal for a college
student who can fit everything they own in the back of their Yugo.  :-)

---
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: Future with Ada

[Michal Nowak]

On 01-11-10 at 17:31 Ted Dennison wrote:

>Mae West said, "If I have to choose between two evils, I choose the one I
>haven't tried before". :-)

The longer I learn Ada, the more I am convinced that this evil is
an angel. :-)

>The fact is, the more stuff on your Resume', the easier time you will have
>finding your fist job.

And more encouraging for a beginner (and mostly for a beginner) is that
number of offers increases logarithmically with time of experience
gained.

>But that's not such a big deal for a college
>student who can fit everything they own in the back of their Yugo.  :-)

Polish kind of Yugo is Small Fiat (and has nothing common with
Italian Fiat) :-)

Mike
-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Michal Nowak]

On 01-11-10 at 14:28 Frode Tennebø wrote:

>Good to hear that.
>
>Here's my 2p with respect to hiering people. If _I_ were to employ
>_one_ person and had the choice between one with extensive coursing in
>C/C++ but little general informatics and one with perhaps only one
>course in several languages, _I_ would asume that the latter one is
>probably more adaptable and hence more suited for the needs of my
>company.

Of course, I agree. Programming laguage is a tool and it shouldn't be
any trouble to learn new one in shorter (or longer) time for
a programmer. The problem may be, that if somebody was doing wrong
in one language, he will probably duplicate the errors in the newly
learned.

>I was inexperienced before I got my first position programming Ada. :)

A good news :-)

Mike
-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Preben Randhol]

On Sun, 11 Nov 2001 00:09:26 +0100, Michal Nowak wrote:
> On 01-11-10 at 14:28 Frode Tenneb� wrote:
> 
>>Good to hear that.
>>
>>Here's my 2p with respect to hiering people. If _I_ were to employ 
>>_one_ person and had the choice between one with extensive coursing in 
>>C/C++ but little general informatics and one with perhaps only one 
>>course in several languages, _I_ would asume that the latter one is 
>>probably more adaptable and hence more suited for the needs of my 
>>company.
> 
> Of course, I agree. Programming laguage is a tool and it shouldn't be
> any trouble to learn new one in shorter (or longer) time for 
> a programmer. The problem may be, that if somebody was doing wrong 
> in one language, he will probably duplicate the errors in the newly
> learned.

I think it is better to learn to how to program with Ada 95 than C++.

Preben
-- 
                 �For me, Ada95 puts back the joy in programming.�

Re: Future with Ada

[Ehud Lamm]

Michal Nowak <vinnie@inetia.pl> wrote in message
news:mailman.1005328653.20306.comp.lang.ada@ada.eu.org...
> It comes time to write my M. Sc. diploma

One good thing to be able to do with an MSc thesis is to publish it. This is
useful if you ever want to continue in academia, but it also looks nice in
resumes (IMHO).
It seems that it is much easier to publish something that uses Java, rather
the Ada.
(Take a look at some CS journals. You'll see th trend...)

Ehud

Re: Future with Ada

[Michal Nowak]

>I think it is better to learn to how to program with Ada 95 than C++.

This is why I regret, that Ada was not the first language I was 
introduced to. 
Some mess was with C++, because it was given as an _extension_ to C.
Maybe if it was presented as an independent, new language, the situation
would be a slight better. 
I had lectures on object analysis and software engineering, where 
I was shown benefits of generics, packages and other features which
Ada has (and there was no word about Ada!). Further there were notes
about code analisys and inspection, maintenace. After that I found Ada 
modern language enabling to keep high quality of software. I cannot
understand, why it is not so widely used...

Mike


-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Michal Nowak]

>One good thing to be able to do with an MSc thesis is to publish it. This
>is
>useful if you ever want to continue in academia, but it also looks nice in
>resumes (IMHO).

The idea is to create full functional system running at institute of computing
science at my univeristy.

>It seems that it is much easier to publish something that uses Java, rather
>the Ada.

Maybe I do not get the point. Why easier?

>(Take a look at some CS journals. You'll see th trend...)

You are right here. But trends may change. Although Java (as a language, not
as environment) is better than C++, I hope (for many reasons), that it will
not became the world's only language. Besides, I am a bit cotradictious,
and do not have tendency to go with the crowd's direction with blind eyes.
I try to consider some alternatives at start.

Mike
-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Maciej Sobczak]

Hi,

Michal Nowak wrote:

>> It seems that it is much easier to publish something that uses Java, rather
>> the Ada.
> 
> 
> Maybe I do not get the point. Why easier?
> 
> 
>> (Take a look at some CS journals. You'll see th trend...)
> 
> 
> You are right here. But trends may change.

It does not depend on the programmers, but on the big companies that run 
our lives.

> Although Java (as a language, not
> as environment) is better than C++,

Not so fast, man! (at least, don't say it loudly to any of the C++ 
gurus, because you will have to spend at least an hour listening why 
you're wrong :-)).

> I hope (for many reasons), that it will
> not became the world's only language.

Me too.

> Besides, I am a bit cotradictious,
> and do not have tendency to go with the crowd's direction with blind eyes.
> I try to consider some alternatives at start.

Good idea. The problem is that you can learn and try many different 
languages as your own hobby, but when it comes to commerce, you're at 
the mercy of big companies, like M$ or Sun. You see, the problem with 
Ada (and recently with C++ - its market is shrinking, I think - esp. in 
Poland) is that they're *standard* languages. It means, that no company 
can close its market with any of those languages. Making compilers of 
Ada or C++ just does not pay well if people can migrate with their 
software from one compiler's vendor to another. M$ is better off 
investing big bucks into the C# development (and marketing), because 
once you get into the trap, you belong to them forever. The same is true 
for Sun with Java. You will never hear from them that C# and/or Java are 
far behind Ada and C++, even if M$ officially admits that C++ is the 
most extensively used language in the company (Windows, Office, 
Exchange, VStudio, all other stuff). I can bet that Sun still keeps lots 
of C/C++ programmers for server and OS development (and Java run-time, 
for that matter), too. So where this trend to Java/C# comes from? From 
money, of course. And there's a crowd that follows.

That's why I'm not so optimistic when it comes to the near future.
Ada is fine (I try to learn it, too), I personally like C++ (and I think 
I know quite a bit of it), but don't ask me what I'm doing at work... :-(


> Mike

Czesc,
-- 
Maciej Sobczak
http://www.maciejsobczak.com

Re: Future with Ada

[Don]

> Good idea. The problem is that you can learn and try many different
> languages as your own hobby, but when it comes to commerce, you're at
> the mercy of big companies, like M$ or Sun. You see, the problem with
> Ada (and recently with C++ - its market is shrinking, I think - esp. in
> Poland) is that they're *standard* languages. It means, that no company
> can close its market with any of those languages. Making compilers of
> Ada or C++ just does not pay well if people can migrate with their
> software from one compiler's vendor to another. M$ is better off
> investing big bucks into the C# development (and marketing), because
> once you get into the trap, you belong to them forever. The same is true
> for Sun with Java. You will never hear from them that C# and/or Java are
> far behind Ada and C++, even if M$ officially admits that C++ is the
> most extensively used language in the company (Windows, Office,
> Exchange, VStudio, all other stuff). I can bet that Sun still keeps lots
> of C/C++ programmers for server and OS development (and Java run-time,
> for that matter), too. So where this trend to Java/C# comes from? From
> money, of course. And there's a crowd that follows.
>

Good analysis--this issue has been on my mind for a while.  I'd like to add
that part of choosing a language is what you, as a developer, can learn.
Choosing a standardized general purpose (non-proprietary) language means
that you'll learn concepts that you can take with you to other languages.
The literature tends to be better: less marketing and hype.  More
flexibility and control.

When I was looking for another language to learn, I  considered Java, C# or
Ada.
I chose Ada because  I thought I could get more out of it in the long run.

> That's why I'm not so optimistic when it comes to the near future.
> Ada is fine (I try to learn it, too), I personally like C++ (and I think
> I know quite a bit of it), but don't ask me what I'm doing at work... :-(

If C# or Java becomes the lingua franca of programming, I'm confident that
knowledge of more flexible non-proprietary languages will help to master
these proprietary languages.  To a plain VB programmer, a Variant is some
mysterious type; to a VB programmer w/ C++ knowledge, it's a glorified
union, as simple as that.

The problem w/ these marketing machines is that they target the innocent and
ignorant.  If you have a non-tech client or manager who's been brainwashed
by all that rubbish, there's an opportunity to sell the virtues of your
prefered tool.  If it is in fact better, the benefits will ring true.  If
the benefits are tangible, but your audience is unconvinced, then you might
question whether you're at the right place.

So basically, (1) Find a place that values your opinion, might consider
letting you do some programming in different languages(maybe small or
non-tech). (2) Become an advocate. I became interested in Ada when someone
posted a logical, persuasive post in  the c++.moderated ng.  More
advocacy->more programmers->more visibility->more jobs.

-Don

Re: Future with Ada

[Mark Lundquist]

"Maciej Sobczak" <maciej@maciejsobczak.com> wrote in message
news:3BF193F3.5090903@maciejsobczak.com...
>
>So where this trend to Java/C# comes from? From
> money, of course. And there's a crowd that follows.
>

"Money-oriented programming".

A quote from Alexander Stepanov (author of the C++ Standard Template
Library):

"I spent several months programming in Java. Contrary to its authors
prediction, it did not grow on me. : I did not find any new insights - for
the first time in my life programming in a new language did not bring me new
insights. It keeps all the stuff that I never use in C++ - inheritance,
virtuals - OO gook - and removes the stuff that I find useful. It might be
successful - after all, MS DOS was - and it might be a profitable thing for
all your readers to learn Java, but it has no intellectual value whatsoever.
Look at their implementation of hash tables. Look at the sorting routines
that come with their "cool" sorting applet. Try to use AWT. The best way to
judge a language is to look at the code written by its proponents. "Radix
enim omnium malorum est cupiditas" - and Java is clearly an example of a
money oriented programming (MOP). As the chief proponent of Java at SGI told
me: 'Alex, you have to go where the money is.' But I do not particularly
want to go where the money is - it usually does not smell nice there."

- Mark

P.S. I still need someone like Dewar to tell me what the Latin means :-)

Re: Future with Ada

[David C. Hoos]

----- Original Message ----- 
From: "Mark Lundquist" <up.yerz@nospam.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Wednesday, November 14, 2001 1:32 PM
Subject: Re: Future with Ada


<snip>
> "Radix enim omnium malorum est cupiditas"

The love of money is the root of all evil.

Re: Future with Ada

[Ted Dennison]

In article <yFzI7.26541$XJ4.16314914@news1.sttln1.wa.home.com>, Mark Lundquist
says...
>
>P.S. I still need someone like Dewar to tell me what the Latin means :-)

Naahh. You just need Google. The first hit took me eventually to here:
http://www.librarius.com/gy.htm#radix%20malorum

---
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: Future with Ada

[Michal Nowak]

On 01-11-13 at 22:43 Maciej Sobczak wrote:

>Good idea. The problem is that you can learn and try many different
>languages as your own hobby, but when it comes to commerce, you're at
>the mercy of big companies, like M$ or Sun. You see, the problem with
>Ada (and recently with C++ - its market is shrinking, I think - esp. in
>Poland) is that they're *standard* languages. It means, that no company
>can close its market with any of those languages. Making compilers of
>Ada or C++ just does not pay well if people can migrate with their
>software from one compiler's vendor to another. M$ is better off
>investing big bucks into the C# development (and marketing), because
>once you get into the trap, you belong to them forever. The same is true
>for Sun with Java. You will never hear from them that C# and/or Java are
>far behind Ada and C++, even if M$ officially admits that C++ is the
>most extensively used language in the company (Windows, Office,
>Exchange, VStudio, all other stuff). I can bet that Sun still keeps lots
>of C/C++ programmers for server and OS development (and Java run-time,
>for that matter), too. So where this trend to Java/C# comes from? From
>money, of course. And there's a crowd that follows.

All this is sad truth. I wonder what would be if M$ released something
like MS Ada. Of course it would be specially modified non-portable Ada,
with all M$ tricks inside. I'm really curious, what percentage of
comapnies would stick into it, just because it would be from Bill...
BTW, when I was one time on Sun's page to download JDK for some laboratory
project, I saw their article on Java. It's content was something like:
"Java will make you happy, your life will be easier, you will find the joy
of programming". And there also table with comparision of Java to some
other languages (there was no Ada, of course...). They claimed that Java
programs have the same performance as those in C++. Do I take right the
meaning of 'performance'? In fact Java made my life harder and unhappy
with its slooow execution and large memory demand.
The real joy of programming (and designing) gave me Ada (although I had some
with C++ also). The more I learn it, the more I am fascinated. Yea, Ada
is really great! So why not to have joy of professional work (not only as
a hobby?). That is why I started this thread.
Or maybe the outburst will come? Maybe Ada 95 was designed too early,
maybe the current level of software engineering is too low? Some newly
created languages (like C#, Java, PHP) include a bit of Ada's features.
Then there is a big 'hurrah' during release of them, shouting how great
it is, because it has 'this' or 'that' which no other language has.
But 'this' and 'that' already are in Ada. Reinventing the wheel (or trying
to invent it)?.

>That's why I'm not so optimistic when it comes to the near future.

Thanks to some people I started to look brighter into the future,
the future with Ada!

>Czesc,
Trzymaj sie,
Michal
-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Mark Lundquist]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.1005767069.1670.comp.lang.ada@ada.eu.org...
>
> <snip>
> > "Radix enim omnium malorum est cupiditas"
>
> The love of money is the root of all evil.
>

Thanks :-)

-- mark
--
--
        type Evil (<>) is new Money with private;

Re: Future with Ada

[Preben Randhol]

On Wed, 14 Nov 2001 22:50:53 +0100, Michal Nowak wrote:

> All this is sad truth. I wonder what would be if M$ released something
> like MS Ada. Of course it would be specially modified non-portable Ada,
> with all M$ tricks inside. I'm really curious, what percentage of
> comapnies would stick into it, just because it would be from Bill...

I don't know, but it wouldn't do Ada much good unless it followed the
ISO standard and was portable.

Preben

Re: Future with Ada

[Marin David Condic]

Well, it could adhere to the ISO standard, yet still "Embrace and Extend"
(read: "Engulf and Devour"). It might compile standard Ada, but provide all
sorts of language extensions, custom libraries, etc, that are tempting to
employ, but lock you in to one vendor.

That sort of thing has been going on for years.

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/


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrn9v706s.h6.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Wed, 14 Nov 2001 22:50:53 +0100, Michal Nowak wrote:
>
> I don't know, but it wouldn't do Ada much good unless it followed the
> ISO standard and was portable.
>

Re: Future with Ada

[Preben Randhol]

On Thu, 15 Nov 2001 09:59:37 -0500, Marin David Condic wrote:
> Well, it could adhere to the ISO standard, yet still "Embrace and Extend"
> (read: "Engulf and Devour"). It might compile standard Ada, but provide all
> sorts of language extensions, custom libraries, etc, that are tempting to
> employ, but lock you in to one vendor.

Well, when the vendor is Microsoft it will also lock you into their OS
which sucks even more. 

Preben

Re: Future with Ada

[John English]

Michal Nowak wrote:
> "Java will make you happy, your life will be easier, you will find the joy
> of programming"...

That's Bill Joy, I presume... :-)

-----------------------------------------------------------------
 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: Future with Ada

[Florian Weimer]

"David C. Hoos" <david.c.hoos.sr@ada95.com> writes:

>> "Radix enim omnium malorum est cupiditas"
>
> The love of money is the root of all evil.

"cupiditas" refers to any kind of strong desire (for women, power, or
money and so on).

Re: Future with Ada

[ben]

In article <3wdH7.20135$xS6.32614@www.newsranger.com>, Ted says...
> 
>
>I don't do hiring, but my understanding is that there is a chronic shortage of
>Ada developers (so bad in fact, that its hurting the language). 

That is funny. It is almost impossible to find any Ada wanted ads these days.
Actually there are more openings for almost any other language than for Ada.

Can you point to ONE commerical Ada opening right now that requires no
active security clearance in the US? I bet you there is none.

I guess those looking for Ada programmers must be working on some other
planet other than the earth, may be is some secret project on the moon or
Mars?

One of the reasons I dropped from Ada and now do Java and C is the lack of
work in Ada. Not only Ada jobs are almost impossible to find, if you find one,
they put more requirments on you by asking for things like requiring one
to have an active security clearance allready, and after all of this, if
you find an Ada job, the pay is even less than what you can make in C or Java
or C++.

Yup, this sure sounds like there is a huge demand for Ada.



 

Re: Future with Ada

[Marin David Condic]

I don't know of any Defense contractors that would insist that you already
be sitting on an active security clearance before they would consider you
for direct employment. Sometimes, they may want that for a consultant,
because they need to get the individual onto a project right away & a
clearance can take some time to get, but I've never heard of that for a
direct employee. They may insist that you be *clearable* - US citizen, no
criminal record, etc., - and they may make this a condition of continued
employment, but usually, they're willing to put you to work on
non-classified stuff until they can get the paperwork through the system.

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/


"ben@NO_SPAM_EMAIL" <ben_member@newsguy.com> wrote in message
news:9tqete0gqc@drn.newsguy.com...
> they put more requirments on you by asking for things like requiring one
> to have an active security clearance allready, and after all of this, if

Re: Future with Ada

[Larry Kilgallen]

In article <9ttmmk$dg9$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> I don't know of any Defense contractors that would insist that you already
> be sitting on an active security clearance before they would consider you
> for direct employment. Sometimes, they may want that for a consultant,
> because they need to get the individual onto a project right away & a
> clearance can take some time to get, but I've never heard of that for a
> direct employee.

The phrases "Full-Time Employee" and "Existing clearance required" are
both present in the Raytheon page:

http://www.headhunter.net/JobSeeker/Jobs/JobDetails.asp?did=JZ46T64B5WGN658688&CiBookMark=1&strCrit=QS%3Ddom%5Fbookmarks%3BQID%3DA3844800433238%3Bst%3Da%3Buse%3DAll%3BrawWords%3Dvms%3BTID%3D141104%3BBID%3DD8IJ%3BCTY%3DBoston%3BSID%3DMA%3BCID%3DUS%3BENR%3DNO%3BDTP%3DDR3%3BYDI%3DYES%3BIND%3DAll%3BPDQ%3DAll%3BJN%3DA%3BTITL%3D0&zbid=X15128F4B2C5F3F979BA6B438A073158BC76DE663A0E320638B6769472A799F9E9

Re: Future with Ada

[Marin David Condic]

O.K. I'm willing to stand corrected. Perhaps there are some companies with
some jobs for which there is an existing clearance requirement. In all the
times I have dealt with defense contractors and in the experience of many of
the people I know in that business, its usually required that you be
*clearable* rather than already cleared. (Although it can get tough to
interview for a job on a project that doesn't exist and you don't have SAR
clearance for it - they can't ask you too many specific questions and they
can't give you *any* answers! {been there, done that} :-)

If Raytheon requires you already be cleared, I'd wonder if it was for some
specific job or is that a general policy? It would give them a bit of
chicken-and-egg problem if they insisted on it across the board, eh? That's
generally why I'd be skeptical of any claim that defense contractors working
with Ada would want an existing clearance in most cases. How do you hire
fresh-outs? Are the only people you can ever hire the ones that work for
your competitors who *did* bite the bullet and get their people clearances?
What happens if all the players follow that policy & the folks with existing
clearances retire?

I do know that it is usually easier/faster to get a clearance if you have
had one in recent history rather than applying for one for the first time or
trying to renew one that has been inactive for a number of years. But
companies still do it - it just takes longer.

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:K5+QUda6Bu6Z@eisner.encompasserve.org...
> In article <9ttmmk$dg9$1@nh.pace.co.uk>, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> writes:
>
> The phrases "Full-Time Employee" and "Existing clearance required" are
> both present in the Raytheon page:
>
>
http://www.headhunter.net/JobSeeker/Jobs/JobDetails.asp?did=JZ46T64B5WGN6586
88&CiBookMark=1&strCrit=QS%3Ddom%5Fbookmarks%3BQID%3DA3844800433238%3Bst%3Da
%3Buse%3DAll%3BrawWords%3Dvms%3BTID%3D141104%3BBID%3DD8IJ%3BCTY%3DBoston%3BS
ID%3DMA%3BCID%3DUS%3BENR%3DNO%3BDTP%3DDR3%3BYDI%3DYES%3BIND%3DAll%3BPDQ%3DAl
l%3BJN%3DA%3BTITL%3D0&zbid=X15128F4B2C5F3F979BA6B438A073158BC76DE663A0E32063
8B6769472A799F9E9

Re: Future with Ada

[Ted Dennison]

In article <K5+QUda6Bu6Z@eisner.encompasserve.org>, Larry Kilgallen says...
>The phrases "Full-Time Employee" and "Existing clearance required" are
>both present in the Raytheon page:

That could mean that they will be satified with an old inactive clearance (those
are easier to reactivate than starting from scratch). If it has to be active,
they usually say so.

---
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: Future with Ada

[Jerry Petrey]

Marin David Condic wrote:
> 
> O.K. I'm willing to stand corrected. Perhaps there are some companies with
> some jobs for which there is an existing clearance requirement. In all the
> times I have dealt with defense contractors and in the experience of many of
> the people I know in that business, its usually required that you be
> *clearable* rather than already cleared. (Although it can get tough to
> interview for a job on a project that doesn't exist and you don't have SAR
> clearance for it - they can't ask you too many specific questions and they
> can't give you *any* answers! {been there, done that} :-)
> 
> If Raytheon requires you already be cleared, I'd wonder if it was for some
> specific job or is that a general policy? It would give them a bit of
> chicken-and-egg problem if they insisted on it across the board, eh? That's
> generally why I'd be skeptical of any claim that defense contractors working
> with Ada would want an existing clearance in most cases. How do you hire
> fresh-outs? Are the only people you can ever hire the ones that work for
> your competitors who *did* bite the bullet and get their people clearances?
> What happens if all the players follow that policy & the folks with existing
> clearances retire?
> 
> I do know that it is usually easier/faster to get a clearance if you have
> had one in recent history rather than applying for one for the first time or
> trying to renew one that has been inactive for a number of years. But
> companies still do it - it just takes longer.
> 
> MDC
> 

Marin,

What you said originally has usually been the case but recently, due to
exceptionally long delays (i.e. 2 years or more in some cases) in
getting
clearances, some companies are looking for people who already have them.

We (Raytheon) do have some positions that require you to have one but 
we do hire a lot of people without current clearances as long as they
are 'clearable' as you said.  Having a current clearance is always a big
plus
but for most jobs, we will grab a good candidate with or without one.
If you had a clearance that is over 2 years old (since last job used) it
is basically like starting over.  Many people can get an 'Interim'
Secret
in a fairly short time and, in most cases, that will suffice until the
full clearance comes in.


Jerry

-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to
reply                  
-----------------------------------------------------------------------------

Re: Future with Ada

[Marin David Condic]

Its been a while since I last had to jump through the hoops from scratch -
but I seem to recall getting a Secret in 6-8 weeks. Two years??? How the
heck does DoD expect you to get any work done when by that time your
fresh-outs have found another job and moved on?

Personally, I had my clearances dropped about a year ago, and last I had
heard, there was some sort of 5-year-not-too-bad-to-reactivate kind of
timeline, but over that it required a full investigation from scratch. I
understand that what with recent events around the US, they've probably
tightened up a bunch, but there still seems to be some practical necessity
here - if you want weapons designers, you've got to clear them before they
hit retirement. :-)

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/


"Jerry Petrey @west.raytheon.com>" <"jdpetrey<NOSPAM> wrote in message
news:3C02D13B.63DBBF16@west.raytheon.com...
>
> What you said originally has usually been the case but recently, due to
> exceptionally long delays (i.e. 2 years or more in some cases) in
> getting
> clearances, some companies are looking for people who already have them.
>

Re: Future with Ada

[Richard Riehle]

"ben@NO_SPAM_EMAIL" wrote:

> That is funny. It is almost impossible to find any Ada wanted ads these days.
> Actually there are more openings for almost any other language than for Ada.
>
> Can you point to ONE commerical Ada opening right now that requires no
> active security clearance in the US? I bet you there is none.

Over and over, we encounter companies who, after deciding to use Ada for
its technological advantages, cannot hire qualified Ada programmers.  Our
most recent experience was a company in Silicon Valley.  They were excited
about using Ada, asked us to train some of the people, and then tried to hire
more programmers to do Ada.   They found it nearly impossible to find
people with experience in their domain,  sufficient mathematics, and lots
of experience in Ada.   Sadly, they finally decided to use C++ because it
was so much easier to find programmers.

We encounter this same problem with DoD contractors.    One reason I am given
by major DoD software developers, for their choice of C++ is availability
of personnel.   Often they admit the superiority of Ada but justify their choice
of C++ or Java on the basis of the difficulty of hiring Ada programmers.

In those same organizations, many programmers don't want to program in Ada
because they see few commercial opportunities for that skill.    These programmers
don't care whether Ada is a better language.  They care about the future of their
career.   The companies don't care whether Ada is superior to C++.   They
often admit it is.  They do care about being able to hire people who want to
program in Ada.

One can dismiss this as a "chicken and egg" problem.  However, it is a problem
that needs solving.   There are still a few brave non-DoD managers out there who
are
enjoying the benefits of Ada and would choose nothing else.  This kind of
enlightenment is not as widespread as we might like.

If the DoD had not given the impression of abandoning Ada when it did,  we might
be a lot further ahead.   Yes, I know, abandonment was not the intention of the
letter that abrogated the mandate, but that is how it is widely interpreted by both

DoD contractors and commercial organizations that might have chosen it.   We
need to raise the visibility of Ada in the media, and among our non-Ada colleagues.

At present, no one is making any effective effort to make Ada visible and attactive

to the larger software community.   Nothing is being done to promote it among the
software managers at DoD contractor sites, not to mention the non-DoD sites.

Those commercial organizations who have chosen Ada have done so on
the basis of their own wisdom.    They benefit from that choice and rarely see the
benefit of proseletyzing their competitors.

As a technology, I believe Ada is still a better choice for many software domains.
It is going to take something more than better technology to make the difference. A

long time ago, Ralph Crafts was a powerful spokesman for the industry.  He finally
gave up, recognizing that his "voice in the wilderness" was not being as
appreciated
as it should have been.   No one has stepped in to take over the work Ralph was
doing.  If someone has stepped in, they are not making themselves or Ada visible.

Richard Riehle

Re: Future with Ada

[Suzie Cube]

Having relocated just over a year ago, I find myself once again in the job
market (a post-9-11 layoff).

I am finding that most, if not all, the Ada jobs will require another
relocation.  I had hoped that that would not be the case in the Dallas/Fort
Worth Metroplex.  Lockheed Martin cites no language in their JSF postings,
and conversations here (cla) indicate it's not Ada.  (It would be a
relocation, too, from east Dallas 'burb, to west FW company, but that's
o.k.)  Other companies appear to have converted to other languages or sent
their Ada work elsewhere... or just aren't hiring now.

www.flipdog.com and www.headhunter.net seem to be better than
www.monster.com, but the boards at AdaIC are not very helpful (few jobs, out
of date).  It would certainly help to match Ada-friendly companies with the
qualified Ada programmers they need if there was more up-to-date information
there (or somewhere!)

In the meantime, if someone out there wants to get a finder's fee for
referring a dyed-in-the-wool-Ada-fanatic... er, ahem, experienced Ada
software engineer... (veteran of JUG, AdaJUG, AdaTec, SIGAda, Ada Follies
Working Group...), well, you know where I am.

PS Norby

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C0924D6.2B5A3087@adaworks.com...
> "ben@NO_SPAM_EMAIL" wrote:
>
> > That is funny. It is almost impossible to find any Ada wanted ads these
days.
> > Actually there are more openings for almost any other language than for
Ada.
> >
> > Can you point to ONE commerical Ada opening right now that requires no
> > active security clearance in the US? I bet you there is none.
>
> Over and over, we encounter companies who, after deciding to use Ada for
> its technological advantages, cannot hire qualified Ada programmers.  Our
> most recent experience was a company in Silicon Valley.  They were excited
> about using Ada, asked us to train some of the people, and then tried to
hire
> more programmers to do Ada.   They found it nearly impossible to find
> people with experience in their domain,  sufficient mathematics, and lots
> of experience in Ada.   Sadly, they finally decided to use C++ because it
> was so much easier to find programmers.
>
> We encounter this same problem with DoD contractors.    One reason I am
given
> by major DoD software developers, for their choice of C++ is availability
> of personnel.   Often they admit the superiority of Ada but justify their
choice
> of C++ or Java on the basis of the difficulty of hiring Ada programmers.
>
> In those same organizations, many programmers don't want to program in Ada
> because they see few commercial opportunities for that skill.    These
programmers
> don't care whether Ada is a better language.  They care about the future
of their
> career.   The companies don't care whether Ada is superior to C++.   They
> often admit it is.  They do care about being able to hire people who want
to
> program in Ada.
>
> One can dismiss this as a "chicken and egg" problem.  However, it is a
problem
> that needs solving.   There are still a few brave non-DoD managers out
there who
> are
> enjoying the benefits of Ada and would choose nothing else.  This kind of
> enlightenment is not as widespread as we might like.
>
> If the DoD had not given the impression of abandoning Ada when it did,  we
might
> be a lot further ahead.   Yes, I know, abandonment was not the intention
of the
> letter that abrogated the mandate, but that is how it is widely
interpreted by both
>
> DoD contractors and commercial organizations that might have chosen it.
We
> need to raise the visibility of Ada in the media, and among our non-Ada
colleagues.
>
> At present, no one is making any effective effort to make Ada visible and
attactive
>
> to the larger software community.   Nothing is being done to promote it
among the
> software managers at DoD contractor sites, not to mention the non-DoD
sites.
>
> Those commercial organizations who have chosen Ada have done so on
> the basis of their own wisdom.    They benefit from that choice and rarely
see the
> benefit of proseletyzing their competitors.
>
> As a technology, I believe Ada is still a better choice for many software
domains.
> It is going to take something more than better technology to make the
difference. A
>
> long time ago, Ralph Crafts was a powerful spokesman for the industry.  He
finally
> gave up, recognizing that his "voice in the wilderness" was not being as
> appreciated
> as it should have been.   No one has stepped in to take over the work
Ralph was
> doing.  If someone has stepped in, they are not making themselves or Ada
visible.
>
> Richard Riehle
>

Re: Future with Ada

[IsraelRT]

On Sat, 01 Dec 2001 10:43:35 -0800, Richard Riehle
<richard@adaworks.com> wrote:
>In those same organizations, many programmers don't want to program in Ada
>because they see few commercial opportunities for that skill.    These programmers
>don't care whether Ada is a better language.  They care about the future of their
>career.   The companies don't care whether Ada is superior to C++.   They
>often admit it is.  They do care about being able to hire people who want to
>program in Ada.

The same could be said of Smalltalk, Ocaml, Haskell and any other
low-marketshare language.
That is the problem with  niche languages.

Live with it ( and the satisfaction of using a superior language ) or
use something more mainstream...

Re: Future with Ada

[Brian Rogoff]

On Sat, 1 Dec 2001, Richard Riehle wrote:
> "ben@NO_SPAM_EMAIL" wrote:
> > That is funny. It is almost impossible to find any Ada wanted ads these days.
> > Actually there are more openings for almost any other language than for Ada.
> >
> > Can you point to ONE commerical Ada opening right now that requires no
> > active security clearance in the US? I bet you there is none.
>
> Over and over, we encounter companies who, after deciding to use Ada for
> its technological advantages, cannot hire qualified Ada programmers.  Our
> most recent experience was a company in Silicon Valley.  They were excited
> about using Ada, asked us to train some of the people, and then tried to hire
> more programmers to do Ada.   They found it nearly impossible to find
> people with experience in their domain,  sufficient mathematics, and lots
> of experience in Ada.

Well, duh! These people must be pretty dumb. Overconstrain the problem and
there are no solutions. Did they think about hiring people who don't know
Ada? Ada is a fairly easy language to learn IMO, *far* easier than C++,
especially if you're willing to omit concurrency.

As a resident of the aforementioned valley, there are a number of reasons
I've never had an Ada job.

(1) Availability of jobs here. I almost never see them.
(2) Pay. When I do see them, they want to pay far less than the valley
    average. Sorry, it costs a lot to live here, so companies had better
    pay more.
(3) The security thing. I have no qualms about working on weapons (better
    that *we* have'em than not I say), but if someone insists on a
    security clearance up front almost everyone is hosed.

I never saw a job solicitation from an SV company here, so it seems that
your clients neglected this newsgroup. Doesn't seem like they tried too
hard.

> Sadly, they finally decided to use C++ because it was so much easier to
> find programmers.

It's easier to find Perl and Java programmers too I suppose, or even just
plain old C programmers. This sounds like a lame excuse. Ada is easy
enough to learn.

> In those same organizations, many programmers don't want to program in Ada
> because they see few commercial opportunities for that skill.    These programmers
> don't care whether Ada is a better language.  They care about the future of their
> career.   The companies don't care whether Ada is superior to C++.   They
> often admit it is.  They do care about being able to hire people who want to
> program in Ada.

Hmmph. I took a job programming in OCaml, far less widely used than Ada.
Why people worry about this is beyond me. I wouldn't want a job where
the language du-jour was the primary considertaion. Been there, done that
(with Java) and as Alex Stepanov said, it doesn't smell so good.

> One can dismiss this as a "chicken and egg" problem.  However, it is a problem
> that needs solving.

Hire willing programmers who don't know Ada and train them. It is *not*
that hard! A good programmer will not be hung up on surface syntax and
will be able to take much of their knowledge of C/C++/Java over to Ada.

Much of the interesting Ada work we see now is in the open source
community. That's great, but there needs to be some more activity in the
commercial world too.

FWIW, I've discussed Ada quite a bit with my manager and he acknowledges
that it's a lot better than C, C++ or Java, from his POV. We use OCaml but
if we had to do some C level work I'd have no problem doing it in Ada.
There are a *lot* of managers and programmers who are willing to try new
things. Thank goodness (really Schonberg, Dewar, and the rest of ACT)
that there is a high quality, free Ada compiler so that prospective users
can kick the tires instead of just reading!

-- Brian

Re: Future with Ada

[Michal Nowak]

On 01-12-01 at 10:43 Richard Riehle wrote:

>Over and over, we encounter companies who, after deciding to use Ada for
>its technological advantages, cannot hire qualified Ada programmers.  Our
>most recent experience was a company in Silicon Valley.  They were excited
>about using Ada, asked us to train some of the people, and then tried to hire
>more programmers to do Ada.   They found it nearly impossible to find
>people with experience in their domain,  sufficient mathematics, and lots
>of experience in Ada.   Sadly, they finally decided to use C++ because it
>was so much easier to find programmers.

The problem may be about word 'experience'. If Ada is not used widely enough,
gaining exeprience is almost impossible. When I browsed job postings at AdaIC,
most of them required 2, 5 or even 10 or 15 years of experience.
Where to get it? If companies do not have places for inexperienced programmers,
in some time they will not find exeperienced. And than there will be
no Ada...:-((

>They do care about being able to hire people who want
>to program in Ada.
>
>One can dismiss this as a "chicken and egg" problem.  However, it is a
>problem that needs solving.

One of the way to start are universities. Most programmers have
CS background (or are required to have). That requires of course, the
lecturers are aware of what Ada is. It can't be like that student makes
advices to lecturer. However it is easy to get to know all features about
Ada, but...  ...money play some role here.
What are doing big companies like Micro$oft or Oracle? They make some kind
of sponsoring to universities. As I know, Oracle invested some funds in
my university so on labs we got Oracle Developer, Designer, Oracle Databases,
etc. On another one, MS gave their operating systems and their tools (Office,
MS Money, etc.), so students are performing all analysis on their software.
Maybe some program like "Ada goes to university" or something, maybe try
this way...There are students, who are likely to learn something new,
but they are not aware about Ada.


>We
>need to raise the visibility of Ada in the media, and among our non-Ada
>colleagues.
>
>At present, no one is making any effective effort to make Ada visible and
>attactive to the larger software community.

Maybe use computer magazines. They often are sold with accompanied CDs.
Write some article about Ada, about all these good features, ask the
publihers to put for example GNAT and some tutorials on CD to enable
readers quick start. Such magazines are also read by students, this
should enable them at least became aware about Ada.

Borland (it is now Inprise as I know), was doing interesting promotions
using such magazines (at least in Poland). When they were releasing
new version of their compiler (i.e. Delphi 5.0), they put on CD
trial version of it, but also fully fuctionable, legal copy of some
earlier varsion of this compiler (i.e. Delphi 2.0), for non-commercial
use. There was possibiliy to buy a license for creating commercial
software with this product, for very inexpensive price (about 40 $).

I know that it is harder to promote a programming language than a
specialized software. But if companies wolud not have possibility to
find Ada programmers, they will stop to buying Ada compilers. And
than...

>As a technology, I believe Ada is still a better choice for many software
>domains.

So do I.

Mike
-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Richard Riehle]

Brian Rogoff wrote:

> Well, duh! These people must be pretty dumb. Overconstrain the problem and
> there are no solutions. Did they think about hiring people who don't know
> Ada? Ada is a fairly easy language to learn IMO, *far* easier than C++,
> especially if you're willing to omit concurrency.

We did train a core group within their company.   As I understand it, some
of their software is still written in Ada.   However, any new work is being
done in C++, for the reasons mentioned earlier.

As a resident of the aforementioned valley, there are a number of reasons

> I never saw a job solicitation from an SV company here, so it seems that
> your clients neglected this newsgroup. Doesn't seem like they tried too
> hard.

Au contraire.  The advertised in the SJ Mercury News, posted to this very
web site and posted to the Team-Ada Listserv.   Also, I reconmended some
people, but none of them was interested at the time.


> Hmmph. I took a job programming in OCaml, far less widely used than Ada.
> Why people worry about this is beyond me. I wouldn't want a job where
> the language du-jour was the primary considertaion. Been there, done that
> (with Java) and as Alex Stepanov said, it doesn't smell so good.

I have been consistent in my support for Ada for a long time.  My company,
AdaWorks, has been focusing almost entirely on Ada for about fourteen
years.   We kept going through lean times as well as through those that
were more lively.   Currently, I am engaged in an effort to increase interest
about Ada among a specific and carefully targeted group of future influencers.
I hope the fruits of this effort will result in more decisions to use the language
for more systems.

In my view,  Ada is the still the most appropriate language development
environment for DoD military software and any decision to use something
else does not represent careful  evaluation of the relative merits of the
competing alternatives.   I may be accused of C++ bashing, so be it.  I
really don't care.   I regard the choice of C++ for military software as
just plain bad.    It is a dangerous choice, and those who make it often
fail to realize just how bad it is when compared to the current Ada
standard.

> Hire willing programmers who don't know Ada and train them. It is *not*
> that hard! A good programmer will not be hung up on surface syntax and
> will be able to take much of their knowledge of C/C++/Java over to Ada.

Good advice.  However, it ignores the realities of the software marketplace,
the current state of awareness among managers, and the substantial anti-Ada
bias that pervades the Silicon Valley software community.   It is a bias that
originates, not in actual knowledge, but in a collection of minsinformation
that conveys a false view of Ada as a programming language.  This false
impression goes back a long way, beginning in the early eighties when the
DoD mandate required Ada for all new software even though the compilers
were not at production quality and the programmers were not adequately
trained to understand how to use it correctly.  We are still working to
overcome this history.

> Much of the interesting Ada work we see now is in the open source
> community. That's great, but there needs to be some more activity in the
> commercial world too.

Agreed.  And we also need to start using Ada for DoD weapons systems
again.   Of course, one of the best things that could happen for Ada is for
someone to create a suite of commercial software that competes with the
stuff that comes from Redmond, using Ada.   Sell lots of copies.  Make it
wildly popular.   Later announce that it was programmed in Ada, using
CLAW or GtkAda.

For example, the publishers of the new XP series of software have just
made it attractive, with their oppressive new licensing policies, for
someone to put a competing integrated office suite on the market, one
that runs on all operating systems (using something like GtkAda).   I
just participated in a project using GtkAda that, although quite specific
to a particular application, demonstates how easily one can get out from
under the domination of a software Mafia.

It would take funding, creative people, and extraordinary management,
but the current state of Ada technology is such that it is possible.

On a scale less grand,  we need some original products written in Ada
that attract a commercial following.  With all the brainpower that exists
in this forum, I find it odd that there are no entrepreneurs with the chutzpah
to take on this kind of project, no one with the imagination to conceive a
new product or improved version of an existing product.  When Ada succeeds
in the commercial marketplace, it will be because Ada enthusiasts have
started to build viable commercial products in the language.   Once that
happens.  Others will follow and corporations will take Ada seriously.

> FWIW, I've discussed Ada quite a bit with my manager and he acknowledges
> that it's a lot better than C, C++ or Java, from his POV. We use OCaml but
> if we had to do some C level work I'd have no problem doing it in Ada.
> There are a *lot* of managers and programmers who are willing to try new
> things. Thank goodness (really Schonberg, Dewar, and the rest of ACT)
> that there is a high quality, free Ada compiler so that prospective users
> can kick the tires instead of just reading!

I agree.   The work of ACT has made all the difference, even for those who
publish commercial compilers such as ICC, DDC-I, and OCS.   But not
everything can be free.   The ACT business model is unique and creative,
but few businesses can survive on that model.  RR Software sells a powerful
tool, CLAW, that is pretty much unrivaled for its completeness, the level
of craftsmanship that goes into it, and the dedication one sees in Ada
stalwart, Randy Brukhardt.    We need to be willing to support, with our
checkbooks, those who keep Ada alive through their day-to-day efforts
with commercially available products.

We also need to keep others in our community informed about what is
going on.   The only newsletter I receive on a regular basis from an Ada
company is from DDC-I.     Joyce Tokar and Jennifer Sanchez do a great
job of summarizing their current successes, sharing a little bit of technical
information, and informing about the current state of the community.   No
one else takes the trouble to do this.    As far as the Ada community is
concerned, nothing is going on.   There is no news of new projects, follow-on
work,  contracts won for Ada software,  new products released that
use Ada,   new tools, new compilers, etc.   There is an Ada consortium,
but it is a tightly-knit group that seems to assume no one outside their
immediate group is interested in what is happening with Ada.   They
never announce anything, never publish anything, never post anything
to this newsgroup, and never send anything like a newsletter to those
who continue to support Ada.

If Ada is not visible, even to its supporters, imagine how little visibility
it has among those who might benefit from it if they only knew it still was
an option.

Richard Riehle

Re: Future with Ada

[Michal Nowak]

On 01-12-02 at 00:46 Brian Rogoff wrote:

>Well, duh! These people must be pretty dumb. Overconstrain the problem and
>there are no solutions. Did they think about hiring people who don't know
>Ada? Ada is a fairly easy language to learn IMO, *far* easier than C++,
>especially if you're willing to omit concurrency.

Concurrency is one of the greatest things in Ada. This is one of the reasons
I have chosen Ada. It is much simpler to do multithreaded (miltitasking)
programs in Ada than in C++. In my opinion the difference between conurrency
between Ada and C++ shouldn't be ommited. It shows the advantege of Ada.

>> Sadly, they finally decided to use C++ because it was so much easier to
>> find programmers.
>
>It's easier to find Perl and Java programmers too I suppose, or even just
>plain old C programmers. This sounds like a lame excuse. Ada is easy
>enough to learn.

Yes, but when somebody sticks to C-like language for some years (and did
not know Ada earlier) and wants to learn Ada fast (or is told to learn fast),
in most cases gets nervous and has troubles to succeed.

Mike
-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Ted Dennison]

In article <3C0924D6.2B5A3087@adaworks.com>, Richard Riehle says...
>of experience in Ada.   Sadly, they finally decided to use C++ because it
>was so much easier to find programmers.

I always find that logic quite bogous, as *true* C++ programmers are actually
quite rare too. If you are willing to train C (with // comments) programmers to
properly use C++, I don't see why you'd have qualms about training them to use
Ada instead.

However, I quite understand that Silly Valley is the next best thing to a lost
cause. Ada's most attractive to people who are in it for the long haul. How do
you sell Ada to folks who are only looking to cash out when the company goes
public?

---
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: Future with Ada

[Ted Dennison]

In article <mailman.1007322664.31535.comp.lang.ada@ada.eu.org>, Michal Nowak
says...
>gaining exeprience is almost impossible. When I browsed job postings at AdaIC,
>most of them required 2, 5 or even 10 or 15 years of experience.
.. and that was for the C# jobs. ;-)

---
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: Future with Ada

[Wes Groleau]

> On a scale less grand,  we need some original products written in Ada
> that attract a commercial following.  With all the brainpower that exists
> in this forum, I find it odd that there are no entrepreneurs with the chutzpah
> to take on this kind of project, no one with the imagination to conceive a
> new product or improved version of an existing product.  When Ada succeeds
> in the commercial marketplace, it will be because Ada enthusiasts have
> started to build viable commercial products in the language.   Once that
> happens.  Others will follow and corporations will take Ada seriously.

I have plenty of chutzpah and enough imagination to
think up good products.  What I do not have is time,
and business talent.

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

Re: Future with Ada

[Richard Riehle]

Michal Nowak wrote:

> Maybe some program like "Ada goes to university" or something, maybe try
> this way...There are students, who are likely to learn something new,
> but they are not aware about Ada.

The current problem is that there is no money for any programs to promote
Ada.   There are no companies with "deep pockets" in the world of Ada;
there is no longer any DoD money to support it; and there is no research
agency interested in helping.

The Ada community is so small that textbook publishers have abandoned
interest in publishing new books about Ada.   Periodicals devoted to
software development have little interest in publishing articles related
to Ada.   Conferences summarily reject any proposal for a tutorial or
paper that promotes Ada.

Much of this is due to the misinterpretation of the memo from Assistant
Secretary of Defense Emmett Paige.   Throughout the DoD there is a
widespread assumption that closing of the AJPO means that the DoD no
longer wants people programming in Ada.   The assumption is false, but
there is no forum for countering it.   Among DoD contractors,  there is
the belief that the DoD has abandoned Ada totally.    That was never
the intent of Mr. Paige's memo, but many have drawn that conclusion.

On the positive side, those who continue to choose Ada do so because
they believe in its virtues.   Ultimately, this may be good for the language
because it is, in nearly every  respect, a better choice for DoD software
than any other language currently available.

We in the Ada community need to continue our efforts to keep the language
visible outside of our community.   This means continuing to submit papers
to non-Ada conferences,  proposing articles about software solutions that
used Ada to publications, and building software solutions in Ada whenever
we can.

For those with the credentials and ability,  you could propose
teaching an  evening class in Ada at your local community college.  At
first your enrollment will be low, but if you make it interesting, it will
grow.    My classes are getting larger because I am now including options
for programming in Windows (JEWL, GtkAda, and CLAW) so students
can build more interesting solutions.  "Word of mouth" advertising, in
this case, informs prospective students that Ada can be fun and worthwhile.

Ada can have a future, will have a future, if each of us is able to leverage
our talents to make that future happen.   What are the alternatives?   There
are some good ones.   Eiffel comes to mind.  But Eiffel is not ready for
safety-critical software.   C++ is its own virus.    Java is OK for small,
non-safety-critical applications where efficiency is no concern.   C# has
some interesting properties, but it still includes many of the flaws of C.
At present, Ada is easier to use, more readable, and more portable than
any of the alternatives.

We can make the future for Ada happen.   It will not happen by itself.  There
is little promotional effort by commercial Ada companies beyond their own
immediate self-interest for survival.  The ARA is doing almost nothing, or
it would seem so, since we never see anything from them.    SigAda still
puts up a booth at a few conferences, but that is not enough.   As I mentioned
earlier, the only Ada compiler publisher who sends out a newsletter seems
to be DDC-I.   The only person who currently publishes articles about Ada
outside the Ada community is Dr. Tokar.   I suppose I need to start publishing
again.   I have a few ideas, and will give it a shot.   But we need more of
our community to be making Ada interesting to the rest of the world.

Perhaps there is someone with leadership skills who will be able to develop
a coherent strategy for promoting Ada, correcting the misconceptions about
it, and reversing the current decline in new projects.   Several people have
tried, but implementing the strategy will require funding as well as leadership.
Where will the funding come from?     Where will the leadership come from?

Richard Riehle

Re: Future with Ada

[Ted Dennison]

In article <3C10F451.16977CBA@adaworks.com>, Richard Riehle says...
>The Ada community is so small that textbook publishers have abandoned
>interest in publishing new books about Ada.   Periodicals devoted to

Actually, the last time I was in my local bookstore I notice a complete lack of
books about C++ as well...

---
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: Future with Ada

[Thomas Mueller]

Regarding the future with Ada, does anybody know what's happening with the
Walnut Creek ASE2 (Ada & Software Engineering, Richard Conn, Editor) CDROM?
Last issue was November 2000.  Walnut Creek CDROM was taken over by BSDi,
subsequently by Wind River, who are not continuing the Walnut Creek CDROMs.
Will somebody else take over the ASE CDROMs, or have they fallen by the wayside?

Re: Future with Ada

[David C. Hoos, Sr.]

----- Original Message -----
From: "Thomas Mueller" <tmueller@bluegrass.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: December 09, 2001 4:56 AM
Subject: Re: Future with Ada


> Regarding the future with Ada, does anybody know what's happening with the
> Walnut Creek ASE2 (Ada & Software Engineering, Richard Conn, Editor) CDROM?
> Last issue was November 2000.  Walnut Creek CDROM was taken over by BSDi,
> subsequently by Wind River, who are not continuing the Walnut Creek CDROMs.
> Will somebody else take over the ASE CDROMs, or have they fallen by the
wayside?
>
As recently posted in this newsgroup:

It's at http://unicoi.kennesaw.edu/ase/index.htm

> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: Future with Ada

[Marin David Condic]

This is a not-uncommon problem with Ada. Many of us wish to work with the
language, but don't necessarily want to keep moving from one defense
contract to another all around the country just to follow wherever Ada may
still be in use. I find myself working in C at the moment because there just
aren't any Ada positions (or at least extremely few!) in the part of the
world I call home. I'd love to see that change, but what is the solution?

Perhaps if the Ada employers were more flexible to the notion of
telecommuting it would be possible to string together a bunch of available
Ada programmers from around the country & provide the services needed.
(Hmmmmmmmm........ ) Perhaps that helps consolidate the niche market - but
it is a mode of operation unfamiliar to most companies.

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/


"Suzie Cube" <zzzette@hotmail.com> wrote in message
news:u0iilkqrts7015@corp.supernews.com...
>
> I am finding that most, if not all, the Ada jobs will require another
> relocation.  I had hoped that that would not be the case in the
Dallas/Fort
> Worth Metroplex.  Lockheed Martin cites no language in their JSF postings,
> and conversations here (cla) indicate it's not Ada.  (It would be a
> relocation, too, from east Dallas 'burb, to west FW company, but that's
> o.k.)  Other companies appear to have converted to other languages or sent
> their Ada work elsewhere... or just aren't hiring now.
>

Re: Future with Ada

[Marin David Condic]

Time is the enemy of us all! :-)

Well, what about a project like this: A suite of office tools (word
processor, spreadhseet, presentation tool, database, e-mail, calendar,
address book, web browser, etc...) that is written in Ada and - because of
inherent portability & portability of the support tools (GUI, etc.) - runs
on Windoze, Unix/Linux, etc...? If its available in source and target
formats for a variety of machines & has advantages over whatever else is out
there, I think it stands a chance of adoption by those who have to use
multiple platforms. I could imagine a scenario in which some of us Ada
advocates took it on as a part-time project (maybe call it "The Great Ada
Conspiracy"?) and eventually commercialize the endeavor. If there's an
initial product to work with, then business management, sales & marketing,
etc. can all be purchased. Build the better mousetrap?

Ideas like this will help cause Ada to be more attractive & perhaps start
generating that job market we'd all like to see...

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/


"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3C0BB57F.61887AFD@sparc01.ftw.rsc.raytheon.com...
>
> I have plenty of chutzpah and enough imagination to
> think up good products.  What I do not have is time,
> and business talent.
>

Re: Future with Ada

[Larry Hazel]

Marin David Condic wrote:

> Perhaps if the Ada employers were more flexible to the notion of
> telecommuting it would be possible to string together a bunch of available
> Ada programmers from around the country & provide the services needed.
> (Hmmmmmmmm........ ) Perhaps that helps consolidate the niche market - but
> it is a mode of operation unfamiliar to most companies.
> 
Perhaps it would also help make Ada more popular if one of the perks of Ada
programming is a higher probablity of working from home.

Larry

Re: Future with Ada

[Ted Dennison]

In article <3C14EAE6.FD136C34@otelco.net>, Larry Hazel says...
>Perhaps it would also help make Ada more popular if one of the perks of Ada
>programming is a higher probablity of working from home.

For those of us with small kids, that isn't much of a perk. :-)

---
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: Future with Ada

[Marin David Condic]

Having worked from home in the past, I can attest to the fact that it has a
number of disadvantages that will tend to offset the advantages. Its an
engineering tradeoff.

However, one would think it might have advantages for a company in terms of
reducing the amount of office space they have to maintain, etc. Being
willing to hire a team of Ada Software Engineers located in diverse parts of
the country with the occasional face-to-face meeting has cost savings and
advantages associated with it. However, it can have its downsides for the
business as well. (There may be legal restrictions & liability issues that
can make it difficult to consider this, along with any number of practical
concerns about productivity, etc.)

Still seems like it would be a good way of pulling together Ada personnel &
getting a job done....

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:196R7.56219$xS6.90429@www.newsranger.com...
> In article <3C14EAE6.FD136C34@otelco.net>, Larry Hazel says...
> >Perhaps it would also help make Ada more popular if one of the perks of
Ada
> >programming is a higher probablity of working from home.
>
> For those of us with small kids, that isn't much of a perk. :-)
>
> ---
> 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: Future with Ada

[Larry Kilgallen]

In article <9v2rme$p0h$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> However, one would think it might have advantages for a company in terms of
> reducing the amount of office space they have to maintain, etc. Being
> willing to hire a team of Ada Software Engineers located in diverse parts of
> the country with the occasional face-to-face meeting has cost savings and
> advantages associated with it. However, it can have its downsides for the
> business as well. (There may be legal restrictions & liability issues that
> can make it difficult to consider this, along with any number of practical
> concerns about productivity, etc.)
> 
> Still seems like it would be a good way of pulling together Ada personnel &
> getting a job done....

Sites that don't do government classified shops might have a competitive
advantage in getting people if they can offer telecommuting.

Re: Future with Ada

[Marin David Condic]

Sure. But there can be other barriers as well. Colocation might be seen as
critical to keeping productivity high. The inability to actually supervise
anyone and be sure that they are spending their day in a semi-productive
manner can also be an issue. (Not always possible even when someone is
on-site, but at least you get a better feeling for it.) Managing programmers
is enough like hearding cats as it is - how much harder would it be if all
the cats are in different locations and have less communications between
them? Can you effectively keep everyone on the same chapter/verse if they
are spread out all over? What about the costs of getting the whole team
together as will be necessary on some non-trivial number of occasions?

I'm not saying it can't be done - I've seen it be relatively successful in
some realizations. Its just that there are downsides - real or imagined -
that can get in the way of companies willingness to try it. (It isn't
exactly a "No Brainer" that telecommuting is a "good" thing. It might not be
in any given set of circumstances.)

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:vuS7rReZ0o$c@eisner.encompasserve.org...
>
> Sites that don't do government classified shops might have a competitive
> advantage in getting people if they can offer telecommuting.

RE: Future with Ada

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin Condic et al.
"A suite of office tools (word processor, spreadsheet, presentation tool,
database, e-mail, calendar, address book, web browser, etc...) that is
written in Ada". Yes! I might note that the trick is to base the suite on
XML. Then, one can achieve true platform independence. A large number of
Microsoft's customers use Microsoft products because we have no other real
choice. We would gladly switch to something that was dependable. An Ada
product where the sources were available would have, as I have published,
the great advantages of truly distributed production (minimal overhead
costs), extensibility by third parties, and thanks to ASIS an equitable way
to distribute the royalties to the developers. Parenthetically, a well
designed office suite would have such minimal hardware requirements, it
would wreck havoc on PC sales. I might note that a virus checker should be
included in these tools.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Monday, December 10, 2001 8:40 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Future with Ada


Time is the enemy of us all! :-)

Well, what about a project like this: A suite of office tools (word
processor, spreadhseet, presentation tool, database, e-mail, calendar,
address book, web browser, etc...) that is written in Ada and - because of
inherent portability & portability of the support tools (GUI, etc.) - runs
on Windoze, Unix/Linux, etc...? If its available in source and target
formats for a variety of machines & has advantages over whatever else is out
there, I think it stands a chance of adoption by those who have to use
multiple platforms. I could imagine a scenario in which some of us Ada
advocates took it on as a part-time project (maybe call it "The Great Ada
Conspiracy"?) and eventually commercialize the endeavor. If there's an
initial product to work with, then business management, sales & marketing,
etc. can all be purchased. Build the better mousetrap?

Ideas like this will help cause Ada to be more attractive & perhaps start
generating that job market we'd all like to see...

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/


"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3C0BB57F.61887AFD@sparc01.ftw.rsc.raytheon.com...
>
> I have plenty of chutzpah and enough imagination to
> think up good products.  What I do not have is time,
> and business talent.
>

Re: Future with Ada

[Marin David Condic]

Certainly, XML would be a good basis for reasons of portability. Not only
for GUI building but any sort of document formatting. So hypothetically, a
good start would be to build a word processor in Ada that stored its
documents in XML and, if possible, had its GUI built from XML. If it defined
its own kind of Look-and-Feel, it would be the basis for a suite of other
tools. You'd have built your own means of generating and displaying XML and
defined a style of interaction that could be taken over to a spreadsheet,
e-mail program, etc.

It could be the "Killer App" that starts having Ada make its inroad into the
popular idiom. The portability thing alone would be a real major advantage
considering all the flavors of Windows, Unix, etc that are out there.
Hmmmmm........

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 C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.1008016322.1298.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin Condic et al.
> "A suite of office tools (word processor, spreadsheet, presentation tool,
> database, e-mail, calendar, address book, web browser, etc...) that is
> written in Ada". Yes! I might note that the trick is to base the suite on
> XML. Then, one can achieve true platform independence. A large number of
> Microsoft's customers use Microsoft products because we have no other real
> choice. We would gladly switch to something that was dependable. An Ada
> product where the sources were available would have, as I have published,
> the great advantages of truly distributed production (minimal overhead
> costs), extensibility by third parties, and thanks to ASIS an equitable
way
> to distribute the royalties to the developers. Parenthetically, a well
> designed office suite would have such minimal hardware requirements, it
> would wreck havoc on PC sales. I might note that a virus checker should be
> included in these tools.
>

Re: Future with Ada

[Darren New]

Marin David Condic wrote:
> It could be the "Killer App" that starts having Ada make its inroad into the
> popular idiom. The portability thing alone would be a real major advantage
> considering all the flavors of Windows, Unix, etc that are out there.

Well, if it doesn't read and write MSWord files, then it's not going to
be very popular. If it does read and write MSWord files, then why would
someone prefer it over MSWord or over any of the other MSWord-compatible
suites (like StarOffice)?

You need something that everyone will want that *hasn't* already been
done but that everyone wants. Something like OpenSSL would have been
good, except it's been done already. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   You will soon read a generic fortune cookie.

Re: Future with Ada

[Marin David Condic]

The problem is that Micro$oft uses "MS-Word-Compatibility" to kill their
competition. As soon as you can suck up an MS-Word file and spit one out,
they go and change the format and you're forever playing catch-up. Not a
good thing.

However, if your program works with XML, , you may miss compatibility with
MS-Word, but you've got compatibility with a whole slew of other things
instead. What you are hoping for is that XML gains enough critical mass (as
did HTML) that Micro$oft is adapting to *you* instead of the other way
around. IOW, for maybe 90% of my needs, I don't really care what the format
is so long as I can read and edit it and people in my office can read and
edit it. MS-Word (if it can't already) eventually will want to read & write
XML. So *my* editor is slick and spiffy and runs on Suns and PCs and Linux
and Macs and anywhere I care to go *and* will spit out something the MS-Word
Ludites can still look at. Where is the problem?

I wouldn't be adverse to including an Import/Export feature for any number
of popular WP formats - but I don't think that should be at the core. Its an
add-on that can be built anytime by anybody. (Thats why its in source,
right? :-) The point being that you've got a spiffy word processor that
works just about anywhere - including over the net because it uses XML as
its storage format and GUI - and that's an incentive for people to want to
use it. If a whole office suite comes out of it, people might get really
attracted to it as an alternative to being tied to Micro$oft or Sun.

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:3C163AAB.1C8EEA69@san.rr.com...
>
> Well, if it doesn't read and write MSWord files, then it's not going to
> be very popular. If it does read and write MSWord files, then why would
> someone prefer it over MSWord or over any of the other MSWord-compatible
> suites (like StarOffice)?
>
> You need something that everyone will want that *hasn't* already been
> done but that everyone wants. Something like OpenSSL would have been
> good, except it's been done already.
>
> --
> Darren New
> San Diego, CA, USA (PST). Cryptokeys on demand.
>    You will soon read a generic fortune cookie.

Re: Future with Ada

[Michal Nowak]

On 01-12-07 at 08:54 Richard Riehle wrote:

>The current problem is that there is no money for any programs to promote
>Ada.   There are no companies with "deep pockets" in the world of Ada;
>there is no longer any DoD money to support it; and there is no research
>agency interested in helping.
>
>The Ada community is so small that textbook publishers have abandoned
>interest in publishing new books about Ada.   Periodicals devoted to
>software development have little interest in publishing articles related
>to Ada.   Conferences summarily reject any proposal for a tutorial or
>paper that promotes Ada.

That looks like a way toward extiction :-(( Too bad ...


>For those with the credentials and ability,  you could propose
>teaching an  evening class in Ada at your local community college.
>At first your enrollment will be low, but if you make it interesting, it will
>grow.

I'm still a student, but I hope it will be possible to make a presentation
on special interests meetings. Especially that there are earlier years
students, so the faster they will hear about Ada, the better effect it
may have.

-Mike

-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

XML and Ada was RE: Future with Ada

[Robert C. Leif, Ph.D.]

From: Bob Leif,
To: Darren New et al.
So far as I can tell, Star Office unfortunately has the same deficiencies as
Microsoft Office. Firstly, since most users only "program" using
spreadsheets, software engineering should be applied to these packages. The
Column and Row labels should be unique names. This A1, B2, etc. is at the
level of a poorly designed assembler. Lotus Improv did it right by employing
unique labels. Lotus in its search for failure killed this very well
designed product.

Real compound documents can be created using XML together with XSL. The
spreadsheet engine should provide the tables for documents. The market needs
a document based system; not a group of dysfunctional, separate programs. In
case some of you remember, there was a program from Ashton-Tate called
FrameWork that did this. It is not a new idea. However, the combined
functionality of Ada and XML will greatly facilitate the development of a
commercial office suite. If the sources are available, it will be truly
extensible.

OLE permits me to incorporate Excel data, usually graphs from spreadsheets
into my FrameMaker documents. Unfortunately, the entire spreadsheet is
incorporated by OLE into the document file. Therefore, if I incorporate 3
graphs from one Excel file, I incorporate 3 copies of the entire Excel file.
I use FrameMaker because the paragraph numbering and styles work.

Since many commercial programs can import Word and Excel files, I do not
think that it will be a problem. In fact, Excel has a Save As function for
XML. Word does not. However, I believe that commercial tools exist that can
import Word.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Darren New
Sent: Tuesday, December 11, 2001 8:57 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Future with Ada


Marin David Condic wrote:
> It could be the "Killer App" that starts having Ada make its inroad into
the
> popular idiom. The portability thing alone would be a real major advantage
> considering all the flavors of Windows, Unix, etc that are out there.

Well, if it doesn't read and write MSWord files, then it's not going to
be very popular. If it does read and write MSWord files, then why would
someone prefer it over MSWord or over any of the other MSWord-compatible
suites (like StarOffice)?

You need something that everyone will want that *hasn't* already been
done but that everyone wants. Something like OpenSSL would have been
good, except it's been done already.

--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
   You will soon read a generic fortune cookie.

Re: Future with Ada

[Richard Riehle]

Marin David Condic wrote:

> The problem is that Micro$oft uses "MS-Word-Compatibility" to kill their
> competition. As soon as you can suck up an MS-Word file and spit one out,
> they go and change the format and you're forever playing catch-up. Not a
> good thing.

This is the very business practice that will ultimately doom the Microsoft
product line.  We are entering a new era of software in which interoperability
is going to become more and more important.  I believe the entire XP
business plan is going to backfire on MS and users are going to be looking
for alternatives.   The XP model for doing business has turned the consumer
into the enemy, treats customers as if they are criminals, and accrues no
benefit to anyone  who chooses to adopt it.

Someone, not necessarily in the world of Ada, should be able to attack this
vulnerability with sensible, user-friendly, interoperable,  and affordable
software that demonstrates how software ought to be rather than how MS
dictates it to be.

There is a real business opportunity for someone here.

Richard Riehle

Re: Future with Ada

[Larry Kilgallen]

In article <3C16B720.AB523493@adaworks.com>, Richard Riehle <richard@adaworks.com> writes:

> This is the very business practice that will ultimately doom the Microsoft
> product line.  We are entering a new era of software in which interoperability
> is going to become more and more important.  I believe the entire XP
> business plan is going to backfire on MS and users are going to be looking
> for alternatives.   The XP model for doing business has turned the consumer
> into the enemy, treats customers as if they are criminals, and accrues no
> benefit to anyone  who chooses to adopt it.

What is the XP business plan ?

Do you mean software enforcement of licenses ?

We have had that for years on other platforms.

Re: Future with Ada

[Mark Biggar]

Larry Kilgallen wrote:
> 
> In article <3C16B720.AB523493@adaworks.com>, Richard Riehle <richard@adaworks.com> writes:
> 
> > This is the very business practice that will ultimately doom the Microsoft
> > product line.  We are entering a new era of software in which interoperability
> > is going to become more and more important.  I believe the entire XP
> > business plan is going to backfire on MS and users are going to be looking
> > for alternatives.   The XP model for doing business has turned the consumer
> > into the enemy, treats customers as if they are criminals, and accrues no
> > benefit to anyone  who chooses to adopt it.
> 
> What is the XP business plan ?
> 
> Do you mean software enforcement of licenses ?
> 
> We have had that for years on other platforms.

No, he means things like swapping out your floppy drive for a second
battery pack on your laptop and having XP decide that it's running on
a different computer and locking up until you spend 2 hrs on the phone
to MS help to get a new license key.  This can happen if you change
anything about your hardware configuration, add memory, upgrade your
sound or video card, add a NIC card for your new DSL line, etc.

--
Mark Biggar
mark.a.biggar@attbi.com

Re: Future with Ada

[rob]

In article <9v57u1$mfb$1@nh.pace.co.uk>, "Marin says...
>
>Certainly, XML would be a good basis for reasons of portability. Not only
>for GUI building but any sort of document formatting. So hypothetically, a
>good start would be to build a word processor in Ada that stored its
>documents in XML and, if possible, had its GUI built from XML.  

you guys are going about it all the wrong way.

to make Ada more popular, you do not need to write yet another word 
processor in it (star office is doing pretty well anyway).

Put the effort into reusable standard packages. there are so many
areas where Ada has no standard packages to do things. Take Java 
libraries as an example.

Re: Future with Ada

[Larry Kilgallen]

In article <3C16FB82.4C243BB3@attbi.com>, Mark Biggar <mark.a.biggar@attbi.com> writes:
> Larry Kilgallen wrote:

>> What is the XP business plan ?
>> 
>> Do you mean software enforcement of licenses ?

> No, he means things like swapping out your floppy drive for a second
> battery pack on your laptop and having XP decide that it's running on
> a different computer and locking up until you spend 2 hrs on the phone
> to MS help to get a new license key.  This can happen if you change
> anything about your hardware configuration, add memory, upgrade your
> sound or video card, add a NIC card for your new DSL line, etc.

I supposed it depends on your lifestyle.  I have lots of computers
(typically not Windows) and it is a rare year I would make such a
configuration change aside from on an external SCSI chain.  But then
I am not a hardware person.

Re: Future with Ada

[Ted Dennison]

In article <3miWUMO0XDWw@eisner.encompasserve.org>, Larry Kilgallen says...
>I supposed it depends on your lifestyle.  I have lots of computers
>(typically not Windows) and it is a rare year I would make such a
>configuration change aside from on an external SCSI chain.  But then
>I am not a hardware person.

We basicly have a rotating hardware system at my house. I purchase about 3-5 new
components a year. The new ones go in my machine, my old ones go in my wife's
machine, and starting this year, my wife's old ones go in the kids' machine.
Eventually we will have enough old ones from that to give each kid their own
machine...

Anyway, I have no huge problem with having to call a # somewhere to activate an
OS license. I'm used to having to do that with Unix software at work. What I do
have a big problem with is the vendor deciding that after 3 or 4 upgrades, I
have to purchase a whole new copy. Depending on the components, that could put
me out 3 whole OS's (one for each machine) in a year (or about $600). The first
time that happens, a Free OS *will* be the replacement...

---
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: Future with Ada

[Marin David Condic]

Well, the problem is that it *works* - for a while. And "for a while" is
about as long as any business plan will work. Microsoft can keep selling
Word and milking the cash cow "for a while" and then they will have to come
up with something else and a different plan. Doom for a particular product
line is inevitable. Doom for Microsoft is another question - will they adapt
to a changing world?

I do agree that there is an opening for a new product line that stresses
openness and interoperability. Developing an office suite that is available
in source and runs on a number of diverse platforms and keeps its data in
formats that are easily accessed by other programs is something that has
advantages to the consumer who wants to be able to keep his options open. It
could be a good business opportunity.

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:3C16B720.AB523493@adaworks.com...
>
> This is the very business practice that will ultimately doom the Microsoft
> product line.  We are entering a new era of software in which
interoperability
> is going to become more and more important.  I believe the entire XP

Re: Future with Ada

[Marin David Condic]

But a product like this would ultimately result in a bunch of standard
packages - if it was designed right. You'd have various kinds of XML
interpretation packages for GUI work and/or rendering of XML files. You'd
have things like a "Document Object" or a "Spreadsheet Object", etc. All of
those things would start to look like things in the Java libraries or
similar language supplied utilities.

I would agree that if Ada can figure out a way of including more libraries
in a standard way that is portable across a number of platforms, it would be
good for making the language more useful.

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/


"rob@z" <rob_member@newsguy.com> wrote in message
news:9v74ov014bc@drn.newsguy.com...
>
> Put the effort into reusable standard packages. there are so many
> areas where Ada has no standard packages to do things. Take Java
> libraries as an example.
>

Re: Future with Ada

[Ian S. Nelson]

rob@z wrote:

> In article <9v57u1$mfb$1@nh.pace.co.uk>, "Marin says...
> 
>>Certainly, XML would be a good basis for reasons of portability. Not only
>>for GUI building but any sort of document formatting. So hypothetically, a
>>good start would be to build a word processor in Ada that stored its
>>documents in XML and, if possible, had its GUI built from XML.  
>>
> 
> you guys are going about it all the wrong way.
> 
> to make Ada more popular, you do not need to write yet another word 
> processor in it (star office is doing pretty well anyway).
> 
> Put the effort into reusable standard packages. there are so many
> areas where Ada has no standard packages to do things. Take Java 
> libraries as an example.


That's a good start.  It certainly hasn't hurt python or perl.  I think 
it's only part of it though.  I like ada and I see the benefits of it 
and it's easy to say what they are but with ada becoming part of the GNU 
compiler collection and possibly becoming more available to millions of 
hackers around the world it could be time to start putting money where 
the mouth is and produce a lot of free apps for Linux and BSD type 
systems.

For example, there are probably a dozen MTAs.  Security is a concern, 
reliability is a concern, performance is a concern and then the ability 
to shove the thing in to the various odd ball configurations people run 
for mail servers.  It's a hard problem and of those dozen MTAs, I don't 
see one written in ada.  DNS is the same way, there are probably 20 
different packages the serve up names.

I would think some kind of effort like the GNU project would be the best 
way.  Build a ton of tools and apps in ada and show that they are easier 
to maintain, more reliable (kind of hard since so many packages have 
been hammered on for decades) easier to extend and then ultimately 
better.  That's kind of what the AdaOS project is/was, except they were 
starting with the kernel and working out. It's a ton of work, it's not 
all terribly sexy work and some of it is difficult, I'm not sure how you 
build a better grep, but the end result should be well thought out tools 
and app that work, share lot's of common code and are easy to maintain 
and enhance.

Ian

Re: Future with Ada

[Peter Hend�n]

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

> Anyway, I have no huge problem with having to call a # somewhere to
activate an
> OS license. I'm used to having to do that with Unix software at work. What
I do
> have a big problem with is the vendor deciding that after 3 or 4 upgrades,
I
> have to purchase a whole new copy. Depending on the components, that could
put
> me out 3 whole OS's (one for each machine) in a year (or about $600). The
first
> time that happens, a Free OS *will* be the replacement...

Once upon a time we threw out DomainIX (Apollo - Unix look-alike long since
swallowed and digested by HP) in favor of Windows NT just because of
the activation calls necessary when swapping hardware. We have also
systematically expunged any software requiring dongles or any type of
non-permanent code. These "protections" have cost us more than its worth,
and until the vendors offer a no-delay clause with stiff penalties this
is a no-no.

/Peter H

--
Peter Hend�n           http://www.algonet.se/~phenden
ICQ: 14672398
Teknisk Dokumentation AB          http://www.tdab.com

Re: Future with Ada

[tmoran]

> openness and interoperability. Developing an office suite that is available
> in source and runs on a number of diverse platforms and keeps its data in
> formats that are easily accessed by other programs is something that has
> advantages to the consumer who wants to be able to keep his options open. It
> could be a good business opportunity.
  Observing my wife's struggles with MS Office, and my own difficulties
in figuring out "the MS way" to do things, I'd guess the number of
people who want something in source, interoperable, etc., is dwarfed by
the number who would leap at something that made sense.

Re: Future with Ada

[Mark Lundquist]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:tWJR7.58768$xS6.95360@www.newsranger.com...
>
> We basicly have a rotating hardware system at my house. I purchase about
3-5 new
> components a year. The new ones go in my machine, my old ones go in my
wife's
> machine, and starting this year, my wife's old ones go in the kids'
machine.
> Eventually we will have enough old ones from that to give each kid their
own
> machine...

Kind of a trickle-down effect, huh?  I guess it becomes true "rotation" the
day your kids nag you into trading computers with them... :-)

Re: Future with Ada

[Ted Dennison]

In article <WjOR7.36636$wL4.190944@rwcrnsc51>, Mark Lundquist says...
>"Ted Dennison" <dennison@telepath.com> wrote in message
>news:tWJR7.58768$xS6.95360@www.newsranger.com...
>>
>> We basicly have a rotating hardware system at my house. I purchase about
..
>Kind of a trickle-down effect, huh?  I guess it becomes true "rotation" the
>day your kids nag you into trading computers with them... :-)

True. Right now the trailing edge of technology is more than enough to run the
"Freddy Fish" and "JumpStart" titles they want to run. My wife is good in the
middle doing her web-based chats and an occasional turn-based strategy game. But
there will probably come a day when the kids are just about as pleased with
trickle-down computers as lower wager earners are with trickle-down economics.
:-)

---
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: Future with Ada

[Darren New]

Marin David Condic wrote:
> The problem is that Micro$oft uses "MS-Word-Compatibility" to kill their
> competition. As soon as you can suck up an MS-Word file and spit one out,
> they go and change the format and you're forever playing catch-up. Not a
> good thing.

Well, not for MS's competition, no.

> Where is the problem?

As soon as you try to sell it to an ad executive, CEO, or other
non-technical person, and explain that they can't read the documents
made up by people in other companies, or perhaps even other departments.
Nor can they send the document. Nor is it compatible with the add-ons
that other folks use. Etc.

I'll repeat - if it doesn't read & write MSWord files, it won't be
popular enough to be a killer app. I also suspect you underestimate just
how much spif really is in MS Office already.

Maybe if MSOffice ossifies and you can actually catch up on a
feature-by-feature basis...

But I think it would be more effective to find something *new* to do,
where you can start small and still have a chance of being popular.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   You will soon read a generic fortune cookie.

Re: Future with Ada

[John Kern]

Does anyone know whether this is a press release for an Ada project or
not?

http://www.wrs.com/html/x38.html

Richard Riehle wrote:
> 
> "ben@NO_SPAM_EMAIL" wrote:
> 
> > That is funny. It is almost impossible to find any Ada wanted ads these days.
> > Actually there are more openings for almost any other language than for Ada.
> >
> > Can you point to ONE commerical Ada opening right now that requires no
> > active security clearance in the US? I bet you there is none.
> 
> Over and over, we encounter companies who, after deciding to use Ada for
> its technological advantages, cannot hire qualified Ada programmers.  Our
> most recent experience was a company in Silicon Valley.  They were excited
> about using Ada, asked us to train some of the people, and then tried to hire
> more programmers to do Ada.   They found it nearly impossible to find
> people with experience in their domain,  sufficient mathematics, and lots
> of experience in Ada.   Sadly, they finally decided to use C++ because it
> was so much easier to find programmers.
> 
> We encounter this same problem with DoD contractors.    One reason I am given
> by major DoD software developers, for their choice of C++ is availability
> of personnel.   Often they admit the superiority of Ada but justify their choice
> of C++ or Java on the basis of the difficulty of hiring Ada programmers.
> 
> In those same organizations, many programmers don't want to program in Ada
> because they see few commercial opportunities for that skill.    These programmers
> don't care whether Ada is a better language.  They care about the future of their
> career.   The companies don't care whether Ada is superior to C++.   They
> often admit it is.  They do care about being able to hire people who want to
> program in Ada.
> 
> One can dismiss this as a "chicken and egg" problem.  However, it is a problem
> that needs solving.   There are still a few brave non-DoD managers out there who
> are
> enjoying the benefits of Ada and would choose nothing else.  This kind of
> enlightenment is not as widespread as we might like.
> 
> If the DoD had not given the impression of abandoning Ada when it did,  we might
> be a lot further ahead.   Yes, I know, abandonment was not the intention of the
> letter that abrogated the mandate, but that is how it is widely interpreted by both
> 
> DoD contractors and commercial organizations that might have chosen it.   We
> need to raise the visibility of Ada in the media, and among our non-Ada colleagues.
> 
> At present, no one is making any effective effort to make Ada visible and attactive
> 
> to the larger software community.   Nothing is being done to promote it among the
> software managers at DoD contractor sites, not to mention the non-DoD sites.
> 
> Those commercial organizations who have chosen Ada have done so on
> the basis of their own wisdom.    They benefit from that choice and rarely see the
> benefit of proseletyzing their competitors.
> 
> As a technology, I believe Ada is still a better choice for many software domains.
> It is going to take something more than better technology to make the difference. A
> 
> long time ago, Ralph Crafts was a powerful spokesman for the industry.  He finally
> gave up, recognizing that his "voice in the wilderness" was not being as
> appreciated
> as it should have been.   No one has stepped in to take over the work Ralph was
> doing.  If someone has stepped in, they are not making themselves or Ada visible.
> 
> Richard Riehle

Re: Future with Ada

[Mark Lundquist]

"rob@z" <rob_member@newsguy.com> wrote in message
news:9v74ov014bc@drn.newsguy.com...
> In article <9v57u1$mfb$1@nh.pace.co.uk>, "Marin says...
>
> you guys are going about it all the wrong way.
>
> to make Ada more popular, you do not need to write yet another word
> processor in it (star office is doing pretty well anyway).
>
> Put the effort into reusable standard packages. there are so many
> areas where Ada has no standard packages to do things. Take Java
> libraries as an example.
>

I think you're right on the money there, Rob Z :-)

Java came along at a time when people who needed to write software were
looking around to see what were the viable alternatives for an
implementation language, and it seemed to them that the only things out were
C++ and Perl, and they said, "There has got to be a better way".  Then along
comes Java, which was way simpler to learn than C++ (though don't get me
wrong, it does have its share of confusing mind-rot, just nowhere near as
byzantine as C++'s), and unlike Perl you had a decent chance of being able
to figure out the meaning of your own code if you came back to it the next
day (let alone a year later).

But on top of these advantages, Java had a huge standard library of relevant
stuff! ("standard" enough for the purposes of this discussion -- please,
please do not anyone revive that lame thread about the True Meaning Of
"Standard".  Just don't).  Anyway, like I was saying... a huge library of
relevant stuff!  I think that is a key part of the appeal of Java, and I
think future languagues that want mainstream acceptance are going to have to
have big libraries.  People don't just want a language that facilitates
reuse, they want the actual reusable stuff, and they want it to be standard.
Languages will continue to target different points on the spectrum of
minimal-to-rich syntax (e.g. Ada and C++ have rich syntax, Smalltalk has a
simple syntax, LISP extreme minimalist syntax), but whichever way they go on
syntax, the library had better be there, or mainstream acceptance is a
non-starter.  The minimal-library philosophy is a failure for mainstream
languages.  The big library philosophy won (and if I may add, rightly so
IMHO).  I feel it will be best for Ada if the maintainers of the language
lose any hangups they may have over this (I don't know if they have any or
not), e.g. any lingering sensitivity to 80's criticism of Ada as "too big" a
language.  People are used to thinking of a "core language" + "standard
library", and they expect the library to be big.  They understand the
difference between that and a huge core language.

--

--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Re: Future with Ada

[Marin David Condic]

I'm basically with you here and have argued in this forum in the past that
Ada should have more "standard" libraries. Some work is being done in the
area of data structures - hopefully that much could become a de facto
standard if not a de jure standard.

I agree that it would be nice to have a large library of stuff just as does
Java. In particular, some version of a standard GUI library of some sort.
One of the problems with doing this is that Ada targets a whole slew of
computers not all of which would have such a library make sense. Even for
the platforms for which something like a GUI does make sense, you still
might have problems specifying something that is portable and still makes
reasonably good use of what is actually available on the given platform.
Windows GUI stuff, for example, looks very different from what you get under
Motif. Would a "standard" GUI library be able to work on both without
restricting itself to some unacceptable subset of what is possible? Would
Windows programmers/users want something that didn't look a lot like a
typical Windows app? (GtkAda works in a variety of places, but it doesn't
seem to look a lot like "Windows" when its on that platform. Is that going
to be a handicap?)

So I think there is a problem with getting large libraries of stuff
"standardized" in Ada. To get it into The Real Standard, it would have to a)
reduce itself to the lowest common denominators for the platforms on which
it was possible and b) exist as an optional annex so it could be eliminated
for platforms on which it was difficult or impossible to implement. (I don't
see "b" as being a big problem - but there may be other opinions on that...)

The other alternative - a de facto standard - might be a better choice. For
example, you could have a "Windows-GUI" library and a "Motif-GUI" library
that assumed the capabilities of a given platform and compiler vendors would
have to come to some kind of agreement that if they were putting out a
Windows targeted compiler that they would support the appropriate "standard"
library. But this, in and of itself, has problems. It creates portability
between compilers - but that's not necessarily in the interest of the
vendors and may not be that interesting to the consumers. It certainly
doesn't provide portability across platforms - which might be of varying
levels of interest to the consumers.

Besides, no matter how much discussion there is around here about the need
for semi-standard libraries, we never seem to hear anything from the vendors
indicating that they are at all amenable to the idea. If they won't get
behind it, the issue is dead. We already have lots of libraries of Ada code
available for the cost of a download, but that leaves the end-user bumbling
around, cobbling together a development environment of dubious quality and
consistency. Not to mention that it isn't a "standard" then - or maybe its
in the mode of: "Standards are such a wonderful thing that everyone wants
one of their very own!" :-)

So I'm not sure how to get there other than by doing what is happening in
one small corner of this newsgroup with respect to the idea of an Ada
Standard Components Library: If a group of interested parties gang up on a
given problem space and produce a reasonably good library that they are
willing to put in the public domain, it might stand a chance. If there is
some reasonable level of consensus that it is "The Right Thing" or "Good
Enough" and finds some following, then *maybe* the vendors will get behind
it and distribute it. But that's a big "maybe".

If Ada were owned by Sun or Microsoft, it might get the funding to produce
some large standard libraries for at least the platforms targeted by either
of those giants. If Ada had not been "abandoned" by the DoD, it is
conceivable that they might have thrown some big $$$ at developing some
"standard" libraries. (Indeed, they were the source of some of the numerous,
disparate, bits-and-pieces libraries that are out on the Internet today.)
But without the deep pockets and/or the will/direction to Make It So
(expressed by the vendors and/or SIGAda?) I don't see much chance of it
happening.

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 Lundquist" <no.spam@getalife.com> wrote in message
news:oN5S7.47886$Yy.536849@rwcrnsc53...
> languages.  The big library philosophy won (and if I may add, rightly so
> IMHO).  I feel it will be best for Ada if the maintainers of the language
> lose any hangups they may have over this (I don't know if they have any or
> not), e.g. any lingering sensitivity to 80's criticism of Ada as "too big"
a
> language.  People are used to thinking of a "core language" + "standard
> library", and they expect the library to be big.  They understand the
> difference between that and a huge core language.
>

Re: Future with Ada

[Mark Lundquist]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9vb24v$7fg$1@nh.pace.co.uk...
>
> I agree that it would be nice to have a large library of stuff just as
does
> Java. In particular, some version of a standard GUI library of some sort.
> One of the problems with doing this is that Ada targets a whole slew of
> computers not all of which would have such a library make sense. Even for
> the platforms for which something like a GUI does make sense, you still
> might have problems specifying something that is portable and still makes
> reasonably good use of what is actually available on the given platform.
> Windows GUI stuff, for example, looks very different from what you get
under
> Motif. Would a "standard" GUI library be able to work on both without
> restricting itself to some unacceptable subset of what is possible? Would
> Windows programmers/users want something that didn't look a lot like a
> typical Windows app?

You're right, AWT/Swing account for a large part of the JCL.  And
cross-platform GUIs are a big hairy rat's nest, for the reasons you mention.
But I think there's plenty a standard Ada library could focus on that's more
fundamental than GUIs.  I'm interested in things that help with programming
the "under the hood" stuff, and I'd just as soon let the GUI stuff alone for
the time being...

> (GtkAda works in a variety of places, but it doesn't
> seem to look a lot like "Windows" when its on that platform. Is that going
> to be a handicap?)

Well, GtkAda is an Ada binding to Gtk, and Gtk was (I think) meant to be
Motif-alike for Linux, not designed as a cross-platform GUI (I could be
wrong about this, I'm sure someone will correct me if that is the case :-).
The point being, whatever can be said about GtkAda in this regard can also
be said about Gtk.  You wouldn't look to GtkAda to solve any problem that
Gtk itself was not designed to solve.

I think any true cross-platform GUI (regardless of implementation language)
is not going to take the approach of building on top of Windows and Motif
bindings and lifting out a "common denominator" subset.  Rather, it would
bypass the Windows and Motif widget sets and go all the way down to pixels.
Its internal architecture might have pervasive capabilities for emulating
Motif of Windows LAF as much as possible, but it would be a stand-alone
native GUI for running inside Windows frames or X-Windows clients.

As a matter of fact, a native GUI is the route that Java chose.  They could
have tried to isolate a "common denominator" subset and then translated it
to Windows or Motif bindings, which would have resulted in the problems you
mention.  Instead they created a new native GUI that was supposed to look
just as good on either platform.  The early versions were a qualified
success -- they did look "just as good" on either platform, that is to say,
not very good -- but things are better with Swing.

>
> So I think there is a problem with getting large libraries of stuff
> "standardized" in Ada.

For the GUI stuff, you mean?

> To get it into The Real Standard, it would have to a)
> reduce itself to the lowest common denominators for the platforms on which
> it was possible and b) exist as an optional annex so it could be
eliminated
> for platforms on which it was difficult or impossible to implement. (I
don't
> see "b" as being a big problem - but there may be other opinions on
that...)

Of course there is a standard library today, specified in the Annexes --
it's just meager, that's all.  But that standard library is not monolithic;
the Predefined Language Environment (Annex A) is required, and the parts of
the standard library specified in the specialized needs annexes are
optional.  I view things like collections as foundational and not dependent
on platform capabilities, so they should go into the predefined environment.
If there were ever a GUI, it would be a special needs annex.

>
> The other alternative - a de facto standard - might be a better choice.
For
> example, you could have a "Windows-GUI" library and a "Motif-GUI" library
> that assumed the capabilities of a given platform and compiler vendors
would
> have to come to some kind of agreement that if they were putting out a
> Windows targeted compiler that they would support the appropriate
"standard"
> library. But this, in and of itself, has problems. It creates portability
> between compilers - but that's not necessarily in the interest of the
> vendors and may not be that interesting to the consumers. It certainly
> doesn't provide portability across platforms - which might be of varying
> levels of interest to the consumers.

For foundational stuff (like collections), I think a de-facto standard would
be OK only if it were perceived as "standards track".

The "package" of a great core language plus a great standard library is just
so much more compelling than that of a great core language plus a lot of
random freeware (a point you make below...).  It's the total package, not
just the core language, that people look at when making a decision.

At SIGAda '99 there was a paper by somebody who had done a study of U.K.
defense firms who had essentially "not chosen Ada", and the study ranked the
perceptions that contributed to that decision.  Lack of a decent standard
library ranked among the top three reasons.

>
> Besides, no matter how much discussion there is around here about the need
> for semi-standard libraries, we never seem to hear anything from the
vendors
> indicating that they are at all amenable to the idea. If they won't get
> behind it, the issue is dead. We already have lots of libraries of Ada
code
> available for the cost of a download, but that leaves the end-user
bumbling
> around, cobbling together a development environment of dubious quality and
> consistency.

Exactly.  "Great environment to be had for the cobbling" just doesn't cut
it.

For the vendors to get behind such an initiative would take one of two
things, either (a) the paying user community clamoring for it, or (b)
incorporation into the standard.  In practice this amounts to much the same
thing, since (a) will have to hold true for any candidate for (b) :-).  In
fact, (b) in and of it self has much less leverage since the dropping of the
Ada "mandate", which "statutory validation" was designed to support.  In
theory, a vendor could say "we don't support the full standard; big whoopie
ding," although even with an attitude like that toward an expanded standard
library, the presence of a freely redistributable/modifiable reference
implementation would probably go a long way towards making it a no-brainer
for a vendor.

> So I'm not sure how to get there other than by doing what is happening in
> one small corner of this newsgroup with respect to the idea of an Ada
> Standard Components Library

I think that's actually a pretty good way to get there.

Best Regards,
-- mark
--

--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Re: Future with Ada

[Pat Rogers]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:bJsS7.49746$ER5.625524@rwcrnsc52...
>
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9vb24v$7fg$1@nh.pace.co.uk...

<>huge snip>

> > Besides, no matter how much discussion there is around here about the
need
> > for semi-standard libraries, we never seem to hear anything from the
vendors
> > indicating that they are at all amenable to the idea. If they won't get
> > behind it, the issue is dead. We already have lots of libraries of Ada
code
> > available for the cost of a download, but that leaves the end-user
bumbling
> > around, cobbling together a development environment of dubious quality
and
> > consistency.
>
> Exactly.  "Great environment to be had for the cobbling" just doesn't cut
it.
>
> For the vendors to get behind such an initiative would take one of two
> things, either (a) the paying user community clamoring for it, or (b)
> incorporation into the standard.  In practice this amounts to much the
same
> thing, since (a) will have to hold true for any candidate for (b) :-).  In
> fact, (b) in and of it self has much less leverage since the dropping of
the
> Ada "mandate", which "statutory validation" was designed to support.  In
> theory, a vendor could say "we don't support the full standard; big
whoopie
> ding," although even with an attitude like that toward an expanded
standard
> library, the presence of a freely redistributable/modifiable reference
> implementation would probably go a long way towards making it a no-brainer
> for a vendor.
>
> > So I'm not sure how to get there other than by doing what is happening
in
> > one small corner of this newsgroup with respect to the idea of an Ada
> > Standard Components Library
>
> I think that's actually a pretty good way to get there.

I wish I could agree -- it's fun to design things -- but I don't think it
will get there.  We'll spend too much time discussing and debating low-level
details.  That's why I started this thread by proposing one of the existing
implementations:  I believe we should pick one and run with it.  Sure, let's
discuss the characteristics of the overall library -- I would suggest
Bertrand Meyer's criteria in his book describing Eiffel's library: "Reusable
Software: The Base Object-Oriented Component Libraries" -- but then let's go
with it.

If enough people ask for it, the vendors will provide it.  I have words to
that effect from two of them.

--
---
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: Future with Ada

[Mark Lundquist]

"Darren New" <dnew@san.rr.com> wrote in message
news:3C17D0C8.126D694A@san.rr.com...
>
> But I think it would be more effective to find something *new* to do,
> where you can start small and still have a chance of being popular.
>

I'm with ya on that.  I'm sure there are some who would find Yet Another
Office Suite compelling, but not enough to make it the Killer App for Ada.

--- mark

Re: Future with Ada

[James Rogers]

Mark Lundquist wrote:
> 
> I think any true cross-platform GUI (regardless of implementation language)
> is not going to take the approach of building on top of Windows and Motif
> bindings and lifting out a "common denominator" subset.  Rather, it would
> bypass the Windows and Motif widget sets and go all the way down to pixels.
> Its internal architecture might have pervasive capabilities for emulating
> Motif of Windows LAF as much as possible, but it would be a stand-alone
> native GUI for running inside Windows frames or X-Windows clients.
> 
> As a matter of fact, a native GUI is the route that Java chose.  They could
> have tried to isolate a "common denominator" subset and then translated it
> to Windows or Motif bindings, which would have resulted in the problems you
> mention.  Instead they created a new native GUI that was supposed to look
> just as good on either platform.  The early versions were a qualified
> success -- they did look "just as good" on either platform, that is to say,
> not very good -- but things are better with Swing.

That is the route taken for the Java Abstract Windowing Toolkit (AWT).
In Java 2 the Java Foundation Classes were added. Among those classes
is the Swing GUI toolkit. Swing components are mostly implemented only
in Java. This allows programs to provide a consistent look and feel
across target platforms. It also provides a much slower GUI 
interaction due to the inherent performance problems of Java.

Jim Rogers
Colorado Springs, Colorado USA

Re: Future with Ada

[Marin David Condic]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:bJsS7.49746$ER5.625524@rwcrnsc52...
>
> You're right, AWT/Swing account for a large part of the JCL.  And
> cross-platform GUIs are a big hairy rat's nest, for the reasons you
mention.
> But I think there's plenty a standard Ada library could focus on that's
more
> fundamental than GUIs.  I'm interested in things that help with
programming
> the "under the hood" stuff, and I'd just as soon let the GUI stuff alone
for
> the time being...
>
True. I could imagine a (semi)standard library that included basic data
structures, various math libraries, text manipulation, possibly interesting
tools for multitasking, etc. Things like that could be done strictly in Ada
syntax and a reference implementation could  be built that the vendors would
perhaps have to adapt for the peculiarities of their compiler.

The problem is that most of the real big leverage items start to become
things that intersect with the OS or machine peculiarities. I could imagine
things like a GUI, file management stuff, networking, etc., all being much
more useful than data structures and math, but then there is some question
about how it could be done in such a way as to be "standard" yet not end up
unimplementable (or simply difficult to implement) on most platforms where
the capabilities exist.

And then its a problem to consider that a handful of dedicated Ada fanatics
aren't likely to be able to produce something that big in a reasonable
timespan and offer the vendors a reference implementation. You'd have to
provide those sorts of things as a "Here's the Unix variant and here's the
Windows variant and here's the Mac variant...." It may not be impossible,
but the bigger the scope gets, the less likelihood it would get done with
volunteers.

So I could see concentrating on the kinds of "under the hood" features you
mention as A Good Start. But would that alone make Ada competitive with
MSVC++ or Java?


>
> I think any true cross-platform GUI (regardless of implementation
language)
> is not going to take the approach of building on top of Windows and Motif
> bindings and lifting out a "common denominator" subset.  Rather, it would
> bypass the Windows and Motif widget sets and go all the way down to
pixels.
> Its internal architecture might have pervasive capabilities for emulating
> Motif of Windows LAF as much as possible, but it would be a stand-alone
> native GUI for running inside Windows frames or X-Windows clients.
>
Yeah. That's an angle I didn't bring up. I could see that as a potential
solution, but its a dog with different fleas. You'd still have to do some
version of saying "Here's your Unix variant, your Windows variant....." and
it doesn't lend itself to the notion of a reference implementation that the
vendors can just pick up and tweak. It also suffers some from the problem of
having an entirely different look-and-feel than what a native-mode
application might produce. Netscape is a kind of thing like this - it works
fine, but it doesn't look-and-feel quite like a native Windows app. Would
end-users accept having their word processor and spreadsheet look different
from the rest of the OS environment just because they were built from the
Ada Standard GUI Thingamabob? Maybe - it is not clear they would reject it,
since a lot gets done with Netscape.

I mentioned elsewhere the notion that if there were some flavor of an XML
doohickie out there for Ada that it might be possible to use that as the
basis for a portable, standard GUI. So basically, I'm not against the idea -
just that I have some doubts about how easy it would be to get it
incorporated as a "standard" feature and about how it might be met by the
developer & end-user communities.


>
> >
> > So I think there is a problem with getting large libraries of stuff
> > "standardized" in Ada.
>
> For the GUI stuff, you mean?
>
For the GUI stuff - and for other things. Obviously, the less work you
demand of the vendors to incorporate something, the more likely it is to get
in there. Self-contained Ada libraries would be easier to get adopted - but
it is a long way from a shoe-in. Even if you gave the vendors a totally free
shot at a reference implementation and put it in the public domain, they
might be reluctant. Even if its free, they still have to answer telephone
calls about it and make sure it works in their environment. The further away
you get from Ada-only-reference-implementation (do we have a word for
this???) the harder it would be to get it adopted. Unless, of course,
someone with really deep pockets simply paid to have it implemented and
started supplying "The Compiler" (free, naturally :-) that forced everyone
else to play catch-up.


>
> Of course there is a standard library today, specified in the Annexes --
> it's just meager, that's all.  But that standard library is not
monolithic;
> the Predefined Language Environment (Annex A) is required, and the parts
of
> the standard library specified in the specialized needs annexes are
> optional.  I view things like collections as foundational and not
dependent
> on platform capabilities, so they should go into the predefined
environment.
> If there were ever a GUI, it would be a special needs annex.
>
Well, yeah, but I still think you'll discover there is resistance to that
notion. Should some rather large GUI library get incorporated into the
standard as an annex? (Or some other library of sufficient complexity and
not a Native-Ada-Reference-Implementation) I think you'll find resistance to
that because of the difficulty of writing up the annex in a rigorous enough
way that it can be tested for conformance.

Better to shoot for something that is more of a de facto standard because
most compilers have it available with possibly some variance in quality,
behavior or completeness.

>
> For foundational stuff (like collections), I think a de-facto standard
would
> be OK only if it were perceived as "standards track".
>
I'd settle for most vendors supplying it and skip actually getting it into
the ARM. As I said above, this could be difficult.


> The "package" of a great core language plus a great standard library is
just
> so much more compelling than that of a great core language plus a lot of
> random freeware (a point you make below...).  It's the total package, not
> just the core language, that people look at when making a decision.
>
Yup. And look at things like MSVC++ and Java to see what the competition has
available. That's what Ada would be measured against. And the problem is
there is a lot more in those implementations than simply things that could
come from Ada-Only code - especially if it is developed by volunteer effort.


>
> Exactly.  "Great environment to be had for the cobbling" just doesn't cut
> it.
>
You need to get it as a fully integrated kit so that its just "there" to be
used. If it were (semi)standard, that makes it so much the better so that
books can be written about it, training can be found for it, and developers
can move from one project to the next and not be stuck relearning a whole
new set of cobbled-together tools. (Either that, or the Deep Pockets answer
would have the same effect.)


> For the vendors to get behind such an initiative would take one of two
> things, either (a) the paying user community clamoring for it, or (b)
> incorporation into the standard.  In practice this amounts to much the
same
> thing, since (a) will have to hold true for any candidate for (b) :-).  In
> fact, (b) in and of it self has much less leverage since the dropping of
the
> Ada "mandate", which "statutory validation" was designed to support.  In
> theory, a vendor could say "we don't support the full standard; big
whoopie
> ding," although even with an attitude like that toward an expanded
standard
> library, the presence of a freely redistributable/modifiable reference
> implementation would probably go a long way towards making it a no-brainer
> for a vendor.
>
Agreed - but as I said above, there are problems with getting something like
this into the ARM and even if its free, the vendors may still not adopt it
for a variety of reasons.


> > So I'm not sure how to get there other than by doing what is happening
in
> > one small corner of this newsgroup with respect to the idea of an Ada
> > Standard Components Library
>
> I think that's actually a pretty good way to get there.
>
It is A Good Start and might help to make Ada a more attractive language to
many users. But it is still a long way from creating competition for things
like Java.

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: Future with Ada

[Marin David Condic]

"Pat Rogers" <progers@classwide.com> wrote in message
news:ESsS7.2213$Le3.1716485294@newssvr12.news.prodigy.com...
>
> I wish I could agree -- it's fun to design things -- but I don't think it
> will get there.  We'll spend too much time discussing and debating
low-level
> details.  That's why I started this thread by proposing one of the
existing
> implementations:  I believe we should pick one and run with it.  Sure,
let's
> discuss the characteristics of the overall library -- I would suggest
> Bertrand Meyer's criteria in his book describing Eiffel's library:
"Reusable
> Software: The Base Object-Oriented Component Libraries" -- but then let's
go
> with it.
>
I understand your point, but look at how much resistance there was to most
of the existing container libraries? What is already out there seemed to
have flaws that sufficient numbers of people found strongly objectionable.
If it didn't get adopted by unilateral imposition, its tough to get a
consensus. (I'd bet that if GNAT came bundled with the BC's, people would
still object - but would likely use it anyway.)


> If enough people ask for it, the vendors will provide it.  I have words to
> that effect from two of them.
>
But I don't recall that there were large number of folks calling Thomas
Edison on the phone and asking for him to invent the light bulb. Nor did
people Fax Henry Ford pictures of the car they wanted with a suggested name
of "Model T". :-) Sometimes businesses simply react to demand from their
customers. Sometimes businesses come up with something great and new and go
out and educate their customers as to why they would want to have it.
Waiting for a groundswell of demand from the customer base for some
particular container library is, IMHO, just about guaranteed to result in No
Standard Ada Component Library(tm). If it gets into one vendor at all, other
vendors will cater to different demands and you'll have dozens (or at least
a few) competing standard libraries. Customers don't always know what they
want until its under their nose and they start to discover its advantages.

Hey. If the vendors go for it, great. But I'd bet that it wouldn't happen
any time soon.


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: Future with Ada

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9vdp9f$9vo$1@nh.pace.co.uk...
>
> "Pat Rogers" <progers@classwide.com> wrote in message
> news:ESsS7.2213$Le3.1716485294@newssvr12.news.prodigy.com...
> >
> > I wish I could agree -- it's fun to design things -- but I don't think
it
> > will get there.  We'll spend too much time discussing and debating
> low-level
> > details.  That's why I started this thread by proposing one of the
> existing
> > implementations:  I believe we should pick one and run with it.  Sure,
> let's
> > discuss the characteristics of the overall library -- I would suggest
> > Bertrand Meyer's criteria in his book describing Eiffel's library:
> "Reusable
> > Software: The Base Object-Oriented Component Libraries" -- but then
let's
> go
> > with it.
> >
> I understand your point, but look at how much resistance there was to most
> of the existing container libraries? What is already out there seemed to
> have flaws that sufficient numbers of people found strongly objectionable.

My impression was that most of those doing the objecting were those with
"competing" libraries.  That might be wrong, but it looked that way from
a slight distance (by which I mean I didn't read absolutely all the
relevant posts).  Sure, those of us who've spent time developing code
and thinking about the subject therefore have opinions that are both
more passionate and qualified, but it doesn't seem to me to be a lot of
people overall.

> If it didn't get adopted by unilateral imposition, its tough to get a
> consensus. (I'd bet that if GNAT came bundled with the BC's, people would
> still object - but would likely use it anyway.)

Exactly my point -- we cannot please everybody, completely, under any
circumstances.  So let's pick one and as a group start asking the
vendors to provide them.  We have reason to believe the vendors will
respond.

> > If enough people ask for it, the vendors will provide it.  I have words
to
> > that effect from two of them.
> >
> But I don't recall that there were large number of folks calling Thomas
> Edison on the phone and asking for him to invent the light bulb. Nor did
> people Fax Henry Ford pictures of the car they wanted with a suggested
name
> of "Model T". :-)

:-)  On the other hand, there weren't competing auto makers, lightbulb
manufacturers, etc. available.

> Sometimes businesses simply react to demand from their
> customers.

Which they tell me they will do in this case.

> Sometimes businesses come up with something great and new and go
> out and educate their customers as to why they would want to have it.
> Waiting for a groundswell of demand from the customer base for some
> particular container library is, IMHO, just about guaranteed to result in
No
> Standard Ada Component Library(tm).

I confess I don't see why not, unless you mean there would be no
groundswell, in which case I would have to agree.  Hence my original
proposal -- let's start the groundswell!

Re: Future with Ada

[Richard Riehle]

James Rogers wrote:

> That is the route taken for the Java Abstract Windowing Toolkit (AWT).
> In Java 2 the Java Foundation Classes were added. Among those classes
> is the Swing GUI toolkit. Swing components are mostly implemented only
> in Java. This allows programs to provide a consistent look and feel
> across target platforms. It also provides a much slower GUI
> interaction due to the inherent performance problems of Java.

Just finished teaching an Ada class to twenty programmers who already
know Java.   Lots of positive responses.   However, the consensus was
that it would be nice to have an intelligent development environment
similar to that available in Java as well as an easier set of libraries
such as the one they learned when learning Java.

I certainly don't want Ada to become Java.   However, there are some
positive lessons to be learned from Java.  We already understand that
C++ is a gigantic step backward.   Ada can be a gigantic step forward
when the development environments and tools are as friendly as those
currently available for Java (or even Visual Basic).

These students understand that the superiority of a programming language
does count for much when the tools for development are still immature.

Richard Riehle

Re: Future with Ada

[Eric Merritt]

> That is the route taken for the Java Abstract
> Windowing Toolkit (AWT).
> In Java 2 the Java Foundation Classes were added.
> Among those classes
> is the Swing GUI toolkit. Swing components are
> mostly implemented only
> in Java. This allows programs to provide a
> consistent look and feel
> across target platforms. It also provides a much
> slower GUI 
> interaction due to the inherent performance problems
> of Java.
Actuall the slowness of swing results mostly from its
poor implementation and the heavy reliance on the MVC
pattern. Although the MVC pattern is a nice pattern it
is pretty heavy and overhead intensive for an
interpreted language like java.


__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

RE: Future with Ada

[Robert C. Leif, Ph.D.]

From: Bob Leif,
To: Richard Riehle et al.
One way to quickly extend Ada's functionality is to annex (pun intended)
XML.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Richard Riehle
Sent: Friday, December 14, 2001 5:34 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Future with Ada


James Rogers wrote:

> That is the route taken for the Java Abstract Windowing Toolkit (AWT).
> In Java 2 the Java Foundation Classes were added. Among those classes
> is the Swing GUI toolkit. Swing components are mostly implemented only
> in Java. This allows programs to provide a consistent look and feel
> across target platforms. It also provides a much slower GUI
> interaction due to the inherent performance problems of Java.

Just finished teaching an Ada class to twenty programmers who already
know Java.   Lots of positive responses.   However, the consensus was
that it would be nice to have an intelligent development environment
similar to that available in Java as well as an easier set of libraries
such as the one they learned when learning Java.

I certainly don't want Ada to become Java.   However, there are some
positive lessons to be learned from Java.  We already understand that
C++ is a gigantic step backward.   Ada can be a gigantic step forward
when the development environments and tools are as friendly as those
currently available for Java (or even Visual Basic).

These students understand that the superiority of a programming language
does count for much when the tools for development are still immature.

Richard Riehle

Re: Future with Ada

[Georg Bauhaus]

Larry Kilgallen <Kilgallen@spamcop.net> wrote:
 
: Do you mean software enforcement of licenses ?

Methinks, the question to ask is "Why do we have to have this
in the first place?" Not many would hire crafts people[*] and not be
willing to pay them. However, many will obtain software but will not
be willing to pay the producer. Who is responsible for this 
unfortunate situation on the PC software market?!

[*] see the title of John English's book.

Georg

Re: Future with Ada

[Georg Bauhaus]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
 
: You'd
: have things like a "Document Object" or a "Spreadsheet Object", etc. All of
: those things would start to look like things in the Java libraries or
: similar language supplied utilities.
 
Should we arrive at the good old Document Object Model at last :-)

See also
GNOME, GnORBA, ... and their resp. proprietary counterparts,
including OLE2,  COM*+-, ..., what had that Apple variant been
called, oh, where did it all com from....


Georg

Re: Future with Ada

[Georg Bauhaus]

Richard Riehle <richard@adaworks.com> wrote:
:    Lots of positive responses.   However, the consensus was
: that it would be nice to have an intelligent development environment
: similar to that available in Java as well as an easier set of libraries
: such as the one they learned when learning Java.

It may not be obvious, look as unfamiliar as a one-eyed dog,
but there is an IDE that provides "checked" and "unchecked"
identifier completion, an abundance of source code templates,
compiler integration, debugger integration, source code
browsing (including Ada's library, installed 3rd party libraries,
and your own units), integrated help system, interface to
source code control systems, ...

It doesn't cost any money, you can use it with your mouse,
but you first have to do what you have to do for efficient
use of _any_ decent IDE: read a few pages of documentation.

The thing is called  Ada mode for Emacs + GNAT ali files.
You are not surprised, are you?

Georg

Re: Future with Ada

[Eric Merritt]

> It doesn't cost any money, you can use it with your
> mouse,
> but you first have to do what you have to do for
> efficient
> use of _any_ decent IDE: read a few pages of
> documentation.
> 
> The thing is called  Ada mode for Emacs + GNAT ali
> files.
> You are not surprised, are you?

Ah, but one of the reasons the this discussion is
taking place is to attract new Ada programmers. Emacs
is a very unsexy thing, its multitude of commands and
somewhat cryptic use (from a new users perspective)
make it extreamly unfriendly for the first month or
so. This is bad for the language as a whole as it
requires a fair amount of commitment to learning the
editor even before a user really gives the language a
chance to prove itself. 

Personally I find emacs distasteful in the extreme, I
just don't tend to think in the way emacs requires.
Don't get me wrong, I realize the emacs is extremely
productive I just don't like it. I think allot of
programmers in my age group (mid-late twenties) feel
the same way. Most that I know started out in IDEs and
though we can use the command line and editors like
emacs well we generally don't choose to. It may be
that  this IDE becomes an entry point for Ada and
later in the learning process students realize the
power of emacs and move to that environment. In any
case, a good professional quality IDE will never hurt
Ada and can only help it.

At the moment I have been using code forge which has
good support for Ada and is not terribly expensive.
Its not quite as nice as an Ada dedicated IDE would be
but fits the bill for now.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

Re: Future with Ada

[Georg Bauhaus]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
 
: Should we arrive at the good old Document Object Model at last :-)
System Object Model
or
Distribued System Object Model
I should have said.
Sorry.

Re: Future with Ada

[Georg Bauhaus]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
: System Object Model

OpenDoc.

Gee; I'll leave the computer alone now 8-(

Re: Future with Ada

[Mark Lundquist]

"Pat Rogers" <progers@classwide.com> wrote in message
news:ESsS7.2213$Le3.1716485294@newssvr12.news.prodigy.com...
>[snip...]
> I wish I could agree -- it's fun to design things -- but I don't think it
> will get there.  We'll spend too much time discussing and debating
low-level
> details.

I suppose I would take a position that the details are important, and that
some time should be spent debating them.

A cynic would say that those discussions are doomed to go around endlessly
in circles.  But I don't think that has to happen, and by and large I don't
think that has been the case in the discussions surrounding Ted's
"strawman"...

>  That's why I started this thread by proposing one of the existing
> implementations:  I believe we should pick one and run with it.  Sure,
let's
> discuss the characteristics of the overall library -- I would suggest
> Bertrand Meyer's criteria in his book describing Eiffel's library:
"Reusable
> Software: The Base Object-Oriented Component Libraries" -- but then let's
go
> with it.

If you "just pick one", then it's a foregone conclusion... what's the point
of discussing it (except to thoroughly understand the limitations of the
thing that has been chosen?)  Or if the aim of the discussion is to pick
which library to recommend, then would you not expect the discussion to have
the same character as in the "from scratch" approach -- that is, debating
the details?

-- mark

Re: Future with Ada

[Mark Lundquist]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9vdp9f$9vo$1@nh.pace.co.uk...
>
> "Pat Rogers" <progers@classwide.com> wrote in message
> news:ESsS7.2213$Le3.1716485294@newssvr12.news.prodigy.com...
> >
> > I wish I could agree -- it's fun to design things -- but I don't think
it
> > will get there.  We'll spend too much time discussing and debating
> low-level
> > details.  That's why I started this thread by proposing one of the
> existing
> > implementations:  I believe we should pick one and run with it.  Sure,
> let's
> > discuss the characteristics of the overall library -- I would suggest
> > Bertrand Meyer's criteria in his book describing Eiffel's library:
> "Reusable
> > Software: The Base Object-Oriented Component Libraries" -- but then
let's
> go
> > with it.
> >
> I understand your point, but look at how much resistance there was to most
> of the existing container libraries? What is already out there seemed to
> have flaws that sufficient numbers of people found strongly objectionable.

Yes, exactly!

I think you have a good feel for the issues here.

Remember, even the adoption of the C++ STL was attended with controversy,
and this was something with very high goals.  AIR, the controversies had to
do with how big the STL would be (there was a lot more Stepanov wanted, but
it didn't make the "size" cut), and also with the changes required to the
C++ language itself (it helped STL to have an influential champion --
Strousrup! -- on the standardization committee).

> If it didn't get adopted by unilateral imposition, its tough to get a
> consensus. (I'd bet that if GNAT came bundled with the BC's, people would
> still object - but would likely use it anyway.)

Right, and that is precisely the kind of standard (de factor or de jure) for
a foundation library that we do *not* want to have.  Not something that
people use because it's the path of least resistance, but then complain
about.  I want to provide something that will not give programmers reason to
complain.  I think it's possible.

If the aim is to improve the overall appeal of the whole Ada "package" --
the attractiveness of Ada as a solution -- then choosing something on the
basis of convenience will not do.  Expedite the aim, not just quickness.
Even if something is merely a "de facto standard", it must be every bit as
good as to be in the "Real Standard".  Perhaps that, is the reason there is
no current "de facto standard" -- not just that nobody has bothered to ring
up the compiler vendors and ask them to bundle something.

Ehud Lamm has suggested that the perfect library for Ada has not been
written yet.  I suspect that this is true, and in that light the current
lack of a standard is actually a good thing, as are the debates that we have
about all these issues.

-- mark

Re: Future with Ada

[Mark Lundquist]

"Pat Rogers" <progers@classwide.com> wrote in message
news:YxvS7.2239$_h.1737012240@newssvr12.news.prodigy.com...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9vdp9f$9vo$1@nh.pace.co.uk...
> >
> > I understand your point, but look at how much resistance there was to
most
> > of the existing container libraries? What is already out there seemed to
> > have flaws that sufficient numbers of people found strongly
objectionable.
>
> My impression was that most of those doing the objecting were those with
> "competing" libraries.  That might be wrong, but it looked that way from
> a slight distance (by which I mean I didn't read absolutely all the
> relevant posts).  Sure, those of us who've spent time developing code
> and thinking about the subject therefore have opinions that are both
> more passionate and qualified, but it doesn't seem to me to be a lot of
> people overall.

Do you wish there were *more* people with strong opinions about these
things? :-)  Maybe I'm getting you wrong, but it seems as though you are
saying that the people who actually care about how this stuff works are an
obstruction to the process... :-)

>
> > If it didn't get adopted by unilateral imposition, its tough to get a
> > consensus. (I'd bet that if GNAT came bundled with the BC's, people
would
> > still object - but would likely use it anyway.)
>
> Exactly my point -- we cannot please everybody, completely, under any
> circumstances.

With all respect, I feel this is a cop-out.  I firmly believe that an Ada
foundation library with collections (and more), with which everybody *will*
be genuinely pleased, *can* be written.  It just has not been --  yet.

>  So let's pick one and as a group start asking the
> vendors to provide them.  We have reason to believe the vendors will
> respond.

I have a hard time believing that some kind of petition from a handful of
comp.lang.ada readers is going to induce the Ada vendors to bundle some
library.  That does not constitute a business "demand".

How many compiler licenses do you suppose are on the table over this? :-)

I must say that I'm quite opposed to the "pick one and go with it idea", and
I really wish that you would reconsider recommending it.  I think we can do
better than that, and that's what some of us here are trying to do.

Time is not of the essence.  As much as I believe it is vital for Ada to
have a strong foundation library, it has survived this long without one, and
it's not going anywhere.  If it takes months to produce something
satisfactory, that is OK.

-- mark

Re: Future with Ada

[Marin David Condic]

We could probably come up with a huge list of things that exist in other
languages or environments that it would be great to have available in some
form in Ada. This might not be a bad idea, but it would certainly end up
kind of ecclectic. :-) I'd think that starting from a review of what is
available elsewhere that is generally regarded as useful, some sort of
Ada-ish "Wish List" could be developed - perhaps eventually emerging as a
set of requirements & design? It could produce a really swell Ada component
library that would make Ada much more attractive.

The big problem is that without a Deep Pockets investor (philanthropist? :-)
it would be extremely difficult to see something like this come about. It
*might* be possible if there were a project going on with an end-product in
mind that could utilize lots of utilities - you get the library as a
consequence of building something else. AdaOS, for example, might result in
a large library of GUI/Graphics stuff, communication stuff, etc. But then
you've got to find some people willing to look at that project (AdaOS?,
Ada-Office? Ada-Web?) as a mission worth persuing and with a goal of leaving
behind a large volume of (semi)portable utilities.

Sans a Deep Pockets investor/philanthropist willing to pay a bunch of
salaries on spec that something worth while comes about, I'm not sure how to
bring about such a situation. Volunteer time with minimal chance of
financial reward will only go so far. Its possible that with an interesting
enough project and a small group of developers willing to do some work on
speculation that a commercial thing could come out of it, you might see some
motion in the right direction. But then you need a project that captures
some imaginations and develops from there. Suggestions?

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/


"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:9vi8ms$c8t$1@a1-hrz.uni-duisburg.de...
>
> See also
> GNOME, GnORBA, ... and their resp. proprietary counterparts,
> including OLE2,  COM*+-, ..., what had that Apple variant been
> called, oh, where did it all com from....
>

Re: Future with Ada

[Pat Rogers]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:fQhT7.14016$Kg2.1376304@rwcrnsc51...
>
> "Pat Rogers" <progers@classwide.com> wrote in message
> news:YxvS7.2239$_h.1737012240@newssvr12.news.prodigy.com...
> > "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> > message news:9vdp9f$9vo$1@nh.pace.co.uk...
> > >
> > > I understand your point, but look at how much resistance there was to
> most
> > > of the existing container libraries? What is already out there seemed
to
> > > have flaws that sufficient numbers of people found strongly
> objectionable.
> >
> > My impression was that most of those doing the objecting were those with
> > "competing" libraries.  That might be wrong, but it looked that way from
> > a slight distance (by which I mean I didn't read absolutely all the
> > relevant posts).  Sure, those of us who've spent time developing code
> > and thinking about the subject therefore have opinions that are both
> > more passionate and qualified, but it doesn't seem to me to be a lot of
> > people overall.
>
> Do you wish there were *more* people with strong opinions about these
> things? :-)  Maybe I'm getting you wrong, but it seems as though you are
> saying that the people who actually care about how this stuff works are an
> obstruction to the process... :-)

My point is not that "too many cooks spoil the soup", although I believe
that apllies here too, but rather that the cooks will argue amongst
themselves endlessly (about what to name their dishes for example) while the
customers "starve".  (Excuse the hyperbole.:)

> > > If it didn't get adopted by unilateral imposition, its tough to get a
> > > consensus. (I'd bet that if GNAT came bundled with the BC's, people
> would
> > > still object - but would likely use it anyway.)
> >
> > Exactly my point -- we cannot please everybody, completely, under any
> > circumstances.
>
> With all respect, I feel this is a cop-out.  I firmly believe that an Ada
> foundation library with collections (and more), with which everybody
*will*
> be genuinely pleased, *can* be written.  It just has not been --  yet.

I'm speaking from personal experience -- YMMV -- when I submit that a
universally accepted library that pleases everyone will not happen.  (Of
course I don't mean that I will not like it, therefore it will not be
"universal". :)

> >  So let's pick one and as a group start asking the
> > vendors to provide them.  We have reason to believe the vendors will
> > respond.
>
> I have a hard time believing that some kind of petition from a handful of
> comp.lang.ada readers is going to induce the Ada vendors to bundle some
> library.  That does not constitute a business "demand".

Then we're in trouble no matter how the library comes about (new design v.
existing) if we cannot get the vendors to take it on board.  However, a
"petition from a handfull of c.l.a. readers" is not what I had in mind.  I
was thinking that c.l.a. and team-ada would be used to get the word out (to
ask the vendors for it).  I know some of the vendors well; it would not take
a number in the thousands.

> How many compiler licenses do you suppose are on the table over this? :-)

:-) None, of course, but that's not what is at risk, is it?

> I must say that I'm quite opposed to the "pick one and go with it idea",
and
> I really wish that you would reconsider recommending it.  I think we can
do
> better than that, and that's what some of us here are trying to do.

Then I hope I am wrong.

Re: Future with Ada

[Marin David Condic]

"Pat Rogers" <progers@classwide.com> wrote in message
news:YxvS7.2239$_h.1737012240@newssvr12.news.prodigy.com...
> > >
> > But I don't recall that there were large number of folks calling Thomas
> > Edison on the phone and asking for him to invent the light bulb. Nor did
> > people Fax Henry Ford pictures of the car they wanted with a suggested
> name
> > of "Model T". :-)
>
> :-)  On the other hand, there weren't competing auto makers, lightbulb
> manufacturers, etc. available.
>
But that ought to be a clue that "The Market" is in desire of some specific
kinds of things. If C++ provides the STL and developers like it and use it,
that ought to suggest that a compiler that comes with something similar
would be of desire to the users of Ada. If Java comes with class libraries
for building GUI apps, that should  be a signal that users would want
something similar from Ada. Customers don't always call you on the phone and
tell you they want a specific capability. Sometimes they "vote with their
feet" and buy some other product because it fits their needs better. (Can
you hear a customer saying "Ada's O.K. for this kind of thing but when we
want to build Web/GUI apps, we just switch to Java..."?)

Granted, you can't do everything and you can't be all things to all people.
Hence you have to try to get some signals as to what is going to be the most
profitable way of allocating your resources. But I think with the "Data
Structures" case, the problem is that you might have - say - 50 ways of
doing essentially the same thing and 100 opinions about which is the best
and why. Specifically *because* there's such a shortage of consensus,
(except consensus that having one would be A Good Thing) getting something
imposed from the outside (or at least some direction/guidance) would likely
be a big push for success.

I like the stuff that has been come up with in the latest discussion. I
think that Ted's strawman would be a good compromise of all the competing
goals and objectives. If we had that much (and Maps) riding along with most
compilers (and a promise of possibly more things as experience suggests)
we'd have a richer language.


>
> > Sometimes businesses come up with something great and new and go
> > out and educate their customers as to why they would want to have it.
> > Waiting for a groundswell of demand from the customer base for some
> > particular container library is, IMHO, just about guaranteed to result
in
> No
> > Standard Ada Component Library(tm).
>
> I confess I don't see why not, unless you mean there would be no
> groundswell, in which case I would have to agree.  Hence my original
> proposal -- let's start the groundswell!
>
>
Well, because what you have is a single groundswell that says "A library of
components is a good thing" and then you have a thousand mini-groundswells
that say "And in the library that *I* want, there should be X and Y and..."
So if a vendor is going to wait for - say - 50 paying customers to all stand
up and unanimously say "Put Library N On Your Distribution" it might be a
cold day in Florida before it happens. :-) Whereas, if the vendors were
saying "We agree that if a library is going to be distributed and supported,
it ought to be: <Insert your requirements or favorite library here>" it
might start coalescing some of the demand around something in particular.

So while I understand the direction you are proposing and I agree that it
would be expedient & would get results, I guess I have doubts that the
consensus will congeal unless the vendors were involved in setting the
direction. That's why in some ways what is going on with the strawman
discussed elsewhere is a positive step. In the abscence of any other
direction, people are coming together and negotiating something they can
mutually live with. That might produce a library that has enough "buy in"
that there might actually be some demand for one specific existing library.

Just my thinking on the subject.....

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: Future with Ada

[Marin David Condic]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:eQhT7.13950$MM5.1154373@rwcrnsc53...
>
>
> If the aim is to improve the overall appeal of the whole Ada "package" --
> the attractiveness of Ada as a solution -- then choosing something on the
> basis of convenience will not do.  Expedite the aim, not just quickness.
> Even if something is merely a "de facto standard", it must be every bit as
> good as to be in the "Real Standard".  Perhaps that, is the reason there
is
> no current "de facto standard" -- not just that nobody has bothered to
ring
> up the compiler vendors and ask them to bundle something.
>
I understand and sympathize. OTOH, I was around once before when there was
an attempt to come up with an Ada Standard Components Library (A Good Thing)
and watched the whole thing kind of wither because of endless discussion and
lack of consensus. I'm not blaming anybody - just observing that the risk of
trying to come up with something new in this area is difficult and the net
result has been "No Standard Ada Library". A poor, de facto standard by
adopting something already out there is infinitely superior to the perfect
standard that does not exist.


> Ehud Lamm has suggested that the perfect library for Ada has not been
> written yet.  I suspect that this is true, and in that light the current
> lack of a standard is actually a good thing, as are the debates that we
have
> about all these issues.
>
A "Perfect" library will never exist - just too many competing design goals.
Some amount of debate and some amount of consensus-building is a good thing.
If it results in months and months with no concrete results, its going to
wither and die. Generating a concrete result of *some* size in some
reasonable timespan will go a long way towards keeping momentum going on it.

If this were organized a little more along the lines of how Ada itself was
built (a chief designer with some committee feedback & approval) it might
meet the objectives you outline more easily. To some extent, we have that.
However, it really lacks any sort of "Official Charter" with a clear
mission, milestones, deadlines and an identifiable end-customer to keep it
on track. That's where I see some risk in the sort of informal thing going
on now. I'd like to minimize the risks and help insure we actually end up
with a result. It looks like we're getting there to some extent...

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: Future with Ada

[Brian Rogoff]

On Mon, 17 Dec 2001, Pat Rogers wrote:
> "Mark Lundquist" <no.spam@getalife.com> wrote in message
> > Do you wish there were *more* people with strong opinions about these
> > things? :-)  Maybe I'm getting you wrong, but it seems as though you are
> > saying that the people who actually care about how this stuff works are an
> > obstruction to the process... :-)
>
> My point is not that "too many cooks spoil the soup", although I believe
> that apllies here too, but rather that the cooks will argue amongst
> themselves endlessly (about what to name their dishes for example) while the
> customers "starve".  (Excuse the hyperbole.:)

A nice short way to express this situation is "analysis paralysis". The
solution is the Nike approach, "just do it".

> > With all respect, I feel this is a cop-out.  I firmly believe that an Ada
> > foundation library with collections (and more), with which everybody
> *will*
> > be genuinely pleased, *can* be written.  It just has not been --  yet.
>
> I'm speaking from personal experience -- YMMV -- when I submit that a
> universally accepted library that pleases everyone will not happen.  (Of
> course I don't mean that I will not like it, therefore it will not be
> "universal". :)

I agree entirely with Pat here. Such an Ada library cannot be written, as
some people have contradicting beliefs/desires about such a library.

> > >  So let's pick one and as a group start asking the
> > > vendors to provide them.  We have reason to believe the vendors will
> > > respond.

A better idea IMO would be to pick a few, whip them into shape (make sure
they're portable to a few compilers, well enough documented, etc.) and
just let people use them, or not. Hopefully vendors could provide
something like an Ada Developers Kit with these libraries and more.

> > I must say that I'm quite opposed to the "pick one and go with it idea",
> and
> > I really wish that you would reconsider recommending it.  I think we can
> do
> > better than that, and that's what some of us here are trying to do.
>
> Then I hope I am wrong.

I don't think you are. Remmeber there was another waste of time effort in
this direction a few years ago, too.

-- Brian

Re: Future with Ada

[Marin David Condic]

But Ada is almost 20 years old. Java is how old? And yet Ada is less
"mature"? This, IMHO, is a problem. It kind of indicates that people
*expect* a language to come with an IDE and a library and if you're there
without one you won't get taken seriously.

I hope we succeed in fixing that - but how do we get there without Micro$oft
or Sun getting behind us? If the DoD was still there with a little vision to
say "Ada having an IDE and a GUI and some other library stuff and some tools
is good for us because it will create the user base we need..." then we
would stand a better chance of getting there. But without a large sponsor it
is difficult to achieve this sort of thing. How do we get there in the
abscence of such support?

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:3C1AA877.914DB6EF@adaworks.com...
>
> These students understand that the superiority of a programming language
> does count for much when the tools for development are still immature.
>

Re: Future with Ada

[Marin David Condic]

Well, its a classic "Make or Buy" decision. There are a number of libraries
that were proposed that might have been used - with modifications. That gets
you out the door quicker but doesn't necessarily meet with all the
requirements. The problem seems to be that in tossing out a handful of
possible libraries to adopt, there were a non-trivial number of people who
had some non-trivial objections to the existing libraries. We're never going
to get 100% acceptance of any library, but it wasn't sounding as if there
was any fairly large body of developers that was willing to "Adopt & Adapt"
(Embrace & Extend?).

I agree it would be quicker and guarantee a result to go the "Adopt & Adapt"
route - but there didn't seem to be something out there that was good enough
to get some acquiescence. If its going to be "interest group driven" then
there's got to be "interest group buy-in" and I don't see a large amount of
that for any given candidate library already out there. (Unless there's a
great silent-majority of lurkers out there who aren't expressing any of
their desires?) Hence, I think the best chance there is to get something
group-driven is to keep persuing the group-developed alternative.

I wouldn't mind being wrong about this but I don't see it happening. Unless
the vendors want to say "Just Do It - (with library X)" it looks like the
only way its going to get done is if the group builds one of its own.

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/


"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0112171622550.17842-100000@bpr.best.vwh.net...
> On Mon, 17 Dec 2001, Pat Rogers wrote:
> > "Mark Lundquist" <no.spam@getalife.com> wrote in message
> > > I must say that I'm quite opposed to the "pick one and go with it
idea",
> > and
> > > I really wish that you would reconsider recommending it.  I think we
can
> > do
> > > better than that, and that's what some of us here are trying to do.
> >
> > Then I hope I am wrong.
>
> I don't think you are. Remmeber there was another waste of time effort in
> this direction a few years ago, too.
>
> -- Brian
>
>

Re: Future with Ada

[Ian S. Nelson]

Marin David Condic wrote:


> bring about such a situation. Volunteer time with minimal chance of
> financial reward will only go so far. Its possible that with an interesting
> enough project and a small group of developers willing to do some work on
> speculation that a commercial thing could come out of it, you might see some
> motion in the right direction. But then you need a project that captures
> some imaginations and develops from there. Suggestions?

Come on.  What about Linux and GCC and GIMP, and the tons and tons of other free softwares?  What about all that stuff the Eric Raymond has written?  



Ian Nelson

Re: Future with Ada

[Marin David Condic]

Never said it couldn't be done. Said it was less likely to be done. (Or at
least that was my intent.)

Lots of software gets built by students, professors, hobbyists, idealists,
etc., and gets put out in the world at little or no cost. That's O.K. with
me. I'm only suggesting that if someone were funding the development of an
Ada library with deep pockets, or if it were being build as a byproduct of
some product development, it would stand a better chance of emerging into
the world in a more timely manner.

Now if someone has an interesting idea for a product and is looking to find
some on-spec developers, I could probably name a few people who might be
interested in spending some time working on it. If part of the result were a
library full of Ada utilities that were made available to the Ada community,
it would probably fly, but I doubt any of the people I know (myself
included) would have that kind of time to devote to it so long as its only a
"labor of love".

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/


"Ian S. Nelson" <nelsonis@earthlink.net> wrote in message
news:3C1E728E.7030702@earthlink.net...
>
> Come on.  What about Linux and GCC and GIMP, and the tons and tons of
other free softwares?  What about all that stuff the Eric Raymond has
written?
>
>

Re: Future with Ada

[Georg Bauhaus]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
: We could probably come up with a huge list of things that exist in other
: languages or environments that it would be great to have available in some
: form in Ada.

What I was thinking of is CORBA. The old idea, I'm sure you know,
is in part what now is hyped as .NET; if you build office software,
say, you have a text editing component ready. Could we perhaps
turn AWS into another component usable in a CORBA environment
(like GNOME is)? The template mechanism alone is worth having;
AWS could request services from other components, resulting in
a small application server...

Just a thought
 Georg

RE: Future with Ada

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Ian S. Nelson et al,
As I have already pointed out, the developers of Linux have contributed
mightily to the fortunes of the founders of RedHat and the shareholders of
companies like IBM. I hope that entrance to the software engineering
profession does not require an oath of poverty.

R. C. Leif, "SIGAda 99, Workshop: How do We Expedite the Commercial Use of
Ada?" Ada Letters XX pp19-26 (2000).
-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Ian S. Nelson
Sent: Monday, December 17, 2001 2:33 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Future with Ada


Marin David Condic wrote:


> bring about such a situation. Volunteer time with minimal chance of
> financial reward will only go so far. Its possible that with an
interesting
> enough project and a small group of developers willing to do some work on
> speculation that a commercial thing could come out of it, you might see
some
> motion in the right direction. But then you need a project that captures
> some imaginations and develops from there. Suggestions?

Come on.  What about Linux and GCC and GIMP, and the tons and tons of other
free softwares?  What about all that stuff the Eric Raymond has written?



Ian Nelson

Re: Future with Ada

[Marin David Condic]

As well you know, Bob, I'm much in favor of the notion of making money from
the development of software. I think in particular that I liked the idea you
expressed in this and other papers that one of the best ways to promote Ada
and encourage its use is to demonstrate how people can make money by
developing in Ada.

Many companies don't necessarily know about or believe in the benefits of
using Ada because they have not witnessed the tangible monetary benefits of
doing so. If their competitors were using Ada and developing better
software, faster and cheaper, then they'd have to take a look at that.

Many individual programmers are reluctant to learn or use Ada because they
don't see a job future in it. They see thousands of ads for jobs using other
languages and few ads for Ada positions. If they saw more companies using
Ada, they might be encouraged to want to earn a living that way.

If the ad-hoc developers out there saw a chance to develop something in Ada
that might gain them fame and fortune rather than just the undying gratitude
of end users and corporations who picked up their work at no cost, there
might be more of them flocking to the fold. Perhaps that's where I was
headed by suggesting the construction of some commercial product in Ada that
would compete against some of the other big time apps out there. If Ada is
so great, it ought to be possible to build something that competes
effectively with the big guys, produces a better quality end product for the
consumer, makes money for those involved and produces more tools/utilities
for the Ada community. Seems like everyone could win.

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 C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.1008690662.8682.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Ian S. Nelson et al,
> As I have already pointed out, the developers of Linux have contributed
> mightily to the fortunes of the founders of RedHat and the shareholders of
> companies like IBM. I hope that entrance to the software engineering
> profession does not require an oath of poverty.
>
> R. C. Leif, "SIGAda 99, Workshop: How do We Expedite the Commercial Use of
> Ada?" Ada Letters XX pp19-26 (2000).

Re: Future with Ada

[Mark Lundquist]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9vdo2a$9h3$1@nh.pace.co.uk...
>
> The problem is that most of the real big leverage items start to become
> things that intersect with the OS or machine peculiarities. I could
imagine
> things like a GUI, file management stuff, networking, etc., all being much
> more useful than data structures and math, but then there is some question
> about how it could be done in such a way as to be "standard" yet not end
up
> unimplementable (or simply difficult to implement) on most platforms where
> the capabilities exist.

If a foundation library included some of those things, and they were (a)
optional, and (b) straightforward to implement on both Unix and Windows,
then I wouldn't lose too much sleep over the other platforms.

>
> So I could see concentrating on the kinds of "under the hood" features you
> mention as A Good Start. But would that alone make Ada competitive with
> MSVC++ or Java?

It'd be an important step in the right direction, especially for
implementers who appreciate the strengths of Ada but are realistic about the
state of affairs regarding GUIs and IDEs.  For them, some more beef in the
"under-the-hood" area might tip the scales in the scenario of
"backend/engine in Ada, UI in Java" (or UI in VC++ if a different team's
doing it and that's what they know), or for web development where the UI is
one of the web scripting languages.

Let's not equivocate on the subject under consideration, which is
libraries... while IDEs are important, and also part of the "total package"
along with libraries, we should still observe a separation of concerns
between them.  So the aim of a library effort would be to make Ada more
competetive with C++/STL, and also more competetive with Java+JFC modulo the
GUI issue (on that score, Ada and C++ are on a par anyway; that is to say,
you can develop using Claw, Gwindows etc. on Windows and be using the same
GUI as if you were writing in C++, and if you use Gtk on Linux with C++, you
might just as well use GtkAda).

Best,
mark

--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Portable GUI (was Re: Future with Ada)

[Mark Lundquist]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9vdo2a$9h3$1@nh.pace.co.uk...
>
> I mentioned elsewhere the notion that if there were some flavor of an XML
> doohickie out there for Ada that it might be possible to use that as the
> basis for a portable, standard GUI
>

Not sure exactly what you mean by an "XML doohickie" :-), but I'd be
thinkin' something along these lines:

1) First, you write your native Ada GUI library.  This is the hard part.
Make it the very best thing you can make.  Also let it be configurable with
traits that allow it to emulate Windows-like or Motif-like LAF.

2) Next, write an XML schema to define GUI layout in terms of the primitives
that map to those of your portable GUI.  It wouldn't hurt if (1) were done
with a view to (2).  Now, you have a way for GUIs to be represented as XML
documents, instead of encoded in program source code.

3) Now we need a way for your applications to talk to these GUIs.  First
step is to define a simple object model to ride on top of some middleware:
CORBA and/or SOAP and/or Bonobo...  The semantic level of this layer is what
is left after abstracting away from all the details of appearance, layout,
perhaps even some choices of controls, etc... that are now all loaded into
the XML representation.

4) We also need a way to render the GUIs, and so we write an XML browser (in
Ada, of course) to interpret the schema.  This is trivial, since the schema
is just an XML oil-slick over the native portable Ada GUI (1).  This
component brings together (1), (2), and (3).  It's a standalone executable.
Start with Windows and Linux.

5) Write/generate the bindings to (3) in every popular language that knows
how to talk to the middleware options you support.  So now you can offer a
platform-independent GUI for C++, Perl, Python, Ada of course, and even Java
for those who find compelling advantages in this GUI over Swing (and there
would be some advantages, I think).

6) While you're at it, write a GUI-builder.  It's target-language
independent, because it doesn't have to generate program source code, only
XML and IDL (or whatever).

7) Now take what we've done, and hype the living daylights out of it, while
preserving our dignity (we might need that later on).  Sell it at a modest
price to every cross-platform developer in the world.  Get written up in all
the trendy industry rags (cover stories of course). Win a Jolt award.  Get
the schema recommended as a W3C standard. Go public.

8) Let it slip that it has "Ada inside".

9) Developers everywhere become interested in the technology behind this
wonderful creation, the killer mini-app for Ada.  They discover the joy of
programming in Ada, the new high-performance language for the '00's (you
know... what comes after the '80's and the '90's).  Ada takes over the
world.

10) In the process, people discover that the XML GUI rendering engine is
nothing but a front-end to the standard Ada native GUI library and that 98%
of the work to duplicate it would be done for them because it's just
plumbing together things from the Ada foundation library.  The jig is up.
Exercise stock options now.  The free knockoffs start to appear, but that's
OK because we knew it was coming.  Move while you still control mindshare,
and release your source code under an open source license, thereby becoming
the world's great benefactor.  Restructure the business model around support
and consulting services.

11) Now we can either (a) spend most of our time sailing in the Caribbean,
or (b) take one of the many cushy jobs that await us now that Ada has
conquered.


Whoops, I left out a step... Step (0), find an investor to $upport us while
we do the work...

:-) :-) :-)
-- mark

-------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

RE: Portable GUI (was Re: Future with Ada)

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Mark Lundquist
If you base the entire GUI on the parts of XML that use XML syntax, you
probably would have a chance at becoming very rich. It would employ the hot
buzz word, XML, and be backed by solid technology, Ada.

One of the major reasons for Microsoft's success is the technical
incompetence of its competitors. First they were dumb enough to try to beat
Microsoft by employing Microsoft's own products; and after that, they
adopted Java as a panacea.

Reliability and simplicity are really major selling points. We should have
both of them by combining XML with Ada. Ada has a very great advantage for
commercial development in that a tool based on ASIS could be used to divide
up the royalties. If anyone is serious about making Ada number one and
attempting to make money doing it, we can take this discussion off-line.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Mark Lundquist
Sent: Tuesday, December 18, 2001 4:12 PM
To: comp.lang.ada@ada.eu.org
Subject: Portable GUI (was Re: Future with Ada)



"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9vdo2a$9h3$1@nh.pace.co.uk...
>
> I mentioned elsewhere the notion that if there were some flavor of an XML
> doohickie out there for Ada that it might be possible to use that as the
> basis for a portable, standard GUI
>

Not sure exactly what you mean by an "XML doohickie" :-), but I'd be
thinkin' something along these lines:

1) First, you write your native Ada GUI library.  This is the hard part.
Make it the very best thing you can make.  Also let it be configurable with
traits that allow it to emulate Windows-like or Motif-like LAF.

2) Next, write an XML schema to define GUI layout in terms of the primitives
that map to those of your portable GUI.  It wouldn't hurt if (1) were done
with a view to (2).  Now, you have a way for GUIs to be represented as XML
documents, instead of encoded in program source code.

3) Now we need a way for your applications to talk to these GUIs.  First
step is to define a simple object model to ride on top of some middleware:
CORBA and/or SOAP and/or Bonobo...  The semantic level of this layer is what
is left after abstracting away from all the details of appearance, layout,
perhaps even some choices of controls, etc... that are now all loaded into
the XML representation.

4) We also need a way to render the GUIs, and so we write an XML browser (in
Ada, of course) to interpret the schema.  This is trivial, since the schema
is just an XML oil-slick over the native portable Ada GUI (1).  This
component brings together (1), (2), and (3).  It's a standalone executable.
Start with Windows and Linux.

5) Write/generate the bindings to (3) in every popular language that knows
how to talk to the middleware options you support.  So now you can offer a
platform-independent GUI for C++, Perl, Python, Ada of course, and even Java
for those who find compelling advantages in this GUI over Swing (and there
would be some advantages, I think).

6) While you're at it, write a GUI-builder.  It's target-language
independent, because it doesn't have to generate program source code, only
XML and IDL (or whatever).

7) Now take what we've done, and hype the living daylights out of it, while
preserving our dignity (we might need that later on).  Sell it at a modest
price to every cross-platform developer in the world.  Get written up in all
the trendy industry rags (cover stories of course). Win a Jolt award.  Get
the schema recommended as a W3C standard. Go public.

8) Let it slip that it has "Ada inside".

9) Developers everywhere become interested in the technology behind this
wonderful creation, the killer mini-app for Ada.  They discover the joy of
programming in Ada, the new high-performance language for the '00's (you
know... what comes after the '80's and the '90's).  Ada takes over the
world.

10) In the process, people discover that the XML GUI rendering engine is
nothing but a front-end to the standard Ada native GUI library and that 98%
of the work to duplicate it would be done for them because it's just
plumbing together things from the Ada foundation library.  The jig is up.
Exercise stock options now.  The free knockoffs start to appear, but that's
OK because we knew it was coming.  Move while you still control mindshare,
and release your source code under an open source license, thereby becoming
the world's great benefactor.  Restructure the business model around support
and consulting services.

11) Now we can either (a) spend most of our time sailing in the Caribbean,
or (b) take one of the many cushy jobs that await us now that Ada has
conquered.


Whoops, I left out a step... Step (0), find an investor to $upport us while
we do the work...

:-) :-) :-)
-- mark

-------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Re: Future with Ada

[Marin David Condic]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:cVPT7.3856$xl6.637425@rwcrnsc54...
>
> If a foundation library included some of those things, and they were (a)
> optional, and (b) straightforward to implement on both Unix and Windows,
> then I wouldn't lose too much sleep over the other platforms.
>
Are we talking about putting them into the ARM as an annex? Or simply
documenting some kind of pseudo-standard that gets implemented & finds wide
acceptance?

I'd agree that covering Windows and Unix would account for most things.
However, I still think there might be a least-common-denominator problem. It
would probably be better for Ada to have its own kind of GUI engine -
althought that (like anything else) has its own set of problems.


>
> It'd be an important step in the right direction, especially for
> implementers who appreciate the strengths of Ada but are realistic about
the
> state of affairs regarding GUIs and IDEs.  For them, some more beef in the
> "under-the-hood" area might tip the scales in the scenario of
> "backend/engine in Ada, UI in Java" (or UI in VC++ if a different team's
> doing it and that's what they know), or for web development where the UI
is
> one of the web scripting languages.
>
No doubt that adding *any* additional capabilities to Ada makes it more
attractive. However, I have not seen many projects that deliberately go out
and say "Lets use language X for the GUI and language Y for all the guts..."
Sometimes that happens by evolution, but not very often by design. Typically
a project is going to have the view that if it has to use language X to do
the GUI, it might just as well use language X to do everything - especially
since it is common that the GUI is most of the really hard work anyway.

So I think if Ada wants to compete in the markets where people develop apps
that are GUI based, it needs to have a GUI or it won't likely get chosen.
(Oh, yes, certainly. Of course there *will* be exceptions and people can
point to projects where this is the case. I'm suggesting that this will be
the *general* case.)

> Let's not equivocate on the subject under consideration, which is
> libraries... while IDEs are important, and also part of the "total
package"
> along with libraries, we should still observe a separation of concerns
> between them.  So the aim of a library effort would be to make Ada more
> competetive with C++/STL, and also more competetive with Java+JFC modulo
the
> GUI issue (on that score, Ada and C++ are on a par anyway; that is to say,
> you can develop using Claw, Gwindows etc. on Windows and be using the same
> GUI as if you were writing in C++, and if you use Gtk on Linux with C++,
you
> might just as well use GtkAda).
>
In some ways Ada is better off than C++ when it comes to libraries. One of
the things that struck me about the MFC when I first started looking at it
was that you could typically divide things into two categories: A) Stuff
that was constructed to make up for weaknesses in the Win32api and B) Stuff
that was constructed to make up for weaknesses in C++. Most of the stuff in
the B category, Ada wouldn't need.

Still, having better libraries that were "commonly implemented" (rather than
"standard" - since I think that is an overly optimistic goal) would make Ada
more attractive. We could probably describe them as belonging to one of
three classes:

a) Libraries that can be constructed entirely in the Ada language and don't
depend on any particular OS or platform or compiler in any significant way.

b) Libraries that can have a common interface and a common behavior across
implementations, but depend on the back-end being platform specific. (GtkAda
is a good example)

c) Libraries that are designed to provide access to specific capabilities of
a platform or OS. (CLAW is a good example)

Things that fit into category A are obviously the easiest things to get
constructed and distributed. Concentrating on those things would be good,
but I don't think they would in and of themselves be enough to really
promote Ada use where it doesn't already exist. Its things in the B or C
category that languages like Java offer that makes them attractive for
development in domains where Ada doesn't find much acceptance.

Personally, I think that Ada could do well by finding its way into the
Digital TV Set Top Box because its an area that isn't already "owned" by
some other language. Because its relatively new, no one language has any
sort of huge toolset that makes it impossible to replace without a billion
dollars and ten years of development time. Unfortunately, I don't think Ada
will find its way into this domain because most of the guys who know
anything about it and are inclined to build software for it are all pretty
much die-hard C-heads. But it would be a great opportunity....

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: Portable GUI (was Re: Future with Ada)

[Marin David Condic]

Something that would probably be a combination of a few things: You'd need a
subsystem that would render XML for you to a screen & interact with the user
to get input. It would probably return results to the user program in XML,
so you'd also need access to an XML parser to interpret the data & get it
into Ada-usable form. If you got that much, you'd still need something that
let you draw up GUIs for your programs that output XML tailored for your
rendering/I/O thingamabob.

Its all kind of vague in my mind so far because I'm not really up to speed
with XML to have a clear vision of how it would be done.

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 Lundquist" <no.spam@getalife.com> wrote in message
news:LXQT7.4103$NM4.198862@rwcrnsc53...
>
>
> Not sure exactly what you mean by an "XML doohickie" :-), but I'd be
> thinkin' something along these lines:
>

Re: Portable GUI (was Re: Future with Ada)

[Marin David Condic]

After reading in detail, I'd say that we're on the same chapter and verse.
Clearly, you have a more detailed vision of it than I do. I especially like
the part about sailing the Caribbean. :-)

So maybe we need to start up The Vast Ada Conspiracy & figure out how to get
the job done?

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 Lundquist" <no.spam@getalife.com> wrote in message
news:LXQT7.4103$NM4.198862@rwcrnsc53...
>
> 11) Now we can either (a) spend most of our time sailing in the Caribbean,
> or (b) take one of the many cushy jobs that await us now that Ada has
> conquered.
>
>
> Whoops, I left out a step... Step (0), find an investor to $upport us
while
> we do the work...
>

Re: Future with Ada

[Mr. Caffiene]

On Tue, 18 Dec 2001 11:41:08 -0500
"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote:

> As well you know, Bob, I'm much in favor of the notion of making money from
> the development of software. I think in particular that I liked the idea you
> expressed in this and other papers that one of the best ways to promote Ada
> and encourage its use is to demonstrate how people can make money by
> developing in Ada.
> 
> Many companies don't necessarily know about or believe in the benefits of
> using Ada because they have not witnessed the tangible monetary benefits of
> doing so. If their competitors were using Ada and developing better
> software, faster and cheaper, then they'd have to take a look at that.
> 
> Many individual programmers are reluctant to learn or use Ada because they
> don't see a job future in it. They see thousands of ads for jobs using other
> languages and few ads for Ada positions. If they saw more companies using
> Ada, they might be encouraged to want to earn a living that way.
> 
> If the ad-hoc developers out there saw a chance to develop something in Ada
> that might gain them fame and fortune rather than just the undying gratitude
> of end users and corporations who picked up their work at no cost, there
> might be more of them flocking to the fold. Perhaps that's where I was
> headed by suggesting the construction of some commercial product in Ada that
> would compete against some of the other big time apps out there. If Ada is
> so great, it ought to be possible to build something that competes
> effectively with the big guys, produces a better quality end product for the
> consumer, makes money for those involved and produces more tools/utilities
> for the Ada community. Seems like everyone could win.
> 
> MDC

I understand your reasoning here, however I get the impression (although I could be mistaken) that you beleive money is always the primary motivating factor for software development.
I disagree strongly. For several reasons...

1. I develope software because I enjoy it. Ada95 has made this process even more enjoyable because it cuts down on the number of hoops I have to jump through in order to get a piece of software just right. In many cases I can actually track and prove a procedure from start to finish. I see it as a sort of "zen" like artform, rather than as a die hard science.
Sure, I might end up getting a financial reward by being hired somewhere, or perhaps by re-licensing the code to a commercial house. But that would sort of be icing on the cake.

2. As far as developing a "big-time" application, arent there many such apps already mature and floating around for additions and improvements. Apache, the Linux kernel, PostGres SQL, etc... (not to mention the GNU system which runs on just about every Unix and Non-Unix platform out there.) These were developed not by a few developers hoping to make a profit, but rather by significantly sized groups of developers exchanging thier "ideas"(the code just happened to be a mode of communication).
As far as this goes, I'm currently working on a Plan9/Inferno type virtual kernel designed for complete transparency over most networks. This might take off, might not, but I sure am having fun experimenting and learning from it.

3. If money was the primary motivating factor for development, I beleive that if it were possible, there would be an even smaller pool of competent developers among todays "digeratti", and software in general would be in an even worse condition than it is now. A person doesn't endeavor to master something they dont enjoy when half-assed will get them paid just as well. Notice the current crop of cookie cutter developers pouring out of colleges and universities these days. They're in it because they expect to be well paid, unfortunately they end up developing software that I wouldn't pay 10 cents for. Note: This particular comment is directed at those who have taken the time to master thier field of software development. 

I hope this helps clarify some of the reasons that I write software. I cant speak for everyone, but I'm sure there are at least a "few" who might agree with me. ;->

I'm not slamming you either Mr. Condic. Just trying to point out some inconsistencies in your rather sweeping generalization about software developers.


As far as advancing Ada(95) goes; it would seem that allowing would-be Ada developers access to the source code, so as to prove in practice the benefits that Ada brings to the table, would be a much more convincing way to target developers rather than using statistics that are second and third level removed from a project and using anecdotal stories.

At least, that's my .02 worth. ;->

Chris
Mcdoobie
chris@dont.spam.me

Re: Portable GUI (was Re: Future with Ada)

[Darren New]

Mark Lundquist wrote:
 
> 1) First, you write your native Ada GUI library.  This is the hard part.
> Make it the very best thing you can make.  Also let it be configurable with
> traits that allow it to emulate Windows-like or Motif-like LAF.

The problem with doing it this way (i.e., not using native GUI calls) is
that when the native GUI changes, your GUI does not. E.g., if you make
it look like Win98 without using native widgets, it won't look right on
WinXP.
 
> 2) Next, write an XML schema to define GUI layout in terms of the primitives
> that map to those of your portable GUI.  It wouldn't hurt if (1) were done
> with a view to (2).  Now, you have a way for GUIs to be represented as XML
> documents, instead of encoded in program source code.

This too has already been done. It's called HTML. Actually, it's been
done many times. And XML is probably *not* a real good representation
for a GUI description language. It would be OK, but not excellent.
 
> 3) Now we need a way for your applications to talk to these GUIs.  First
> step is to define a simple object model to ride on top of some middleware:
> CORBA and/or SOAP and/or Bonobo...  The semantic level of this layer is what
> is left after abstracting away from all the details of appearance, layout,
> perhaps even some choices of controls, etc... that are now all loaded into
> the XML representation.
> 
> 4) We also need a way to render the GUIs, and so we write an XML browser (in
> Ada, of course) to interpret the schema.  This is trivial, since the schema
> is just an XML oil-slick over the native portable Ada GUI (1).  This
> component brings together (1), (2), and (3).  It's a standalone executable.
> Start with Windows and Linux.
> 
> 5) Write/generate the bindings to (3) in every popular language that knows
> how to talk to the middleware options you support.  So now you can offer a
> platform-independent GUI for C++, Perl, Python, Ada of course, and even Java
> for those who find compelling advantages in this GUI over Swing (and there
> would be some advantages, I think).
> 
> 6) While you're at it, write a GUI-builder.  It's target-language
> independent, because it doesn't have to generate program source code, only
> XML and IDL (or whatever).
> 
> 7) Now take what we've done, and hype the living daylights out of it, while
> preserving our dignity (we might need that later on).  Sell it at a modest
> price to every cross-platform developer in the world.  Get written up in all
> the trendy industry rags (cover stories of course). Win a Jolt award.  Get
> the schema recommended as a W3C standard. Go public.

So far, this sounds like HTML. Indeed, it would seem that AWS is a fine
way of building GUIs for Ada programs, yes?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
               "This wine goes good with feet."

Re: Portable GUI (was Re: Future with Ada)

[Marin David Condic]

That may not be A Bad Thing. Granted, if you were trying to closely emulate,
say, Windows Look & Feel, then you'd constantly be trying to play catch-up
with Micro$oft. However, if you said "The Ada GUI is going to be its *own*
thing" then maybe before too long, Micro$oft is trying to play catch-up with
*you*. (Well, we can dream, right?) Making a distinctive L&F would have its
own advantages - especially since it is a relatively easy thing to change
every model-year and convince the public that you've got a whole new thing.
:-)

The instant you get out of "native mode" for application development, you
might as well go your own way. Its either that, or you're going with Least
Common Denominator GUI implementation for portability.

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:3C20C5CE.DBFE5B96@san.rr.com...
>
> The problem with doing it this way (i.e., not using native GUI calls) is
> that when the native GUI changes, your GUI does not. E.g., if you make
> it look like Win98 without using native widgets, it won't look right on
> WinXP.
>

Re: Future with Ada

[Marin David Condic]

Oh, we've been this route before and I'd hate to hash it up all over again.
Let me say this: I don't believe that money is the sole motivator for
anything. I don't even believe that it is the strongest motivator for
anything. Money is a *complex* motivator and it certainly isn't the first
and last word behind every single software development effort anywhere in
the world.

My position is, ande always has been, that monetary reward encourages the
development of software. People do it because they get paid a salary. People
do it because they think they might make a buck on it down the road. People
do it for a lot of other reasons too, but most companies have a hard time
hiring programmers with a promise of personal fulfillment in leu of a
paycheck. I don't see why that seems to be such a controversial statement?

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/


"Mr. Caffiene" <nospam@attbi.com> wrote in message
news:20011219113724.09dc6ffa.nospam@attbi.com...
> On Tue, 18 Dec 2001 11:41:08 -0500
>
> I understand your reasoning here, however I get the impression (although I
could be mistaken) that you beleive money is always the primary motivating
factor for software development.
> I disagree strongly. For several reasons...
>

RE: Future with Ada

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Mr. Caffiene et al.
1) Charging for software and providing the sources are two separate
subjects. I favor charging for the software and providing the sources.

2) Although many professionals enjoy their work, they still expect to be
paid. This is particularly true when someone else can make a large amount of
money off of the professional's work. For instance, some professional
athletes enjoy their sport and receive very adequate compensation. In short
software developers should NOT be required to take a poverty oath.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Mr. Caffiene
Sent: Wednesday, December 19, 2001 8:33 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Future with Ada


On Tue, 18 Dec 2001 11:41:08 -0500
"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote:

> As well you know, Bob, I'm much in favor of the notion of making money
from
> the development of software. I think in particular that I liked the idea
you
> expressed in this and other papers that one of the best ways to promote
Ada
> and encourage its use is to demonstrate how people can make money by
> developing in Ada.
>
> Many companies don't necessarily know about or believe in the benefits of
> using Ada because they have not witnessed the tangible monetary benefits
of
> doing so. If their competitors were using Ada and developing better
> software, faster and cheaper, then they'd have to take a look at that.
>
> Many individual programmers are reluctant to learn or use Ada because they
> don't see a job future in it. They see thousands of ads for jobs using
other
> languages and few ads for Ada positions. If they saw more companies using
> Ada, they might be encouraged to want to earn a living that way.
>
> If the ad-hoc developers out there saw a chance to develop something in
Ada
> that might gain them fame and fortune rather than just the undying
gratitude
> of end users and corporations who picked up their work at no cost, there
> might be more of them flocking to the fold. Perhaps that's where I was
> headed by suggesting the construction of some commercial product in Ada
that
> would compete against some of the other big time apps out there. If Ada is
> so great, it ought to be possible to build something that competes
> effectively with the big guys, produces a better quality end product for
the
> consumer, makes money for those involved and produces more tools/utilities
> for the Ada community. Seems like everyone could win.
>
> MDC

I understand your reasoning here, however I get the impression (although I
could be mistaken) that you beleive money is always the primary motivating
factor for software development.
I disagree strongly. For several reasons...

1. I develope software because I enjoy it. Ada95 has made this process even
more enjoyable because it cuts down on the number of hoops I have to jump
through in order to get a piece of software just right. In many cases I can
actually track and prove a procedure from start to finish. I see it as a
sort of "zen" like artform, rather than as a die hard science.
Sure, I might end up getting a financial reward by being hired somewhere, or
perhaps by re-licensing the code to a commercial house. But that would sort
of be icing on the cake.

2. As far as developing a "big-time" application, arent there many such apps
already mature and floating around for additions and improvements. Apache,
the Linux kernel, PostGres SQL, etc... (not to mention the GNU system which
runs on just about every Unix and Non-Unix platform out there.) These were
developed not by a few developers hoping to make a profit, but rather by
significantly sized groups of developers exchanging thier "ideas"(the code
just happened to be a mode of communication).
As far as this goes, I'm currently working on a Plan9/Inferno type virtual
kernel designed for complete transparency over most networks. This might
take off, might not, but I sure am having fun experimenting and learning
from it.

3. If money was the primary motivating factor for development, I beleive
that if it were possible, there would be an even smaller pool of competent
developers among todays "digeratti", and software in general would be in an
even worse condition than it is now. A person doesn't endeavor to master
something they dont enjoy when half-assed will get them paid just as well.
Notice the current crop of cookie cutter developers pouring out of colleges
and universities these days. They're in it because they expect to be well
paid, unfortunately they end up developing software that I wouldn't pay 10
cents for. Note: This particular comment is directed at those who have taken
the time to master thier field of software development.

I hope this helps clarify some of the reasons that I write software. I cant
speak for everyone, but I'm sure there are at least a "few" who might agree
with me. ;->

I'm not slamming you either Mr. Condic. Just trying to point out some
inconsistencies in your rather sweeping generalization about software
developers.


As far as advancing Ada(95) goes; it would seem that allowing would-be Ada
developers access to the source code, so as to prove in practice the
benefits that Ada brings to the table, would be a much more convincing way
to target developers rather than using statistics that are second and third
level removed from a project and using anecdotal stories.

At least, that's my .02 worth. ;->

Chris
Mcdoobie
chris@dont.spam.me

RE: Future with Ada

[tmoran]

> 2) Although many professionals enjoy their work, they still expect to be
> paid.
  Isn't being paid the difference between "professional" and "amateur"?
The "starving artist" genius programmer is certainly a romantic notion,
but even starving artists have to waste valuable time working as waiters
or something to pay the rent.  Of course one could make an argument that
programs, like paintings or music, are what the economists call "public
goods" which will only be supplied adequately if the government (through
DoD funding of universities perhaps?) pays for it...

RE: Future with Ada

[Eric Merritt]

--- tmoran@acm.org wrote:
> > 2) Although many professionals enjoy their work,
> they still expect to be
> > paid.
>   Isn't being paid the difference between
> "professional" and "amateur"?
> The "starving artist" genius programmer is certainly
> a romantic notion,
> but even starving artists have to waste valuable
> time working as waiters
> or something to pay the rent.  Of course one could
> make an argument that
> programs, like paintings or music, are what the
> economists call "public
> goods" which will only be supplied adequately if the
> government (through
> DoD funding of universities perhaps?) pays for it...

Just as an aside, there is nothing wrong with asking
for volunteers to work on a project. If a programmer
is willing to donate his time to a project all the
better for everyone. Of course, expecting him to work
on it full time or donate a fixed amount per week is
improper. In actuality I am a professional programmer
(I program for a living) and regularly donate my time
to open source projects. I enjoy it and I get to give
something back to the open source community that has
given me so much.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

Re: Future with Ada

[Ian S. Nelson]

Robert C. Leif, Ph.D. wrote:


> athletes enjoy their sport and receive very adequate compensation. In short
> software developers should NOT be required to take a poverty oath.

I don't know any free software developers living in poverty.  Where are they all at?  


Ian

Re: Future with Ada

[Wes Groleau]

Mark Lundquist wrote:
> If a foundation library included some of those things, and they were (a)
> optional, and (b) straightforward to implement on both Unix and Windows,
> then I wouldn't lose too much sleep over the other platforms.

If you have Unix, you have Mac OS X, and Mac, Windows, and Unix
(and variants) are probably more than 95%.

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

Re: Future with Ada

[Ian S. Nelson]

Marin David Condic wrote:

 

> do it for a lot of other reasons too, but most companies have a hard time
> hiring programmers with a promise of personal fulfillment in leu of a
> paycheck. I don't see why that seems to be such a controversial statement?
> 
> MDC
 

The only thing I would qualify is that the involvment of companies isn't 
always needed.  In some cases it's not even a good thing.

Presumably we're all on the same page and want to advocate the use of 
ada.  I've watched this thread and I've seen it start with a discussion 
of building a new office suite which deteriorated in to why XML should 
be used for the file formats and how it will fail without MS Office 
interop.  And I've watched it go from a suggestion of some free software 
effort in to a discussion on the merits of professional programming.

My suggestion to write free stuff was more of a gauntlet drop than 
anything else.  We can talk forever about what kinds of projects might 
demonstrate the strengths of ada and it will remain an academic 
discussion.  Walking the walk as well as talking the talk can be 
compelling.  As with Linux and GNU, it didn't take a lot of software, 
relatively speaking, to snowball into a huge effort and I happen to be 
someone who makes his money from that stuff.  In no way do I want any 
programmers to go with out food or money.  What I do want is that if you 
program in ada and you've got some interesting code you wouldn't mind 
sharing or there is a pet project you would like to do then take the 
code and put it on sourceforge.net and let's show the world some 
programs done in ada. If 5000 programmers got interested then the thing 
to do would be to start an organized project to build a complete system 
out of ada, it should be easier to do and more correct than the GNU 
project.  Trust me on this, if that happened, companies would get 
interested.


Ian

Re: Future with Ada

[Marin David Condic]

I agree - there is absolutely nothing wrong with asking someone if they want
to volunteer some time to work on a project. Anyone volunteering their time
to some effort is absolutely free to do so.

Who would expect someone to work full time on a project - or commit to some
fraction of their time to a project, without remuneration? At least in terms
of having some *right* to their labor? You, of course, could volunteer to
come mow my lawn every Saturday, but I wouldn't have any *right* to expect
you to show up and do it. Certainly not in any sort of legal or moral sense.
That would sound a little like slavery to me.

Donating your time to some project is a matter of your own desires and
interests, but I'd imagine that short of your becoming independently wealthy
that you wouldn't quit your day job to do it. Certainly nobody should expect
that it is their "right" or your "duty" to work on the project free of
compensation.

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/


"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:mailman.1008793022.10355.comp.lang.ada@ada.eu.org...
>
> Just as an aside, there is nothing wrong with asking
> for volunteers to work on a project. If a programmer
> is willing to donate his time to a project all the
> better for everyone. Of course, expecting him to work
> on it full time or donate a fixed amount per week is
> improper. In actuality I am a professional programmer
> (I program for a living) and regularly donate my time
> to open source projects. I enjoy it and I get to give
> something back to the open source community that has
> given me so much.
>

Re: Future with Ada

[Marin David Condic]

"Ian S. Nelson" <nelsonis@earthlink.net> wrote in message
news:3C210174.3010007@earthlink.net...

> programs done in ada. If 5000 programmers got interested then the thing
> to do would be to start an organized project to build a complete system
> out of ada, it should be easier to do and more correct than the GNU
> project.  Trust me on this, if that happened, companies would get
> interested.
>
>
I would suspect that if an interesting enough Ada project got a toe-hold of
a start, there would be people willing to jump on it & turn it into
something big. A lot of the discussion around this particular thread has
been about what sort of Ada project would be interesting enough to capture
the imaginations of a bunch of developers.

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: Future with Ada

[Michal Nowak]

On 01-12-19 at 16:33 Mr.Caffiene wrote:

>I understand your reasoning here, however I get the impression (although I
>could be mistaken) that you beleive money is always the primary motivating
>factor for software development.
>I disagree strongly. For several reasons...
>
>1. I develope software because I enjoy it. Ada95 has made this process
>even more enjoyable because it cuts down on the number of hoops I have to
>jump through in order to get a piece of software just right. In many cases
>I can actually track and prove a procedure from start to finish.

I'm with you here, with a little exception - some money for living must
come from somewhere. After 4 years of writting in C/C++ I suddenly
switched to Ada, just after I saw this language. Now, if I need a
program for a laboratory I do it in Ada (no need to write why :-)).
But at work, there is C++, and from time to time I have to look at
somebody's code, because it is not working as it should. And the
horror begins (what was his intent here, why like this and not like
that, etc.) Or when sometimes, when it comes to extending the software.
I don't want to say that everything in C++ is automatically bad, and in
Ada is good. It is possible to write bad Ada programs and good C++
programs.
I still consider myself as an Ada-newbie, but getting familiar with
the code, I do not have much trouble to read the code and understand
what it does. That is nice - great support for reusability, modifications,
adding own stuff.
I used to be somebody like C-fanatic (now I'm not ;-)) . I liked to
write in C/C++ (I still like).  But I enjoy much more when writting in Ada.
And that was why I started this thread - if to work as a programmer,
why not in Ada? And the main qustion was - how do companies look at
inexperienced (professionally) Ada programmer...

-Mike-
-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Future with Ada

[Michal Nowak]

On 01-12-18 at 11:41 Marin David Condic wrote:

>Many companies don't necessarily know about or believe in the benefits of
>using Ada because they have not witnessed the tangible monetary benefits of
>doing so. If their competitors were using Ada and developing better
>software, faster and cheaper, then they'd have to take a look at that.
>
>Many individual programmers are reluctant to learn or use Ada because they
>don't see a job future in it. They see thousands of ads for jobs using
>other
>languages and few ads for Ada positions. If they saw more companies using
>Ada, they might be encouraged to want to earn a living that way.

There are beginners, who would like to write in Ada. There are posts to
the group like "I'm new to Ada, I found it great, I want to learn more".
Maybe that is not stunning number, but there are also not unique cases.
These people may start writting programs in Ada, but it will not count as
professional experience. They may be willing to write in Ada at work.
Maybe the point is in convincing the managers to Ada. The experience
must come from somewhere. From little projects. So if it comes from
somehere it means that there must be employement for inexperienced
programmers. So if there comes to hire inexperienced programmer, why
not Ada? There are companies, which use Ada (I mean they got qualified,
staff). If the managers have the benefits of using Ada (or maybe they
don't?), they will see, that Ada is good thing. So if they see, that
Ada is good, why they abandon Ada...That is clear, that inexperienced
worker cannot get programming a plane or spacecraft. But I hope, that
there should be places for newbies...

-Miked
-----------------------------------------
                             ____|
                             \%/ |~~\
  O                                  |
 o>>        Mike Nowak               |
 T                                   |
/ >       vinnie@inetia.pl           |
http://www.geocities.com/vinnie14pl _|__

Re: Portable GUI (was Re: Future with Ada)

[Steve Doiel]

If you really want it to sell as an Ada environment.
#1 Make the GUI Windows only.
#2 Make the only productive development environment Ada 95.
#3 Create the "perception" that the Ada 95 development enviroment is more
friendly than the others (it doesn't really have to be).
#4 Spark some hype (I don't know how this is effectively done, if I did I'd
be rich).

It worked for Micro$oft.

;-)

"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.1008747421.26661.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Mark Lundquist
> If you base the entire GUI on the parts of XML that use XML syntax, you
> probably would have a chance at becoming very rich. It would employ the
hot
> buzz word, XML, and be backed by solid technology, Ada.
>
> One of the major reasons for Microsoft's success is the technical
> incompetence of its competitors. First they were dumb enough to try to
beat
> Microsoft by employing Microsoft's own products; and after that, they
> adopted Java as a panacea.
>
> Reliability and simplicity are really major selling points. We should have
> both of them by combining XML with Ada. Ada has a very great advantage for
> commercial development in that a tool based on ASIS could be used to
divide
> up the royalties. If anyone is serious about making Ada number one and
> attempting to make money doing it, we can take this discussion off-line.
>

RE: Portable GUI (was Re: Future with Ada)

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Steve Doiel et al.
I totally agree that one needs marketing and could play the tricks that
Microsoft learned from IBM, who probably learned them from some other
company. However, there are enough intelligent customers who would
appreciate honesty, quality, simplicity, and reliability to do quite well.
Microsoft is now behaving like an American automobile manufacturer in the
1960s. No one in Detroit would listen to Deming about statistical quality
control. The Japanese to their everlasting credit did and quite properly
took away a large part of the American automobile market.

I just spent a significant amount of time and failed to upgrade from Windows
Me to XP. Even though XP never loaded, I still had to reload some of the
drivers for ME. After an hour, XP reported that it did not work with my
onboard UDMA (EIDE)disc controller. Just as the hubris of IBM contributed to
the success of the then under-dog Microsoft, the present hubris of Microsoft
has made a market for the developers of reliable software.

XML is a good technology, which has the great advantage of both providing
portability and the even greater advantage of having been accepted as
providing portability.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Steve Doiel
Sent: Wednesday, December 19, 2001 9:01 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Portable GUI (was Re: Future with Ada)


If you really want it to sell as an Ada environment.
#1 Make the GUI Windows only.
#2 Make the only productive development environment Ada 95.
#3 Create the "perception" that the Ada 95 development enviroment is more
friendly than the others (it doesn't really have to be).
#4 Spark some hype (I don't know how this is effectively done, if I did I'd
be rich).

It worked for Micro$oft.

;-)

"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.1008747421.26661.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Mark Lundquist
> If you base the entire GUI on the parts of XML that use XML syntax, you
> probably would have a chance at becoming very rich. It would employ the
hot
> buzz word, XML, and be backed by solid technology, Ada.
>
> One of the major reasons for Microsoft's success is the technical
> incompetence of its competitors. First they were dumb enough to try to
beat
> Microsoft by employing Microsoft's own products; and after that, they
> adopted Java as a panacea.
>
> Reliability and simplicity are really major selling points. We should have
> both of them by combining XML with Ada. Ada has a very great advantage for
> commercial development in that a tool based on ASIS could be used to
divide
> up the royalties. If anyone is serious about making Ada number one and
> attempting to make money doing it, we can take this discussion off-line.
>

Re: Future with Ada

[tmoran]

> I'd agree that covering Windows and Unix would account for most things.
> However, I still think there might be a least-common-denominator problem. It
> would probably be better for Ada to have its own kind of GUI engine -
> althought that (like anything else) has its own set of problems.
  Based on a grand total of two data points, I'd hazard that the
cost/benefit ratio of replacing an app's GUI when transporting it, is not
especially unreasonable.  There is value in a GUI that makes the user feel
comfortable, and it may not be all that much work.  (The two data points
are converting Dining Philosophers (ANSI.SYS) and Mine Detector (GtkAda) to
MS Windows (Claw).  Admittedly they are small apps, and Mike Feldman and
Jeffrey Carter's good design made the job much easier.  But hey, lots of
people make claims with even less data. :)

Re: Portable GUI (was Re: Future with Ada)

[Marin David Condic]

The problem is that you won't ever beat Microsoft if you continue to play
Microsoft's game. They make the rules and are way bigger than you are. The
way to beat Microsoft is to invent your *own* game - something that was done
with Linux and now has Microsoft scared.

Sure, they're big and wealthy - but that doesn't mean that someone can't
come along with a better mousetrap and a different angle and find people
willing to start migrating away from their stranglehold. Any company can be
beat. History is repleat with examples.

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/


"Steve Doiel" <nospam_steved94@attbi.com> wrote in message
news:VfeU7.11318$Ah.563223@rwcrnsc52...
> If you really want it to sell as an Ada environment.
> #1 Make the GUI Windows only.
> #2 Make the only productive development environment Ada 95.
> #3 Create the "perception" that the Ada 95 development enviroment is more
> friendly than the others (it doesn't really have to be).
> #4 Spark some hype (I don't know how this is effectively done, if I did
I'd
> be rich).
>
> It worked for Micro$oft.
>
> ;-)

Re: Portable GUI (was Re: Future with Ada)

[Richard Riehle]

I am now reading the language comparison papers from my
NPS class, "Ada As A Second Language."    Nearly all of the
students in this class have at least two other languages:
C++ and Java.   Some have Fortran from their undergraduate
engineering but have forgotten much of it.   Others have a
smattering of other languages.

One of the last assignments for this class was to write a paper
comparing Ada to one of their "first" languages.    Some
compared Ada to C++.  Most compared it to Java.   A few
compared it to multiple languages, usually C++ and Ada. One
even included a comparison to PL/I.

Almost all of them prefer Ada to C++.    Some don't like Ada
very much due to difficulties they had completing some of their
assignments.   Most expressed a newfound appreciation for Ada,
even as they expected it to be dull, dead, and a waste of time.

In nearly every paper, especially those comparing Ada to Java,
the students said they would be more inclined to use Java because
of the easy-to-use development environment.    Even those who
really took to Ada noted their disappointment with the available
tools for creating, testing, and debugging programs when comparing
their Java experience with their Ada experience.

The conclusion:   Ada is attractive, as a language.   It is not attractive
when one examines the associated development tools and libraries. We
have a long way to go.

That being said, some of the compiler developers do have good development
environments available.  I need to see whether I can get access to the
Rational Apex environment or some of the other really good commercial
tools (DDC-I, Wind River, etc.)  for future NPS classes.   One problem with
that is that students put the compiler and development tools on their laptops
for the quarter and practice at home, in the library, and in the lunch area.  I
fear I would have trouble getting permission from a commercial compiler
publisher to distribute their product so freely.   ObjectAda is an option,
because of its GUI environment.  Some students use it.   Too bad ObjectAda
does not decouple from its compiler so we could use any compiler we
wanted with it.

Meanwhile,  we will continue to use the tools that are freely available and
encourage students with glimpses of other environments when possible.  Still,
it is difficult when they see the tools available for Java compared to what they

have for Ada.

Some of you are old enough to remember Eddie Cantor singing, "How you
gonna keep'em down on the farm after they've seen Pareeeeee?"

Richard Riehle

Re: RE: Future with Ada

[Ted Dennison]

In article <gb6U7.9423$xl6.1003584@rwcrnsc54>, tmoran@acm.org says...
>or something to pay the rent.  Of course one could make an argument that
>programs, like paintings or music, are what the economists call "public
>goods" which will only be supplied adequately if the government (through
>DoD funding of universities perhaps?) pays for it...

I wouldn't agree with that. I've spent my entire career developing software that
was never directly distributed to more than one party. Developing software is a
valuable activity, and *that* is what should (and will) be paid for. It is also
the expensive part, so it is the most sensible part to charge for.

Sure there are some companies trying to mass-market commercial software with
"tolls". But most software developers are still either working directly for
their users, or for some kind of "hardware" vendor (who needs that software so
they can sell their hardware). I see no reason why we wouldn't be just as well
off today, if not better, if all those toll-based software companies didn't
exist, and instead developers were occasionally paid to add a new feature here
or there to the standard word-processor or database that their company uses. It
wouldn't alter my job (or pay, most likely) one iota, except that I wouldn't
have to waste time installing license managers and typing in software keys.

Another relevant term I have heard from the world of economics is a "Natural
Monopoly". The basic idea is that cost of developing the infrastructure is so
high compared to the cost of running it that it really doesn't pay for anyone to
even try to compete by building their own. In such a mileu, you *will* have a
monopoly. Its just a matter of how regulated you want to make 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: Portable GUI (was Re: Future with Ada)

[Ted Dennison]

In article <3C223DE4.9A50C1B2@adaworks.com>, Richard Riehle says...
>One of the last assignments for this class was to write a paper
>comparing Ada to one of their "first" languages.    Some

An incredibly interesting study. One done of professionals would be more
interesting, but that would be much tougher to achieve.

>In nearly every paper, especially those comparing Ada to Java,
>the students said they would be more inclined to use Java because
>of the easy-to-use development environment.    Even those who

Its been quite a few years since I fiddled w/ Java. What exactly does this refer
to? Is it just the standard libraries that are at issue?

>Some of you are old enough to remember Eddie Cantor singing, "How you
>gonna keep'em down on the farm after they've seen Pareeeeee?"
Any such person would have to be at least 65, would they not?

---
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: Portable GUI (was Re: Future with Ada)

[Marin David Condic]

Its pretty obvious to me that there's a *big* business advantage to being
able to utilize everything that you get with something like Java or MSVC++.
For whatever the flaws are in the language, you just get to market so much
quicker because you've got the GUI tools, etc., available to get it running
that much faster. Being able to bind to it with Ada is interesting, but not
compelling - it just adds another layer of work and makes it difficult or
impossible to use all of the other spiffy tools in the IDE.

We can't *fault* Ada for not having this kind of thing - at least it seems
moderately unfair. After all, Microsoft and Sun are behind the
aforementioned tools & they've got the cash to dump into building the
spiffiness. But if Ada wants to compete where these other guys play, its
just a non-starter without the libraries and IDE. And the price has to be
competitive as well.

So it seems to me that for Ada to break into this realm it either has to
find a really big sponsor willing to invest in the toolkit or it needs to
evolve a GUI and IDE of similar calibre in some sort of volunteer or
speculative venture.

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:3C223DE4.9A50C1B2@adaworks.com...
>
> In nearly every paper, especially those comparing Ada to Java,
> the students said they would be more inclined to use Java because
> of the easy-to-use development environment.    Even those who
> really took to Ada noted their disappointment with the available
> tools for creating, testing, and debugging programs when comparing
> their Java experience with their Ada experience.
>

Re: Portable GUI (was Re: Future with Ada)

[Stephen Leake]

Richard Riehle <richard@adaworks.com> writes:

> <snip description of results of student study>
> 
> The conclusion:   Ada is attractive, as a language.   It is not attractive
> when one examines the associated development tools and libraries. We
> have a long way to go.

What sort of application did they do? If it's a GUI system, this makes
perfect sense. For an embedded real time system, I'd be more
surprised.

And what exactly were the development environments used? (for all the
languages).

Is there any sort of published/web accessible description of this?

-- 
-- Stephe

Re: RE: Portable GUI (was Re: Future with Ada)

[Ted Dennison]

In article <mailman.1008747421.26661.comp.lang.ada@ada.eu.org>, Robert C. Leif,
Ph.D. says...
>One of the major reasons for Microsoft's success is the technical
>incompetence of its competitors. First they were dumb enough to try to beat

Microsoft certainly likes to spread this story (check their anti-trust arguments
sometimes). But I'm not really enamored of any theory that depends on there
being some kind of mass incompetence between large amounts of diverse
organizations and individuals who have no connection to each other (according to
the theory) but coincidental ones. For one thing, it doesn't make a very good
theory, scientificly, as there are no predictions one can make from it to test
it.

For instance, lets take the alternative theory that everyone is equally
(in)compentent, but that everything's basicly a crap shoot. Whenever you talk
about gambling, in the long run the odds favor the party with the most money.
This theory would predict that if any software company were to get in a dominant
financial position, it could just outlast anyone it competes with because it
will have the resources to survive blunders that will take down the lesser
companies. This theory may not be fully correct, but at least it explains *why*
the winners and losers are who they are, and gives you something you can draw
testable conculsions from.

---
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: RE: Portable GUI (was Re: Future with Ada)

[Marin David Condic]

Luck probably has a lot to do with it. But then, you've got to do a lot of
practice to be standing at the plate during the World Series when that
easy-to-hit pitch comes your way by "luck".

Sure, Microsoft has been "lucky". (Whenever someone else wins and I don't,
its *always* because of luck! :-) Bill Gates got lucky that IBM, et alia,
dropped the ball on more than one occasion and he was there to pick it up.
It could have been someone else, right? But there still has to be plenty of
skill to explain the results as well. I believe that many of Microsoft's
competitors have dropped the ball and failed to exploit all of the
opportunities they might have had to win. But that doesn't mean that
Microsoft will *always* win or that luck didn't play a role.

But for some people, luck itself is a form of art. :-)

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:edsU7.5948$XC5.7777@www.newsranger.com...
> For instance, lets take the alternative theory that everyone is equally
> (in)compentent, but that everything's basicly a crap shoot. Whenever you
talk
> about gambling, in the long run the odds favor the party with the most
money.
> This theory would predict that if any software company were to get in a
dominant
> financial position, it could just outlast anyone it competes with because
it
> will have the resources to survive blunders that will take down the lesser
> companies. This theory may not be fully correct, but at least it explains
*why*
> the winners and losers are who they are, and gives you something you can
draw
> testable conculsions from.
>

Re: RE: Future with Ada

[Hyman Rosen]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:OhrU7.5856$XC5.7655@www.newsranger.com...
> I see no reason why we wouldn't be just as well
> off today, if not better, if all those toll-based software companies didn't
> exist, and instead developers were occasionally paid to add a new feature here
> or there

I think the classic counterexample is computer games. They have huge
development costs, volatile development schedules, and short shelf lives.

Re: Future with Ada

[tmoran]

> Personally, I think that Ada could do well by finding its way into the
> Digital TV Set Top Box because its an area that isn't already "owned" by
> some other language. Because its relatively new, no one language has any
> sort of huge toolset that makes it impossible to replace without a billion
  So perhaps, instead of an angel to fund development of a huge toolset,
we need an angel to fund some new application, like set top boxes, where
Ada has the advantages, and not the disadvantages.

Re: Future with Ada

[Marin David Condic]

An Ada OS that rode inside of a STB would be a little like MS-DOS riding
along inside of IBM-PCs. Millions of these units are going to be sold and
they start to blend the difference between your TV set and your home
computer. Right now the OS that rides around in a lot of these boxes isn't
terribly more sophisticated than MS-DOS - well maybe it has a lot more
features, but I don't think the sophistication or reliability is there.
Certainly not like you see in Windows NT or Linux. (And yes, NT is a *lot*
more reliable than the OS I've got humming around in my STB at the moment.)
Could you imagine what the world for Ada would look like if MS-DOS had been
written in Ada? Or Windows 3.1 had its API specified in Ada? I think that's
pretty much the kind of opportunity that exists here.

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/

<tmoran@acm.org> wrote in message news:KDtU7.15329$NM4.3204765@rwcrnsc53...
> > Personally, I think that Ada could do well by finding its way into the
> > Digital TV Set Top Box because its an area that isn't already "owned" by
> > some other language. Because its relatively new, no one language has any
> > sort of huge toolset that makes it impossible to replace without a
billion
>   So perhaps, instead of an angel to fund development of a huge toolset,
> we need an angel to fund some new application, like set top boxes, where
> Ada has the advantages, and not the disadvantages.

Re: Future with Ada

[Eric Merritt]

--- Marin David Condic
<dont.bother.mcondic.auntie.spam@[acm.org>]>,
MISSING_MAILBOX_TERMINATOR@.SYNTAX-ERROR. wrote:
> I agree - there is absolutely nothing wrong with
> asking someone if they want
> to volunteer some time to work on a project. Anyone
> volunteering their time
> to some effort is absolutely free to do so.
> 
> Who would expect someone to work full time on a
> project - or commit to some
> fraction of their time to a project, without
> remuneration? At least in terms
> of having some *right* to their labor? You, of
> course, could volunteer to
> come mow my lawn every Saturday, but I wouldn't have
> any *right* to expect
> you to show up and do it. Certainly not in any sort
> of legal or moral sense.
> That would sound a little like slavery to me.

I absolutely agree. Even when I have been asked if I
could provide an estimation of the time I could spend
on an open source project (for estimation purposes) I
set the amount of time and the subject was never
brought up in any case.



> 
> Donating your time to some project is a matter of
> your own desires and
> interests, but I'd imagine that short of your
> becoming independently wealthy
> that you wouldn't quit your day job to do it.
> Certainly nobody should expect
> that it is their "right" or your "duty" to work on
> the project free of
> compensation.

Good lord no, if that becomes the case that person
should be removed as project lead or you should leave
the project yourself. That would just be an untenable
situation altogether. It comes down to the fact the if
you want to volunteer that is great, but if not that's
fine too.


__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

Re: RE: Portable GUI (was Re: Future with Ada)

[Ted Dennison]

In article <9vtkbe$kth$1@nh.pace.co.uk>, Marin David Condic says...
>
>Luck probably has a lot to do with it. But then, you've got to do a lot of
>practice to be standing at the plate during the World Series when that
>easy-to-hit pitch comes your way by "luck".
>
>Sure, Microsoft has been "lucky". (Whenever someone else wins and I don't,
>its *always* because of luck! :-) Bill Gates got lucky that IBM, et alia,

Not exactly. I was talking about *chance*, not luck. There is a subtle
difference. Luck favors no one. Chance favors the party that can keep playing
longest (as they are less likely to go bankrupt first). Microsoft has had as
many disasters as anyone else, if you care to look into it. Anyone remember
"Bob"? How about version 1.0 of about anything they have ever released? They
just have a huge bankroll, and a really good cash cow behind it, that lets them
survive disasters that would lay anyone else low. 

Whenever they enter a new market, you can think of them as like the Russians in
World War II. Sure their equipment starts out below par, and they may not even
know what they are doing until they are in it for a while. But, unlike their
enemies, they can loose whole armies and hardly feel 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: RE: Portable GUI (was Re: Future with Ada)

[Marin David Condic]

Little guys can afford to make little mistakes. Big guys can afford to make
big mistakes. I understand how their size & wealth have enabled them to
survive some bad product decisions, etc. But if they didn't have some
enormously big successes (which means they must be doing *something* right!)
they wouldn't have the cash cows out there to make up for the marketing
flops and tactical blunders.

I'm no big fan of Microsoft, but I will admit that they do manage to do some
things pretty well from time to time. Sometimes us techies look at what they
do and see the technical flaws and say "Microsoft is a bunch of boneheads".
The problem is that the object of the game is not to make good software -
its to make money for the stockholders. That they seem to do reasonably
well.

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:o1IU7.6812$XC5.8608@www.newsranger.com...
> In article <9vtkbe$kth$1@nh.pace.co.uk>, Marin David Condic says...
>
> Not exactly. I was talking about *chance*, not luck. There is a subtle
> difference. Luck favors no one. Chance favors the party that can keep
playing
> longest (as they are less likely to go bankrupt first). Microsoft has had
as
> many disasters as anyone else, if you care to look into it. Anyone
remember
> "Bob"? How about version 1.0 of about anything they have ever released?
They
> just have a huge bankroll, and a really good cash cow behind it, that lets
them
> survive disasters that would lay anyone else low.
>

Re: RE: Future with Ada

[Ted Dennison]

In article <1008884265.464967@master.nyc.kbcfp.com>, Hyman Rosen says...
>I think the classic counterexample is computer games. They have huge
>development costs, volatile development schedules, and short shelf lives.

True, that's the toughest nut. But in a sense, that is the way things are
because that is the way things are. People have been writing computer games just
for fun almost as long as computers have been around, so I highly doubt they'd
disappear altogether under some different incentive system. Some types of games,
eg: Massively Multiplayer Online games, wouldn't even be affected all that much.

As much as I play games (I have a large bookshelf full of them at home, and
another closet full of obsolete ones), I have actually thought about this a
great deal. I think the only real problem with Free Software games is that open
sources make it too easy for programmers to cheat in muliplayer games.
Everything would basicly have to be designed with a host and dumb clients. 

---
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: RE: Portable GUI (was Re: Future with Ada)

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Ted Dennison et al.
From my experience in business, managerial incompetence and stupidity are
the cause of many disasters. This is one of the main reasons Dilbert is very
successful. IBM did not understand the PC revolution and tried to use OS/2
as a means to sell their proprietary hardware, the microchannel. This killed
O/S2 and greatly helped Microsoft. WordPerfect switched to Windows,
abandoned their very successful look and feel, and did a poor job
implementing their code. That helped make Word. Lotus junked Improv and
never incorporated any of its functionality into 123. That greatly helped
Excel. It took literally years to rewrite Dbase in C++ for Windows. That
helped Access. I do not know of any well designed reliable Office type
products.

No one has tried to market a well engineered office suite base on an
international standard. An XML security blanket should provide sufficient
risk reduction to permit the adoption of a new technology. Even Microsoft
provides XML output for Excel and other products.
-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Ted Dennison
Sent: Thursday, December 20, 2001 12:54 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: RE: Portable GUI (was Re: Future with Ada)


In article <mailman.1008747421.26661.comp.lang.ada@ada.eu.org>, Robert C.
Leif,
Ph.D. says...
>One of the major reasons for Microsoft's success is the technical
>incompetence of its competitors. First they were dumb enough to try to beat

Microsoft certainly likes to spread this story (check their anti-trust
arguments
sometimes). But I'm not really enamored of any theory that depends on there
being some kind of mass incompetence between large amounts of diverse
organizations and individuals who have no connection to each other
(according to
the theory) but coincidental ones. For one thing, it doesn't make a very
good
theory, scientificly, as there are no predictions one can make from it to
test
it.

For instance, lets take the alternative theory that everyone is equally
(in)compentent, but that everything's basicly a crap shoot. Whenever you
talk
about gambling, in the long run the odds favor the party with the most
money.
This theory would predict that if any software company were to get in a
dominant
financial position, it could just outlast anyone it competes with because it
will have the resources to survive blunders that will take down the lesser
companies. This theory may not be fully correct, but at least it explains
*why*
the winners and losers are who they are, and gives you something you can
draw
testable conculsions from.

---
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: RE: Portable GUI (was Re: Future with Ada)

[Ted Dennison]

In article <9vvja5$edn$1@nh.pace.co.uk>, Marin David Condic says...
>
>Little guys can afford to make little mistakes. Big guys can afford to make
>big mistakes. I understand how their size & wealth have enabled them to

Quite so.

>survive some bad product decisions, etc. But if they didn't have some
>enormously big successes (which means they must be doing *something* right!)
>they wouldn't have the cash cows out there to make up for the marketing
>flops and tactical blunders.

If you read the history of the company, you will find that it could easily be
argued that everything they now have has flowed out of having the OS monopoly.
How they ended up with that was indeed luck (early on they actually tried to
give it away twice). However, *someone* would have ended up with it either way.
So from our perspective luck wasn't an issue at all. We would have had our
Microsoft, no matter what their name ended up being. :-)

It could be argued that they have been at least fairly crafty in maintaining
their monopoly, and in continuing to keep plugging away when they enter new
markets and fail initially. But I don't see where we need to ascribe to the
company unnatural levels of skill, intelligence, or good looks to explain the
current state of affairs.

---
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: Portable GUI (was Re: Future with Ada)

[Richard Riehle]

Stephen Leake wrote:

> What sort of application did they do? If it's a GUI system, this makes
> perfect sense. For an embedded real time system, I'd be more
> surprised.

Some of their projects did include tasking. All were GUI
oriented.   Several required them to develop their own generic
data structures and create a working application.

I agree that, if we had been building an embedded systems
application (I plan to include that in a follow-on class sometime),
the results might have been different.

> And what exactly were the development environments used? (for all the
> languages).

Students were allowed to select from a collection of tools, based on their
own experience and ability.   I gave them some guidance.   Some opted
for the simple JEWL package designed by John English.  Others decided
to try CLAW ( the free download version), and a few brave souls did
their projects using GtkAda.    Those using GtkAda were also using Linux.
One of the GtkAda/Linux users is a die-hard vi enthusiast and he definitely
skews the curve.    In fact, he is writing a little GtkAda tutorial as part
of his final project.   If it turns out to be useful, I will get his permission
to post it to AdaPower.

> Is there any sort of published/web accessible description of this?

Not yet.  I plan to collect these from my students over time and
eventually publish the results as a paper, probably in Ada Letters.

Richard Riehle

Re: Portable GUI (was Re: Future with Ada)

[Michal Nowak]

On 01-12-20 at 11:37 Richard Riehle wrote:

>I am now reading the language comparison papers from my
>NPS class, "Ada As A Second Language."    Nearly all of the
>students in this class have at least two other languages:
>C++ and Java.   Some have Fortran from their undergraduate
>engineering but have forgotten much of it.   Others have a
>smattering of other languages.
>
>One of the last assignments for this class was to write a paper
>comparing Ada to one of their "first" languages.    Some
>compared Ada to C++.  Most compared it to Java.   A few
>compared it to multiple languages, usually C++ and Ada. One
>even included a comparison to PL/I.

>Almost all of them prefer Ada to C++.    Some don't like Ada
>very much due to difficulties they had completing some of their
>assignments.   Most expressed a newfound appreciation for Ada,
>even as they expected it to be dull, dead, and a waste of time.

At least, they were interested in Ada (less or more). Just for
curiosity - what year of study is it (or for how long they know
Java/C++)? I was presented Ada on VIII semester (just 2 lectures,
intro + distibuted system annex). The rest was Java RMI, CORBA,
PVM and MPI. We had to the same distibuted application in all
above environments and compare them. This short time caused, that
Ada wasn't presented well enough (we were familiar with PVM, Java
from previous semesters). From 2nd semester, when C and then C++
and Java were introduced, nealy every programs we were writting in
these languages (there were of course others languages, but these
seemed most functional). Most of us writes in Java or C++ at work,
so after all this time (nearly 4 years), they are thinking in C++
or Java and see the world through this perspective
(i.e. Object->method()).

I was talking with my colleagues what they think about Ada, here
are some opinions:
1. Are there any data structures like Lists, Queues, Hash Tables, etc
  in Ada? Such structures exists in Java.
2. Does it have any visual extensions or GUI builder like JBuilder
  or Visual C++ (hmm, I did not looked at them seriously, because
  thay have trouble of compiling Java program from command line
  if they were without a JBuilder. Reading through other posts,
  shows, that after all I should have take this seriously).
  In fact, they wanted something like Borland C++ Builder, where
  click, click - and GUI is ready. CLAW or GWindows was not an
  option for them.
3. It has great tasking model and protected objects. If Ada was
  more popular here (Poland), they were willing to learn it deeper.
4. Troubles in using Strings - this is not strange to me, idea of Ada
  Strings was not presented;
5. GLADE was easy to use, espacially writting callbacks (when compared
  to SUN rpcgen horror), quite easy to use;
6. Troubles in using Reference Manual. Some needed something like
  Java Doc. Predefined language environment (annex A), is much
  more poor in compare to Java Docs.
7. It is Pascal, what's that Pascal again? (total C-guys)

Ada was taken better than C++, but wore than Java. Most of opinions
favored Java because of reasons mentioned in point 1 and 6.

I'm trying to make Ada presentation on next semester on my
university on a special interest meeting. Maybe if some eariler
year students will see Ada (especially about tasking), they
will use Ada on some lab projects.

>In nearly every paper, especially those comparing Ada to Java,
>the students said they would be more inclined to use Java because
>of the easy-to-use development environment.    Even those who
>really took to Ada noted their disappointment with the available
>tools for creating, testing, and debugging programs when comparing
>their Java experience with their Ada experience.
>
>The conclusion:   Ada is attractive, as a language.   It is not attractive
>when one examines the associated development tools and libraries. We
>have a long way to go.

Ada still has performance advantage over Java. But there are slowly
cominig Java compilers to native code. If some $$$ company will put
hands on it....

-Mike

Marry Christmas and Happy New Year - with Ada - to all of you.

Re: Future with Ada

[Gerhard Häring]

In article <9v7r4u$p8v$1@nh.pace.co.uk>, Marin David Condic wrote:
> [...] Developing an office suite that is available
> in source and runs on a number of diverse platforms and keeps its data in
> formats that are easily accessed by other programs is something that has
> advantages to the consumer who wants to be able to keep his options open. It
> could be a good business opportunity.

OpenOffice (http://www.openoffice.org/) and its commercial incarnation,
StarOffice 6.0 (beta available from Sun) store their documents in a zip
file containing XML and the dependencies, like images. Very neat, IMHO.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Containers package

[Eric Merritt]

Hello All, 

I have another newbie question for you. Is there a
well documented container library out there. I have
checked out several and on every one so far the
documentation on how to use it is sparse at best and
nonexistant at worst. It is just that the lack of
containers (or in this case, lack of instruction in
how to use those containers) has never been an issue
for any other language I have used. In any case, could
someone point out a decent containers library and its
associated documentation. The most well documented so
far seems to be Corey Minyard's library and the least
documented seems to be the PargmArc components. Mr.
Minyard did a good job in his documentation, however,
he only gave examples for a small subset of the
components.

All I am really looking for are a few examples and a
list of caveats. I have been looking through source
code and test suites to figure out the uses of these
libraries, but I shouldn't really have to do this for
truly reusable components. 

Thank You,
Eric Merritt

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: Containers package

[Michael Erdmann]

Eric Merritt schrieb:

Maybe you should contact Nick Roberts,

they are currently developing something
like this. I have the hope that ithis will
be better document then the old ones.

Or follow the Container Strawman 1.4 thread
in comp.lang.ada.

Michael



> Hello All,
>
> I have another newbie question for you. Is there a
> well documented container library out there. I have
> checked out several and on every one so far the
> documentation on how to use it is sparse at best and
> nonexistant at worst. It is just that the lack of
> containers (or in this case, lack of instruction in
> how to use those containers) has never been an issue
> for any other language I have used. In any case, could
> someone point out a decent containers library and its
> associated documentation. The most well documented so
> far seems to be Corey Minyard's library and the least
> documented seems to be the PargmArc components. Mr.
> Minyard did a good job in his documentation, however,
> he only gave examples for a small subset of the
> components.
>
> All I am really looking for are a few examples and a
> list of caveats. I have been looking through source
> code and test suites to figure out the uses of these
> libraries, but I shouldn't really have to do this for
> truly reusable components.
>
> Thank You,
> Eric Merritt
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com

Re: Containers package

[Marc A. Criley]

Eric Merritt wrote:
> 
> Hello All,
> 
> I have another newbie question for you. Is there a
> well documented container library out there. I have
> checked out several and on every one so far the
> documentation on how to use it is sparse at best and
> nonexistant at worst. It is just that the lack of
> containers (or in this case, lack of instruction in
> how to use those containers) has never been an issue
> for any other language I have used. In any case, could
> someone point out a decent containers library and its
> associated documentation. The most well documented so
> far seems to be Corey Minyard's library and the least
> documented seems to be the PargmArc components. Mr.
> Minyard did a good job in his documentation, however,
> he only gave examples for a small subset of the
> components.

I was going to suggest Corey's, but I see you already found it.  I
pretty much use those components for everything I write.

Here's a bit of advice on using them:

When you figure out what component you want to use, e.g.,
Asgc.List.Expandable, start instantiating at the top and work your way
down--

 package Client_Manager_Base is new Asgc(Client_Manager_Handle);
 package List_Client_Manager is new Client_Manager_Base.List;
 package Client_Manager_List is new List_Client_Manager.Expandable;

 Clients : aliased Client_Manager_List.Object(10, 5);

Notice how each instantiated package is used in the subsequent
instantiation.

The other important thing to know (and the reason the list object is
aliased) is that when you're going to use an iterator, like:

 Client_Iter : Client_Manager_List.Iterator;
 
don't forget to do a Set_Container--

  Set_Container(Client_Iter, Clients'Access);

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

Re: Containers package

[Eric Merritt]

Michael,

I have been following, it looks very interesting.
However, who is to say when a usable product will
result? But thanks for the information anyway.

--- Michael Erdmann <michael.erdmann@snafu.de> wrote:
> Eric Merritt schrieb:
> 
> Maybe you should contact Nick Roberts,
> 
> they are currently developing something
> like this. I have the hope that ithis will
> be better document then the old ones.
> 
> Or follow the Container Strawman 1.4 thread
> in comp.lang.ada.
> 
> Michael
> 
> 
> 
> > Hello All,
> >
> > I have another newbie question for you. Is there a
> > well documented container library out there. I
> have
> > checked out several and on every one so far the
> > documentation on how to use it is sparse at best
> and
> > nonexistant at worst. It is just that the lack of
> > containers (or in this case, lack of instruction
> in
> > how to use those containers) has never been an
> issue
> > for any other language I have used. In any case,
> could
> > someone point out a decent containers library and
> its
> > associated documentation. The most well documented
> so
> > far seems to be Corey Minyard's library and the
> least
> > documented seems to be the PargmArc components.
> Mr.
> > Minyard did a good job in his documentation,
> however,
> > he only gave examples for a small subset of the
> > components.
> >
> > All I am really looking for are a few examples and
> a
> > list of caveats. I have been looking through
> source
> > code and test suites to figure out the uses of
> these
> > libraries, but I shouldn't really have to do this
> for
> > truly reusable components.
> >
> > Thank You,
> > Eric Merritt
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Send your FREE holiday greetings online!
> > http://greetings.yahoo.com
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: Containers package

[Nick Roberts]

I am indeed developing a containers library, called "Tenet", which will
hopefully be hosted on AdaPower.net.

I shall get this done ASAP, and with reasonable documentation (but I can't
write a book). I am going to release it under the LGPL.

--
Best wishes,
Nick Roberts

Re: Containers package

[Eric Merritt]

Nick,

Will this be based on the list strawman that is
currently being dicussed?

--- Nick Roberts <nickroberts@adaos.worldonline.co.uk>
wrote:
> I am indeed developing a containers library, called
> "Tenet", which will
> hopefully be hosted on AdaPower.net.
> 
> I shall get this done ASAP, and with reasonable
> documentation (but I can't
> write a book). I am going to release it under the
> LGPL.
> 
> --
> Best wishes,
> Nick Roberts
> 
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: Containers package (Tenet)

[Nick Roberts]

Tenet's going to based on: a design for iterators which I have sent to some
people privately for comment, based on a proposal I made to the ASCL project
two years ago; my proposal for list containers (V6R1), as amended based on
comments by Ted Dennison, Jeff Carter, and others (to whom thanks); a
'common sense' design for sets, lookups (content-addressed arrays, aka
associative arrays); maps (a variation of lookups); a few extra bits and
bobs (under the name "Workbench").

Each container will come in bounded and unbounded forms. Tenet is not going
to have user-defined memory management (storage pools); users who need this
level of control and sophistication can use Booch. The only concurrent
containers Tenet will provide are queues and bags; the other containers will
be suitable for having concurrency control wrapped around them.

I'll supply a sample implementation of the whole library, but this will
(initially) be aimed more at debugging than efficiency. I'll try to make the
documentation fairly good.

These are the things I need as a utility base for AdaOS, so that will
provide any bias for their design. Other than that, I intend the design to
be as general-purpose as possible.

--
Best,
Nick Roberts

Re: Containers package

[Ted Dennison]

In article <a0p1lr$mbi89$1@ID-25716.news.dfncis.de>, Nick Roberts says...
>write a book). I am going to release it under the LGPL.

The LGPL isn't really all that appropriate to Ada packages. For one thing, it
could be (and has been) argued that instantiation of a generic's code is
inclusion and not simple linking against a library, and thus any user would have
to GPL their code. For another, it actually requires that you provide all
end-users with compilers and any other tools they might need to recompile the
library and relink the program when a new version of the library comes out.

For situations where your code gets copied directly into someone else's object
files (and you don't want that to render their code GPL only), it is generally
suggested that you use something like the license used for Bison (GNU's YACC
clone). See http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF for a
discussion. Gnat's GMGPL is a license of this ilk.

The LGPL was written for link libraries (eg: "libfoo.a"). It isn't very useful
outside that domain.

---
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: Containers package

[Nick Roberts]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:72cY7.642$wp1.383@www.newsranger.com...

> In article <a0p1lr$mbi89$1@ID-25716.news.dfncis.de>, Nick Roberts says...
> >write a book). I am going to release it under the LGPL.
>
> The LGPL isn't really all that appropriate to Ada packages. For one thing,
it
> could be (and has been) argued that instantiation of a generic's code is
> inclusion and not simple linking against a library, and thus any user
would have
> to GPL their code.

I will put a special clause in a comment in source files countering this
problem.

> For another, it actually requires that you provide all
> end-users with compilers and any other tools they might need to recompile
the
> library and relink the program when a new version of the library comes
out.

I assume this idea is based on a skim of the licence (section 6?). In fact,
no such condition is imposed on anyone, except under certain very specific
circumstances (described in section 6). Furthermore, as I am the
copyrightholder, the notion that my own licence prevents me from doing
something is a wee bit silly: do you think I would sue myself for breach of
my own licence?

> For situations where your code gets copied directly into someone else's
object
> files (and you don't want that to render their code GPL only), it is
generally
> suggested that you use something like the license used for Bison (GNU's
YACC
> clone). See http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF
for a
> discussion. Gnat's GMGPL is a license of this ilk.
>
> The LGPL was written for link libraries (eg: "libfoo.a"). It isn't very
useful
> outside that domain.

See above.

--
Happy New Year,
Nick Roberts

Re: Containers package

[Ted Dennison]

In article <a0tgto$n9kha$2@ID-25716.news.dfncis.de>, Nick Roberts says...
>
>circumstances (described in section 6). Furthermore, as I am the
>copyrightholder, the notion that my own licence prevents me from doing
>something is a wee bit silly: do you think I would sue myself for breach of
>my own licence?

Of course not. Licenses are only applicable when software is distributed, and
then only to the parties to whom it is distributed.

---
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: Future with Ada

[Harri J Haataja]

Michal Nowak wrote:
>On 01-12-18 at 11:41 Marin David Condic wrote:
>
>>Many individual programmers are reluctant to learn or use Ada because they
>>don't see a job future in it. They see thousands of ads for jobs using
>>other
>>languages and few ads for Ada positions. If they saw more companies using
>>Ada, they might be encouraged to want to earn a living that way.
>
>There are beginners, who would like to write in Ada. There are posts to
>the group like "I'm new to Ada, I found it great, I want to learn more".
<snip>
>Maybe the point is in convincing the managers to Ada. The experience
>must come from somewhere. From little projects. So if it comes from
>somehere it means that there must be employement for inexperienced
>programmers. So if there comes to hire inexperienced programmer, why
<snip>

I believe there would be a way to sneak into somewhere and if not, at
least get a larger bulk of programmers by providing a better way for
"hobbyists" to get in.

As a complete newbie, I can say that after Lovelace, there's not much to
go to. There's a huge step before you can start getting something useful
done.

Contrasting perl, you can get going with a commandline (mostly replacing
sed and awk) and then a few lines etc. Extremely well aimed and useful
single programs. It's an easy language to get into, though it's not a
clean language. Stull you see it used for pretty big things because most
other languages are a major pain.
Also going GUI or especially DBI is amazingly easy and above all,
there's simple tutorials *that get something done* and you can expand
from that.
To avoid a DSW or holy war, let me say perl was an example only because
it has an extremely even and low curve; results often reflect this,
though.

That's just a personal view I've gotten (or a slice of, anyway).

-- 
If xawtv dumps core, you can fix this with "ulimit -c 0".

Re: Future with Ada

[Michael Card]

Hey CLA-

RE: Richard's & Ben's comments about a shortage of ada programmers:

In article <3C0924D6.2B5A3087@adaworks.com>, Richard Riehle
<richard@adaworks.com> wrote:

> "ben@NO_SPAM_EMAIL" wrote:
> 
> > That is funny. It is almost impossible to find any Ada wanted ads these
> > days.
> > Actually there are more openings for almost any other language than for Ada.
> >
> > Can you point to ONE commerical Ada opening right now that requires no
> > active security clearance in the US? I bet you there is none.
> 
> Over and over, we encounter companies who, after deciding to use Ada for
> its technological advantages, cannot hire qualified Ada programmers.  Our
> most recent experience was a company in Silicon Valley.  They were excited
> about using Ada, asked us to train some of the people, and then tried to hire
> more programmers to do Ada.   They found it nearly impossible to find
> people with experience in their domain,  sufficient mathematics, and lots
> of experience in Ada.   Sadly, they finally decided to use C++ because it
> was so much easier to find programmers.

I was wondering why it is perceived as undesirable to train new
programmers in Ada? Certainly hiring an experienced S/W engineer who
has only done C++ or Java, for example, would not require a significant
additional investment to train them in Ada? If teh language really
offers benefits, wouldn't those benefits more than offset the
relatively small cost of buying 2-3 weeks of intense Ada training for
the programmers?

- Mike

Re: Future with Ada

[Jim Rogers]

Michael Card wrote:

> I was wondering why it is perceived as undesirable to train new
> programmers in Ada? Certainly hiring an experienced S/W engineer who
> has only done C++ or Java, for example, would not require a significant
> additional investment to train them in Ada? If teh language really
> offers benefits, wouldn't those benefits more than offset the
> relatively small cost of buying 2-3 weeks of intense Ada training for
> the programmers?


I agree. I have found good C++ programmers to be trainable.
I watched one pick up the basics of Ada in about 2 weeks with the
help of "Ada as a Second Language". He was using the Aonix
compiler and wanted to use the latest Visual Studio for his IDE.
No problem. He simply customized Visual Studio and proceded to
happily program in Ada. He was amused to discover that the Aonix
compiler worked better with the Microsoft debugger than did
Visual C++. He found he was able to display more detailed information
about arrays when using Aonix.

Jim Rogers

Re: Future with Ada

[Adrian Hoe]

Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3C7B0B13.3080003@worldnet.att.net>...
> Michael Card wrote:
> 
> > I was wondering why it is perceived as undesirable to train new
> > programmers in Ada? Certainly hiring an experienced S/W engineer who
> > has only done C++ or Java, for example, would not require a significant
> > additional investment to train them in Ada? If teh language really
> > offers benefits, wouldn't those benefits more than offset the
> > relatively small cost of buying 2-3 weeks of intense Ada training for
> > the programmers?
> 
> 
> I agree. I have found good C++ programmers to be trainable.
> I watched one pick up the basics of Ada in about 2 weeks with the
> help of "Ada as a Second Language". He was using the Aonix
> compiler and wanted to use the latest Visual Studio for his IDE.
> No problem. He simply customized Visual Studio and proceded to
> happily program in Ada. He was amused to discover that the Aonix
> compiler worked better with the Microsoft debugger than did
> Visual C++. He found he was able to display more detailed information
> about arrays when using Aonix.
> 
> Jim Rogers


One of my colleague holds the record of 8 days to pick up the basics of Ada. :)

Re: Future with Ada

[Adrian Hoe]

Michael Card <thehouseofcards@remove.this.part.mac.com> wrote in message news:<250220022121494455%thehouseofcards@remove.this.part.mac.com>...
> Hey CLA-
> 
> RE: Richard's & Ben's comments about a shortage of ada programmers:
> 
> In article <3C0924D6.2B5A3087@adaworks.com>, Richard Riehle
> <richard@adaworks.com> wrote:
> 
> > "ben@NO_SPAM_EMAIL" wrote:
> > 
> > > That is funny. It is almost impossible to find any Ada wanted ads these
> > > days.
> > > Actually there are more openings for almost any other language than for Ada.
> > >
> > > Can you point to ONE commerical Ada opening right now that requires no
> > > active security clearance in the US? I bet you there is none.
> > 
> > Over and over, we encounter companies who, after deciding to use Ada for
> > its technological advantages, cannot hire qualified Ada programmers.  Our
> > most recent experience was a company in Silicon Valley.  They were excited
> > about using Ada, asked us to train some of the people, and then tried to hire
> > more programmers to do Ada.   They found it nearly impossible to find
> > people with experience in their domain,  sufficient mathematics, and lots
> > of experience in Ada.   Sadly, they finally decided to use C++ because it
> > was so much easier to find programmers.
> 
> I was wondering why it is perceived as undesirable to train new
> programmers in Ada? Certainly hiring an experienced S/W engineer who
> has only done C++ or Java, for example, would not require a significant
> additional investment to train them in Ada? If teh language really
> offers benefits, wouldn't those benefits more than offset the
> relatively small cost of buying 2-3 weeks of intense Ada training for
> the programmers?
> 
> - Mike


According to my experience in introducing Ada in my region, the most
common factors are the incompetency of the managers to evaluate the
software technology and lacking the guts to transition to something
they less frequently heard of.

ANother influential factor is market trend. Again, the above leads to
fearing not compliant to latest market trend.

                              -- Adrian Hoe
                              -- http://greenlime.com/users/adrian.hoe

Re: Future with Ada

[Warren W. Gay VE3WWG]

Jim Rogers wrote:

> Michael Card wrote:
>> I was wondering why it is perceived as undesirable to train new
>> programmers in Ada? Certainly hiring an experienced S/W engineer who
>> has only done C++ or Java, for example, would not require a significant
>> additional investment to train them in Ada? If teh language really
>> offers benefits, wouldn't those benefits more than offset the
>> relatively small cost of buying 2-3 weeks of intense Ada training for
>> the programmers?
> 
> I agree. I have found good C++ programmers to be trainable.
> I watched one pick up the basics of Ada in about 2 weeks with the
> help of "Ada as a Second Language". ...


While I can only speak about my own experience here (ie. learning
Ada95), I would suggest that picking up the language in about 2 weeks
is about right.. but...

I found it took a while longer before I could properly
design applications from scratch in Ada95. This is because the
entire framework is considerably different than C/C++ from a
number of viewpoints, most notably from a visibility point of
view, not to mention standard packages et. al.

Ada's package design, its restrictions on visibility etc., can
lead to a lot of head-scratching to a C/C++ designer.
In C/C++ I was always able to obtain pointers to something,
declare a new friend function, whatever. Ada requires you to
more carefully think about all these relationships before hand,
or you wind up moving/rewriting parts of your application
later as you get those "you can't get there from here" messages
from your favourite Ada compiler.

In this regard, I think somewhere between 3 months to a year
is required in order to gain the sufficient level of experience
to get it nearly right the first time. Even then, I believe
that the new Ada programmer still gets burned on what can
and cannot be done (in a given way) with generics for example.

The language is large enough that it takes time to gain enough
experience with all of these elements. For example, just the
"use" clause is hotly debated as to how and when
it should be used. I am still tinkering with how I want to
use "use", even though some advise against using it at all.
A new user of it is likely to abuse it, only to learn from
that lesson later on. ;-)

So while I agree that an experienced programmer can quickly
embrace Ada and *maintain* existing code, I do believe you
want someone with a bit more experience if he is designing
major subsystems from scratch. Otherwise, you'll have to
allow time for that programmer more time to learn from
his mistakes ;-)

Just my $0.02 worth.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Future with Ada

[Ken Pinard]

I still find it amazing that Companies feel that they are trapped into using
a language because of "Trained" available programmers.  Companies want Ada
because of what it offers, but never want to train individuals on how to use
it. If companies actually compare costs, it is cheaper to train programmers
to use Ada.

The Boeing 777 aircraft was developed using Ada. It was done in half the
time with only an 1/8 of the problems of any previous commercial jet
aircraft. Boeing then decided that Ada was to expensive. The next project my
company worked on was in C++. After its completion, Boeing realized their
mistake (it had just as many problems as the original C code). They
commissioned our company to redo the software in Ada from the 777 source
code. Well, it was cheaper and most important it worked.

As another note, I was slated for the 777 upgrade after leaving the company.
I never got the job. It seems that it took 1/2 of the expected number of
programmers to do the upgrade in Ada then other projects with similiar
demands. It was also done in a fraction of the expected time.   There are
still people at Boeing that believe Ada is too expensive and takes longer.

There is still Ada work from the Boeing subcontractors. Finding them is the
fun part.

Just my 2cents worth

Ken Pinard

"Michael Card" <thehouseofcards@remove.this.part.mac.com> wrote in message
news:250220022121494455%thehouseofcards@remove.this.part.mac.com...
> Hey CLA-
>
> RE: Richard's & Ben's comments about a shortage of ada programmers:
>
> In article <3C0924D6.2B5A3087@adaworks.com>, Richard Riehle
> <richard@adaworks.com> wrote:
>
> > "ben@NO_SPAM_EMAIL" wrote:
> >
> > > That is funny. It is almost impossible to find any Ada wanted ads
these
> > > days.
> > > Actually there are more openings for almost any other language than
for Ada.
> > >
> > > Can you point to ONE commerical Ada opening right now that requires no
> > > active security clearance in the US? I bet you there is none.
> >
> > Over and over, we encounter companies who, after deciding to use Ada for
> > its technological advantages, cannot hire qualified Ada programmers.
Our
> > most recent experience was a company in Silicon Valley.  They were
excited
> > about using Ada, asked us to train some of the people, and then tried to
hire
> > more programmers to do Ada.   They found it nearly impossible to find
> > people with experience in their domain,  sufficient mathematics, and
lots
> > of experience in Ada.   Sadly, they finally decided to use C++ because
it
> > was so much easier to find programmers.
>
> I was wondering why it is perceived as undesirable to train new
> programmers in Ada? Certainly hiring an experienced S/W engineer who
> has only done C++ or Java, for example, would not require a significant
> additional investment to train them in Ada? If teh language really
> offers benefits, wouldn't those benefits more than offset the
> relatively small cost of buying 2-3 weeks of intense Ada training for
> the programmers?
>
> - Mike

Re: Future with Ada

[Richard Riehle]

"Warren W. Gay VE3WWG" wrote:

> Jim Rogers wrote:
>
> > Michael Card wrote:
> >> I was wondering why it is perceived as undesirable to train new
> >> programmers in Ada? Certainly hiring an experienced S/W engineer who
> >> has only done C++ or Java, for example, would not require a significant
> >> additional investment to train them in Ada? If teh language really
> >> offers benefits, wouldn't those benefits more than offset the
> >> relatively small cost of buying 2-3 weeks of intense Ada training for
> >> the programmers?
> >
> > I agree. I have found good C++ programmers to be trainable.
> > I watched one pick up the basics of Ada in about 2 weeks with the
> > help of "Ada as a Second Language". ...
>
> So while I agree that an experienced programmer can quickly
> embrace Ada and *maintain* existing code, I do believe you
> want someone with a bit more experience if he is designing
> major subsystems from scratch. Otherwise, you'll have to
> allow time for that programmer more time to learn from
> his mistakes ;-)

This goes to the heart of one of Ada's benefits, not one of its
liabilities.   In C/C++ a programmer can write code that
compiles and seems just fine until one day it explodes
quite unexpectedly.     Also,  "The Devil is in the details,"
to coin an completely new an wonderful expression.  :)

At first, it seems so easy to create C++ code.  Then, as one
gets deeper and deeper into the process,  "The Devil"
begins to emerge from the Hades populated by "friends,"
copy constructors, destructors, unhappy pointers, and the
host of other little creatures of that realm.

This is not to say that C++ is inherently evil.   The really
experienced C++ programmer can easily tame this collection
of Mephistophelian gargoyles, but the new C++ programmer
can be easily led astray.    The same is true with a new Ada
programmer.  We simply do not want newbies doing the
critical design in a brand-new language regardless of how
good that language might be.

The benefit of Ada is that newbies are prevented, due to the
Draconian constraints of the language, from making the same
number of mistakes they might make as a newbie in C++.
However, it would be foolish to believe they cannot make
mistakes of the same magnitude simply because of those
constraints.

I believe that, in the long run, Ada is a better language, but
newcomers to any language need a lot of adult supervision.

Richard Riehle

Re: Future with Ada

[Michal Nowak]

On 2002-02-27 at 17:51 Warren W. Gay VE3WWG wrote:

>While I can only speak about my own experience here (ie. learning
>Ada95), I would suggest that picking up the language in about 2 weeks
>is about right.. but...
>
>I found it took a while longer before I could properly
>design applications from scratch in Ada95. This is because the
>entire framework is considerably different than C/C++ from a
>number of viewpoints, most notably from a visibility point of
>view, not to mention standard packages et. al.

[cut the rest]

I fully agree with you. I had similiar experiences when I started
Ada (although to pick up the basics I had several hours - just one
lecture - which was in fact enough (but I really mean the basics)).

Paradoxically learning Ada came much easier to me than for example Java.
I think, that was because there is so much difference between Ada and C++.
This maybe similiar to comparing colours - it is harder to distinguish
white and yellow than white and blue (for example). Java has differrent
concept than C++, but uses C++ notation, what (I suppose) made me often
confused. It also caused, that I wrote C++ like code in Java, what rather
hasn't good effects ;-) (not to mention mixing C nad C++)

Another issue when learning a programming language is if the learner
likes it. Maybe that is why learning Ada came rather easily to me.
Even if language is hard to learn and somebody likes it, he will
learn it easily, he will not learn it properly, no matter how easy the
language is, if he dislikes it. Some of my university colleagues did 
not wanted to learn  another, a bit different language, that they already
knew. No matter how good features Ada has to offer, it seemed  impossible
to convince them to learn Ada. "Ada is bad, I don't like it" - and that
was all I heard. In this cases, even if they had a whole year to spent, it
won't have any positive results.

Just my remarks,
Mike

Re: Future with Ada

[Hyman Rosen]

Michal Nowak wrote:
> Another issue when learning a programming language is if the learner
> likes it. Maybe that is why learning Ada came rather easily to me.

I know I have a visceral dislike for the Pascal-style languages.
Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
way when I look at them. It's hard for me to appreciate that Ada
is intended to be reader-friendly when my brain is going "yuck"
whenever I look at some code.

Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
thing :-)

Re: Future with Ada

[Ed Falis]

Hyman Rosen wrote:
> Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
> thing :-)
> 


Nah, I'm an American who prefers the Pascal style over the C style syntax.

- Ed

Re: Future with Ada

[Warren W. Gay VE3WWG]

Richard Riehle wrote:

> "Warren W. Gay VE3WWG" wrote:
>>Jim Rogers wrote:
>>>Michael Card wrote:
>>>
>>>>I was wondering why it is perceived as undesirable to train new
>>>>programmers in Ada? Certainly hiring an experienced S/W engineer who
>>>>has only done C++ or Java, for example, would not require a significant
>>>>additional investment to train them in Ada? If teh language really
>>>>offers benefits, wouldn't those benefits more than offset the
>>>>relatively small cost of buying 2-3 weeks of intense Ada training for
>>>>the programmers?
>>>>
>>>I agree. I have found good C++ programmers to be trainable.
>>>I watched one pick up the basics of Ada in about 2 weeks with the
>>>help of "Ada as a Second Language". ...
>>>
>>So while I agree that an experienced programmer can quickly
>>embrace Ada and *maintain* existing code, I do believe you
>>want someone with a bit more experience if he is designing
>>major subsystems from scratch. Otherwise, you'll have to
>>allow time for that programmer more time to learn from
>>his mistakes ;-)
>>
> 
> This goes to the heart of one of Ada's benefits, not one of its
> liabilities.   ...


Just in case there is any doubt on this issue : I never said
that this was a "disadvantage".  I only said it was a
practical item to take into account.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Future with Ada

[Wes Groleau]

> way when I look at them. It's hard for me to appreciate that Ada
> is intended to be reader-friendly when my brain is going "yuck"

I'm in the western hemisphere.  It's easy for me
to appreciate the readability of Ada when I look
at samples of one of those languages that has the
love affair with punctuation marks.

:-)

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

Re: Future with Ada

[Adrian Hoe]

Ed Falis <efalis@attbi.com> wrote in message news:<3C7E84BA.3040604@attbi.com>...
> Hyman Rosen wrote:
> > Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
> > thing :-)
> > 
> 
> 
> Nah, I'm an American who prefers the Pascal style over the C style syntax.
> 
> - Ed


Pascal was my first structural programming language I learned. Then
FORTRAN, COBOL, C/C++ than Ada. Before Pascal, I was on Apple BASIC.

It was Pascal, I think, that allows me to appreciate Ada more than
others. :)

                             -- Adrian Hoe
                             -- http://AdrianHoe.com

Re: Future with Ada

[Richard Riehle]

Hyman Rosen wrote:

> Michal Nowak wrote:
> > Another issue when learning a programming language is if the learner
> > likes it. Maybe that is why learning Ada came rather easily to me.
>
> I know I have a visceral dislike for the Pascal-style languages.
> Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
> way when I look at them. It's hard for me to appreciate that Ada
> is intended to be reader-friendly when my brain is going "yuck"
> whenever I look at some code.
>
> Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
> thing :-)

There is a credible rumor that the we are on the verge of a world-wide
shortage of curly braces.    When we exhaust the remaining supply,
everyone will have to switch to some language not in the C family.  :-)

Richard Riehle

Re: Future with Ada

[Dave Poirier]

Richard Riehle wrote:
> Hyman Rosen wrote:
> 
> 
>>Michal Nowak wrote:
>>
>>>Another issue when learning a programming language is if the learner
>>>likes it. Maybe that is why learning Ada came rather easily to me.
>>>
>>I know I have a visceral dislike for the Pascal-style languages.
>>Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
>>way when I look at them. It's hard for me to appreciate that Ada
>>is intended to be reader-friendly when my brain is going "yuck"
>>whenever I look at some code.
>>
>>Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
>>thing :-)
>>
> 
> There is a credible rumor that the we are on the verge of a world-wide
> shortage of curly braces.    When we exhaust the remaining supply,
> everyone will have to switch to some language not in the C family.  :-)
> 
> Richard Riehle

Yay! I'll be able to get back programming in Assembly ! ;)

EKS - Dave Poirier

Re: Future with Ada

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:

: Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
: thing :-)

Stroustrup beeing from Denmark...
(And the roumor(?) that C++ is because there was no
Simula compiler around?)


- georg

Re: Future with Ada

[Michal Nowak]

On 2002-02-28 at 21:18 Richard Riehle wrote:

>Hyman Rosen wrote:
>
>> Michal Nowak wrote:
>> > Another issue when learning a programming language is if the learner
>> > likes it. Maybe that is why learning Ada came rather easily to me.
>>
>> I know I have a visceral dislike for the Pascal-style languages.
>> Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
>> way when I look at them. It's hard for me to appreciate that Ada
>> is intended to be reader-friendly when my brain is going "yuck"
>> whenever I look at some code.
>>
>> Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
>> thing :-)
>
>There is a credible rumor that the we are on the verge of a world-wide
>shortage of curly braces.    When we exhaust the remaining supply,
>everyone will have to switch to some language not in the C family.  :-)

Assuming, that nobody builds a factory of this resource :-)

-Mike,

Re: Future with Ada

[Michal Nowak]

On 2002-02-28 at 13:53 Hyman Rosen wrote:

>Michal Nowak wrote:
>> Another issue when learning a programming language is if the learner
>> likes it. Maybe that is why learning Ada came rather easily to me.
>
>I know I have a visceral dislike for the Pascal-style languages.
>Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
>way when I look at them. It's hard for me to appreciate that Ada
>is intended to be reader-friendly when my brain is going "yuck"
>whenever I look at some code.
>
>Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
>thing :-)

Yea, I see the smiley, but there must be something in this 
"begin ... end" vs "{ ... }" conflict. Sometimes some colleagues
of mine are telling me, that Ada is Pascal after mutation and
they don't like to look at such code (just like you). Hmm, Pascal was
first language I learnt (I their case that was C), so maybe that's the
reason. Although I am a bit like a sine, when I started doing C (and 
completly abondoned Pascal for 4 years). Now I'am back from "{ ... }" 
land, again in "begin ... end" style, and ... I think I like it more.

Mikeh

Re: Future with Ada

[Jeffrey Carter]

Hyman Rosen wrote:
> 
> I know I have a visceral dislike for the Pascal-style languages.
> Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
> way when I look at them. It's hard for me to appreciate that Ada
> is intended to be reader-friendly when my brain is going "yuck"
> whenever I look at some code.
> 
> Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
> thing :-)

No, it's primarily the difference between coders and software engineers.

-- 
Jeffrey Carter

Re: Future with Ada

[Pascal Obry]

byhoe@greenlime.com (Adrian Hoe) writes:

> Pascal was my first structural programming language I learned. Then
> FORTRAN, COBOL, C/C++ than Ada. Before Pascal, I was on Apple BASIC.

Interresting, I have the exact same programing language background (I mean in
the very same order) :) Just that at the same time I learned Pascal I was also
building my first full text editor in z80 on an Amstrad 6128.

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: Future with Ada

[Adrian Hoe]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uk7swi2ds.fsf@wanadoo.fr>...
> byhoe@greenlime.com (Adrian Hoe) writes:
> 
> > Pascal was my first structural programming language I learned. Then
> > FORTRAN, COBOL, C/C++ than Ada. Before Pascal, I was on Apple BASIC.
> 
> Interresting, I have the exact same programing language background (I mean in
> the very same order) :) Just that at the same time I learned Pascal I was also
> building my first full text editor in z80 on an Amstrad 6128.
> 
> Pascal.

Hummm...

I wrote an extension to Apple DOS using UCSD Pascal. This extension
speeds up the booting process of Apple DOS. Too bad I did not sell it
to Apple! (Otherwise, I could be richer now :) What an innocent
(naive?) boy I was then?

I got a chance to look at Ada on in Z80 on Apple but never learned it.
There was no Internet at that time and could not find Ada books.

                                       -- Adrian Hoe
                                       -- http://adrianhoe.com

Re: Future with Ada

[Hyman Rosen]

Jeffrey Carter wrote:
> No, it's primarily the difference between coders and software engineers.

You mean because software engineers value conciseness and economy
of expression, they prefer braces, while coders, who get paid by
the line, prefer the wordier languages and begin/end?

Re: Future with Ada

[Hyman Rosen]

Georg Bauhaus wrote:
> Hyman Rosen <hyrosen@mail.com> wrote:
> 
> : Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
> : thing :-)
> 
> Stroustrup beeing from Denmark...

And doesn't it show, given the botch-up that is C++ syntax?
Clearly he is a begin-end guy who was forced into braces by
his employer and the fact that he was extending C! :-) :-)

Re: Future with Ada

[Larry Kilgallen]

In article <3C81DF1F.9000503@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Jeffrey Carter wrote:
>> No, it's primarily the difference between coders and software engineers.
> 
> You mean because software engineers value conciseness and economy
> of expression, they prefer braces, while coders, who get paid by
> the line, prefer the wordier languages and begin/end?

We seem to have more communications problems, as I don't think that
was what Jeffrey Carter meant at all :-)

Re: Future with Ada

[Chad R. Meiners]

Ah, there is that evil word, "concise".  Often thought of as a holy
objective by computer scientist and mathematician alike.  The danger here is
that people often equate conciseness with clarity.  This of course is an
incorrect assumption.  Concise expressions, theorems, definitions, etc are
valued since because they allow you to refresh your memory quickly.  The
problem is that they do not make good teaching material without the
accompaniment of an introduction and explanation.  The "curly braced
languages are concise hence better" argument is malformed at best and
perverse at worst since  the mathematical symbols curly braced languages
adopted are meant for a completely different type of communication.

I know you most likely meant to include a smiley in your statement, Hyman,
but if you didn't perhaps the above will establish why many have preferences
opposite of yours.

-CRM

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C81DF1F.9000503@mail.com...
> Jeffrey Carter wrote:
> > No, it's primarily the difference between coders and software engineers.
>
> You mean because software engineers value conciseness and economy
> of expression, they prefer braces, while coders, who get paid by
> the line, prefer the wordier languages and begin/end?
>

Re: Future with Ada

[Eric Merritt]

--- Hyman Rosen <hyrosen@mail.com> wrote:
> Jeffrey Carter wrote:
> > No, it's primarily the difference between coders
> and software engineers.
> 
> You mean because software engineers value
> conciseness and economy
> of expression, they prefer braces, while coders, who
> get paid by
> the line, prefer the wordier languages and
> begin/end?
> 
 I believe you have this backwards (although I
understand the sarcasm). In any case, on with my rant.
No self respecting person who values his work would
prefer quick coding times and clever statements to
maintainability and readability. In my opinion you can
usually tell the cube monkeys from the craftsmen by
spending a few minutes looking at their code. The less
readably their code (in any language not just Ada) and
the more often 'clever' occur the more likely it is
that they are cube monkeys.

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Future with Ada

[Hyman Rosen]

Eric Merritt wrote:
> The less readably their code (in any language not just Ada)
 > and the more often 'clever' occur the more likely it is that
 > they are cube monkeys.

To continue torturing analogies, you can build housing projects
or you can build skyscrapers. Any one who looks at a housing
project can immediately discern its purpose. With only a little
bit of counting, they can probably calculate how many units the
project holds. And after a while, they become unbearable to look
at and to live in. Compare it to modern steel and glass skyscrapers
with their enormous atriums and surprising and playful architectures.

Re: Future with Ada

[Eric Merritt]

> 
> To continue torturing analogies, you can build
> housing projects
> or you can build skyscrapers. Any one who looks at a
> housing
> project can immediately discern its purpose. With
> only a little
> bit of counting, they can probably calculate how
> many units the
> project holds. And after a while, they become
> unbearable to look
> at and to live in. Compare it to modern steel and
> glass skyscrapers
> with their enormous atriums and surprising and
> playful architectures.

Mr. Rosen, I would have to say that this analogy is
completely unfit for the purpose you have put it.
Software and buildings generally have very little in
common. In this particular instance they have nothing
in common. I think the main reason this analogy was
chosen was because it supports your position. This is
kind of like me saying software is like the two faces
of the sky, 'my software' is pretty and blue and 'your
software' is ugly and black. Because the analogy has
not correlation to this particular case of reality
there are no conclusions you can draw beyond the fact
that I like a certain type of software.

I would have to ask, have you been a contractor for
your entire career (I mean no detriment by that
comment, I have been one at times in the past). It has
been my experience that most contracts spend quit a
bit of time designing their a program, at times
implementing it but never ever maintaining it. The
other possibility is that you have never worked on
project with a team of individuals (talented or
otherwise). I really cant accept the other possibility
that you are a new programmer with only a few months
under your belt. I all truth I mean no disrespect, I
just cannot fathom an experienced programmer who feels
maintainability has no value.

 Regardless of language I have never known a
programmer worth his salt that decried
maintainability. If a project has any life beyond a
few weeks or months, maintainability becomes not only
a huge cost concern but also, if the original
programmers followed your logic, a huge pain for the
programmers themselves.
 

 


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Future with Ada

[Hyman Rosen]

Eric Merritt wrote:
> Mr. Rosen, I would have to say that this analogy is
> completely unfit for the purpose you have put it.

Yes, I know. I was doing it deliberately in response
to that crack about coders and software engineers.

> I would have to ask, have you been a contractor for
> your entire career

Never.

> The other possibility is that you have never worked on
> project with a team of individuals (talented or
> otherwise). I really cant accept the other possibility
> that you are a new programmer with only a few months
> under your belt. I all truth I mean no disrespect, I
> just cannot fathom an experienced programmer who feels
> maintainability has no value.

I have been working as a programmer since 1983, always in
teams. I was at my previous job for eleven years, taking
the same code base (in C) from a terminal-based system to
GUIs using Windows and Motif, Java, and the web, so I certainly
understand the need for maintainability. I fail to see where
I have said that maintainability has no value.

Perhaps you are confusing mainatinability with verbosity and
lack of punctuation?

Re: Future with Ada

[Hyman Rosen]

Chad R. Meiners wrote:
> The problem is that they do not make good teaching material without the
> accompaniment of an introduction and explanation.

I find it difficult to believe that { } needs an introduction and
explanation that begin/end or if/end do not. On the other hand,
braces are light and airy and nicely set off and separate pieces
of program text which are more wordy, guiding the eye towards seeing
the structure of the code.

It's a religious issue, and a matter of taste. How many times, after
all, has this topic been discussed in the past?

Re: Future with Ada

[Jean-Pierre Rosen]

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


"Eric Merritt" <cyberlync@yahoo.com> a �crit dans le message news: > Mr. Rosen, I would have to say that this analogy is
> completely unfit for the purpose you have put it.
> Software and buildings generally have very little in
> common. [...]
Please note that "Rosen" is an overloaded name, and that full dot notation should be used, i.e. Hyman.Rosen or Jean-Pierre.Rosen.
Especially since I generally do not agree with the  positions of my homonym ;-)

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Future with Ada

[Hyman Rosen]

Jean-Pierre Rosen wrote:
> Especially since I generally do not agree with the  positions of my homonym ;-)

Since you are the author of the "Rosen Trick" which allows
functions to modify their limited in parameters, perhaps we
are not so far apart in spirit :-)

Re: Future with Ada

[Eric Merritt]

> Perhaps you are confusing mainatinability with
> verbosity and
> lack of punctuation?

 I wouldnt say I was confusing the two, i would say
that in many instances they are one and the same
(verbosity and maintainability). Of course, there are
exreame examples, verbosity is not and end unto
itself. In every case that I have come across,
attempts at tersness always lead to code that is more
difficult to understand. I believe that this is largly
becuase diffrent programmers think in diffrent ways.
What might be terse but understandable to you is
simply terse and confusing to others.

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Future with Ada

[Eric Merritt]

> Please note that "Rosen" is an overloaded name, and
> that full dot notation should be used, i.e.
> Hyman.Rosen or Jean-Pierre.Rosen.
> Especially since I generally do not agree with the 
> positions of my homonym ;-)

I will be more specific in my future rants :)

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Future with Ada

[Chad R. Meiners]

The problem is you are addressing each symbol independently from the
language as a whole.  For example, which of the following looks more
incorrect (barring some syntax adjustments).

if (x == y) {
   cout << "We can use either.";
   z = 2 * x; }

-or-

if (x ==y ) begin
   cout << "We can use either.";
   z = 2 * x; end

The second looks much worse than the first, and note that neither is
accomplishing its objective of highlighting the if's block.  In the first
example, though, the {}'s almost disappear while the begin and end's scream
that they are being misused.

I wasn't trying to claim that every feature of a curly braced language needs
an introduction and explanation.  I was stating that 'concise' statements
such as

x = z << w = t ? x : y;

need an introduction and an explanation.  Thus, the curly braced languages'
'conciseness' which is so often a flagship of their religious propaganda of
superiority appears to be a liability instead of an asset.

I don't think either of us really wants to start a religious discussion on
either of the types of languages, but I do think the differences and goals
of the two languages can be compared reasonably.

-CRM

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C83A112.6080302@mail.com...
> Chad R. Meiners wrote:
> > The problem is that they do not make good teaching material without the
> > accompaniment of an introduction and explanation.
>
> I find it difficult to believe that { } needs an introduction and
> explanation that begin/end or if/end do not. On the other hand,
> braces are light and airy and nicely set off and separate pieces
> of program text which are more wordy, guiding the eye towards seeing
> the structure of the code.
>
> It's a religious issue, and a matter of taste. How many times, after
> all, has this topic been discussed in the past?
>

Re: Future with Ada

[Jeffrey Carter]

Hyman Rosen wrote:
> 
> Jeffrey Carter wrote:
> > No, it's primarily the difference between coders and software engineers.
> 
> You mean because software engineers value conciseness and economy
> of expression, they prefer braces, while coders, who get paid by
> the line, prefer the wordier languages and begin/end?

It's nice to be able to recognize sarcasm without emoticons.
-- 
Jeffrey Carter

Re: Future with Ada

[Richard Riehle]

Hyman Rosen wrote:

> Chad R. Meiners wrote:
> > The problem is that they do not make good teaching material without the
> > accompaniment of an introduction and explanation.
>
> I find it difficult to believe that { } needs an introduction and
> explanation that begin/end or if/end do not. On the other hand,
> braces are light and airy and nicely set off and separate pieces
> of program text which are more wordy, guiding the eye towards seeing
> the structure of the code.
>
> It's a religious issue, and a matter of taste. How many times, after
> all, has this topic been discussed in the past?

Actually, curly braces would not be so bad if the C/C++/Java compilers
were able to detect a name at the end of them.   For example,

                  LabelName:       {

                                                    source code

                                           } LabelName

One reason I prefer Ada to the C family of languages is that the compiler
allows me to document my code blocks with names and actually checks
that the block I started corresponds to the name with which I ended it. Of
course, this is probably a religious issue and has very little to recommend
it
as a model for self-documenting code.

Richard Riehle

Re: Future with Ada

[Brian Rogoff]

On Mon, 4 Mar 2002, Hyman Rosen wrote:
> Chad R. Meiners wrote:
> > The problem is that they do not make good teaching material without the
> > accompaniment of an introduction and explanation.
>
> I find it difficult to believe that { } needs an introduction and
> explanation that begin/end or if/end do not. On the other hand,
> braces are light and airy and nicely set off and separate pieces
> of program text which are more wordy, guiding the eye towards seeing
> the structure of the code.

How do you feel about using layout, like ABC, Python, OCCAM, Haskell,
etc.?

> It's a religious issue, and a matter of taste. How many times, after
> all, has this topic been discussed in the past?

Yup. Too many times. The interesting question to me is this: what is the
relationship between verbosity and readability? I don't think that there
is a simple answer. I find Ada readable, but I think that the syntax is
not the most important factor in that opinion.

-- Brian

Re: Future with Ada

[Pascal Obry]

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> Please note that "Rosen" is an overloaded name, and that full dot notation
> should be used, i.e. Hyman.Rosen or Jean-Pierre.Rosen.

Indeed and this is why I do not like use clauses :) Full qualified names are
never ambiguous... Jean-Pierre.Rosen I think to remember that you are ok with
the "use" clause right ? :)

Certainly a good way to start a very long thread... :)

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: Future with Ada

[Warren W. Gay VE3WWG]

Chad R. Meiners wrote:

> The problem is you are addressing each symbol independently from the
> language as a whole.  For example, which of the following looks more
> incorrect (barring some syntax adjustments).
> 
> if (x == y) {
>    cout << "We can use either.";
>    z = 2 * x; }
> 
> -or-
> 
> if (x ==y ) begin
>    cout << "We can use either.";
>    z = 2 * x; end

But if you clean up the if statement, and the formatting, it
becomes much cleaner as :

if x = y then
    whatever...;
else
    stmt...;
end;

And, when you have very loooong blocks, labelling
them helps :

Big_Outer_Loop : while ... loop
    ...
     Some_Inner_Loop : while .... loop
        ...
     end Some_Inner_Loop;
    ...
end Big_Outer_Loop;

With braces, you cannot label the blocks in any way. Hence
people resort to such contrivances as :

if ( x == y ) {
    ...;
} /* if ( x == y ) */

The problem with this, is the compiler cannot read your comment
and tell if the "}" matches up correctly. And if you excuse me
for saying so, but this also looks UGLY.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Future with Ada

[Jean-Pierre Rosen]

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


"Pascal Obry" <p.obry@wanadoo.fr> a �crit dans le message news: u4rjvc5vl.fsf@wanadoo.fr...
> > Please note that "Rosen" is an overloaded name, and that full dot notation
> > should be used, i.e. Hyman.Rosen or Jean-Pierre.Rosen.
>
> Indeed and this is why I do not like use clauses :) Full qualified names are
> never ambiguous... Jean-Pierre.Rosen I think to remember that you are ok with
> the "use" clause right ? :)
Sure, and since I always "use Jean-Pierre" and never "use Hyman", there is no ambiguity...

> Certainly a good way to start a very long thread... :)
Sticking my hands away of the keyboard to resist...

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Future with Ada

[Jacob Sparre Andersen]

Georg Bauhaus wrote:

> Stroustrup beeing from Denmark...

Hey! Don't blame that on us.

Jacob (who is willing to take some of the blame for Turbo
Pascal 4)

:-)

Re: Future with Ada

[Wes Groleau]

> Actually, curly braces would not be so bad if the C/C++/Java compilers
> were able to detect a name at the end of them.   ....
> 
> One reason I prefer Ada to the C family of languages is that the compiler
> allows me to document my code blocks with names and actually checks
> that the block I started corresponds to the name with which I ended it. Of
> course, this is probably a religious issue and has very little to recommend

One minor thing I've always thought odd about Ada is the
inconsistency where some ends require a name, some
forbid it, and some don't care.

Also, some demand a keyword match (end record) and some don't.

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

Re: Future with Ada

[Marin David Condic]

To toss in yet another stink-bomb... :-)

Why not allow the labeling of all structures that have an "end"? You can
name a loop with a label and it helps find which "end" you mean if you've
got nested loops. Same with declare blocks. Why not for "if" statements and
"case" statements? Maybe also records - but the record already has a name
and aren't nested so it would probably look inconsistent.

It probably wouldn't amount to a major syntax change & might be mildly
useful. But not having thought about it thoroughly, there may be issues.
(What would you do if you had lots of "elsif" parts?) Anyway, its just an
idea to think about....

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/


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C853A04.34826F39@despammed.com...
>
> One minor thing I've always thought odd about Ada is the
> inconsistency where some ends require a name, some
> forbid it, and some don't care.
>
> Also, some demand a keyword match (end record) and some don't.
>

Re: Future with Ada

[Dmitry A. Kazakov]

On Tue, 5 Mar 2002 17:04:24 -0500, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

>To toss in yet another stink-bomb... :-)
>
>Why not allow the labeling of all structures that have an "end"? You can
>name a loop with a label and it helps find which "end" you mean if you've
>got nested loops. Same with declare blocks. Why not for "if" statements and
>"case" statements? Maybe also records - but the record already has a name
>and aren't nested so it would probably look inconsistent.

That's easy, just allow nested [anonymous] record types! (:-))

In any case I'd prefer:

type X is record ... end X; which would be perfectly consistent with
the syntax of protected and task types.

>It probably wouldn't amount to a major syntax change & might be mildly
>useful. But not having thought about it thoroughly, there may be issues.
>(What would you do if you had lots of "elsif" parts?) Anyway, its just an
>idea to think about....

Regards,
Dmitry Kazakov

Re: Future with Ada

[Frank J. Lhota]

> Why not for "if" statements and
> "case" statements?

That's not a bad idea, given that Ada programmer frequenly include a comment
at the end of an "if" or "case" statement to indicate which statement is
ending.

Re: Future with Ada

[Marin David Condic]

Well the nice thing is that since it has no semantic meaning, it wouldn't
really impact the compiler in a difficult way if it were added. Since its
pretty much "noise", you would have 100% upward compatibility with existing
code and would just need some parser changes to detect the label & make sure
it matched at the end.

Would it be attractive to be able to do something like:

Outer_Check: if (Some_Boolean) then
    Inner_Check: if (Some_Other_Boolean) then
        Some_Statement ;
    end if Inner_Check ;
end if Outer_Check ;

I suppose it would help when you have really long chunks of code inside the
ifs.

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/

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> wrote in message
news:a64vhv$f90$1@bob.news.rcn.net...
> > Why not for "if" statements and
> > "case" statements?
>
> That's not a bad idea, given that Ada programmer frequenly include a
comment
> at the end of an "if" or "case" statement to indicate which statement is
> ending.
>
>
>

Re: Future with Ada

[Georg Bauhaus]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
: 
: Why not for "if" statements

Hmm, are you suggesting that you feel comfortable with if
statements that span more than say 12 lines and/or are nested
to some unspeakable level of say 3 or more? :-)

- georg

Re: Future with Ada

[Wes Groleau]

> Why not allow the labeling of all structures that have an "end"? You can
> name a loop with a label and it helps find which "end" you mean if you've
> got nested loops. Same with declare blocks. Why not for "if" statements and
> "case" statements? Maybe also records - but the record already has a name
> and aren't nested so it would probably look inconsistent.

I think it's a great idea, and I can't think of any drawbacks.
if, case, select, accept, task, loop, block.
Records, too, only for them, use the record type name.
In places that currently require a reserved word after the
'end,' make it optional and allow the label instead.

Let me go a step further: Some houses have style requirements
to comment 'begin' and 'exception' with the name of the level of scope.
Why not have an optional identifier after 'begin' or 'exception'
which is checked by the compiler.  Same rules as the corresponding
'end.'  Possibly require a colon IF it makes it look better

procedure X is

   -- pages of declarations

begin X:  -- compiler would reject any other name,
          -- thereby proofing nesting level

  [statement]
....

This is a little more complicated than the end issue, because
you would not want to allow

   Label:
      begin Label

but you would want to allow

   Label:
      declare
         -- lots of stuff
      begin Label

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

Re: Future with Ada

[Marin David Condic]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a65gj5$n73$1@a1-hrz.uni-duisburg.de...
> Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
> :
> : Why not for "if" statements
>
> Hmm, are you suggesting that you feel comfortable with if
> statements that span more than say 12 lines and/or are nested
> to some unspeakable level of say 3 or more? :-)
>

Why, "yes". What's your point? :-) Sometimes a big case or if is a perfectly
good way of reflecting what's going on. (Think of lots of "when" or "elsif"
parts, for example.) Things should be made as simple as possible, but no
simpler.

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: Future with Ada

[Georg Bauhaus]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:

:  Sometimes a big case or if is a perfectly
: good way of reflecting what's going on. (Think of lots of "when" or "elsif"
: parts, for example.) Things should be made as simple as possible, but no
: simpler.

yes, sometimes, highest speed dfa in inner loops, say?.
my point was that this need not be reflected in "big" if, in a sense.
With inlined subprograms, tag magic, ... you can do a lot to reduce
the "textual length" of an if or case statement, without much or any
loss in performance. At the expense of increased expressiveness,
sometimes :-)

I'm saying this remembering a 500 lines program consisting of one
procedure, nested ifs and some state variables named state1 etc,
no comment, no layout, produced by a human.
Even at only 500 lines this wasn't exactely a pleasure, and it
turned out that the program worked by accident.

- georg

Re: Future with Ada

[Georg Bauhaus]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
 
: I suppose it would help when you have really long chunks of code inside the
: ifs.

If `end if something' will invite to have long chunks of code inside
the ifs, the idea should be banned. Sometimes Structured Programming
is really convincing. Ada is good at stepwise refinement _not_ using
ifs, but different language facilities.

- georg

Re: Future with Ada

[Marin David Condic]

In theory, this might be a really good idea. "If" statements that span too
many lines (define "too many"?) or nest too deep (again, define "too deep"?)
ought to be avoided. When possible, it should be refined to subprogram calls
or whatever so that it doesn't get "too complicated". :-)

But in practice, there will be times when an "if" statement or "case"
statement is going to get beyond one screen's worth of lines and any attempt
to shorten it up to fit within a screen is going to result in gyrations that
make an unholy mess just to avoid "too many" or "too deep" as defined in
some coding guideline. When an "if" or "case" gets longer than a single
screen or contains within it another "if" or "case" (one level of nesting) I
think it would be useful for any block of code that spans more than a single
screen to have a label identifying what exactly is being ended when you hit
the "end if" or "end case". One wouldn't need to use it if it seemed to be
creating too much clutter, but there *will* be cases where two or three
levels of nesting occur or 40 or 50 lines of code go by & knowing what the
"end" connects with would be handy.

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/

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a683ab$3ls$2@a1-hrz.uni-duisburg.de...
>
> If `end if something' will invite to have long chunks of code inside
> the ifs, the idea should be banned. Sometimes Structured Programming
> is really convincing. Ada is good at stepwise refinement _not_ using
> ifs, but different language facilities.
>

Re: Future with Ada

[Marin David Condic]

Oh... I probably wouldn't do it out of concern for speed. I'd do it if it
seemed that constructing subprograms to squeeze something into some
arbitrary line or nesting limit was going to make the code less intuitively
obvious to the casual observer. Say you have an enumeration with 20 values
and a case statement handling it with 10 statements per enumeral. That's 200
lines + overhead, right? Would you create something like:

case (var) is
    when First_Enum =>
        Do_Ten_Lines_Of_Stuff ; --  I wouldn't generally object to this...
maybe
    when others =>
        Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to this.
end case ;

procedure Do_Another_Case_In_A_Procedure (var : in var_type) is
begin
    case (var) is
        when Second_Enum =>
            Do_Ten_Lines_Of_Stuff ;
        when others =>
            Do_Yet_Another_Case_In_A_Procedure (var) ;
    end case ;
end Do_Another_Case_In_A_Procedure ;

And so on, and so on, and so on... Just to avoid a 200 line case statement
where and "end case Identifier;" might help you see what you were ending? I
guess I've written enough code where I've exceeded a screen's worth of lines
or had two or three levels of nesting and thought it would be useful to
identify what the "end" parts came from. If that's bad code by some
definition of "bad" then I guess I'll just have to live with the stigma.
(Bad Programmer! No Cookie! :-)

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/


"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a6831k$3ls$1@a1-hrz.uni-duisburg.de...
>
> yes, sometimes, highest speed dfa in inner loops, say?.
> my point was that this need not be reflected in "big" if, in a sense.
> With inlined subprograms, tag magic, ... you can do a lot to reduce
> the "textual length" of an if or case statement, without much or any
> loss in performance. At the expense of increased expressiveness,
> sometimes :-)
>

Re: Future with Ada

[Kevin Cline]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a65jhi$112$1@nh.pace.co.uk>...
> "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
> news:a65gj5$n73$1@a1-hrz.uni-duisburg.de...
> > Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
> > :
> > : Why not for "if" statements
> >
> > Hmm, are you suggesting that you feel comfortable with if
> > statements that span more than say 12 lines and/or are nested
> > to some unspeakable level of say 3 or more? :-)
> >
> 
> Why, "yes". What's your point? :-) Sometimes a big case or if is a perfectly
> good way of reflecting what's going on. (Think of lots of "when" or "elsif"
> parts, for example.) Things should be made as simple as possible, but no
> simpler.

I used to happily program this way until I realized people
(including me, after a few weeks)
trying to read my code were drowning in details.  Now I limit
myself to one level of nesting per function, unless some
performance analysis proves the function call overhead is too great.

It's true that the complexity has to be somewhere, but it's not necessary
nor desirable that it all be in one place.

I find it much easier to understand five ten-line functions
than to understand one fifty-line function.

Re: Future with Ada

[Chad R. Meiners]

"Kevin Cline" <kcline@optelnow.net> wrote in message
news:dcfe911f.0203071252.582e0401@posting.google.com...

> I used to happily program this way until I realized people
> (including me, after a few weeks)
> trying to read my code were drowning in details.  Now I limit
> myself to one level of nesting per function, unless some
> performance analysis proves the function call overhead is too great.
>
> It's true that the complexity has to be somewhere, but it's not necessary
> nor desirable that it all be in one place.

> I find it much easier to understand five ten-line functions
> than to understand one fifty-line function.

If you had read the post you are replying to carefully, you would have
realized that the Marin is not advocating a practice that requires you to
always favor using deeply nested if statements.  He is stating that there
are cases in which using nested if statements is the most appropriate
solution.

You seem to be stating that there is never a case is which nested ifs are
appropriate (barring speed constraints).  I find this claim very difficult
to believe.  Is this the claim you really want to be making?

-CRM

Re: Future with Ada

[Gary Scott]

Marin David Condic wrote:
> 
> Well the nice thing is that since it has no semantic meaning, it wouldn't
> really impact the compiler in a difficult way if it were added. Since its
> pretty much "noise", you would have 100% upward compatibility with existing
> code and would just need some parser changes to detect the label & make sure
> it matched at the end.
> 
> Would it be attractive to be able to do something like:
> 
> Outer_Check: if (Some_Boolean) then
>     Inner_Check: if (Some_Other_Boolean) then
>         Some_Statement ;
>     end if Inner_Check ;
> end if Outer_Check ;

Hmmm, looks exactly like Fortran 95...(except ; is optional)


> 
> I suppose it would help when you have really long chunks of code inside the
> ifs.
> 
> 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/
> 
> -- 

Gary Scott
mailto:scottg@flash.net

Re: Future with Ada

[Marin David Condic]

Does that mean I can put on my resume that I'm now a Fortran95 programmer?
:-)

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/


"Gary Scott" <scottg@flash.net> wrote in message
news:3C8A2249.E7B0D7E5@flash.net...
>
> Hmmm, looks exactly like Fortran 95...(except ; is optional)
>
>

Re: named control statements (was: Future with Ada)

[Wes Groleau]

> > Would it be attractive to be able to do something like:
> >
> > Outer_Check: if (Some_Boolean) then
> >     Inner_Check: if (Some_Other_Boolean) then
> >         Some_Statement ;
> >     end if Inner_Check ;
> > end if Outer_Check ;
> 
> Hmmm, looks exactly like Fortran 95...(except ; is optional)

That's OK.  Nothing wrong with borrowing a good idea
from another language.  Others have been borrowing good
ideas from Ada for almost twenty years.....

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

Re: named control statements (was: Future with Ada)

[Gary Scott]

Wes Groleau wrote:
> 
> > > Would it be attractive to be able to do something like:
> > >
> > > Outer_Check: if (Some_Boolean) then
> > >     Inner_Check: if (Some_Other_Boolean) then
> > >         Some_Statement ;
> > >     end if Inner_Check ;
> > > end if Outer_Check ;
> >
> > Hmmm, looks exactly like Fortran 95...(except ; is optional)
> 
> That's OK.  Nothing wrong with borrowing a good idea
> from another language.  Others have been borrowing good
> ideas from Ada for almost twenty years.....

Nope, that's the argument I use promoting Fortran 95...I say "it's got
all this nice stuff borrowed from Ada and Modula now, you should try
it"...still, I can't for the life of me understand why "implicit none"
wasn't made the default when free form source form was formally
standardized over a decade ago.  Some compromises for backward
compatibility should simply not be made.

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


-- 

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: Future with Ada

[Richard Riehle]

Michael Card wrote:

> RE: Richard's & Ben's comments about a shortage of ada programmers:

Some readers might be interested in this story.

On Friday, one of my former students, a Naval officer, dropped by my office
for a few minutes.   He is now with the Fleet as an EDO (engineering duty
officer).   In the Ada class he took, we studied several options for creating
GUI applications using GtkAda, CLAW, and JEWL, among others.   His
reason for dropping by was to let me know he has had the opportunity to
write a lot of small applications at his current duty station using Ada.

If you are paying attention, John English, he found your JEWL packages
easy to use and at the right level of simplicity for what he needed to do.
I have suggested to him that he acquire a copy of CLAW for doing more
robust applications, and I think he will look into getting funds for a CLAW
license.

He is one of those very bright officers who will, if he has his way, infect
the rest of his organization with a zeal for Ada.   The problem he will
face is the naysayers who outrank him and know little about the value
of Ada -- those who still believe Java is such a great idea, for example.

Richard Riehle

Re: named control statements (was: Future with Ada)

[Jeffrey Carter]

Wes Groleau wrote:
> 
> > > Would it be attractive to be able to do something like:
> > >
> > > Outer_Check: if (Some_Boolean) then
> > >     Inner_Check: if (Some_Other_Boolean) then
> > >         Some_Statement ;
> > >     end if Inner_Check ;
> > > end if Outer_Check ;
> >
> > Hmmm, looks exactly like Fortran 95...(except ; is optional)
> 
> That's OK.  Nothing wrong with borrowing a good idea
> from another language.  Others have been borrowing good
> ideas from Ada for almost twenty years.....

Something like this was part of the Red language, IIRC. There was also
something like this in the early forms of 9X, IIRC; not surprising,
since 9X was done by Intermetrics, who developed Red. I guess it was one
of many things considered not important enough to make it into Ada, like
"return when".

At the Ada Launch (1980 Dec 10), Ichbiah, Barnes, and Firth talked about
the "comb structures" in Ada. These are things like

procedure X is
|
begin
|
exception
|
end X;

package X is
|
private
|
end X;

and also things like

if X then
|
elsif Y then
|
elsif Z then
|
else
|
end if;

case X is
when ...
|
when ...
|
when ...
|
end case;

These look like combs: they have a backbone on the left and teeth
projecting to the right. If we repeat names on the inner parts of the
combs for subprograms, tasks, and packages (begin, exception, and
private), then it seems we should like to put them on the inner parts of
conditional statements (elsif, else, and when), but it's not clear where
they should go. Would we want

elsif Z then (X)
when A => (X)

or

X : elsif Z then
X : when A =>

? Maybe it would be best to be inconsistent and not allow them at all.
But I would certainly like compiler-checked names on as many parts of as
many structures as possible.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: Future with Ada

[Georg Bauhaus]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:

:  Say you have an enumeration with 20 values
: and a case statement handling it with 10 statements per enumeral. That's 200
: lines + overhead, right? Would you create something like:

What I might consider is turning the enumeration into
something that allows branching by other means than an explicit case
statement. If that wasn't too artificial, or overdoing things.
And I wouldn't turn away from a case statement if the
cases depended on one input variable (and a lookahead, perhaps?).
Does this seem like O.K.? Still, I find "end case/if foo" too inviting;
Might prevent overuse of case/if if these are left as they are now ;-)

irrelevant side note: Knuth has made heavy use of nested cases
in his literate programming tools, squeezing a case into a screen or
less by way of named sections, similar to what you have written.

: 
: case (var) is
:    when First_Enum =>
...
:    when others =>
:        Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to this.
: end case ;
: 
: procedure Do_Another_Case_In_A_Procedure (var : in var_type) is

Re: Future with Ada

[Kevin Cline]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<a68ns5$23nj$1@msunews.cl.msu.edu>...
> "Kevin Cline" <kcline@optelnow.net> wrote in message
> news:dcfe911f.0203071252.582e0401@posting.google.com...
> 
> > I used to happily program this way until I realized people
> > (including me, after a few weeks)
> > trying to read my code were drowning in details.  Now I limit
> > myself to one level of nesting per function, unless some
> > performance analysis proves the function call overhead is too great.
> >
> > It's true that the complexity has to be somewhere, but it's not necessary
> > nor desirable that it all be in one place.
>  
> > I find it much easier to understand five ten-line functions
> > than to understand one fifty-line function.
> 
> If you had read the post you are replying to carefully, you would have
> realized that the Marin is not advocating a practice that requires you to
> always favor using deeply nested if statements.  He is stating that there
> are cases in which using nested if statements is the most appropriate
> solution.
> 
> You seem to be stating that there is never a case is which nested ifs are
> appropriate (barring speed constraints).  I find this claim very difficult
> to believe.  Is this the claim you really want to be making?

That's pretty much it.   Functions with nested ifs are hard to code
correctly,
and hard to understand.  Worst, they're hard to test competely.  A
single function is the smallest unit that can be tested.  Separating
the top-level branches into separate functions allows each branch to
be tested separately.

Some people may enjoy painstakingly creating and verifying a complex
function.
I find that my accuracy improves if I write several small functions
that
can be easily read and tested.

Additionally, I find that it's very often the case that a set of
nested ifs would be better expressed in another way -- perhaps via
data and a simple
lookup function, or as a set of subclasses.  I find that breaking up
the
function makes the overall structure more apparent.

Re: Future with Ada

[Wes Groleau]

>     when others =>
>         Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to this.

I would, too.  But I would probably NOT object to

    when others =>
       Default_Var_Handling (voo);

Matter of fact, whether by nesting or by calling,
I would object to a case choice on a variable that
dispatches to a case on the same variable.

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

Re: Future with Ada

[Chad R. Meiners]

I see.  I agree that there are many cases where subroutine logic should be
broken into smaller subroutines, but I have also encountered many
subroutines in which the additional nesting within contains a small set of
atomic actions so the cost of switching your mindframe to peek into another
subroutine is greater than the cost of the additional level of nesting.

"Kevin Cline" <kcline@optelnow.net> wrote in message
news:dcfe911f.0203111043.53a94cc4@posting.google.com...
> "Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:<a68ns5$23nj$1@msunews.cl.msu.edu>...
> > "Kevin Cline" <kcline@optelnow.net> wrote in message
> > news:dcfe911f.0203071252.582e0401@posting.google.com...
> >
> > > I used to happily program this way until I realized people
> > > (including me, after a few weeks)
> > > trying to read my code were drowning in details.  Now I limit
> > > myself to one level of nesting per function, unless some
> > > performance analysis proves the function call overhead is too great.
> > >
> > > It's true that the complexity has to be somewhere, but it's not
necessary
> > > nor desirable that it all be in one place.
> >
> > > I find it much easier to understand five ten-line functions
> > > than to understand one fifty-line function.
> >
> > If you had read the post you are replying to carefully, you would have
> > realized that the Marin is not advocating a practice that requires you
to
> > always favor using deeply nested if statements.  He is stating that
there
> > are cases in which using nested if statements is the most appropriate
> > solution.
> >
> > You seem to be stating that there is never a case is which nested ifs
are
> > appropriate (barring speed constraints).  I find this claim very
difficult
> > to believe.  Is this the claim you really want to be making?
>
> That's pretty much it.   Functions with nested ifs are hard to code
> correctly,
> and hard to understand.  Worst, they're hard to test competely.  A
> single function is the smallest unit that can be tested.  Separating
> the top-level branches into separate functions allows each branch to
> be tested separately.
>
> Some people may enjoy painstakingly creating and verifying a complex
> function.
> I find that my accuracy improves if I write several small functions
> that
> can be easily read and tested.
>
> Additionally, I find that it's very often the case that a set of
> nested ifs would be better expressed in another way -- perhaps via
> data and a simple
> lookup function, or as a set of subclasses.  I find that breaking up
> the
> function makes the overall structure more apparent.

Re: Future with Ada

[Marin David Condic]

I *think* we're on the same wavelength. I was trying to say I don't object
to something like:

case (Var) is
    when Enum_01 =>
        Something_01 ;
    when Enum_02 =>
        Something_02 ;
    when Enum_03 =>
        Something_03 ;
    when Enum_04 =>
        Something_04 ;
    when Enum_05 =>
        Something_05 ;
    when Enum_06 =>
        Something_06 ;
    when Enum_etc =>
        Something_etc ;
    when others =>
        Something_Others ;
end case ;

And I would find attempts to go through gyrations to make this shorter just
to fit some kind of "Don't make a case statement longer than twentysomething
lines" rule a bit silly. My original illustration was to show a
stupid-code-trick needed to bust up the case statement to make it shorter.
Can you think of a way to make a case statement like this shorter that
doesn't look silly? (Assuming you've got 20 or so enumerals for some
reason - op-codes maybe? Lexical elements of some language you're parsing?
Reserved words in Ada? Not hard to imagine a fairly long list of enumerals,
eh?)

Once that case statement gets longer than a screen, I'd find it handy to
have a name at the end of it reminding me of what I'm ending. Of course, one
could always encase the case in a procedure that did nothing more than
provide the name for the check - and I'd think that was a good thing. But
would you try to make that procedure into three procedures if the case was
75 lines long just to shorten it up into 25 line segments?

Maybe I've run into similar things with if statements or nesting of
structures and didn't want to start making subprograms that had no
identifiable function other than to encapsulate some arbitrary chunk of code
& avoid some arbitrary nesting or line length limit. If I can write a
subprogram name like: "Is_Device_Ready" or
"Check_Employee_Payroll_Deductions" then I'm more than fine about taking
that nested if or long stream of code and hiding it in there. If I have a
hard time writing a good name for it and start resorting to
"Run_Some_Long_Block_Of_Code_To_Avoid_The_Nesting_Police", then I know I'm
better off leaving it the way it was. :-) (It reminds me of stunts pulled to
get subroutines under some arbitrary line limit - divide the routine you
have by the number of lines in the arbitrary limit and just find convenient
places to cut along those breaks. One 400 line subroutine becomes four 100
line routines with a "main" to call each in sequence, eh? :-)

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/


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C8D0D70.BB09F3DA@despammed.com...
>
> >     when others =>
> >         Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to
this.
>
> I would, too.  But I would probably NOT object to
>
>     when others =>
>        Default_Var_Handling (voo);
>
> Matter of fact, whether by nesting or by calling,
> I would object to a case choice on a variable that
> dispatches to a case on the same variable.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: code partitioning (was: Future with Ada)

[Wes Groleau]

> I *think* we're on the same wavelength. 

Yes, I agree.  No splitting things up except on
"logical" boundaries so that the parts can have
meaningful names.

> And I would find attempts to go through gyrations to make this shorter just
> to fit some kind of "Don't make a case statement longer than twentysomething
> lines" rule a bit silly. My original illustration was to show a

Without actually endorsing this, here's a sort of
borderline situation:

   case Animal is

      when Horse | Tiger   | Elephant | Whale | Mouse |
           Dog   | Gorilla | Platypus | Koala | Dingo   =>

         Classify_Mammal (Animal);

      when Lizard | Snake | Alligator | Tortoise =>

         Classify_Reptile (Animal);

      ......

      when others =>

         Classify_Some_Really_Wierd_Thing (Animal);

                        -- gratuitous demo of
   end case (Animal);   -- yet another way of
                        -- naming a case statement
      
  -- to bring it back to the original topic
  -- now that I've updated the subject line  :-)

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

Re: code partitioning (was: Future with Ada)

[Marin David Condic]

Well, yea, I could see that - even breaking it up into a "when mammal ...
when others..." case in something like this. It kind of goes to my original
point: You ought to keep ifs and cases short and as unnested as may make
sense for the problem at hand, but don't go crazy.

You've got to use some judgment, thinking "Shortness and non-nestedness are
good things taken from The Book Of Devoutly To Be Desired Results, but lets
not forget that the spirit of the law is to make things readable and
comprehensible" If statements nest for three or four levels or span several
dozen lines, yet remain comprehensible (being a natural reflection of the
problem at hand) and breaking them up would require unnatural acts of
contortion, then don't fight it. Programming is often an "art" that requires
an "artistic eye" rather than an exact science... much like other writing
and communication skills.

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/


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C8E3110.F36F2DC8@despammed.com...
>
> Without actually endorsing this, here's a sort of
> borderline situation:
>
>    case Animal is
>
>       when Horse | Tiger   | Elephant | Whale | Mouse |
>            Dog   | Gorilla | Platypus | Koala | Dingo   =>
>
>          Classify_Mammal (Animal);
>
>       when Lizard | Snake | Alligator | Tortoise =>
>
>          Classify_Reptile (Animal);
>
>       ......
>
>       when others =>
>
>          Classify_Some_Really_Wierd_Thing (Animal);
>
>                         -- gratuitous demo of
>    end case (Animal);   -- yet another way of
>                         -- naming a case statement
>
>   -- to bring it back to the original topic
>   -- now that I've updated the subject line  :-)
>

Re: Future with Ada

[John English]

Marin David Condic wrote:
> 
> I *think* we're on the same wavelength. I was trying to say I don't object
> to something like:
> 
> case (Var) is
>     when Enum_01 =>
>         Something_01 ;
>     when Enum_02 =>
>         Something_02 ;
>     when Enum_03 =>
>         Something_03 ;
>     when Enum_04 =>
>         Something_04 ;
>     when Enum_05 =>
>         Something_05 ;
>     when Enum_06 =>
>         Something_06 ;
>     when Enum_etc =>
>         Something_etc ;
>     when others =>
>         Something_Others ;
> end case ;

I think I'd be tempted to use an array of access-to-procedures here.

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

Re: labeling (was: partitioning (was: Future))

[Wes Groleau]

We veered off on another topic, but while there
I discovered another possibility for labeling:

    case Animal is

       ......

    end case (Animal);

    -- Contents of parens have no effect on behavior
    -- of program.  Constitutes compiler-checked comment,
    -- nothing more.  Parens and contents optional.  If present,
    -- contents must be semantically identical to case selector.


    if Animal in Mammal then

       .....

    elsif Animal in Reptile then

       .....

    else

       .....

    end if (Animal in Mammal | Animal in Reptile | not);

    -- Contents of parens have no effect on behavior
    -- of program.  Constitutes compiler-checked comment,
    -- nothing more.  Parens and contents optional.  If present,
    -- contents must be semantically identical to if condition.
    -- If elsif's are present, contents of paren may be semantically
    -- identical to ONE OR MORE of the conditions.  If a straight
    -- else is present, the " | not " is optional


    procedure P (Param : in Param_Type) is

       .....

    begin (P (Param : in Param_Type))

       .....

    exception (P (Param : in Param_Type))

       .....

    end P (Param : in Param_Type);

    -- Contents of parens have no effect on behavior
    -- of program.  Constitutes compiler-checked comment,
    -- nothing more.  Parens and contents optional.  If present,
    -- contents must conform.


I intend to "formally" submit this
as a proposed improvement.

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

Re: Future with Ada

[Marin David Condic]

"John English" <je@brighton.ac.uk> wrote in message
news:3C8F4571.3BE24266@brighton.ac.uk...
>
> I think I'd be tempted to use an array of access-to-procedures here.
>
That would certainly be an interesting approach and one that might greatly
simplify the code. But I'd imagine it might not work well in all cases -
where the branches might have common behavior for some set of the enumerals,
but with slight variations with specific cases, or where the procedure calls
needed different parameter lists, or any number of other things like that.
The technique you suggest hadn't occurred to me & I could see it as useful
and probably a good idea for a lot of cases. I just wouldn't imagine it
totally eliminates all instances wherein one might have a fairly long case
statement and that being a "good" implementation of the solution.

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: Future with Ada

[Kevin Cline]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a6jg6p$iec$1@nh.pace.co.uk>...
> ...One 400 line subroutine becomes four 100
> line routines with a "main" to call each in sequence, eh? :-)

Well, that would be better, although even 100 lines is rather long.
Why?  Because understanding or testing a 400-line subroutine is
considerably
more than four times as difficult as understanding or testing four
100-line subroutines.

Presumably you don't have 400 uncommented lines, 
so your 400-line subroutine is going to be sprinkled with
comments like

-- do something
... code to do something ...
-- do something else
... code to do something else ...
-- do another thing
...

Extract each block of code to a separate function
named by the comment preceding the block:

do_something()
do_something_else()
do_another_thing()

If the argument lists to the subroutines are long,
then consider introducing a new type to hold the
data passed between the subroutines.

Re: Future with Ada

[Marin David Condic]

I don't know about that. Back when I was in college they kept telling us we
should write subprograms that high functional independence and low coupling.
Arbitrarily dividing up a routine just to get it into some line limit was
considered one of the better ways of intercoursing that up. :-)

But then they seem to have quit teaching that "Y = M*X + B" in favor of "Y =
A + B*X" or some such, so maybe functional independence and coupling have
fallen out of favor too. :-)

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/


"Kevin Cline" <kcline@optelnow.net> wrote in message
news:dcfe911f.0203130716.50981806@posting.google.com...
>
> Well, that would be better, although even 100 lines is rather long.
> Why?  Because understanding or testing a 400-line subroutine is
> considerably
> more than four times as difficult as understanding or testing four
> 100-line subroutines.
>
> Presumably you don't have 400 uncommented lines,
> so your 400-line subroutine is going to be sprinkled with
> comments like
>
> -- do something
> ... code to do something ...
> -- do something else
> ... code to do something else ...
> -- do another thing
> ...
>
> Extract each block of code to a separate function
> named by the comment preceding the block:
>
> do_something()
> do_something_else()
> do_another_thing()
>
> If the argument lists to the subroutines are long,
> then consider introducing a new type to hold the
> data passed between the subroutines.

Re: Future with Ada

[Wes Groleau]

> > I think I'd be tempted to use an array of access-to-procedures here.
> >
> That would certainly be an interesting approach ....
> The technique you suggest hadn't occurred to me & I could see it as useful
> and probably a good idea for a lot of cases. I just wouldn't imagine it

It's a super way to make a state machine.  If the inputs
can be enumerated, and the states can be enumerated, then
you have a two-dimensional array, indexed by current state
and input.  Each element is a record containing next state
and transition action procedure pointer.

Logic is just a tight loop looking up what to do and
next state.

Aggregate to initialize the array can be laid out
easily in a tabular format suitable for documentation--
or copied _from_ the requirements.

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

Re: Future with Ada

[John English]

Marin David Condic wrote:
> 
> "John English" <je@brighton.ac.uk> wrote in message
> news:3C8F4571.3BE24266@brighton.ac.uk...
> >
> > I think I'd be tempted to use an array of access-to-procedures here.
> >
> That would certainly be an interesting approach and one that might greatly
> simplify the code. But I'd imagine it might not work well in all cases -
> where the branches might have common behavior for some set of the enumerals,

Try: (a|b|c..d => Proc_1'Access, others => Proc_2'Access)

> but with slight variations with specific cases, or where the procedure calls
> needed different parameter lists, or any number of other things like that.

Use little wrapper procedures which call the (parameterised) procedures.

It's not a magic bullet, but it can produce more readable code in
many (ahem ;-) cases.

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

Re: labeling (was: partitioning (was: Future))

[Michal Nowak]

On 2002-03-13 at 08:42 Wes Groleau wrote:

>We veered off on another topic, but while there
>I discovered another possibility for labeling:
>
>    case Animal is
>
>       ......
>
>    end case (Animal);
>
>    -- Contents of parens have no effect on behavior
>    -- of program.  Constitutes compiler-checked comment,
>    -- nothing more.  Parens and contents optional.  If present,
>    -- contents must be semantically identical to case selector.

What about:

    case Animal is

       ......

    end case Animal;

with the same rules as for ending procedure/function?

>    if Animal in Mammal then
>
>       .....
>
>    elsif Animal in Reptile then
>
>       .....
>
>    else
>
>       .....
>
>    end if (Animal in Mammal | Animal in Reptile | not);

This looks short and terse when there are not too much branches
(and is not necessary then, becaue it should be possible to
see all branches on one screen). When there will be more branches,
this may grow to some extraordinary size, affecting readibility
(in my opinion).

>    procedure P (Param : in Param_Type) is
>
>       .....
>
>    begin (P (Param : in Param_Type))
>
>       .....
>
>    exception (P (Param : in Param_Type))
>
>       .....
>
>    end P (Param : in Param_Type);
>
>    -- Contents of parens have no effect on behavior
>    -- of program.  Constitutes compiler-checked comment,
>    -- nothing more.  Parens and contents optional.  If present,
>    -- contents must conform.

Please no! Why put parameter list (or this proposal is for only
one-parameter?) to every element of comb? Why parameters near
exception handlig? And what, when there will be three or more 
parameters? This won't be readable I think.

Just my comments,
Mike

Re: Future with Ada

[John R. Strohm]

Observation: Underlying all this is a PERFECT example of what might be
called "80-column card thinking".

The underlying assumption is that the terminal screen has 25 lines and so
you should have everything broken into 25-line chunks.

However, printer pages typically allow around 60 lines, and PCs have
supported 43 and 50 line text modes for well over 10 years now.  Printer
pages also have the advantage that you can scribble on them as needed.  Hm.
I don't remember what the old Symbolics console provided, but it was a hell
of a lot more than 25 lines.

At the same time, the principle remains the same.  Having a single
procedure, spanning hundreds of run-on lines, is usually a Bad Thing.

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a6jg6p$iec$1@nh.pace.co.uk...
> I *think* we're on the same wavelength. I was trying to say I don't object
> to something like:
>
> case (Var) is
>     when Enum_01 =>
>         Something_01 ;
>     when Enum_02 =>
>         Something_02 ;
>     when Enum_03 =>
>         Something_03 ;
>     when Enum_04 =>
>         Something_04 ;
>     when Enum_05 =>
>         Something_05 ;
>     when Enum_06 =>
>         Something_06 ;
>     when Enum_etc =>
>         Something_etc ;
>     when others =>
>         Something_Others ;
> end case ;
>
> And I would find attempts to go through gyrations to make this shorter
just
> to fit some kind of "Don't make a case statement longer than
twentysomething
> lines" rule a bit silly. My original illustration was to show a
> stupid-code-trick needed to bust up the case statement to make it shorter.
> Can you think of a way to make a case statement like this shorter that
> doesn't look silly? (Assuming you've got 20 or so enumerals for some
> reason - op-codes maybe? Lexical elements of some language you're parsing?
> Reserved words in Ada? Not hard to imagine a fairly long list of
enumerals,
> eh?)
>
> Once that case statement gets longer than a screen, I'd find it handy to
> have a name at the end of it reminding me of what I'm ending. Of course,
one
> could always encase the case in a procedure that did nothing more than
> provide the name for the check - and I'd think that was a good thing. But
> would you try to make that procedure into three procedures if the case was
> 75 lines long just to shorten it up into 25 line segments?
>
> Maybe I've run into similar things with if statements or nesting of
> structures and didn't want to start making subprograms that had no
> identifiable function other than to encapsulate some arbitrary chunk of
code
> & avoid some arbitrary nesting or line length limit. If I can write a
> subprogram name like: "Is_Device_Ready" or
> "Check_Employee_Payroll_Deductions" then I'm more than fine about taking
> that nested if or long stream of code and hiding it in there. If I have a
> hard time writing a good name for it and start resorting to
> "Run_Some_Long_Block_Of_Code_To_Avoid_The_Nesting_Police", then I know I'm
> better off leaving it the way it was. :-) (It reminds me of stunts pulled
to
> get subroutines under some arbitrary line limit - divide the routine you
> have by the number of lines in the arbitrary limit and just find
convenient
> places to cut along those breaks. One 400 line subroutine becomes four 100
> line routines with a "main" to call each in sequence, eh? :-)
>
> 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/
>
>
> "Wes Groleau" <wesgroleau@despammed.com> wrote in message
> news:3C8D0D70.BB09F3DA@despammed.com...
> >
> > >     when others =>
> > >         Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to
> this.
> >
> > I would, too.  But I would probably NOT object to
> >
> >     when others =>
> >        Default_Var_Handling (voo);
> >
> > Matter of fact, whether by nesting or by calling,
> > I would object to a case choice on a variable that
> > dispatches to a case on the same variable.
> >
> > --
> > Wes Groleau
> > http://freepages.rootsweb.com/~wgroleau
>
>

Re: code partitioning (was: Future with Ada)

[John R. Strohm]

Well, yes, in theory that is all true.

In practice, in thirty years of slinging bits, both as student and as
professional, I have seen exactly one procedure that NEEDED to be more than
one printer page of code and that COULDN'T easily be factored down any
further.  (For the record, it was the photon torpedo routine in the old
Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a6lfgd$gj6$1@nh.pace.co.uk...
> Well, yea, I could see that - even breaking it up into a "when mammal ...
> when others..." case in something like this. It kind of goes to my
original
> point: You ought to keep ifs and cases short and as unnested as may make
> sense for the problem at hand, but don't go crazy.
>
> You've got to use some judgment, thinking "Shortness and non-nestedness
are
> good things taken from The Book Of Devoutly To Be Desired Results, but
lets
> not forget that the spirit of the law is to make things readable and
> comprehensible" If statements nest for three or four levels or span
several
> dozen lines, yet remain comprehensible (being a natural reflection of the
> problem at hand) and breaking them up would require unnatural acts of
> contortion, then don't fight it. Programming is often an "art" that
requires
> an "artistic eye" rather than an exact science... much like other writing
> and communication skills.
>
> 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/
>
>
> "Wes Groleau" <wesgroleau@despammed.com> wrote in message
> news:3C8E3110.F36F2DC8@despammed.com...
> >
> > Without actually endorsing this, here's a sort of
> > borderline situation:
> >
> >    case Animal is
> >
> >       when Horse | Tiger   | Elephant | Whale | Mouse |
> >            Dog   | Gorilla | Platypus | Koala | Dingo   =>
> >
> >          Classify_Mammal (Animal);
> >
> >       when Lizard | Snake | Alligator | Tortoise =>
> >
> >          Classify_Reptile (Animal);
> >
> >       ......
> >
> >       when others =>
> >
> >          Classify_Some_Really_Wierd_Thing (Animal);
> >
> >                         -- gratuitous demo of
> >    end case (Animal);   -- yet another way of
> >                         -- naming a case statement
> >
> >   -- to bring it back to the original topic
> >   -- now that I've updated the subject line  :-)
> >
>
>
>

Re: Future with Ada

[John R. Strohm]

The catch is that such matrices for real state machines tend to be VERY
sparse.  Most of the entries will be "Can't Happen/Error", indicating that
this input can't happen in that state.  Explicitly listing all the error
combinations obscures the non-error cases.

The obvious fix for that is a vector of 4-tuples

  (state input handler next-state)

and an initialization-time routine that starts by prefilling the matrix with
error_cant_happen and an appropriate state, and then walks the vector
filling the matrix.

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C901A57.FC90C430@despammed.com...
>
> > > I think I'd be tempted to use an array of access-to-procedures here.
> > >
> > That would certainly be an interesting approach ....
> > The technique you suggest hadn't occurred to me & I could see it as
useful
> > and probably a good idea for a lot of cases. I just wouldn't imagine it
>
> It's a super way to make a state machine.  If the inputs
> can be enumerated, and the states can be enumerated, then
> you have a two-dimensional array, indexed by current state
> and input.  Each element is a record containing next state
> and transition action procedure pointer.
>
> Logic is just a tight loop looking up what to do and
> next state.
>
> Aggregate to initialize the array can be laid out
> easily in a tabular format suitable for documentation--
> or copied _from_ the requirements.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: labeling (was: partitioning (was: Future))

[Wes Groleau]

> >    end case (Animal);
> 
> What about:
> 
>     end case Animal;
> 
> with the same rules as for ending procedure/function?

That was somebody's earlier proposal.  Someone had some reason
for proposing adding the parens.  I might have been one or both
somebodies--I can't remember.  I also don't remember the reason
for using parentheses. (Yeah, I know the archives are available.)

> >    end if (Animal in Mammal | Animal in Reptile | not);
> 
> This looks short and terse when there are not too much branches
> (and is not necessary then, becaue it should be possible to
> see all branches on one screen). When there will be more branches,
> this may grow to some extraordinary size, affecting readibility
> (in my opinion).

If you put in everything allowed, yes.  But I suggested that you
don't have to put in all branches--in fact, you don't have to put
in any.  Besides, if you have a zillion eslifs you probably should
have used a case statement.

> >    end P (Param : in Param_Type);
> >
> >    -- Contents of parens have no effect on behavior
> >    -- of program.  Constitutes compiler-checked comment,
> >    -- nothing more.  Parens and contents optional.  If present,
> >    -- contents must conform.
> 
> Please no! Why put parameter list (or this proposal is for only
> one-parameter?) to every element of comb? Why parameters near
> exception handlig? And what, when there will be three or more
> parameters? This won't be readable I think.

Again, I said the parameter list is _optional_ but if used, must
conform.
Might help navigation when the subprogram identifier is overloaded,
but is OPTIONAL.

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

Re: Future with Ada

[Wes Groleau]

> The catch is that such matrices for real state machines tend to be VERY
> sparse.  Most of the entries will be "Can't Happen/Error", indicating that
> this input can't happen in that state.  Explicitly listing all the error
> combinations obscures the non-error cases.

Perhaps.  But

   Impossible : constant Transition_Record :=
        ( Handler => Report_Murphys_Law, Next_State => Error );

   Fatal : constant Transition_Record :=
        ( Handler => Report_Error_And_Exit, Next_State => Error );

   Error : constant Transition_Record :=
        ( Handler => Recover_From_Error, Next_State => Start );

So most of the entries are Impossible, Fatal, or Error.

> The obvious fix for that is a vector of 4-tuples
> 
>   (state input handler next-state)
> 
> and an initialization-time routine that starts by prefilling the matrix with
> error_cant_happen and an appropriate state, and then walks the vector
> filling the matrix.

This is good, too.  It's a matter of judgment.  In some cases,
the two-dimensional state/input lookup table in tabular aggregate form
is more readable.  In others it might be more readable to say:

  State_Transition_Table : constant ......
     := ((state, input, handler, next-state),
         (state, input, handler, next-state),
          ......
         (state, input, handler, next-state),
         (state, input, handler, next-state));

EITHER could be autogenerated from a diagrammatic version
in a C.A.S.E. tool. EITHER expresses the requirements clearly
in compilable form.  EITHER is much better than the

      ....
   elsif Current_State = .....  and
         Input         = .....
   then
      Handler (Current_State, Input);

   elsif Current_State = .....  and
      ....

that I've seen too often.

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

Re: labeling (was: partitioning (was: Future))

[Marin David Condic]

This is not very orthogonal with the rest of Ada and is potentially quite
awkward since "case (Animal)..." is really an expression rather than an
identifier for a structure. It would be much more orthogonal to do something
like:

Animal: case (Some_Expression) is
...
end case Animal ;

That is consistent with the loop and block statements.

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/


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C90DD8A.21D57CD2@despammed.com...
>
>
> > >    end case (Animal);
> >
> > What about:
> >
> >     end case Animal;
> >
> > with the same rules as for ending procedure/function?
>
> That was somebody's earlier proposal.  Someone had some reason
> for proposing adding the parens.  I might have been one or both
> somebodies--I can't remember.  I also don't remember the reason
> for using parentheses. (Yeah, I know the archives are available.)
>

Re: labeling (was: partitioning (was: Future))

[Tarjei T. Jensen]

Wes Groleau wrote
> We veered off on another topic, but while there
> I discovered another possibility for labeling:
>
>     case Animal is
>
>        ......
>
>     end case (Animal);

I would prefer

   case Animal label animal is


   ......

    end animal;

    if Animal in Mammal label animal_if
    then

    ...
    end animal_if;

or possibly more readable:

    label animal_if
    if Animal in Mammal
    then
    ...
    end animal_if;

Prepending the statement which one want a named end for is perhaps easier to
accomodate?

The label would not be available for anything else but end verification, so
it would not be a problem that it has the same name as a variable or type.
In other words; labels would have their own name space.

Re: code partitioning (was: Future with Ada)

[Ted Dennison]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<9F6CC4A4404878F6.5B5BBAA9D5258CDF.AA7E4D06ED4F8781@lp.airnews.net>...
> In practice, in thirty years of slinging bits, both as student and as
> professional, I have seen exactly one procedure that NEEDED to be more than
> one printer page of code and that COULDN'T easily be factored down any
> further.  (For the record, it was the photon torpedo routine in the old
> Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)

I once had a command decoding and dispatching routine that had a >50
branch case statement. Not only was it really big, but it completly
blew by our MacCabe complexity target (somewhere around 4 or 5 I
belive). There was no cleaning that baby up.

But you are right that this is a rare exception.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: labeling (was: partitioning (was: Future))

[Wes Groleau]

> >     case Animal is
> >
> >        ......
> >
> >     end case (Animal);
> 
> I would prefer
> 
>    case Animal label animal is


In my opinion, the two best proposals so far are

   Label:
      case/if expression is/then
         .....
      end case/if Label;

AND

   case/if expression is/then
       .....
   end case/if (expression);

The first is simpler, but the second has more flexibility.

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

Re: code partitioning (was: Future with Ada)

[Kevin Cline]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0203150615.4282773b@posting.google.com>...
> "John R. Strohm" <strohm@airmail.net> wrote in message news:<9F6CC4A4404878F6.5B5BBAA9D5258CDF.AA7E4D06ED4F8781@lp.airnews.net>...
> > In practice, in thirty years of slinging bits, both as student and as
> > professional, I have seen exactly one procedure that NEEDED to be more than
> > one printer page of code and that COULDN'T easily be factored down any
> > further.  (For the record, it was the photon torpedo routine in the old
> > Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)
> 
> I once had a command decoding and dispatching routine that had a >50
> branch case statement. Not only was it really big, but it completly
> blew by our MacCabe complexity target (somewhere around 4 or 5 I
> belive). There was no cleaning that baby up.

I have done this a few times in different ways:

* Use yacc or a similar tool to generate the code.  I did this when
I wrote an Ada program to parse Ada-83 package specifications.

* Convert the code to data.  During initialization,
create a tree with nodes labeled by commands and subcommands, 
with functions at the leaves.

* Embed the Tcl interpreter into the application.
This gives the users a lot scripting functionality for free.