Improving Ada's image - Was: 7E7 Flight Controls Electronics

Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Per Dalgas Jakobsen]

> That's not so easy. I've seen lot of project managers chosing C++ even if
> they knew that Ada was cheaper/safer. As I said that's not so easy... This
is
> political, choising a technology that everybody uses can't be something
that
> we'll be reproached to you if the project is not on schedule/budget!

The good old story: "You don't get fired for choosing IBM".
The good old story on a new bottle: "You don't get fired for choosing
Microsoft".
The good old story on a another new bottle: "You don't get fired for
choosing C/C++".

One way to make Ada come through, is to make it visible to them. Not just to
those at the "safety-critical" segment, but to the entire software segment.
A couple of years ago I suggested changing from C/C++ to Ada on a company
strategy meeting. The suggestion was met with comments like: "No real
company is using Ada for anything", "Ada is a heavy/slow and expensive
language", "Only projects with a *lot* of money can do that", "We are not
building rockets or aeroplanes, we are just building ...".

Even though you can counter-argue most of their claims, they still have it
in their stomach and won't make the leap.

Instead of advertising for Ada in software magazines, web-sites, etc. I
believe that Ada needs to get an "image-lift" at executive level. Imagine if
we could get to the point when project managers are suggesting C/C++ and the
executive asks: "Why not use Ada?" :-p

It doesn't take many arguments to convince most serious programmers of the
advantages in Ada (even though there *are* religious extremists around, that
believe void-pointers and goto-statements are the only true way) - But it
really doesn't matter if the project managers doesn't have the courage to
even suggest it, because of the opinion of the executives.

Executives will like to hear:
*) that the reusability factor of Ada is magnitudes higher than for C/C++.
*) that Ada is much better suited than C/C++ for larger projects with
several (potential distanced) developers. And by larger, I mean almost any
project with a project manager.
*) that Ada projects results in fewer bugs at the customer.
I'll bet that this news-group can come up with a dozen or more easy-to-prove
arguments...

But another important thing to nail into their heads are: It does *not* have
to be expensive to choose Ada. Most visible projects are safety-critical
once, with budgets in the "heavy league".
We need to establish a common knowledge, that Ada is as cheap as choosing
C/C++ (buying toolchains), and that even small projects will have a higher
probability to complete on time with fewer bugs.
The cost of sending people on Ada courses will be insignificant in anything
but the narrowest view.


But how can we get the attention of the executives?
Let the brainstorm start ;-)

Per

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Pascal Obry]

"Per Dalgas Jakobsen" <i@hate.spam> writes:

I agree 100% about what you said!

> But how can we get the attention of the executives?
> Let the brainstorm start ;-)

That's the real problem :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Luke A. Guest]

On Sun, 30 May 2004 18:13:59 +0200, Pascal Obry wrote:

> 
> "Per Dalgas Jakobsen" <i@hate.spam> writes:
> 
> I agree 100% about what you said!
> 
>> But how can we get the attention of the executives?
>> Let the brainstorm start ;-)
> 
> That's the real problem :)

No, the real problem is that executives = management and management =
morons and morons are in charge.

Simple as that.

Luke.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Per Dalgas Jakobsen]

>>> But how can we get the attention of the executives?
>>> Let the brainstorm start ;-)
>>
>> That's the real problem :)
>
> No, the real problem is that executives = management and management =
> morons and morons are in charge.

Well, I understand your view, but I have (almost) never seen a person that
acted irrational, when seing things from a certain point of view.
That view might not be yours for several reasons, one being that you know
more about some stuff than they do or visa versa.

I have more than once looked at a decision and thought: "Now they went mad",
but later found out that the stuff have become a political "hot potato".
Again, reasonable seing stuff from the political angle, but completely
old-fashioned-foot-shooting seing it from a any other angle.
The problem being most project managers do not have the courage to put their
reputation at stake to make an unorthodox decision, because all the other
project managers will know immediately where to point fingers if the project
runs off track, disregarding the real reason (the majority are right...).

Thats why it makes no sense to try forcing Ada from the bottom up (even
though Linux seems to have accomplished that to a certain extend), but let
it enter at top level and let the executives suggest it, so the project
managers have their backs free.


One way to get their attention could be to suggest Berkeley or Oxford (or
whoever makes these kinds of analyses) to make a thorough investigations
based on real business cases, with help from "people in the business" = us,
and make them do all the economical consequence maths, for very small
projects with no safety critical issues, to very large projects with all the
whistles and bells.

If (or hopefully when) their results shows that the current accepted
business model with C/C++ is a very bumpy one, and that a business model
based on Ada would result in a significant profit and lower risk, then I'm
pretty sure that such a result will be published in all financial magazines
world-wide.
Software is big business, and a low-risk path to increased profit is
something that will generate a "certain" interest.


So anyone knows a (preferably respected) business university professor that
might be interested? ;-)

Per

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Richard Riehle]

"Per Dalgas Jakobsen" <i@hate.spam> wrote in message
news:40ba315a$0$254$edfadb0f@dread16.news.tele.dk...
>
> One way to get their attention could be to suggest Berkeley or Oxford (or
> whoever makes these kinds of analyses) to make a thorough investigations
> based on real business cases, with help from "people in the business" =
us,
> and make them do all the economical consequence maths, for very small
> projects with no safety critical issues, to very large projects with all
the
> whistles and bells.

Any Berkeley professor who espoused, or even attempted to justify the use
of Ada, would be laughed out of her/his tenure.   That person be subjected
to a barrage of ridicule that any previous credibility would vanish like a
candle flame in a dust storm.

Wind River was originally founded by Berkeley students.  They used to deny
any
connection with Ada because, from their point of view, it is the language of
death and destruction, the programming language of war.   In more recent
times,
the Wind River management seems to have softened its stance regarding Ada,
and position it as simply an annoying language that they must temporarily
support
until it completely fades into oblivion.

Berkeley has never been a friendly place for Ada.

As to other universities, there is currently no incentive for professors to
carry out
any kind of research that might favor Ada.   The scholarly journals prefer
contributions
that avoid Ada,  the textbook publishers edit out excessive references to
Ada, and
the DoD is not funding any Ada research projects anymore.

At this point, Ada is standing entirely on its own.  It must survive on its
own merits.  It
must endure the ridicule of the academics, the widespread misinformation
among the
developers, and the inane criticism of those who have never written a
seropus system in
the language.  When one considers the obstacles that have been thrown at it
during
the past six years, it is a wonder that it survives at all.   The fact that
it continues to be
the choice of many intelligent users is a tribute to its value.   Those who
select Ada,
when there are so many other options available must be doing so for very
good
reasons.   One must ask what those reasons are.    No one can say, in this
time,
that Ada is only used because of the "mandate."

I am of the opinion that those who choose Ada are on to something that the
other
developers have failed to apprehend.   Perhaps, in time, the secret of Ada
will be
out, and more will discover that they can build better, more maintainable
software
with Ada, within well-bounded budgets, than they can with competing choices.

Until then, those who do decide for Ada will reap the benefits of that
decision while
those who decide for other options will continue to do whatever it is they
think they
are doing.

Richard Riehle

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Wes Groleau]

Richard Riehle wrote:
> At this point, Ada ..... must survive .....  the inane criticism of those
 > who have never written a
> seropus system in
> the language.  

And a large subset of that is the inane criticism of those
who have never written a serious system in any language.

-- 
Wes Groleau
    "Lewis's case for the existence of God is fallacious."
"You mean like circular reasoning?"
    "He believes in God.  Therefore, he's fallacious."

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Wes Groleau wrote:
> Richard Riehle wrote:
>> At this point, Ada ..... must survive .....  the inane criticism of those
>> who have never written a seropus system in the language. 
> And a large subset of that is the inane criticism of those
> who have never written a serious system in any language.

But notice that C, which is so widely derided in the Ada community,
has been used to produce Linux, a stable, portable, efficient, and
high-quality operating system which is maintained by a host of
programmers. Too often, the pro-Ada argument of "you can do it
faster and better" turns into the anti-C bash of "you can't do it at
all", and too many people know better than to buy that.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Wes Groleau]

Hyman Rosen wrote:
> But notice that C, which is so widely derided in the Ada community,
> has been used to produce Linux, a stable, portable, efficient, and
> high-quality operating system which is maintained by a host of

Right.  We should not make the false claim that it can't be done.
Given enough resources, almost anything can be done in almost
any language.  And even if the language is as clumsy as C, enough
careful programmers and enough time can produce a good system.

A related point is that the world's best language with a lack of time
and/or people cannot compete with the world's worst if the latter
has the kind of resources (people/time) that Linux has.

(And bad as it is, C is probably not the worst.)

-- 
Wes Groleau

Always listen to experts.  They'll tell you
what can't be done and why.  Then do it.
                     -- Robert A. Heinlein

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Wes Groleau wrote:
>> Richard Riehle wrote:
>>> At this point, Ada ..... must survive .....  the inane criticism of 
>>> those
>>> who have never written a seropus system in the language. 
>>
>> And a large subset of that is the inane criticism of those
>> who have never written a serious system in any language.
> 
> But notice that C, which is so widely derided in the Ada community,
> has been used to produce Linux, a stable, portable, efficient, and
> high-quality operating system 

But this begs the question "stable, ... high-quality compared
to what?"  Do we have Ada operating systems to make a fair
comparison with?  Don't get me wrong - I am a fan of *NIX/Linux,
but I wouldn't go as far as to say that they couldn't be more
stable, portable, efficient and higher-quality than present.
Looking at the weekly list of Linux vulnerability/patches that
come out for security issues, suggests that improvements
in this area are possible and desirable.

> which is maintained by a host of
> programmers. Too often, the pro-Ada argument of "you can do it
> faster and better" turns into the anti-C bash of "you can't do it at
> all", and too many people know better than to buy that.

<troll>
Perhaps, but this doesn't change the underlying fundamentals
to the position ;-)
</troll>
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> But this begs the question "stable, ... high-quality compared
> to what?"

In absolute terms. Linux systems, as well as BSD systems which
are also written in C, stay up for long periods of time and work
as they are supposed to. Various pieces are always being reworked
and enhanced, apparently without much difficulty.

 > Do we have Ada operating systems to make a fair
> comparison with?

No, you don't. Read what meaning you want from that.

By the way, to "beg the question" means to assume that which you
are trying to prove, not to force a question to be asked.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Warren W. Gay VE3WWG wrote:
>> But this begs the question "stable, ... high-quality compared
>> to what?"
> 
> In absolute terms. Linux systems, as well as BSD systems which
> are also written in C, stay up for long periods of time and work
> as they are supposed to. Various pieces are always being reworked
> and enhanced, apparently without much difficulty.

Uptime is a crude way of measuring "reliability" and
"stability". A system that is up 365 days a year is
not much good to a university that allows its students
to use root exploits, for example.

>  > Do we have Ada operating systems to make a fair
> 
>> comparison with?
> 
> No, you don't. Read what meaning you want from that.

Whatever.

> By the way, to "beg the question" means to assume that which you
> are trying to prove, not to force a question to be asked.

Going back to the original statement:

Hyman Rosen wrote:
 > But notice that C, which is so widely derided in the Ada community,
 > has been used to produce Linux, a stable, portable, efficient, and
 > high-quality operating system which is maintained by a host of

That statement leaves several unanswered questions. By what
measurements is the product stable, portable, efficient?
By what measure is the product considered stable? By what
measure is the software portable? What are the metrics
that caused it to be judged efficient? By what measure
is a product deemed high quality?

Microsofties would argue that Windows XP is stable. So
then you have to answer how these systems are different. What
metrics do you want to apply to the comparison? Uptime
alone, I don't think is a good measure (that was stated
in your subsequent post, BTW). So I stand by the original
assertion that there are questions begging to be answered
in this kind of a statement before it can be accepted as
any level of proof.

In the end yours is not a justifiable statement WRT to Ada.
It does not compare at all to Ada (which is what the discussion
was). Unless you bring metrics into the discussion, and involve
metrics that can be compared to Ada, you are then
just stating an opinion (above) that C is as good as Ada
(or something to that effect), and offering Linux as
some sort of proof.

The bottom line is that unless Linux is perfect, you
cannot state that Ada could not have done better.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> In the end yours is not a justifiable statement WRT to Ada.
> It does not compare at all to Ada (which is what the discussion
> was). Unless you bring metrics into the discussion, and involve
> metrics that can be compared to Ada, you are then just stating
 > an opinion (above) that C is as good as Ada (or something to that
 > effect), and offering Linux as some sort of proof.
> 
> The bottom line is that unless Linux is perfect, you
> cannot state that Ada could not have done better.

Unsurprisingly, you don't get it. The burden of proof is on you,
not me, because you are the one trying to move people away from
the established uses of C and C++ over to Ada. Linux and Microsoft
operating systems and applications serve as existence proofs of the
ability to use C and C++ to build good, stable systems, systems
which are used every day by millions of people to get their work
done. Ariane 5 is an existence proof that the mere use of Ada in
the building of a system is not a panacea against disaster.

Furthermore, Ada is a language where many people who were forced
to use it during the mandate fled from its use afterward, apparently
not having noticed the benefits it was supposed to confer on the
development process.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Warren W. Gay VE3WWG wrote:
>> In the end yours is not a justifiable statement WRT to Ada.
>> It does not compare at all to Ada (which is what the discussion
>> was). Unless you bring metrics into the discussion, and involve
>> metrics that can be compared to Ada, you are then just stating
> 
>  > an opinion (above) that C is as good as Ada (or something to that
>  > effect), and offering Linux as some sort of proof.
> 
>> The bottom line is that unless Linux is perfect, you
>> cannot state that Ada could not have done better.
> 
> Unsurprisingly, you don't get it. The burden of proof is on you,
> not me, because you are the one trying to move people away from
> the established uses of C and C++ over to Ada. Linux and Microsoft
> operating systems and applications serve as existence proofs of the
> ability to use C and C++ to build good, stable systems, systems
> which are used every day by millions of people to get their work
> done. 

Fine the OP (not me) said that Ada is "better/whatever".
Sure, the burden of proof is on the promoter of that
position.

But you've stated a position also.

You keep making this statement that the existing O/S's
are "stable.." etc. Yes, they are existance proofs
of operating systems _implemented_ in C, but nothing
further. Existence does not imply efficient for example.

And Yes, people get useful work done by them -
this was true of Windows 3.1 too, but _that_ was hardly
stable! The only stable element of that C system was
the BSOD ;-) <insert quote about how IBM invented
Ctrl-Alt-Delete but how Microsoft made it famous>

Your assertion that they are so "good" is the point that
doesn't hold water. If you are going to promote that view,
then you need to substantiate it. Otherwise it is useless
information apart from existance. Existence does not
imply stable, efficient, useful that you keep saying
it does.

> Ariane 5 is an existence proof that the mere use of Ada in
> the building of a system is not a panacea against disaster.

Nobody has said that here; certainly not me.

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

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> Your assertion that they are so "good" is the point that
> doesn't hold water. If you are going to promote that view,
> then you need to substantiate it. Otherwise it is useless
> information apart from existance. Existence does not
> imply stable, efficient, useful that you keep saying
> it does.

No, I'm saying that in absolute terms, people find both
Linux and Microsoft operating systems and applications
to be all of those things, and the evidence is the number
of people using them.

In c.l.a. you find many posts deriding managers who choose
to implement systems in C or C++, as if it were somehow
impossible to do such a thing. As MDC keeps saying, it would
be nice if you could point to equivalent or equivalently
large systems in Ada that would demonstrate the same thing
that Linux and Microsoft do.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1086733411.736049@master.nyc.kbcfp.com...
> Warren W. Gay VE3WWG wrote:
> > Your assertion that they are so "good" is the point that
...
> No, I'm saying that in absolute terms, people find both
> Linux and Microsoft operating systems and applications
> to be all of those things, and the evidence is the number
> of people using them.

That is fine except that doesn't say that Ada
couldn't improve upon this, were it put to the test.

What other choice do people have?  Do they get to
choose between Ada and C based operating systems?
Not in the general purpose scene AFAIK.

> In c.l.a. you find many posts deriding managers who choose
> to implement systems in C or C++, as if it were somehow
> impossible to do such a thing. As MDC keeps saying, it would
> be nice if you could point to equivalent or equivalently
> large systems in Ada that would demonstrate the same thing
> that Linux and Microsoft do.

But MDC is right in the sense that it  _would_ be
nice to be able to point to something (O/S) in Ada as evidence
to its strengths. Then we'd have something more to compare
with (operating system to operating system). As it stands, we
can only speculate about how much better an Ada based
O/S would be.

You seem to be saying what we have now
is good enough. Some of us, can't agree.

Warren.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[I R T]

The very fact that noone has bothered to write a commercial OS in Ada is
itself a datapoint.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Richard Riehle]

"I R T" <rambam@bigpond.net.au> wrote in message
news:hdtlgx6r.fsf@pop-server.bigpond.net.au...
>
> The very fact that noone has bothered to write a commercial OS in Ada is
> itself a datapoint.

I wonder what datapoint you might be suggesting.

Writing a commercial database is a fairly large effort.  The fact that few
have
bothered writing operating systems that compete with Microsoft is a
datapoint?

In fact, several of the Run-time Environments that support Ada are written
in
Ada.  These are mini-OS's targeted to support of bare-board computers.
Further, there have been experimental OS's written in Ada, but those who
have written them are not supported by the financial resources necessary
to turn them into commercial products.

We did miss an opportunity back when the DoD was a principle sponsor
of the language.   If someone had thought to port the idea of P-Code
(now Java bytecode) to Ada so that resulting code would be portable
across any system, we might have a different story today.

If the compiler publishers had a better sense of how to commericialize
Ada instead of raising the cost per seat to a level that could only be
endured by a captive client such as the DoD, Ada might have had
better commercial success and people might have used it for more
applications, including operating system development.   Instead, the
developers found it more convenient to use a readily available language
that required no up-front investment, C, as a the development tool.
Can anyone blame them?

The more I look back at the failure of Ada to capture the interest
of the computer industry, the more I realize that, as Jeff Dunteman
once noted, the compiler publishers deliberately priced it out of
reach of the average commercial developer.   Further, they identified
it within their own organizations as the domain of "federal systems"
sales force, and that sales force had no inclination to push for
commercial sales since they were not likely to get the good commissions
for their efforts.

Ada 95, and GNAT, changed much of that.   Notice that now there are
far fewer Ada compiler publishers than before.   There are certainly no
"checkbox" compilers.   Companies such as Green Hills, DDC-I, and
ACT take their Ada responsibilties seriously, and they continue to
provide good products.   Some others now seem to see Ada as a
necessary evil rather than a market opportunity.  One almost gets
the feeling that some of those other companies would not be unhappy
if Ada simply vanished so they would not have to be bothered by it.

Dissenting views from any compiler publishers?

Richard Riehle

                          OOOOOOPS!  Sorry. I forgot to give kudos to Irvine
                                                    Compiler for hanging in
there too.
>

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Randy Brukardt]

"Richard Riehle" <adaworks@earthlink.net> wrote in message
news:fkyxc.7649$uX2.6475@newsread2.news.pas.earthlink.net...
...
> We did miss an opportunity back when the DoD was a principle sponsor
> of the language.   If someone had thought to port the idea of P-Code
> (now Java bytecode) to Ada so that resulting code would be portable
> across any system, we might have a different story today.

I think *everybody* had that idea back then. Certainly, we designed and used
such a code in Janus/Ada; it's still the primary intermediate form. And we
had intended to make interpreted versions available on various platforms.
But the realities of the hardware of the time prevented us from using
interpreters -- when programs took minutes to get anything done, doubling
the time simply wasn't acceptable.

And, of course, we didn't have the balls to go around telling everyone that
what generally was considered an inferior technology was actually a good
idea. You have to give Sun credit for convincing many people of that (even
though the cases where it would help are rare).

                         Randy.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Randy Brukardt wrote:

> "Richard Riehle" <adaworks@earthlink.net> wrote in message
> news:fkyxc.7649$uX2.6475@newsread2.news.pas.earthlink.net...
> ...
> 
>>We did miss an opportunity back when the DoD was a principle sponsor
>>of the language.   If someone had thought to port the idea of P-Code
>>(now Java bytecode) to Ada so that resulting code would be portable
>>across any system, we might have a different story today.
> 
> 
> I think *everybody* had that idea back then. Certainly, we designed and used
> such a code in Janus/Ada; it's still the primary intermediate form. And we
> had intended to make interpreted versions available on various platforms.
> But the realities of the hardware of the time prevented us from using
> interpreters -- when programs took minutes to get anything done, doubling
> the time simply wasn't acceptable.

Remember that there was an early Ada compiler validated on a hardware 
P-code machine.  (I'm trying to remember the name of David Fisher's 
company, immediately after bought out by Western Digital.)  If they or 
Telesoft, another company with a P-code heritage, had done a good job of 
marketing, they probably could have used Ada to keep P-code alive.

And of course, as I have said, the govenment attempts to build an Ada 
development environment all got hugely bloated and were too big and slow 
for the systems of that day.  For all I know some of that code might 
actually be worth using now, and it still exists. ;-)

-- 

                                           Robert I. Eachus

The ideology he opposed throughout his political life insisted that 
history was moved by impersonal tides and unalterable fates. Ronald 
Reagan believed instead in the courage and triumph of free men and we 
believe it all the more because we saw that courage in him.  -- George 
W. Bush June 11, 2004

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> That is fine except that doesn't say that Ada
> couldn't improve upon this, were it put to the test.

You still don't understand. The common attitude around here
is that people who choose C and C++ are stupid, misguided,
and wrong. Look at the current thread on rewriting BIND in
Ada - someone asks why, and the response is that the original
is written in C, and isn't that enough of a reason?

But I have shown you systems written in C and C++ that are
responsible for billins in revenue, are used happily and
productively by millions of people, that are maintained by
widely distributed groups of programmers, and so forth. Why
would someone without an axe to grind accept the thesis that
there is something so intrinsically bad about those languages
that choosing them for a new project is absolutely wrong?

> What other choice do people have?  Do they get to
> choose between Ada and C based operating systems?

The fact that no such choices exist invite suspicion that the
other languages are unsuitable for creating them. That certainly
does not help your case. Try to imagine what your statements look
like to an outsider - you are claiming that this vaporware which
doesn't exist and probably never will would be much better than
existing systems that people are already happy with, if only
somebody would write it.

> You seem to be saying what we have now
> is good enough. Some of us, can't agree.

That's fine, but hectoring the rest of us about it isn't going to
help you.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[I R T]

Hyman Rosen <hyrosen@mail.com> writes:

> The fact that no such choices exist invite suspicion that the
> other languages are unsuitable for creating them. That certainly
> does not help your case. Try to imagine what your statements look
> like to an outsider - you are claiming that this vaporware which
> doesn't exist and probably never will would be much better than
> existing systems that people are already happy with, if only
> somebody would write it.


The mythical Magic Pudding would be so very tasty if only someone would make it.

!! 

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Georg Bauhaus]

I R T <rambam@bigpond.net.au> wrote:
 
: The mythical Magic Pudding would be so very tasty if only someone would make it.
: 
: !! 

The very fact that there is an idea of a Magic Pudding
drives forces. Sometimes the idea is the only incentive.
One set of ideas has given birth to a libre operating system.
Why do some ideas "succeed"?

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> That is fine except that doesn't say that Ada
>> couldn't improve upon this, were it put to the test.
> 
> You still don't understand. The common attitude around here
> is that people who choose C and C++ are stupid, misguided,
> and wrong. Look at the current thread on rewriting BIND in
> Ada - someone asks why, and the response is that the original
> is written in C, and isn't that enough of a reason?

Oh, but I do understand. But evidently we understand
things differently (I can live with that).

As far as rewriting BIND, why must you be critical of
that. So far we have identified that Ada is sadly
missing in the operating systems arena. Sounds like
you would give the same treatment to that kind of
project as well. IOW, you are either hostile to Ada
or you think what we already have is "good enough",
and no improvements should be attempted.

I believe, either point of view is short sighted ;-)

> But I have shown you systems written in C and C++ that are
> responsible for billins in revenue, are used happily and

And sometimes very unhappily, if you remember any of the
Windows 3.1 experience. Win3k, WinXp still crashes. Linux
still panics from time to time. Security vulnerabilities
exist on so many platforms. Ask all those poor folks
about how they felt about their virus infected computers,
that they had to beg borrow or steal a solution for (or
had to pay someone to reinstall everything). I'll bet
they were less than happy ;-)

> productively by millions of people, 

How productive is it keeping your virus signatures up
to date, or reinstalling after a disaster because some
poor sap doesn't know how to do a windows update, or
keep virus signatures up to date. A lot of non-computer
people are really struggling with this now. This is
less than happy and productive!

> widely distributed groups of programmers, and so forth. Why
> would someone without an axe to grind accept the thesis that
> there is something so intrinsically bad about those languages
> that choosing them for a new project is absolutely wrong?

And people keep pointing out (like I just did) that the
computing world is less than a happy productive efficient
world that you claim it to be. You must live a sheltered
life, or don't have relatives/friends calling you for
help with their PC woes.

>> What other choice do people have?  Do they get to
>> choose between Ada and C based operating systems?
> 
> The fact that no such choices exist invite suspicion that the
> other languages are unsuitable for creating them. 

That is certainly one possibility. But there are also many
other suspects that are even more likely (see other posts
in this thread).

> does not help your case. Try to imagine what your statements look
> like to an outsider - you are claiming that this vaporware which

Everyone is concious of this fact (at least as far as
operating systems go). Hence the reason for "pining for
something to point to." ;-)

> doesn't exist and probably never will would be much better than
> existing systems that people are already happy with, if only
> somebody would write it.

People are saying there are reasons to believe this. You
don't necessarily have to agree, but we can discuss it.

>> You seem to be saying what we have now
>> is good enough. Some of us, can't agree.
> 
> That's fine, but hectoring the rest of us about it isn't going to
> help you.

Was I "hectoring"? I thought I responding to
some points and counter-claims.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> As far as rewriting BIND, why must you be critical of that.

I am not critical about rewriting BIND in Ada.
I think it's a great idea, because it would serve
as a nice showcase for Ada's features. I was being
critical about people who say that it should be
rewritten simply because it is now written in C.

Now, will this actually happen? Well, we'll see.

> you are either hostile to Ada or you think what
 > we already have is "good enough"

Neither. I am merely hostile to claims of how much
better this program would be in Ada, if only someone
would write it. I am also hostile to claims that C++
can be chosen only through stupidity.

> And sometimes very unhappily...
> How productive is it keeping your virus signatures up...

Cars overheat, break down, get flat tires, wear out,
need to be inspected, and need parts replaced. They
have assorted design flaws that result in numerous
recalls for repairs. That does not prevent millions
of people from productively using them, and indeed
loving them.

As I keep saying, you cannot use vaporware as evidence
for the superiority of your chosen language. Any version
of Windows, no matter how error prone, is superior to the
most perfect AdaOS if that doesn't exist.

You keep saying - see this system written in C, look at its
flaws. I say - show me a similar system written in Ada that
lacks those flaws.

> Everyone is concious of this fact (at least as far as
> operating systems go). Hence the reason for "pining for
> something to point to." ;-)

I may be wrong, but even GNAT seems to serve as a counterexample.
Every time someone breathes on the underlying GCC, it seems that
GNAT stops working with it.

> Was I "hectoring"? I thought I responding to some points and
 > counter-claims.

Not you in particular. Just the general attitude here.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Wes Groleau]

Hyman Rosen wrote:
> I may be wrong, but even GNAT seems to serve as a counterexample.
> Every time someone breathes on the underlying GCC, it seems that
> GNAT stops working with it.

Maybe that's because the "underlying gcc" is written in C. :-)

-- 
Wes Groleau

    "A man with an experience is never
     at the mercy of a man with an argument."
                       -- Ron Allen

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Wes Groleau wrote:
> Maybe that's because the "underlying gcc" is written in C. :-)

Maybe so, but interfacing with C libraries is probably universal
for real-life Ada programs, and the difficulties involved can't
be minimized away. For one thing, if GNAT were written in C, then
people who changed the underlying gcc could go through the GNAT
code and find where the changes affected that, and do updates.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> Wes Groleau wrote:
> > Maybe that's because the "underlying gcc" is written in C. :-)
> 
> Maybe so, but interfacing with C libraries is probably universal

You are just missing the point, how sad it is to see that you are
pushing a bit too hard by making just stupid statements like this one!

Look, GNAT is based on GCC backend. Now suppose that the GCC backend changes
some interfaces, worst than that, that the GCC backend changes the way to
use it (implementation of new optimizations that requires some more
information from the frontend)... How is this supposed to work without
changing the frontend ? The point is that it just requires some work (sometime
lot of work to comply to new backend requirements) and this work takes
time.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Rewriting an existing system in a new language is mostly a waste of time 
unless a) The existing implementation is so bad that it can only really 
be fixed by tossing it out and starting again or b) You intend to add 
some significant new capability that can't be easily added to the 
existing system. I'd agree that just because a program is written in C 
or C++ is not on the face of it a justification for rewriting it in Ada. 
Solid systems can and have been written in other languages and rewriting 
them in Ada doesn't add any real value. It would be far more productive 
to develop something *new* that gave the world some capability it didn't 
already have.

MDC

Hyman Rosen wrote:
> 
> But I have shown you systems written in C and C++ that are
> responsible for billins in revenue, are used happily and
> productively by millions of people, that are maintained by
> widely distributed groups of programmers, and so forth. Why
> would someone without an axe to grind accept the thesis that
> there is something so intrinsically bad about those languages
> that choosing them for a new project is absolutely wrong?
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Rewriting an existing system in a new language is mostly a waste of time 
> unless a) The existing implementation is so bad that it can only really 
> be fixed by tossing it out and starting again or b) You intend to add 
> some significant new capability that can't be easily added to the 
> existing system. I'd agree that just because a program is written in C 
> or C++ is not on the face of it a justification for rewriting it in Ada. 
> Solid systems can and have been written in other languages and rewriting 
> them in Ada doesn't add any real value. It would be far more productive 
> to develop something *new* that gave the world some capability it didn't 
> already have.
> 
> MDC

You missed another good reason: c) improved security. Any daemon or process
that interfaces with the wild wooly world out there, should be very
secure (perfectly secure if theoretically possible). I think Ada can
add some real value in this particular area, to the many "services"
currently written in C/C++.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

That makes the possibly unwarranted assumptions that a) the original 
program is just inherently insecure because it was written in C/C++ and 
b) that implementation in Ada guarantees security. Neither assumption is 
of necessity true.

If the original program is insecure and inherently so, that is probably 
a reflection of my first condition: "The existing implementation is so 
bad that it can only really be fixed by tossing it out and starting 
again" But you *can* write a perfectly secure, reliable system in 
languages other than Ada. Maybe (maybe!) it requires more work, but it 
*can* be done. So unless the original system has some obvious weaknesses 
you intend to fix, what is the value of doing it in Ada? (Other than 
possibly as a hobby or just because you get a thrill out of knowing that 
your personal implementation is in Ada. To the bulk of the real-world 
users, it doesn't matter that the underlying implementation is in Ada so 
long as it works.)

If the original implementation is rewritten in Ada, that is also an 
opportunity to introduce all sorts of *new* bugs and security leaks. 
Just because its done in Ada doesn't mean the designers/implementors are 
going to automatically get it right and not leave any holes to exploit. 
Possibly, you eliminate one particular type of threat or another, but 
bad implementations in Ada are possible. New implementations are usually 
far weaker than legacy systems that have had the opportunity to be 
beaten about a good deal. So I don't see a compelling reason to go 
rewrite existing apps in Ada just so that they can be in Ada.

Now if someone can say "Let's take System X as a baseline but do it 
differently and add some new and amazing capabilities that will make a 
new app that is far more useful..." then you've got something worth 
discussing.

MDC

Warren W. Gay VE3WWG wrote:
> 
> You missed another good reason: c) improved security. Any daemon or process
> that interfaces with the wild wooly world out there, should be very
> secure (perfectly secure if theoretically possible). I think Ada can
> add some real value in this particular area, to the many "services"
> currently written in C/C++.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Berend de Boer]

>>>>> "Marin" == Marin David Condic <nobody@noplace.com> writes:

    Marin> But you *can* write a perfectly secure, reliable system in
    Marin> languages other than Ada. Maybe (maybe!) it requires more
    Marin> work, but it *can* be done.

So far the real world has not produced a reliable secure OS in C. Can
it be done? I doubt it.

-- 
Regards,

Berend. (-:

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[I R T]

Berend de Boer <berend@xsol.com> writes:

> So far the real world has not produced a reliable secure OS in C. Can
> it be done? I doubt it.

Trusted Solaris is largely C.

http://wwws.sun.com/software/solaris/trustedsolaris/index.html

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Berend de Boer wrote:
> So far the real world has not produced a reliable secure OS in C. Can
> it be done? I doubt it.

You see? This is why Ada advocates are dismissed as crackpots.
Wouldn't you be confused if someone ran around shouting that a
perfectly well-dressed man was actually naked?

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

I sympathize - maybe from a different angle. "So writing an OS in Ada 
would guarantee reliability and security? O.K. Show me. Go write one and 
demonstrate that it works."

Its easy to *claim* that Ada would make a perfectly reliable and secure 
OS, but its really tough to actually do it. And I doubt that Ada in and 
of itself would get you the reliability and security imagined. But I'm 
willing to be proven wrong by demonstration. :-)

MDC

Hyman Rosen wrote:
> 
> You see? This is why Ada advocates are dismissed as crackpots.
> Wouldn't you be confused if someone ran around shouting that a
> perfectly well-dressed man was actually naked?


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> I sympathize - maybe from a different angle. "So writing an OS in Ada 
> would guarantee reliability and security? O.K. Show me. Go write one and 
> demonstrate that it works."
> 
> Its easy to *claim* that Ada would make a perfectly reliable and secure 
> OS, but its really tough to actually do it. And I doubt that Ada in and 
> of itself would get you the reliability and security imagined. But I'm 
> willing to be proven wrong by demonstration. :-)
> 
> MDC

Today's slashdot points out yet another exploit in Linux.

   http://slashdot.org/article.pl?sid=04/06/04/1212228&mode=thread&tid=126&tid=95

We like to deride Windows, but Linux, *NIX in general all suffer from
the same problem. Some of these are no doubt due to design issues
(which Ada may or may not help with). But surely, one has to wonder/hope
if/that some other fundamental change (language) can offer an
improvement. I think many are simply saying that they believe it
to be so.

If one can see major improvements on the projects that Ada is
used for, then by extension one has to expect a similar level
of improvement for an operating system.

But everyone's point is well taken: where is the Ada OS? We
have no implementation to point to for a comparison.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> Today's slashdot points out yet another exploit in Linux.

I believe the link is actually
<http://slashdot.org/article.pl?sid=04/06/14/118209&mode=flat&tid=106&tid=126&tid=128&tid=185&tid=190>.

> We like to deride Windows, but Linux, *NIX in general all suffer from
> the same problem. Some of these are no doubt due to design issues
> (which Ada may or may not help with). But surely, one has to wonder/hope
> if/that some other fundamental change (language) can offer an
> improvement. I think many are simply saying that they believe it
> to be so.

Which illustrates that you did not actually bother to read about
what the problem is. The exploit code (which crashes the kernel,
so it's not precisely a security violation) involves user code
which executes a floating-point processor instruction in a signal
handler that should cause a floating-point exception, immediately
followed by a system call. I think that the hardware exception
occurs a little bit later, such that kernel mode has taken over,
and when the kernel goes to restore the floating-point state, the
exception finally kicks in and brings it down.

I suspect the ultimnate fix involves the kernel checking for
deferred user-mode floating point exceptions so that it can reraise
them in user mode, but in any case, this has nothing to do with the
programming language in which the kernel was written - at the point
of death, it is executing an assembly code insertion.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Like I said: The thing that makes operating systems hard to get right 
are not usually language issues. They are related to the asynchronicity 
of events and the complexity of the algorithms involved. Perhaps a 
hypothetical Ada OS might eliminate some errors, but the worst ones are 
not usually an issue of language checks.

Also, because OS's need high efficiency, it is not at all uncommon to 
turn off most of the runtime checks because you really need the 
performance. (Or is someone suggesting that all Ada checks should be 
left in when developing an OS?) Ada can't help with a variety of runtime 
errors unless the checks are left in, so does it really buy enough 
benefit to be able to make claims about how wonderful a theoretical Ada 
OS would be?

MDC



Hyman Rosen wrote:
> Which illustrates that you did not actually bother to read about
> what the problem is. The exploit code (which crashes the kernel,
> so it's not precisely a security violation) involves user code
> which executes a floating-point processor instruction in a signal
> handler that should cause a floating-point exception, immediately
> followed by a system call. I think that the hardware exception
> occurs a little bit later, such that kernel mode has taken over,
> and when the kernel goes to restore the floating-point state, the
> exception finally kicks in and brings it down.
> 
> I suspect the ultimnate fix involves the kernel checking for
> deferred user-mode floating point exceptions so that it can reraise
> them in user mode, but in any case, this has nothing to do with the
> programming language in which the kernel was written - at the point
> of death, it is executing an assembly code insertion.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Brian May]

>>>>> "Marin" == Marin David Condic <nobody@noplace.com> writes:

    Marin> Also, because OS's need high efficiency, it is not at all
    Marin> uncommon to turn off most of the runtime checks because you
    Marin> really need the performance. (Or is someone suggesting that
    Marin> all Ada checks should be left in when developing an OS?)
    Marin> Ada can't help with a variety of runtime errors unless the
    Marin> checks are left in, so does it really buy enough benefit to
    Marin> be able to make claims about how wonderful a theoretical
    Marin> Ada OS would be?

Ada does more checks at compile time then some languages. I would
assume this would benefit an Ada OS, even if all run-time checks are
turned off.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Sure it helps. As would runtime checks since they could be used in 
debugging & turned off for production. I'm not saying that Ada wouldn't 
help to produce a better quality OS (or any other program for that 
matter). What I'm saying is that it isn't "Magic". People can do 
sufficient design & testing on C code to get the same reliability 
(albeit at probably greater cost) and the big problems with OS stability 
are typically the kind of things that are not going to get caught by 
language rules. (Like timing of asynchronous events, etc.)

There is a danger with hyping Ada as capable of doing things it can't 
really do. To those who have developed real world apps in other 
languages and managed to get them stable & reliable, Ada enthusiasts 
will look kind of silly claiming that it can only be done in Ada.

In other newsgroups, people have claimed that "Ada isn't well suited to 
OS work..." and their typical response when challenged on this is "Well, 
show me where it *is* used successfully in OS work?" Small scale 
realtime OS's can be found (and yes, that counts) but not much in the 
way of "real" OS's like Linux or Windows. If Ada can really do this (I 
believe it could) and people want to make claims about how superior it 
would be at doing this, then there needs to be some proof by 
demonstration or the claims get dismissed as coming from a bunch of 
idealogues and kooks.

MDC


Brian May wrote:
> 
> Ada does more checks at compile time then some languages. I would
> assume this would benefit an Ada OS, even if all run-time checks are
> turned off.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Jacob Sparre Andersen]

Marin David Condic wrote:

> Also, because OS's need high efficiency, it is not at all uncommon to
> turn off most of the runtime checks because you really need the
> performance. (Or is someone suggesting that all Ada checks should be
> left in when developing an OS?)

I would probably leave in the checks.  But I don't think there
actually should be that many active checks.

> Ada can't help with a variety of runtime errors unless the checks
> are left in, so does it really buy enough benefit to be able to make
> claims about how wonderful a theoretical Ada OS would be?

If I ever got brave enough to try to write an OS, I would probably use
a tool like SPARK Examiner to check as much of the code as possible.
Ideally this could probably also help a bit with identifying
supressable checks.

Greetings,

Jacob (SPARK fan :)
-- 
"simply because no one had discovered a cure for the universe as a
 whole - or rather the only one that did exist had been abolished"

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:pl8yeh7yf1.fsf@sparre.crs4.it...
> Marin David Condic wrote:
>
> > Also, because OS's need high efficiency, it is not at all uncommon to
> > turn off most of the runtime checks because you really need the
> > performance. (Or is someone suggesting that all Ada checks should be
> > left in when developing an OS?)
>
> I would probably leave in the checks.  But I don't think there
> actually should be that many active checks.

I agree. I haven't seen much performance impact from leaving checks on. The
reason that Janus/Ada used to be shipped with them off was simply memory
usage -- the old MS-DOS machines didn't have enough space to leave them on.
Nobody has complained that the debugging version of Janus/Ada that I shipped
as the most recent beta was too slow - even though it includes a megabyte of
debugging code and assertions.

                               Randy.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Warren W. Gay VE3WWG wrote:
>> Today's slashdot points out yet another exploit in Linux.
> 
> I believe the link is actually
> <http://slashdot.org/article.pl?sid=04/06/14/118209&mode=flat&tid=106&tid=126&tid=128&tid=185&tid=190>. 
> 
>> We like to deride Windows, but Linux, *NIX in general all suffer from
>> the same problem. Some of these are no doubt due to design issues
>> (which Ada may or may not help with). But surely, one has to wonder/hope
>> if/that some other fundamental change (language) can offer an
>> improvement. I think many are simply saying that they believe it
>> to be so.
> 
> Which illustrates that you did not actually bother to read about
> what the problem is. 

You are correct: I skimmed it, due to a lack of time. You are
also correct, if it reads as you say, it is a poor example.

My real point is however, that it wouldn't be hard to find
other examples of loopholes, that continually need to be
closed. If the system is so secure, why are people so
afraid of giving out shell accounts to their machines?

The reality is that these systems are not very secure.

Every network service exposed to the general public on the
wild wooly world is also very much suceptable to
exploits. Surely it is possible to do better
than we are doing today?

I see that _finally_ that AMD and Intel are coming out with
half measures to help stem the tide with buffer overflows,
with their new 64 bit processor cores. I hope that they
continue to work on hardware measures that help.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Warren W. Gay VE3WWG wrote:
 >
 >
 > Today's slashdot points out yet another exploit in Linux.
 >
 >
 > http://slashdot.org/article.pl?sid=04/06/04/1212228&mode=thread&tid=1-
 > 26&tid=95
 >
 >
 > We like to deride Windows, but Linux, *NIX in general all suffer from
 >  the same problem. Some of these are no doubt due to design issues
 > (which Ada may or may not help with). But surely, one has to
 > wonder/hope if/that some other fundamental change (language) can
 > offer an improvement. I think many are simply saying that they
 > believe it to be so.

Developing an operating system - any operating system - is inherently
complex and extremely difficult to get right. Most of the flaws are
*not* going to come from array bounds or integer range check problems.
They come from logic problems or timing problems. I know from experience
that an asynchronous world is extremely difficult to live in and get
right. The logic an OS goes through to schedule multiple processes and
handle shared I/O, etc., are all just inherently hard to get right.
Coding up an OS in Ada might eliminate some flaws - but they are far
from the worst flaws that an OS can have.



 >
 > If one can see major improvements on the projects that Ada is used
 > for, then by extension one has to expect a similar level of
 > improvement for an operating system.
 >
I think if someone did an OS in Ada they would get some benefits in
terms of productivity and error reduction. But those are typically
developmental issues - someone can still do it in C and get an
equivalent job done, just with added effort. Ada isn't going to
automagically make all the problems of getting an OS into stable, secure
operation go away - but I'm willing to be proven wrong by demonstration. ;-)



 > But everyone's point is well taken: where is the Ada OS? We have no
 > implementation to point to for a comparison.

Yup. Its time to shut up about how superior Ada is and how everyone who
isn't using it is a bonehead for selecting inferior technology. If
that's true, then the time has come to go out and start proving it by
developing real world applications that out-compete their rivals because
of that superior Ada technology. And that goes double for any sort of
Ada OS.

All the necessary tools exist. There's a free compiler, IDE, debugger, 
GUI builder, etc., needed to go write apps in Ada. (I wish they were 
better integrated, standardized and came with a library, but if we keep 
waiting for perfection, we'll never be ready.) We can't say "it would be 
better done in Ada..." now without asking ourselves why we aren't doing 
it. We will look like fools or cranks to the rest of the world if we 
keep pissing on their real-world, in-existence apps unless we can 
actually come up with something that is *better* to put next to it and 
say "See?!?! The one I built in *Ada* actually *is* better!!!" I can't 
download and run conceptual vaporware that is only theoretically better. ;-)

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Warren W. Gay VE3WWG wrote:
>  > Today's slashdot points out yet another exploit in Linux.
>  > http://slashdot.org/article.pl?sid=04/06/04/1212228&mode=thread&tid=1-
>  > 26&tid=95
>  > We like to deride Windows, but Linux, *NIX in general all suffer from
>  >  the same problem. Some of these are no doubt due to design issues
>  > (which Ada may or may not help with). But surely, one has to
>  > wonder/hope if/that some other fundamental change (language) can
>  > offer an improvement. I think many are simply saying that they
>  > believe it to be so.
> 
> Developing an operating system - any operating system - is inherently
> complex and extremely difficult to get right. Most of the flaws are
> *not* going to come from array bounds or integer range check problems.
> They come from logic problems or timing problems. I know from experience
> that an asynchronous world is extremely difficult to live in and get
> right. The logic an OS goes through to schedule multiple processes and
> handle shared I/O, etc., are all just inherently hard to get right.
> Coding up an OS in Ada might eliminate some flaws - but they are far
> from the worst flaws that an OS can have.

Generally agreed. I think you would also agree that Ada forces
the writer to engineer the project better. You are forced to
do more planning with Ada. Compared this with C, where you
can always pass around void pointers, etc. to work around
things that you forgot to design for.

I would further add that Ada code can tolerate more static
analysis, which is pretty much useless or impossible in C.
Static analysis not only saves time testing, but gives you
greater confidence in the results.

> All the necessary tools exist. There's a free compiler, IDE, debugger, 
> GUI builder, etc., needed to go write apps in Ada. (I wish they were 
> better integrated, standardized and came with a library, but if we keep 
> waiting for perfection, we'll never be ready.) We can't say "it would be 
> better done in Ada..." now without asking ourselves why we aren't doing 
> it. We will look like fools or cranks to the rest of the world if we 
> keep pissing on their real-world, in-existence apps unless we can 
> actually come up with something that is *better* to put next to it and 
> say "See?!?! The one I built in *Ada* actually *is* better!!!" I can't 
> download and run conceptual vaporware that is only theoretically better. 
> ;-)
> 
> MDC

Yep, but you need bodies of people willing to help. One or
a few individuals can put together an operating system, but
unless many people contribute towards hardward drivers, the
project is not likely to gain general acceptance (at least
on Intel). But even this, is an untested theory, in the
Ada OS arena so far. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> Generally agreed. I think you would also agree that Ada forces
> the writer to engineer the project better. You are forced to
> do more planning with Ada. Compared this with C, where you
> can always pass around void pointers, etc. to work around
> things that you forgot to design for.

Forgetting to design things is obviously not a feature of
the programming language. So the flip side of what you are
saying is that once you accidentally leave out a feature,
Ada will make it difficult to add.

> I would further add that Ada code can tolerate more static
> analysis, which is pretty much useless or impossible in C.

I suppose.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Warren W. Gay VE3WWG wrote:
>> Generally agreed. I think you would also agree that Ada forces
>> the writer to engineer the project better. You are forced to
>> do more planning with Ada. Compared this with C, where you
>> can always pass around void pointers, etc. to work around
>> things that you forgot to design for.
> 
> Forgetting to design things is obviously not a feature of
> the programming language. So the flip side of what you are
> saying is that once you accidentally leave out a feature,
> Ada will make it difficult to add.

Its not a function of memory. Its a function of programmers
taking the path of least resistance. In fact you hear this
from C programmers all the time when they try to learn
Ada ("I just want to do ...", or "it won't let me do...",
"why can't I..."). Ada enforces more rigour in the
code's design.

As far as overall project design, I
would agree that the language isn't going to help
if the developer deliberately leaves out design
effort (or management insists on starting on code
before the design is finished).

>> I would further add that Ada code can tolerate more static
>> analysis, which is pretty much useless or impossible in C.
> 
> I suppose.

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

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> Its not a function of memory. Its a function of programmers
> taking the path of least resistance. In fact you hear this
> from C programmers all the time when they try to learn
> Ada ("I just want to do ...", or "it won't let me do...",
> "why can't I..."). Ada enforces more rigour in the
> code's design.

I'll bet you good money that I can tell you exactly what in
the code those frustrated C programmers are talking about;
string handling.

And that's because Ada comes with a type named String which
behaves nothing at all like strings in C or C++, being just
a name for an array of characters, which may be declared with
runtime bounds or returned from a function but is then fixed
in size.

The concept is foreign to C programmers, for whom arrays in
expressions decay to pointers, and which cannot be passed or
returned by value. And I'll bet that *no one explains this*
when teaching Ada. The semantic gap becomes so large that it's
no wonder that C programmers wind up frustrated when trying to
do simple things that work properly in their old language.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Ed Falis]

On Tue, 15 Jun 2004 22:01:51 GMT, Hyman Rosen <hyrosen@mail.com> wrote:

> And that's because Ada comes with a type named String which
> behaves nothing at all like strings in C or C++, being just
> a name for an array of characters, which may be declared with
> runtime bounds or returned from a function but is then fixed
> in size.
>
> The concept is foreign to C programmers, for whom arrays in
> expressions decay to pointers, and which cannot be passed or
> returned by value. And I'll bet that *no one explains this*
> when teaching Ada. The semantic gap becomes so large that it's
> no wonder that C programmers wind up frustrated when trying to
> do simple things that work properly in their old language.

That's an interesting observation, Hyman.  Out of genuine curiosity, do  
you feel that Simon Johnston's tutorial addresses is reasonably?

http://www.adahome.com/Ammo/cpp2ada.html#1.1.3

- Ed

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Ed Falis wrote:
> That's an interesting observation, Hyman.  Out of genuine curiosity, do  
> you feel that Simon Johnston's tutorial addresses is reasonably?
> http://www.adahome.com/Ammo/cpp2ada.html#1.1.3

No, it's a complete hash. Isn't it wrong as well? It claims that 0
can't be used as a lower bound for String. This "tutorial" is exactly
what I was talking about - something which will utterly confuse C
programmers, because it does nothing to address them on terms they
understand, having come from an environment where strings are
variable-sized sequences within fixed-length buffers, with a null
character as an end marker.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Hyman Rosen wrote:

> No, it's a complete hash. Isn't it wrong as well? It claims that 0
> can't be used as a lower bound for String.

Why ask here?  You can write a couple of lines in Ada, and look at the 
error message you get.

Now, putting on my language lawyer hat Hyman is "correct" but for normal 
use the tutorial is fine.  You can define a null String in Ada as:

Foo: String(0..-1);

and while declaring:

Bar: String(0..1) := "  ";

is legal most compilers will provide a warning that Constraint_Error 
will be raised at run time.  With GNAT 3.15p, the program:

procedure String_Test is
   Foo: String(0..-1);
   Bar: String(0..1) := "  ";
begin null; end;

Compiles, but with the warning:
string_test.adb:3:15: warning: static value out of range of type 
"Standard.Positive"
string_test.adb:3:15: warning: "Constraint_Error" will be raised at run time

> This "tutorial" is exactly
> what I was talking about - something which will utterly confuse C
> programmers, because it does nothing to address them on terms they
> understand, having come from an environment where strings are
> variable-sized sequences within fixed-length buffers, with a null
> character as an end marker.

So it tells them to use Ada.Strings.Unbounded: "To overcome the 
constraint problem for strings Ada has a predefined package 
Ada.Strings.Unbounded which implements a variable length string type." 
Again, as a language lawyer, I would suggest both Bounded and Unbounded 
and explain the differences, but that is not the object of this tutorial.

-- 

                                           Robert I. Eachus

The ideology he opposed throughout his political life insisted that 
history was moved by impersonal tides and unalterable fates. Ronald 
Reagan believed instead in the courage and triumph of free men and we 
believe it all the more because we saw that courage in him.  -- George 
W. Bush June 11, 2004

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Robert I. Eachus wrote:
> Now, putting on my language lawyer hat Hyman is "correct"

Oh, sorry, I was just wrong. I didn't realize that String
was indexed by Positive. Remeber, I don't know Ada (and I
don't have an Ada compiler installed at the office!)

The problem is that as a tutorial, I don't think that it
actually teaches. That is, it makes perfect sense to Ada
programmers who already know how to do this stuff. I don't
think it makes any sense to an Ada newbie who is trying to
figure out how to work with strings in Ada to accomplish
what he was doing in C.

Just for example, it is ubiquitous in C to have arrays of
strings, either with or without a null pointer terminator:
     const char *colors[] = { "Red", "Green", "Blue", 0 };
     const char *CMYK[] = { "Cyan", "Magenta", "Yellow", "Black" };
How do you carry this over into Ada?

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> Just for example, it is ubiquitous in C to have arrays of
> strings, either with or without a null pointer terminator:
>      const char *colors[] = { "Red", "Green", "Blue", 0 };
>      const char *CMYK[] = { "Cyan", "Magenta", "Yellow", "Black" };
> How do you carry this over into Ada?

As you've done in C, using pointers (I mean access types :):

   type String_Access is access constant String;
   type Color_Set is array (Positive range <>) of String_Access;

   Red   : aliased constant String := "Red";
   Green : aliased constant String := "Green";
   Blue  : aliased constant String := "Blue";

   Colors : constant Color_Set := (Red'Access, Green'Access, Blue'Access);

No need for a "null" terminator. In Ada we have the array bounds:

   for K in Colors'Range loop
      ...
   end loop;

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Pascal Obry wrote:
> Hyman Rosen <hyrosen@mail.com> writes:
>>How do you carry this over into Ada?
> 
> As you've done in C, using pointers (I mean access types :):
> 
>    type String_Access is access constant String;
>    type Color_Set is array (Positive range <>) of String_Access;
> 
>    Red   : aliased constant String := "Red";
>    Green : aliased constant String := "Green";
>    Blue  : aliased constant String := "Blue";
> 
>    Colors : constant Color_Set := (Red'Access, Green'Access, Blue'Access);

Good; someone should add this to a tutorial for people converting.
I think Dale Stanbrough said that he's maintaining notes on this.

I think there's a pleasant symmetry between this code in Ada
and enumeration types in C and C++. Here you need to create a
variable for each string, and in C you need to create separate
strings for printing enumeration literals, while Ada provides
this for you.

> No need for a "null" terminator. In Ada we have the array bounds:

In C also, but just as with strings and buffers, in C these arrays
of pointers are sometimes populated dynamically and a null pointer
is used to indicate the end.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Pascal Obry wrote:
:>    Colors : constant Color_Set := (Red'Access, Green'Access, Blue'Access);
: 
: Good; someone should add this to a tutorial for people converting.

(And add a note that new String'("bla") need not mean dynamic heap
allocation, for example at library level.)

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Brian May]

>>>>> "Georg" == Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

    Georg> (And add a note that new String'("bla") need not mean dynamic heap
    Georg> allocation, for example at library level.)

Any chance you could please expand on this statement? How else could
it be implemented? What does GNAT do?

Thanks.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Georg Bauhaus]

Brian May <bam@snoopy.apana.org.au> wrote:
:>>>>> "Georg" == Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:    Georg> (And add a note that new String'("bla") need not mean dynamic heap
:    Georg> allocation, for example at library level.)
: 
: Any chance you could please expand on this statement? How else could
: it be implemented? What does GNAT do?

An assembly listing for the following program shows no occurence
of an allocator for Lib.fixed, and one occurence for dyn in main.
Here is the library part.

package Lib is

   type String_Access is access constant String;

   fixed: constant String_Access := new String'("AZAZAZ");

end Lib;

; ************* Initialized part of the global segment :

    000000 lib.fixed        DD  __lcl.00000015
    000004 __lcl.00000015   DD  00000001
                            DD  00000006
                            DB  41
                            DB  5A
                            DB  41
                            DB  5A
                            DB  41
                            DB  5A
; ********* End of segment, Total size = 18

To me, this looks like the String "AZAZAZ", with bounds 1 and 6.
The listing has been produced by ObjectAda 722, GNAT appears to behave
similarly.

with Lib;

procedure main is
   dyn: Lib.String_Access;
   n: Positive := 4;
   --  to prevent the compiler from "knowing" that lib.fixed(2..4) can be
   --  determined in advance, see the following statement.
begin
   dyn := new String'(Lib.fixed(2..n));
end main;

For this, I get MOVements for dyn, and n, then a small calculation,
then a CALL rts_allocate.
Then some instructions referring to __lcl.00000015 from above the
lib.fixed character bytes, then a CALL _rts_block_move.

So my guess is that the allocation happens for dyn, but not for fixed.
(I don't read ASM fluently though, and neither Power PC assembler, so
take this with a grain of salt.)

IIRC, this has been discussed before.


-- Georg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Brian May]

>>>>> "Pascal" == Pascal Obry <pascal@obry.org> writes:

    Pascal> As you've done in C, using pointers (I mean access types :):

    Pascal> type String_Access is access constant String;
    Pascal> type Color_Set is array (Positive range <>) of String_Access;

    Pascal> Red   : aliased constant String := "Red";
    Pascal> Green : aliased constant String := "Green";
    Pascal> Blue  : aliased constant String := "Blue";

    Pascal> Colors : constant Color_Set := (Red'Access, Green'Access, Blue'Access);

Would this work without pointers? If not, why not? eg:

type Color_Set is array (Positive range <>) of String;

Red   : constant String := "Red";
Green : constant String := "Green";
Blue  : constant String := "Blue";

Colors : constant Color_Set := (Red, Green, Blue);
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Martin Dowie]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4659ppz44.fsf@snoopy.apana.org.au...
> >>>>> "Pascal" == Pascal Obry <pascal@obry.org> writes:
>
>     Pascal> As you've done in C, using pointers (I mean access types :):
>
>     Pascal> type String_Access is access constant String;
>     Pascal> type Color_Set is array (Positive range <>) of String_Access;
>
>     Pascal> Red   : aliased constant String := "Red";
>     Pascal> Green : aliased constant String := "Green";
>     Pascal> Blue  : aliased constant String := "Blue";
>
>     Pascal> Colors : constant Color_Set := (Red'Access, Green'Access,
Blue'Access);
>
> Would this work without pointers? If not, why not? eg:
>
> type Color_Set is array (Positive range <>) of String;
>
> Red   : constant String := "Red";
> Green : constant String := "Green";
> Blue  : constant String := "Blue";
>
> Colors : constant Color_Set := (Red, Green, Blue);

No because String is an unconstrained type. You could have

type Colour_Set is array (Positive) range <>) of String (1 .. 5);

Red : constant Sgtring := "  Red";
Green : constant String := "Green";
Blue : constant String := "Blue";

Colours : constant Colour_Set (Red, Green, Blue);

But that's not quite the same thing... (i.e. not a ragged array).

Cheers

-- Martin

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Martin Dowie wrote:

> No because String is an unconstrained type. You could have
> 
> type Colour_Set is array (Positive) range <>) of String (1 .. 5);
> 
> Red : constant Sgtring := "  Red";
> Green : constant String := "Green";
> Blue : constant String := "Blue";
> 
> Colours : constant Colour_Set (Red, Green, Blue);
> 
> But that's not quite the same thing... (i.e. not a ragged array).

Ah, but you could use Ada.Strings.Bounded:

with Ada.Strings.Bounded;
...
package Color_Strings is new Ada.Strings.Bounded(12);
-- or your choice of bound...

subtype Color_Name is Color_Strings.Bounded_String;

function "+"(Source: in String) return Color_Name is
begin return Color_Strings.To_Bounded_String(Source); end "+";
...
Red: constant Color_Name := +"Red";
Green: constant Color_Name := +"Green";
Blue: constant Color_Name := +"Blue";
Aquamarine: constant Color_Name := +"Aquamarine";
...
type Color_Set is array (Positive range <>) of Color_Name;

Colors: constant Color_Set := (Red, Blue, Green, Aquamarine);

-- Add "u" as appropriate, if you live in Blighty. ;-)

You could also use Unbounded_Strings, but this is the perfect 
application for Bounded_String.  A lot of short strings, of size known 
at compile time.  The other case where I use Bounded_String a lot is in 
binding to databases.  If a text field has a specific length, using 
Bounded_String makes it easy to detect strings too long before starting 
a database transaction.

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Ragged arrays of strings (Was: Improving Ada's image)

[Jacob Sparre Andersen]

Pascal Obry wrote:

>    type String_Access is access constant String;
>    type Color_Set is array (Positive range <>) of String_Access;
> 
>    Red   : aliased constant String := "Red";
>    Green : aliased constant String := "Green";
>    Blue  : aliased constant String := "Blue";
> 
>    Colors : constant Color_Set := (Red'Access, Green'Access, Blue'Access);

I tend to use Ada.Strings.Unbounded for ragged arrays of strings.  I
suppose it gives a larger overhead than an array of pointers to
constant strings, but I like to avoid having to define the
intermediate objects (here the aliased constants Red, Green and Blue)
explicitly.

Jacob
-- 
"Nobody writes jokes in base 13."
 Douglas Adams

Re: Ragged arrays of strings (Was: Improving Ada's image)

[Pascal Obry]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Pascal Obry wrote:
> 
> >    type String_Access is access constant String;
> >    type Color_Set is array (Positive range <>) of String_Access;
> > 
> >    Red   : aliased constant String := "Red";
> >    Green : aliased constant String := "Green";
> >    Blue  : aliased constant String := "Blue";
> > 
> >    Colors : constant Color_Set := (Red'Access, Green'Access, Blue'Access);
> 
> I tend to use Ada.Strings.Unbounded for ragged arrays of strings.  I

I too. But the question was to give an Ada equivalence to some C code
posted. I think my proposal is closer to using Unbounded_String.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Hyman Rosen wrote:

> Just for example, it is ubiquitous in C to have arrays of
> strings, either with or without a null pointer terminator:
>     const char *colors[] = { "Red", "Green", "Blue", 0 };
>     const char *CMYK[] = { "Cyan", "Magenta", "Yellow", "Black" };
> How do you carry this over into Ada?

Others have answered as well, but I carry it over into Ada as:

type Colors is (Red, Green, Blue);
type CMYK is (Cyan, Mageneta, Yellow, Black);

Now if the "spelling" of the name is needed:

X: CMYK;
...
Put_Line(CMYK'Image(X));

I do think it is a shame though that Ada returns the upper case version 
of the name, not the spelling used to declare the type...

This is in part why writing an Ada tutorial for C programmers is so 
hard.  It is not that hard to write C code in Ada, and even get the 
compiler to produce identical executable code.  The problem is that the 
_questions_ that the Ada progammer thinks about are very different from 
those that come up when programming in C.

In this case you have been offered two ways to program a ragged array in 
Ada, one in which the pointer is explicit Red'Access, one in which it is 
implicit, Unbounded_String, and one where the ragged array is created by 
the compiler as part of the type declaration.

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Jeffrey Carter]

Robert I. Eachus wrote:
> 
> In this case you have been offered two ways to program a ragged array in 
> Ada, one in which the pointer is explicit Red'Access, one in which it is 
> implicit, Unbounded_String, and one where the ragged array is created by 
> the compiler as part of the type declaration.

Our 3 main weapons are ...

-- 
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[tmoran]

>In this case you have been offered two ways to program a ragged array in
>Ada, one in which the pointer is explicit Red'Access, one in which it is
>implicit, Unbounded_String, and one where the ragged array is created by
>the compiler as part of the type declaration.
A third (fourth?) way is
  type Top_Succession is (President, Vice_President, Speaker,
                      Senate_President_pro_tempore, Sec_State,
                      Sec_Treasury);
  function Name(Who : Top_Succession) return String is
  begin
    case Who is
      when President                     => return "Bush";
      when Vice_President                => return "Cheney";
      when Speaker                       => return "Hastert";
      when Senate_President_pro_tempore  => return "Stevens";
      when Sec_State                     => return "Powell";
      when Sec_Treasury                  => return "Snow";
    end case;
  end Name;
This, unlike Red=>"RED", allows for change in the value/string relationship.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Dr. Adrian Wrigley]

On Sat, 19 Jun 2004 16:54:14 -0400, Robert I. Eachus wrote:

> I do think it is a shame though that Ada returns the upper case version 
> of the name, not the spelling used to declare the type...

I strongly agree with this view!

It is an enormous extra effort to get the case right when outputting
an enumeration in a program.  In particular, you probably end up
having to declare and pass "To_String" functions as additional
parameters to generic packages etc., simply to get the casing right.

When you don't go to the effort of fixing up the case, and just
ouput all upper case, it makes it look like software from the '70s.

Is it not possible to do *something* about this irksome (if minor)
feature for the upcoming 200Y compilers.  Maybe a Representation
clause?  An additional attribute?  A compiler option? A pragma?
It seems like such a minor amount of work to fix this!

Would the incompatibility be unnacceptable (to 200Y) simply to state that
the case of Enum'Image is exactly as in the declaration.
It could break certain (odd) programs, but that is what the -95 switch
is there for.

I could post some examples where getting the case wrong is
particularly bad - but you can probably make up some of your own.
-- 
Adrian Wrigley, Cambridge, UK.

Enum'Image (Was: Improving Ada's image)

[Jacob Sparre Andersen]

Adrian Wrigley wrote:
> Robert I. Eachus wrote:

> > I do think it is a shame though that Ada returns the upper case
> > version of the name, not the spelling used to declare the type...
> 
> I strongly agree with this view!

I am not sure I support it.  But there is definitely a point.

> Is it not possible to do *something* about this irksome (if minor)
> feature for the upcoming 200Y compilers.  Maybe a Representation
> clause?

That would probably be the best way to do it.  It would keep old
programs working, and it seems like a logical Ada-like way of doing
things.

   type Colours is (Red, Green, Blue);
   for Red'Image use "R";
   for Green'Image use "G";
   for Blue'Image use "B";

> Would the incompatibility be unnacceptable (to 200Y) simply to state
> that the case of Enum'Image is exactly as in the declaration.

I think it would.

Jacob
-- 
"It is very easy to get ridiculously confused about the
 tenses of time travel, but most things can be resolved
 by a sufficiently large ego."

Re: Enum'Image (Was: Improving Ada's image)

[Dr. Adrian Wrigley]

On Mon, 21 Jun 2004 17:30:19 +0200, Jacob Sparre Andersen wrote:
...
> That would probably be the best way to do it.  It would keep old
> programs working, and it seems like a logical Ada-like way of doing
> things.
> 
>    type Colours is (Red, Green, Blue);
>    for Red'Image use "R";
>    for Green'Image use "G";
>    for Blue'Image use "B";

Potentially useful - but very verbose in the simple case.  If it
takes fifteen lines of code to declare an enumeration with
nicely cased 'Image, the critics would have a field day!
Keeping the representations and enumeration synced would be
unnecessary work.

Something to say "use the names spelled as I spell them" is
needed.

pragma Enum_Image_Case (Colours, Verbatim|Upper|Lower|...);

Of course, if we had had Verbatim from the start, we could have
use To_Upper, To_Lower if we wanted :(  And I can't recall any
situation where I wanted the case of the enumerations converted
as the language specifies.
-- 
Adrian Wrigley, Cambridge, UK.

Re: Enum'Image (Was: Improving Ada's image)

[Alexander E. Kopilovich]

"Dr. Adrian Wrigley" wrote:

> Something to say "use the names spelled as I spell them" is
> needed.
>
> pragma Enum_Image_Case (Colours, Verbatim|Upper|Lower|...);
>
> Of course, if we had had Verbatim from the start, we could have
> use To_Upper, To_Lower if we wanted :(  And I can't recall any
> situation where I wanted the case of the enumerations converted
> as the language specifies.

Perhaps the best solution would be to add second argument to Image attribute,
with the sngle possible value Verbatim. That is, you'll write

  Enum'Image(My_Variable, Verbatim)

If you do not use that second argument then the Image attribute acts with
the default (currently standard) way; I don't think that additional values
for that second argument - Upper, Lower, etc, will be good things - I believe
that in those cases explicit translation by a function call is better than
loading the attribute with excess functionality.





Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Enum'Image (Was: Improving Ada's image)

[Jacob Sparre Andersen]

Alexander E. Kopilovich wrote:
> Adrian Wrigley wrote:

> > Something to say "use the names spelled as I spell them" is
> > needed.

Good point.

> Perhaps the best solution would be to add second argument to Image
> attribute, with the sngle possible value Verbatim. That is, you'll
> write
> 
>   Enum'Image(My_Variable, Verbatim)

Why not also allow "Upper_Case" and "Lower_Case"?

The problem with this compared to a representation clause (whether
common for the enumeration type or on a per item basis) is that it
will complicate the Enum'Image function.  I don't know if it is an
acceptable complication or not.

> If you do not use that second argument then the Image attribute acts
> with the default (currently standard) way; I don't think that
> additional values for that second argument - Upper, Lower, etc, will
> be good things - I believe that in those cases explicit translation
> by a function call is better than loading the attribute with excess
> functionality.

Once you have added an extra Enum'Image function, I don't think _also_
adding a lower case version is a big deal.

Using Adrian Wrigley's suggestion, but keeping the view that it is a
representation issue, it could be done with:

   for Enumeration_Type'Image use (Verbatim|Upper_Case|Lower_Case);

and optionally in addition with:

   for Enumeration_Literal'Image use string_constant;

for individual enumeration_literals of the enumeration_type.

Jacob
-- 
"There is a slight error in the exponent" - quantum vaacum
 mass is 10^35 times the total dark matter mass

Re: Enum'Image (Was: Improving Ada's image)

[Alexander E. Kopilovich]

Jacob Sparre Andersen wrote:

> >   Enum'Image(My_Variable, Verbatim)
>
> Why not also allow "Upper_Case" and "Lower_Case"?

Because you always can do these conversions later in your code. Providing
all those translations in any form (attribute, "for ... use" clause or pragma)
is just a redundant feature, perhaps convenient for some relatively rare
programs but  nothing more than that. But Verbatim case is different -
you can't restore by you code an information that is already lost; so this
Verbatim just prevent loss of information, which was present in the source
code.

But even the possibility of Verbatim seems somehow doubtful because it will
slightly violate the rule of case insensitivity for names in Ada programs.
That is, with this Verbatim option the behaviour of a program can depend on
the case of the letters used inside the names in enums. One can argue that
those names in enums resemble literals and therefore the case insensitivity
rule should not be applied to them, but this is a problematic issue, I think.

And anyway, it may be practically impossible for some compilers: if a compiler 
currently translate identifiers (including those from enums) before storing
them in the symbol table then it probably would be not a small pain to change
that tactics.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Enum'Image (Was: Improving Ada's image)

[Larry Kilgallen]

In article <mailman.145.1088005291.391.comp.lang.ada@ada-france.org>, "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:

>> >   Enum'Image(My_Variable, Verbatim)

> But even the possibility of Verbatim seems somehow doubtful because it will
> slightly violate the rule of case insensitivity for names in Ada programs.
> That is, with this Verbatim option the behaviour of a program can depend on
> the case of the letters used inside the names in enums. One can argue that
> those names in enums resemble literals and therefore the case insensitivity
> rule should not be applied to them, but this is a problematic issue, I think.

I was under the impression that the only situations where people cared
about cases of enumerals were when it was converted to a string.  This
does not seem a departure from:

	IF "ABC" = "abc"
	THEN
		NULL; -- never gets here
	ENDIF;

Re: Enum'Image (Was: Improving Ada's image)

[Dmitry A. Kazakov]

On 21 Jun 2004 17:30:19 +0200, Jacob Sparre Andersen <sparre@nbi.dk>
wrote:

>Adrian Wrigley wrote:
>> Robert I. Eachus wrote:
>
>> > I do think it is a shame though that Ada returns the upper case
>> > version of the name, not the spelling used to declare the type...
>> 
>> I strongly agree with this view!
>
>I am not sure I support it.  But there is definitely a point.
>
>> Is it not possible to do *something* about this irksome (if minor)
>> feature for the upcoming 200Y compilers.  Maybe a Representation
>> clause?
>
>That would probably be the best way to do it.  It would keep old
>programs working, and it seems like a logical Ada-like way of doing
>things.
>
>   type Colours is (Red, Green, Blue);
>   for Red'Image use "R";
>   for Green'Image use "G";
>   for Blue'Image use "B";
>
>> Would the incompatibility be unnacceptable (to 200Y) simply to state
>> that the case of Enum'Image is exactly as in the declaration.
>
>I think it would.

All attributes should primitive operations and all types should have
T'Class. That would make the trick.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Enum'Image (Was: Improving Ada's image)

[Frank J. Lhota]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:pl4qp57wtw.fsf_-_@sparre.crs4.it...
> That would probably be the best way to do it.  It would keep old
> programs working, and it seems like a logical Ada-like way of doing
> things.
>
>    type Colours is (Red, Green, Blue);
>    for Red'Image use "R";
>    for Green'Image use "G";
>    for Blue'Image use "B";

As an alternative, how about the ability to write your own Image function?

If I had the task of inventing Ada over again, I would make cut a lot of the
attribute functions (such as 'Max, 'Image, 'Value, etc.) and replace them
with inherited subprograms that the programmer would be free to override. In
other words, if you declare

    type Colours is (Red, Green, Blue);

then this type would inherit the function

    function Image( X : in Colours ) return String;

and this inherited function would return one of the strings "RED", "GREEN",
or "BLUE". If this is unacceptable, you could override this version of Image
by writing your own version, and declaring it in the same scope as the type
definition:

    type Colours is (Red, Green, Blue);
    function Image( X : in Colours ) return String;

If Image worked this way, instead of being an attribute, it would be
completely customizable. We can return results in any letter case: upper,
lower, mixed, or custom. The result of Image can contain spaces when this
aids readability. Image can be internationalized, e.g. we can have
Image(Red) return "Red" if the locale is U.S., but return "Rouge" if the
locale is France. The possibilities would be endless.

Re: Enum'Image

[Jacob Sparre Andersen]

Frank J. Lhota wrote:

> As an alternative, how about the ability to write your own Image
> function?

Definitely usable, but I would worry about:

 1) if my implementation was as efficient as the compiler supplied one

 2) 'Image and 'Value being each other's inverse

> If I had the task of inventing Ada over again, I would make cut a
> lot of the attribute functions (such as 'Max, 'Image, 'Value, etc.)
> and replace them with inherited subprograms that the programmer
> would be free to override.

I have had similar thoughts occasionally, but I am afraid there are
some sensible reasons that it isn't already like that?

Jacob
-- 
"Any newsgroup where software developers hang out is
 an Emacs newsgroup."

Re: Enum'Image

[Frank J. Lhota]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:plhdt05wkw.fsf_-_@sparre.crs4.it...
> Frank J. Lhota wrote:
>
> > As an alternative, how about the ability to write your own Image
> > function?
>
> Definitely usable, but I would worry about:
>
>  1) if my implementation was as efficient as the compiler supplied one

Possibly not, but presumably you would not write your own Image function
unless you desired something different from the compiler-supplied Image
funciton.

>  2) 'Image and 'Value being each other's inverse

This is similar to the situation with user-defined "+" and "-" operators;
you would also want them to be inverses, in that most people would expect
that

    ( A + B ) - B = A

There is no way, however, for the compiler to force user-defined "+" and "-"
to be inverses of each other, so that responsibility falls to the
programmer.

The same could be said of user-defined Image and Value functions. Yes, they
should be inverses, but that is left up to the programmer.

> > If I had the task of inventing Ada over again, I would make cut a
> > lot of the attribute functions (such as 'Max, 'Image, 'Value, etc.)
> > and replace them with inherited subprograms that the programmer
> > would be free to override.
>
> I have had similar thoughts occasionally, but I am afraid there are
> some sensible reasons that it isn't already like that?

Enumeration literals can be overloaded, so I have heard the argument that
attributes are needed to resolve overloading. For example, if we have the
types

    type Name_Of_Nutrient is ( Vitamin_A, Vitamin_B, ... Calcium, Iron,
... );
    type Name_Of_Appliance is ( Blender, Microwave, Iron, ... );

then if we have the function call

    Image( Iron )

is it referring to the Name_Of_Nutirent Iron or the Name_Of_Appliance Iron?
This problem goes away if the Image function is an attribute, for then we
would write

    Name_Of_Nutrient'Image( Iron )

making it clear what the type of Iron we are taking about.

This is one way to resolve the ambiguity. Another way would be to use
qualified expressions. If Image was overloaded for these two enumeration
types, we could also clarify this function call by writing:

    Image ( Name_Of_Nutrient'( Iron ) )

> Jacob
> -- 
> "Any newsgroup where software developers hang out is
>  an Emacs newsgroup."

Re: Enum'Image (Was: Improving Ada's image)

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:pl4qp57wtw.fsf_-_@sparre.crs4.it...
> Adrian Wrigley wrote:
> > Would the incompatibility be unnacceptable (to 200Y) simply to state
> > that the case of Enum'Image is exactly as in the declaration.
>
> I think it would.

Yes, definitely. The problem (ironically) would be all of those little
functions to convert the case of enumerations. Code like that is likely to
assume that the input is upper case, and if that changed, it would silently
break, outputing gibberish.

In any case, Text_IO.Enumeration_IO does let you set the case of the output.
(It could use a Mixed_Case option, though). Remember that 'image is for Q&D
output, not the fancy stuff (something we all forget often).

                   Randy.

Re: Enum'Image (Was: Improving Ada's image)

[Dr. Adrian Wrigley]

On Wed, 23 Jun 2004 15:29:23 -0500, Randy Brukardt wrote:
...
> In any case, Text_IO.Enumeration_IO does let you set the case of the
> output. (It could use a Mixed_Case option, though). Remember that 'image
> is for Q&D output, not the fancy stuff (something we all forget often).

I fear that none of the proposed solutions would be without
heavy (perhaps reasonably justified) criticism from some quarters.

A Mixed_Case option in Enumeration_IO seems pretty harmless though.
I guess we have to wait another ten years for a chance of this
to appear though :(  (Ada 201Z) (I presume it can't be sneaked
in to '0Y :()

Most of the suggestions fail to get the right case for enumeration output
from generic functions, where the type has been passed as a parameter.
Possibiliies that get this right are rejected as having the
potential to break existing code.

Saying that 'Image is for Q&D programming might be true, but ignores
the fact that that's what programmers often want.  Ada is sometimes
shunned because of the presumed costs of meeting the language discipline.
In my experience, however, Ada is well suited to Q&D programming,
because the integrity and clarity of the interfaces, and exceptionally
low debugging time.

Having to define functions that simply convert each enumeration
into the corresponding string, then passing them as generic
parameters really grates against my aesthetic sense, particularly
since it just seems to be working around a language mis-feature.

Curiously, when I first came across the 'Image function attribute
(actually in VHDL, IIRC), I automatically assumed you could
provide your own (as others here have suggesed).  I was quickly
disappointed to find out just how limited it was.

Here's a few enumerations that really need verbatim output of case:
Ada, COBOL, Pascal, PostScript - languages
kWh, Joules, kCal  - energy units
ms, MS             - milliseconds? megasiemens?
Mbps, MBPS, mbps   - megabits per second? millibytes per second?
nVIDIA, ATI, Intel, AMD  - technology companies

I guess there are much more important things for Ada users to
be worried about though...
-- 
Adrian

Re: Enum'Image (Was: Improving Ada's image)

[Jacob Sparre Andersen]

Adrian Wrigley wrote:
> Randy Brukardt wrote:

> > In any case, Text_IO.Enumeration_IO does let you set the case of
> > the output. (It could use a Mixed_Case option, though). Remember
> > that 'image is for Q&D output, not the fancy stuff (something we
> > all forget often).

It took a moment to decode "Q&D" as "quick and dirty".

> A Mixed_Case option in Enumeration_IO seems pretty harmless though.
> I guess we have to wait another ten years for a chance of this to
> appear though

Yes.  The 200Y deadline has passed.

> Most of the suggestions fail to get the right case for enumeration
> output from generic functions, where the type has been passed as a
> parameter.  Possibiliies that get this right are rejected as having
> the potential to break existing code.

How would this fail for the representation clauses?

> Saying that 'Image is for Q&D programming might be true, but ignores
> the fact that that's what programmers often want.  Ada is sometimes
> shunned because of the presumed costs of meeting the language
> discipline.  In my experience, however, Ada is well suited to Q&D
> programming, because the integrity and clarity of the interfaces,
> and exceptionally low debugging time.

Ada _is_ fine for quick and dirty programming.  But for quick and
dirty programming, it can hardly be said to be necessary to output
enumerations verbatim.

> Here's a few enumerations that really need verbatim output of case:
> Ada, COBOL, Pascal, PostScript - languages
> kWh, Joules, kCal  - energy units
> ms, MS             - milliseconds? megasiemens?
> Mbps, MBPS, mbps   - megabits per second? millibytes per second?
> nVIDIA, ATI, Intel, AMD  - technology companies

Remember that since Ada identifiers are case insensitive, you
shouldn't use enumerations for case-specific I/O.  And I am sure that
is not going to change.

Jacob
-- 
"Those who profess to favor freedom and yet depreciate
 agitation, are people who want crops without ploughing the
 ground; they want rain without thunder and lightning; they
 want the ocean without the roar of its waters."
                                        -- Frederick Douglas

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Robert I. Eachus wrote:

> I do think it is a shame though that Ada returns the upper case version 
> of the name, not the spelling used to declare the type...

This comment of mine seems to have touched a nerve.  So let's see if we 
can save the good parts of the discussion and turn them into something 
useful.

As I see it there are three approaches to solving the problem:  Explicit 
user code, compiler implemented langage extensions, and changes to the 
language.  I think we should agree that it is too late to chage the 
language this time around--although if there is an approach that is 
universally accepted, it could happen.  But first let's look at the 
candidates and see which fly and which get shot down.

I'll discuss user code first, then tomorrow sum up the other alternatives.

This is almost a "why didn't I think of that?" category. It is certainly 
no big deal to write:

function Image(S: Suit) return String is
begin return Suit'Image(S); end Image;

Then later when it is time to make the output look pretty change the 
body to:

function Image(S: Suit) return String is
begin
   case S is
       when Spades => return "Spades";
       when Hearts => return "Hearts";
       when Clubs => return "Clubs";
       when Diamonds => return "Diamonds";
   end case;
end Image;

or you can write:

with Ada.Characters.Handling;
   function Mixed (S: in String) return String is
     use Ada.Characters.Handling;
     Capitalize: Boolean := True;
     Result: String := S;
   begin
     for I in Result'Range loop
       if Capitalize
       then Result(I) := To_Upper(Result(I));
       else Result(I) := To_Lower(Result(I));
       end if;
       Capitalize := Result(I) = '_';
     end loop;
     return Result;
   end Mixed;

and:

type Direction is (North, NNE, NE, ENE, East, ESE, SE, SSE,
                    South, SSW, SW, WSW, West, WNW, NW, NNW);

function Image(D: Direction) return String is
    Result: String := D'Image;
begin
   if Result'Length < 4
   then return Result;
   else return Mixed(Result);
   end if;
end Image;

or:

type Color is (Red, Orange, Yellow, Blue, Green, Violet,
                White, Gray, Black, Brown, Pink);

function Image (C: Color) return String is
begin return Mixed(C); end Image;

It might be nice to add Mixed above to Ada.Characters.Handling as 
To_Mixed, but that is getting into other options. ;-)

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Jeffrey Carter]

Robert I. Eachus wrote:

> with Ada.Characters.Handling;
>   function Mixed (S: in String) return String is
>     use Ada.Characters.Handling;
>     Capitalize: Boolean := True;
>     Result: String := S;
>   begin
>     for I in Result'Range loop
>       if Capitalize
>       then Result(I) := To_Upper(Result(I));
>       else Result(I) := To_Lower(Result(I));
>       end if;
>       Capitalize := Result(I) = '_';
>     end loop;
>     return Result;
>   end Mixed;

Or use PragmARC.Mixed_Case.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail
23

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Robert I. Eachus wrote:

> I'll discuss user code first, then tomorrow sum up the other alternatives.

The compiler extension choices seem to rapidly evolve into a much more 
general feature, and one that is needed to support ASIS.  If there is a 
Spelling attribute for enumeration literals, why not support it for all 
variable names?  In fact, why not add it for types as well?  I'm not 
sure I can answer that, but the attribute for enumeration literals 
really needs to be useful in a loop.  You want to convert a value to a 
string, and the fact that it is also the name of an enumeration literal 
that masquerades as a subprogram is a language oddity.

But then again, how many times have you written:

type Color is (Red, Yellow, Green);
C: Color;
...
   Put(C'Image...

and then realized, that no it is Character'Image(C);  Of course, if you 
are using GNAT, you can change it to C'Img,  I guess GNAT could be 
modified to make Img return the original spelling for enumeration 
literals, but I'd much rather have a compiler switch to get that behavior.

Not that big a compiler change.  Will I do it?  No.  I'd rather use the 
methods I posted yesterday and keep the code 'pure' Ada 95 or Ada 05 or 
whatever.

Which leads to language changes.  I'm going to assume that changing 
'Image is a non-starter.  Why?  Well, we might as well implement any 
change the way GNAT implements 'Img, as an attribute of a type or an 
object.  I think if it were to be made a language change, it should be 
'Spelling not 'Img, or maybe there is some other option.

And I guess that is all I have to say on the subject.  It is easy enough 
to implement a 'pure' Ada function Image.  It would also be easy enough 
to add to existing compilers.  If enough people feel strongly that it 
should be done, the compiler vendors will take it from there.

As for me, I guess the only reason I would be in favor of a language 
change would be to get away from Character'Image(C); I think it is ugly, 
and the output you get is ugly too.

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Dale Stanbrough]

Hyman Rosen wrote:

> The concept is foreign to C programmers, for whom arrays in
> expressions decay to pointers, and which cannot be passed or
> returned by value. And I'll bet that *no one explains this*
> when teaching Ada. The semantic gap becomes so large that it's
> no wonder that C programmers wind up frustrated when trying to
> do simple things that work properly in their old language.

I thought I had this in my notes, but upon examination it seems not!
I'll have to update them to include this.

Thanks,

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

A trick would be to be sure to scope the thing down to something 
achievable yet still useful. Start with something that might already 
exist - like MaRTE or RTEMS. Get it working on some common platform and 
get a project whos aim might be low enough that it can be achieved in 
spare time work by those who might be able to make use of it.

But it needs a certain amount of common vision and an objective to aim 
for. I'm not an OS designer by trade, but I know enough about it that I 
can tell someone needs to have some notion of where the thing is going 
or it will just meander or stagnate. It might help if someone has some 
kind of "Theoretical OS Book" that covered something other than an 
inside look at Unix or Windows - something that said "One day, an OS 
could be built that would look like this and offer these advantages over 
existing systems...." If that theoretical groundwork were done, it might 
make the basis for some hobyist project implementing the thing in stages.

MDC


Warren W. Gay VE3WWG wrote:
> 
> Yep, but you need bodies of people willing to help. One or
> a few individuals can put together an operating system, but
> unless many people contribute towards hardward drivers, the
> project is not likely to gain general acceptance (at least
> on Intel). But even this, is an untested theory, in the
> Ada OS arena so far. ;-)


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Enum'Image (Was: Improving Ada's image)

[Larry Kilgallen]

In article <pld63o5w7p.fsf@sparre.crs4.it>, Jacob Sparre Andersen <sparre@nbi.dk> writes:
> Adrian Wrigley wrote:
>> Randy Brukardt wrote:
> 
>> > In any case, Text_IO.Enumeration_IO does let you set the case of
>> > the output. (It could use a Mixed_Case option, though). Remember
>> > that 'image is for Q&D output, not the fancy stuff (something we
>> > all forget often).
> 
> It took a moment to decode "Q&D" as "quick and dirty".

Yes, please do not write "C" in the Ada newsgroup :-)

>> Here's a few enumerations that really need verbatim output of case:
>> Ada, COBOL, Pascal, PostScript - languages

And here is one that will not be helped by the proposal

	Visual Basic

At that point one will still have to go back to the old

	function Printable ( Language : Language_Type ) return String is
	begin
		case Language of

		when Ada =>
			return "Ada";

		when COBOL =>
			return "COBOL";

		when Pascal =>
			return "Pascal";

		when PostScript =>
			return "PostScript";

		when Visual_Basic =>
			return "Visual Basic";
		end;

One advantage of Ada is the degree to which it helps the maintaining
programmer avoid an error.  The programmer charged with adding "Visual
Basic" to the list would have to re-invent the wheel if the original
programmer presumed that 'image would work for all future languages.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

Marin David Condic wrote:

>All the necessary tools exist. There's a free compiler, IDE, debugger, 
>GUI builder, etc., needed to go write apps in Ada.

Not so simple, though - it is not enough to have any tools for demonstrating
benefits of Ada, because main Ada's strength are in conveying information
(more properly and precisely than competing languages) - so you need some
information to convey.

And for a demo that should impress programming community, that information
must:

1) concern some generally known (and more or less interesting) things;
2) be complex at the same time precise enough;
3) be freely available and easily accessible.

Do you know a candidate that satisfies these conditions and still have no
reasonably good and solid implementation in, say, C/C++ ?




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Alexander E. Kopilovich wrote:

> Marin David Condic wrote:
>>All the necessary tools exist. There's a free compiler, IDE, debugger, 
>>GUI builder, etc., needed to go write apps in Ada.
...
> Do you know a candidate that satisfies these conditions and still have no
> reasonably good and solid implementation in, say, C/C++ ?

Unless that was a typo, I would think that the point
would be to compare _with_ an existing C/C++
implementation. Why compare where there is no
competition?
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

If someone dreams up something completely new and never been done 
before, that's wonderful.

If someone can dream up a better way of doing something that already 
exists, that's almost as good.

If someone can take an unstable, bug-ridden app and re-engineer it to be 
stable and reliable, that's still pretty good.

If someone re-implements a stable, reliable app in Ada and adds no new 
capabilities or features, that's interesting, but hardly worth anything 
to an end user.

I think those things should be considered in looking at existing apps 
built in C/C++. It doesn't need to be at the top of my list, but it 
shouldn't be at the bottom.

MDC



Warren W. Gay VE3WWG wrote:
> 
> Unless that was a typo, I would think that the point
> would be to compare _with_ an existing C/C++
> implementation. Why compare where there is no
> competition?


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

Warren W. Gay wrote:

> >>All the necessary tools exist. There's a free compiler, IDE, debugger, 
> >>GUI builder, etc., needed to go write apps in Ada.
> ...
> > Do you know a candidate that satisfies these conditions and still have no
> > reasonably good and solid implementation in, say, C/C++ ?
>
> Unless that was a typo, I would think that the point
> would be to compare _with_ an existing C/C++ implementation.

But I said "still have no reasonably good and solid implementation" - not just
any C/C++ implementation. I think that there is absolutely no reason to try
to compete with reasonably good and solid implementation; and after all you'll
definitely looe such a competition - because if your implementation even
appears better in some details/cases then C++ herd (remember that there are
many talented, skilled and experienced C++ programmers around) immediately
will produce new version of existing C++ implementation, in which they'll pay
enough attention to those not-so-good pieces of their code. And then they will
thank you for good benchmark/example -:) .

> Why compare where there is no competition?

Direct competition is just one and quite narrow and limited form of
comparison. In the case of powerful programming languages, such as Ada
and C++, a direct competition make little sense, if any.

Anyway, currently the aim to prove (for general programming community)
that Ada is better than C++ seems simply ridiculous. It will be great
if Ada proponents can point at one or two obviously good products written
in Ada - big and complex enough, open source, generally interesting (in
particular it should not be an Ada compiler or general-purpose Ada library,
like Charles), and there shouldn't be plenty of C++ analogs around, some
of them lighter while others more powerful (for example, Ada Web Server do not
qualify for that reason). So far I don't know any product of that kind.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Why does it have to be new? Why can't it simply be an innovative view on 
something that already exists? Why not an "Office Suite" or an 
accounting package or a photoshop package? Mostly, it requires taking a 
look at one of the hundreds or thousands of existing, successful 
products that are out there and saying "I think it would be a whole lot 
more effective or easier to use or otherwise better if only I were to 
implement it *this* way..." Or even something that just marries up two 
or more otherwise independent apps - like a Photoshop/Word 
Processor/Accounting Pacakge (if you want to reinvent the Swiss Army Knife.)

So what do you see on your computer that you wish was done a different way?

MDC

Alexander E. Kopilovich wrote:
> 
> Do you know a candidate that satisfies these conditions and still have no
> reasonably good and solid implementation in, say, C/C++ ?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[tmoran]

>something that already exists? Why not an "Office Suite" or an
How about a decent replacement for Outlook.  That would surely be greeted
with tremendous demand.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

I've found Outlook to be bloated, slow, etc. That might make a good 
candidate. Perhaps with a philosophy of not trying to build the Swiss 
Army Knife of e-mail programs: Build the various functions as 
independent units (capable of working together) so that you don't need 
to load/run the pieces you don't want or for which you have a substitute 
(like an address book). That might be a concept that could work well & 
find some popularity in the user community. Perhaps even making it work 
in conjunction with OpenOffice might help?

Of course, there's always the question: "How do we make some money on 
this?" If we don't do that, there are no salaries & no funding of 
vendors. Open Source might be a good way to get it out into the world, 
but would people pay for it in some way?

MDC



tmoran@acm.org wrote:
>>something that already exists? Why not an "Office Suite" or an
> 
> How about a decent replacement for Outlook.  That would surely be greeted
> with tremendous demand.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Brian May]

>>>>> "Marin" == Marin David Condic <nobody@noplace.com> writes:

    Marin> I've found Outlook to be bloated, slow, etc. That might
    Marin> make a good candidate. Perhaps with a philosophy of not

I don't think so...

You are comparing an incredibly poorly designed, poorly written,
insecure application written in C (I assume), with presumably a
properly designed and written application in Ada.

To conclude that the second one is better then the first because of
the choice of language is a bit misleading IMHO. In fact, my guess is
a number of the security flaws in Outlook would also occur in Ada.
eg. look at the JavaScript related security issues.

    Marin> trying to build the Swiss Army Knife of e-mail programs:
    Marin> Build the various functions as independent units (capable
    Marin> of working together) so that you don't need to load/run the
    Marin> pieces you don't want or for which you have a substitute
    Marin> (like an address book). That might be a concept that could
    Marin> work well & find some popularity in the user
    Marin> community. Perhaps even making it work in conjunction with
    Marin> OpenOffice might help?

Do you load these units at compile time, start-up time (when
application starts), or on demand (eg. when user selects address
book)?

Loading units at compile time is fast and efficient as far as the user
is concerned, but means recompiling for adding a new unit. The other
options are more flexible as far as the user is concerned, but may
result in slower execution while the units load and initialize, and
may require more overhead to keep track of the different units at
run-time.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Brian May wrote:
> I don't think so...
> 
> You are comparing an incredibly poorly designed, poorly written,
> insecure application written in C (I assume), with presumably a
> properly designed and written application in Ada.
> 
> To conclude that the second one is better then the first because of
> the choice of language is a bit misleading IMHO. In fact, my guess is
> a number of the security flaws in Outlook would also occur in Ada.
> eg. look at the JavaScript related security issues.
> 

You are missing the point. I'm not comparing Outlook to a theoretical 
Ada-Outlook. Outlook is merely an example of a type of app that someone 
might imagine a better way of doing. Its an 
e-mail/news-reader/address-book and probably a few other things as well. 
It has weaknesses at a conceptual level that someone might be able to 
dream up a better way of doing. (Like not having it try to do all these 
different jobs all in the same package)


> 
> Do you load these units at compile time, start-up time (when
> application starts), or on demand (eg. when user selects address
> book)?
> 
> Loading units at compile time is fast and efficient as far as the user
> is concerned, but means recompiling for adding a new unit. The other
> options are more flexible as far as the user is concerned, but may
> result in slower execution while the units load and initialize, and
> may require more overhead to keep track of the different units at
> run-time.

Now you're running off and designing it without really knowing what to 
design. Start with a list: "What I don't like about the way Office does 
what it does..." When you get done with that list, start another list: 
"The capabilities, features, functions, options, etc. that I would put 
into a similar app if I was the Product Manager for Outlook..." When 
you've done that, you're a considerable step closer to deciding if it is 
going to be one monolithic app or an install-time-configurable app or a 
half a dozen independent apps.

In between the lists and deciding what the app(s) should generally look 
like, it might be a good idea to do a little "Marketing Survey" to try 
to see if your concepts of what is wrong with Outlook and what you'd 
like to see in an alternative are things that are generally shared by 
enough of the rest of the world to make sure you're not trying to build 
an app nobody wants.

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

Marin David Condic wrote:

> Why does it have to be new? Why can't it simply be an innovative view on 
> something that already exists?

Certainly that will be OK also. Just a little problem - where to get that
innovative view? -:)  And not just innovative, but also still not covered by
some wild patent -;) .
 
> Why not an "Office Suite" or an 
> accounting package or a photoshop package?

It would be very easy to answer for that in Russian -:) , but my poor English
severely limits me at this point. Well, I just can't imagine that anyone who
had at least slight experience with those products will try to re-implement
them for free (in any language, including Ada). The obvious problem there is
in requirements: these kinds of products have particularly big and complex and
worse of all - fuzzy - sets of requirements. With any innovative view you may
succeed to satisfy major part of them - but far from all (inevitably, because
you don't know them), and that will topple your product... if you aren't
supported by some strong external source.

> Mostly, it requires taking a 
> look at one of the hundreds or thousands of existing, successful 
> products that are out there and saying "I think it would be a whole lot 
> more effective or easier to use or otherwise better if only I were to 
> implement it *this* way..." Or even something that just marries up two 
> or more otherwise independent apps - like a Photoshop/Word 
> Processor/Accounting Pacakge (if you want to reinvent the Swiss Army Knife.)

Brilliant business plan... but why Ada? - this is obviously for Java... or
at least for C#/.NET,,, but still better for Java.

> So what do you see on your computer that you wish was done a different way?

Hm... a pen instead of the mouse (option)... a handheld or smartphone instead
of the mouse (another option)... an expandable directory tree inside a folder
(option) - sometimes I don't like to switch folders while browsing directories
... ability to change manually the order of items on the taskbar. Seems that
there is nothing relevant to Ada among these wishes -:)




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Lots of thoughtful comments, but let me address just this one. I had not 
thought of hardware devices on a PC until you brought it up. An 
excellent view, too. Why not try to cash in on the coming tide wherein 
the PC in your home is going to start merging with your other electronic 
appliances? Like why not develop some kind of telephone applications & 
work with Voice Over IP? I'm not sure what - but its a road down which 
you could let your mind wander & see if you come up with something 
creative...

MDC


Alexander E. Kopilovich wrote:
> 
> Hm... a pen instead of the mouse (option)... a handheld or smartphone instead
> of the mouse (another option)... an expandable directory tree inside a folder
> (option) - sometimes I don't like to switch folders while browsing directories
> ... ability to change manually the order of items on the taskbar. Seems that
> there is nothing relevant to Ada among these wishes -:)
> 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

Hyman Rosen wrote:

> Wouldn't you be confused if someone ran around shouting that a
> perfectly well-dressed man was actually naked?

Well, I would not be confused if this happens somewhere in tropical lands
and that well-dressed/naked man is one of native inhabitants.

Similarly for "reliable secure" OSes - I easily can see reasons for calling,
for example, Windows 2000, both reliable and secure (because it is well alive
against awful amount of pressure) and at the same time - both unreliable and
insecure (because very many users were affected by various vulnerabilities
in this OS).

I don't know any good definition for "reliable and secure OS", and I don't
think that there is such a definition. Is QNX (probably written C) reliable
and secure? Perhaps yes, but one can say that it has not enough users or that
it isn't general-purpose OS. Was Multics reliable and secure? Perhaps yes,
but one can say that it was not tested in an environment comparable with that
in which Windows live - millions of users, many of them almost illiterate and
some of then wicked.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Dave Thompson]

On Tue, 15 Jun 2004 05:21:12 +0400 (MSD), "Alexander E. Kopilovich"
<aek@VB1162.spb.edu> wrote:

> I don't know any good definition for "reliable and secure OS", and I don't
> think that there is such a definition. Is QNX (probably written C) reliable
> and secure? Perhaps yes, but one can say that it has not enough users or that
> it isn't general-purpose OS. Was Multics reliable and secure? Perhaps yes,
> but one can say that it was not tested in an environment comparable with that
> in which Windows live - millions of users, many of them almost illiterate and
> some of then wicked.
> 
Multics was consciously designed to be used primarily by people who
were not computer experts and some (though hopefully not many)
malicious experts. (I assume you don't really mean illiterate, as user
interfaces = terminals then were nearly all character/textual.) No
system on hardware of the time supported more than hundreds or maybe a
thousand users, and I'm not sure how well it would have scaled; but it
definitely did provide security -- modulo bugs of course, and there
were some -- in those cases, including I believe on the mil sites
"tiger" teams, and on my edu site definitely quite clever hackers (in
the original/true meaning) who were certainly sometimes mischievous
though not truly wicked. (That is, they would try to break security,
but motivated only to demonstrate their ability and perhaps play
jokes, not to actually steal, interfere, deceive, or damage.)

Besides the design -- which as already noted does depend, critically,
on hardware support and thus couldn't use, then and probably now,
"standard" or commodity hardware -- the key was/is that it not be
*administered* by incompetents; system managers and group/project
managers do need to know quite a bit to set up policies and defaults
that suitably secure (and restrict) ordinary users.

For example, active content in email (or the Web) hadn't been dreamt
of then, but if it were/is desired, it should have been/be possible to
put say mail in a highish ring like 2 or 3 protected against even
unintentional weakening by users, and able to force the untrustworthy
content to say ring 7 with access as limited as desired. The one new
problem that I believe Multics never tackled is secure sharing of a
graphics/windowing display; even ignoring blatantly dangerous designs
like MSWindows, X for example has had issues with covert channels. I
think this should be doable but don't know that anyone has.

It was also designed to be reliable, even in the face of component
failures, although I didn't really experience that because we were in
effect an experimental site who *deliberately* shut down fairly often.


- David.Thompson1 at worldnet.att.net

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Dave Thompson wrote:

> It was also designed to be reliable, even in the face of component
> failures, although I didn't really experience that because we were in
> effect an experimental site who *deliberately* shut down fairly often.

I had accounts on bco-multics (Billerica, MA), as well as mit-multics, 
Phoenix AZ (System M), and hi-multics in Minneapolis.  I remember a 
couple of shutdowns due to fried squirrels.  (Jumping from the high 
voltage wiring into the building to the roof which had metal flashing 
could be very detrimental to a squirrel's health, and cause bco-multics 
to shut down when the breaker tripped.)  Other than about two fried 
squirrels and a couple of scheduled updates in the OS, I can't remember 
any hardware or software related loss of service in five years.

I am certain that during that time several dozen hardware failures of 
CPUs, disks, memory, tape drives and so on occurred.  But in that sense 
Multics was totally fault tolerant.  Once when I was in the computer 
room for some reason... (Now I remember, an upgrade to the network 
protocol.) I watched someone power down the CPUs replace the networking 
card, power that CPU up and go on to the next one.

I worked at Stratus following Honeywell.  A lot of the original Stratus 
personnel were ex-Multicians, including Bob Freiburghouse, one of the 
founders.  I'd have to give Stratus, by the time I left, the edge on 
better fault tolerant support, but that was because Stratus systems 
allowed you do to a major OS upgrade, and transfer processes from the 
old OS version to the new without shutting them down.

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

One might ask if it is possible to build a reliable, secure OS in any 
language - besides a trivial one. That's a really tall order and one 
that is far more dependent on the architectural design of the OS than it 
is on the language in which it is implemented. The holes in OS's don't 
all come from lack of array bounds checking, you know.

But I'll bet if you can do it in Ada, the world might just beat a path 
to your door. ;-) That *would* be adding genuine value to an application 
domain, even if it still looked in outward respects like Unix or 
Windows. (I'd still advise making it look like something *new* and 
*different* and go fix problems besides just security & reliability.)

MDC

Berend de Boer wrote:
> 
> So far the real world has not produced a reliable secure OS in C. Can
> it be done? I doubt it.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Larry Kilgallen]

In article <uvfhuc1n3.fsf@xsol.com>, Berend de Boer <berend@xsol.com> writes:
>>>>>> "Marin" == Marin David Condic <nobody@noplace.com> writes:
> 
>     Marin> But you *can* write a perfectly secure, reliable system in
>     Marin> languages other than Ada. Maybe (maybe!) it requires more
>     Marin> work, but it *can* be done.
> 
> So far the real world has not produced a reliable secure OS in C. Can
> it be done? I doubt it.

The claim quoted above did not specify C.  It has been done in PL/I.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Also, I wasn't necessarily refering to an *operating* system - that can 
be awfully complex and may be impossible to get totally right no matter 
what the language. But there are some *systems* that can and have been 
built in languages other than Ada that are 100% reliable and/or secure.

MDC


Larry Kilgallen wrote:
> 
> 
> The claim quoted above did not specify C.  It has been done in PL/I.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Pylinius]

Marin David Condic wrote:
> Also, I wasn't necessarily refering to an *operating* system - that can 
> be awfully complex and may be impossible to get totally right no matter 
> what the language. But there are some *systems* that can and have been 
> built in languages other than Ada that are 100% reliable and/or secure.
> 
> MDC


AARTS 100% Ada operating system.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[David Starner]

On Mon, 14 Jun 2004 14:30:08 +1200, Berend de Boer wrote:

>>>>>> "Marin" == Marin David Condic <nobody@noplace.com> writes:
> 
>     Marin> But you *can* write a perfectly secure, reliable system in
>     Marin> languages other than Ada. Maybe (maybe!) it requires more
>     Marin> work, but it *can* be done.
> 
> So far the real world has not produced a reliable secure OS in C. Can
> it be done? I doubt it.

What OSes are you looking at? You can't expect the major commercial
operating systems to be reliable and secure, because the public doesn't
want reliable and secure. A reliable and secure operating system would run
on one standard set of simple predictable hardware. The public wants
something that will run on their current hardware. A reliable and secure
operating system would probably run everything in its own virtual machine
anyway; the public wants things to go fast. A reliable and secure
operating system can't support kludges that open up security holes; the
public wants their old programs to run (and run fast) on their new system.
A reliable and secure operating system would reduce or eliminate the usage
of a root-like user; the public doesn't want to jump through hoops
every time they want to fix the clock or install a program. A reliable,
secure operating system is simple; the public wants fast (highly tuned)
and featureful operating system.

It's actually quite easy to write a secure, reliable OS in C. It looks
something like this:

main () {
for (;;) {}
}

It's making a _usable_ secure, reliable OS that's hard, and most of that
is independent of programming language. 

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Richard Riehle]

"David Starner" <dvdeug@email.ro> wrote in message
news:pan.2004.06.15.11.40.09.413904@email.ro...
> It's actually quite easy to write a secure, reliable OS in C. It looks
> something like this:
>
> main () {
> for (;;) {}
> }
>
> It's making a _usable_ secure, reliable OS that's hard, and most of that
> is independent of programming language.

How does one define what is meant by an Operating System?   I would include
the many Run-time environments that an Ada program includes when it is
linked.   In that case, there have been lots of functional, dependable
operating
systems.   There are other small real-time embedded operating systems, many
commercially available, and we use them with minimal frustration.  Most of
them
are written in C or Assembler.   The Ada RTE's are frequently written in
Ada.

As you know, when it comes to software, when we expect more features we
get more unexpected features.   This has always been true, and will continue
to
be true for a long time.

So, the simple OS you propose, provides little and we expect little.

Programming language can matter.  An OS written in Assembler will have none
of the
built-in checking that we get from a slightly higher level language such as
C. An
OS written in C++ has the potential for more compiler checking than one
written
in C.   The same OS written in Modula-2 or Ada can benefit from the compile-
time checking inherent those languages.     Still, none of the languages can
ensure
that the designer has avoided contradictory features,  has overlooked some
important variable setting in a declaration, or gotten the algorithms
exactly right
at every place in the program.

That being said, for any large program, where I have to understand what I am
doing,
and need to understand what my co-workers are doing, my preference is still
Ada.
For me, and I stress the "for me," it continues to be more readable and
easier to
understand what I am doing that programming in C++.   For me, Ada code is
far
more straightforward, less filled with extraneous doo-dads, and more
comprehensible
than the alternatives.   The more I am required to use C++, the more annoyed
I get
with what seems like a lot of extra stuff I should not have to need to get
my work
done.   But each of us will see this differently.

Richard Riehle

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

David Starner wrote:

> On Mon, 14 Jun 2004 14:30:08 +1200, Berend de Boer wrote:
>>>>>>>"Marin" == Marin David Condic <nobody@noplace.com> writes:
>>
>>    Marin> But you *can* write a perfectly secure, reliable system in
>>    Marin> languages other than Ada. Maybe (maybe!) it requires more
>>    Marin> work, but it *can* be done.
>>
>>So far the real world has not produced a reliable secure OS in C. Can
>>it be done? I doubt it.
> 
> What OSes are you looking at? You can't expect the major commercial
> operating systems to be reliable and secure, because the public doesn't
> want reliable and secure. 

Well, of course, it depends again on what you consider reliable
and secure to mean (as Alexander Kopilovich has said).  Some of
the public _does_ want reliable and secure (depending on what that
means).

Actually, I'll bet if you asked them, they would want
"reliable and secure", in addition to everything else (they
want it all, for lowest price etc. etc.)

Ask anyone who's had to pay someone to reload their O/S
due to a virus, if they want a secure O/S? Ask them after
they've lost all of their digital photos!  (I know people \
that have suffered this fate).

> A reliable and secure operating system would run
> on one standard set of simple predictable hardware. 

Predictable yes. Simple is what we would want, because
simple is easier to validate. But I am not certain
that simplicity must be a prerequisite.

> The public wants
> something that will run on their current hardware. 

To a point. We all want faster and more powerful too.

> A reliable and secure
> operating system would probably run everything in its own virtual machine
> anyway; 

This only shifts responsibility from one layer to another. There
still must be validation, just at a different level. The bottom
line doesn't really change.

> the public wants things to go fast. 

Speed should not matter. Hardware is always run at suboptimal
speed for reliability reasons. But this is a hardware tradeoff,
not a software security issue (except possibly for complex
timing issues).

> A reliable and secure
> operating system can't support kludges that open up security holes; 

I think that it is generally agreed that we don't want kludges ;-)

 > the
> public wants their old programs to run (and run fast) on their new system.

Backwards compatibilities do carry forward certain risks.

> A reliable and secure operating system would reduce or eliminate the usage
> of a root-like user; the public doesn't want to jump through hoops
> every time they want to fix the clock or install a program. 

This is an interesting area of study. More study on this
problem should be encouraged. Unfortunately, there seems to
be an overall decline in the interest of O/S design these
days (there was a paper released about this, some time ago,
which was discussed in this group (discussed last year?))

 > A reliable,
> secure operating system is simple; 

You are listing simplicity as a prerequisite for secure. I do agree
that a simple system is easier to validate. But it is by no means
a prerequisite, as long as you have a method to validate your
design.

> the public wants fast (highly tuned)
> and featureful operating system.

Agreed, that there are tensions for compromise. But what I have
been saying (and perhaps others), is that surely there are
ways to do better than what we have now.

> It's actually quite easy to write a secure, reliable OS in C. It looks
> something like this:
> 
> main () {
> for (;;) {}
> }

Well, we can do that in Ada too, and even multitask it! ;-)

> It's making a _usable_ secure, reliable OS that's hard, and most of that
> is independent of programming language. 

Well, you and I could argue the "most" or "not" part. I firmly
believe that Ada would greatly influence the design of an operating
system, such that better engineering and fewer defects would
prevail. Obviously, if it is designed incorrectly, it would still
easily give away priviledges when it wasn't appropriate.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> You missed another good reason: c) improved security. Any daemon or process
> that interfaces with the wild wooly world out there, should be very
> secure (perfectly secure if theoretically possible). I think Ada can
> add some real value in this particular area, to the many "services"
> currently written in C/C++.

Check out this paper, back from 1995, on the security issues of BIND.
<http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt>

You will notice that most of the problems mentioned have to do with
attacks against the protocol, by forming messages in various unexpected
ways, by spoofing fields, and by mucking about with connections. Using
a language like Ada (or Java, for that matter) will certainly protect
against buffer overflows, but not against the logical errors described.

That's why it would be really interesting to see an Ada version of BIND.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

So if the protocol is weak and is the source of security errors, then 
how does implementing the same protocol in Ada gain anything? Or would 
it be "interesting" to watch a bunch of guys try to make it so by 
rewriting the exact, same logic flaws in Ada? :-)

OTOH, if you come up with a whole *new* protocol that is designed to add 
security and other beneficial features, then perhaps you have that 
elusive "Enhanced App" that adds genuine value? But, of course, the 
value didn't get added just because it was written in Ada.

MDC

Hyman Rosen wrote:
> 
> Check out this paper, back from 1995, on the security issues of BIND.
> <http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt> 
> 
> 
> You will notice that most of the problems mentioned have to do with
> attacks against the protocol, by forming messages in various unexpected
> ways, by spoofing fields, and by mucking about with connections. Using
> a language like Ada (or Java, for that matter) will certainly protect
> against buffer overflows, but not against the logical errors described.
> 
> That's why it would be really interesting to see an Ada version of BIND.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Marin David Condic wrote:
> Or would it be "interesting" to watch a bunch of guys try to make it
 > so by  rewriting the exact, same logic flaws in Ada? :-)

Yes, that's what I'm thinking would happen. But perhaps Ada lends itself
to better design techniques, and we also have the lessons of hindsight.
And it's a relatively small system. So it's a chance to show off, if
someone chooses to take it.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Marin David Condic wrote:

> So if the protocol is weak and is the source of security errors, then 
> how does implementing the same protocol in Ada gain anything? Or would 
> it be "interesting" to watch a bunch of guys try to make it so by 
> rewriting the exact, same logic flaws in Ada? :-)
> 
> OTOH, if you come up with a whole *new* protocol that is designed to add 
> security and other beneficial features, then perhaps you have that 
> elusive "Enhanced App" that adds genuine value? But, of course, the 
> value didn't get added just because it was written in Ada.

No this is a case where implementing the protocols securely is what is 
needed.  BIND doesn't do as much sanity checking as it should, and that 
provides openings for malicious hackers.

-- 

                                           Robert I. Eachus

The ideology he opposed throughout his political life insisted that 
history was moved by impersonal tides and unalterable fates. Ronald 
Reagan believed instead in the courage and triumph of free men and we 
believe it all the more because we saw that courage in him.  -- George 
W. Bush June 11, 2004

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

If that's the case, then why not work on simply adding some sanity 
checking to BIND? I'm not up on this particular program, but I wanted to 
make the point that rewriting an existing app in Ada is not usually a 
productive use of time unless there are structural flaws or added 
features. If the basic protocol is sound and the basic BIND program is 
sound and all it needs are some sanity checks, then it would seem like a 
smaller job to add the sanity checks than to rewrite the whole thing.

While I'm a believer in Ada, I don't think that coding an app up in Ada 
somehow makes it *better* just by that very fact. Nobody buys programs 
just because it says "Ada Inside" - so its important to add something 
more. Given limited resources, it would seem more productive to come up 
with something new and innovative rather than take existing apps and 
recode them in Ada just to have an Ada version.

MDC


Robert I. Eachus wrote:
> 
> No this is a case where implementing the protocols securely is what is 
> needed.  BIND doesn't do as much sanity checking as it should, and that 
> provides openings for malicious hackers.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Jeff C,]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:40CAF0E1.4000904@noplace.com...
> While I'm a believer in Ada, I don't think that coding an app up in Ada
> somehow makes it *better* just by that very fact. Nobody buys programs
> just because it says "Ada Inside" - so its important to add something
> more. Given limited resources, it would seem more productive to come up
> with something new and innovative rather than take existing apps and
> recode them in Ada just to have an Ada version.
>

While I generally agree with this sentiment, it is thinking "like" this that
would prevent someone from doing something crazy like

"I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.  This has been brewing
since april, and is starting to get ready.  I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things)."

Which is how Linus announced he was starting Linux.

Of course I have seen hundres of similarly bold announcements by software
people over the years that go nowhere.

I think us bitter old men are just too cynical sometimes....It comes from
experience of course...but who knows..maybe this Ada bind thing will really
get completed and be good....

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Sure, Linux had its success and got started as someone trying to 
re-implement Unix. But wouldn't it be better to set up an objective of 
doing something *different* and *better* in some way? Aren't there 
enough versions of Unix out there already? A Unix written in Ada has to 
compete against all sorts of other implementations of Unix and is just 
not all that interesting by virtue of its being implemented in Ada - 
except to Ada enthusiasts.

I don't want to discourage anybody from coming up with Ada programs - 
I'm just suggesting that the effort get expended on making something 
that is new or at least in some significant way better than what is 
already out there. The fact that a program is duplicated in an Ada 
implementation is probably not going to provide enough benefit to be of 
much interest to most people.

MDC


Jeff C, wrote:
> 
> While I generally agree with this sentiment, it is thinking "like" this that
> would prevent someone from doing something crazy like
> 
> "I'm doing a (free) operating system (just a hobby, won't be big and
> professional like gnu) for 386(486) AT clones.  This has been brewing
> since april, and is starting to get ready.  I'd like any feedback on
> things people like/dislike in minix, as my OS resembles it somewhat
> (same physical layout of the file-system (due to practical reasons)
> among other things)."
> 
> Which is how Linus announced he was starting Linux.
> 
> Of course I have seen hundres of similarly bold announcements by software
> people over the years that go nowhere.
> 
> I think us bitter old men are just too cynical sometimes....It comes from
> experience of course...but who knows..maybe this Ada bind thing will really
> get completed and be good....
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Sure, Linux had its success and got started as someone trying to 
> re-implement Unix. But wouldn't it be better to set up an objective of 
> doing something *different* and *better* in some way? ...
> MDC

I don't think that has been ruled out yet. The project is just
getting started. It makes no sense to take C code and just
"port it". I would be rather surprised if the project takes
that direction.

So yes, I believe that there is hope for good things to come out of
the project.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<40CAF0E1.4000904@noplace.com>...

> While I'm a believer in Ada, I don't think that coding an app up in Ada 
> somehow makes it *better* just by that very fact. Nobody buys programs 
> just because it says "Ada Inside" - so its important to add something 
> more. Given limited resources, it would seem more productive to come up 
> with something new and innovative rather than take existing apps and 
> recode them in Ada just to have an Ada version.

You seem to assume that the "recoding in Ada" is a labor-intensive
manual process. But what if it could be automated? I'm an aerospace
engineer, and I don't know much about automated C-to-Ada conversion,
but I think its at least worth consdering. Certainly the resulting Ada
code would have *some* of the benefits of Ada.

I understand that a crappy design will still be a crappy design even
in Ada, but if the original C application works reasonably well,
perhaps the automated Ada conversion could be manually tweaked to
improve security, reliability, or some other aspect. That certainly
seems like a more attractive option than manually rewriting the whole
thing.

Speaking of crappy designs, I sense some disdain for Linux here
because it is written it C. I suggest you all get over that and fast,
or you will just make fools of yourselves. I suggested a long time ago
here that C is to Ada as a motorcycle is to a car. It's not nearly as
safe, but experts can use it effectively. Needless to say, Linux was
written by top exerts. That's not to say that it couldn't be done
better in Ada, but you can't simply assume that.

I think the first step is to try an automated conversion of Linux to
Ada, then go from there. I would try it myself, but I wouldn't know
how to compile a kernel if it was staring me in the face. As I said,
I'm an aerospace engineer.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
 
: I suggested a long time ago
: here that C is to Ada as a motorcycle is to a car.

I'm not sure this analogy is totally appropriate, because
motorcycles and cars are so different. C isn't so much more
flexible as a motorcyle is when compared to a car en route.
They are also used for different purposes.

Maybe we can find a typical C car and a typical Ada car?

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Stephen Leake]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Russ <18k11tm001@sneakemail.com> wrote:
>  
> : I suggested a long time ago
> : here that C is to Ada as a motorcycle is to a car.
> 
> I'm not sure this analogy is totally appropriate, because
> motorcycles and cars are so different. C isn't so much more
> flexible as a motorcyle is when compared to a car en route.
> They are also used for different purposes.
> 
> Maybe we can find a typical C car and a typical Ada car?

C : A 1960 MG; always broken

Ada : A 1995 Toyota Corolla; "it just works" :).

Still not good analogies; no tasking, no inhertance, etc.

-- 
-- Stephe

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Russ]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<caha8s$1qd$2@a1-hrz.uni-duisburg.de>...
> Russ <18k11tm001@sneakemail.com> wrote:
>  
> : I suggested a long time ago
> : here that C is to Ada as a motorcycle is to a car.
> 
> I'm not sure this analogy is totally appropriate, because
> motorcycles and cars are so different. C isn't so much more
> flexible as a motorcyle is when compared to a car en route.
> They are also used for different purposes.

It's just an analogy. I think its a pretty good one, but no analogy is
perfect. If you've ever ridden a motorcycle (I had one about 20 years
ago), you know that they require much more attention to ride and are
much less forgiving than a car. They aren't much good for safe and
practical family transportation, but they are great for high
performance and cheap thrills.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Russ wrote:

> You seem to assume that the "recoding in Ada" is a labor-intensive
> manual process. But what if it could be automated? I'm an aerospace
> engineer, and I don't know much about automated C-to-Ada conversion,
> but I think its at least worth consdering. Certainly the resulting Ada
> code would have *some* of the benefits of Ada.
> 
> I understand that a crappy design will still be a crappy design even
> in Ada, but if the original C application works reasonably well,
> perhaps the automated Ada conversion could be manually tweaked to
> improve security, reliability, or some other aspect. That certainly
> seems like a more attractive option than manually rewriting the whole
> thing.
> 
> Speaking of crappy designs, I sense some disdain for Linux here
> because it is written it C. I suggest you all get over that and fast,
> or you will just make fools of yourselves. I suggested a long time ago
> here that C is to Ada as a motorcycle is to a car. It's not nearly as
> safe, but experts can use it effectively. Needless to say, Linux was
> written by top exerts. That's not to say that it couldn't be done
> better in Ada, but you can't simply assume that.
> 
> I think the first step is to try an automated conversion of Linux to
> Ada, then go from there. I would try it myself, but I wouldn't know
> how to compile a kernel if it was staring me in the face. As I said,
> I'm an aerospace engineer.

Actually, the problems occur mostly in places where C just has serious 
problems doing sanity checks right.  They can be done but it is a pain: 
   Check the length of the string to be read, then read either that 
number of characters or the maximum buffer size.  Of course, this means 
in many cases you have to read the string twice while Ada allows you to 
read it once.  (Ask for N characters and get a count of how many you get.)
As for rewriting a C program in Ada, what I have done is use the old 
Intermetrics tool to create package specs from .h files, then create 
bodies that use pragma Interface(C, ...) or now pragma Import.  Then 
start with the main program and rewrite things--that need to be 
rewritten--one function at a time.  That converts a huge task into a lot 
of smaller, and much more likely to succeed without error, tasks.  If 
the reason you are doing this is, as implied above, to replace some of 
the interfaces with better ones.  (Which is the only reason I have ever 
done this.)  You get up and running with the main program in Ada, then 
get a "thick" binding to compile as a package that calls the thin 
binding you created, change the main program to use the new interface, 
then rewrite the body of the thick binding in Ada.

The last step is not necessary, but...  One time when I did exactly 
this, rewritting the body of the interface packages in Ada was actually 
simpler than binding to the existing C.  This won't always be the case, 
but when it is the reason for the rewrite in the first place you will be 
amazed.  (Or to state it differently, in a way everyone here should 
understand, often in Ada 90% of the work goes into designing the package 
specifications.  If they are done well, writing the bodies is easy.)

-- 

                                           Robert I. Eachus

The ideology he opposed throughout his political life insisted that 
history was moved by impersonal tides and unalterable fates. Ronald 
Reagan believed instead in the courage and triumph of free men and we 
believe it all the more because we saw that courage in him.  -- George 
W. Bush June 11, 2004

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Robert I. Eachus wrote:
>   Check the length of the string to be read, then read either that 
> number of characters or the maximum buffer size.  Of course, this means 
> in many cases you have to read the string twice while Ada allows you to 
> read it once.  (Ask for N characters and get a count of how many you get.)

Huh? fread, fgets, istream.getline, istream.read are all ways of
reading up to a pre-determined amount of data into a buffer in C
and C++. In no case does the string need to be read twice.
What a bizarre claim!

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

Hyman Rosen wrote:

> >   Check the length of the string to be read, then read either that 
> > number of characters or the maximum buffer size.  Of course, this means 
> > in many cases you have to read the string twice while Ada allows you to 
> > read it once.  (Ask for N characters and get a count of how many you get.)
>
> Huh? fread, fgets, istream.getline, istream.read are all ways of
> reading up to a pre-determined amount of data into a buffer in C
> and C++. In no case does the string need to be read twice.
> What a bizarre claim!

Well, for C, that is for fread and fgets I would say that although these
functions indeed have maximum amount of bytes to be read onto a buffer as
a parameter, but:

1) this maximum, if not computed from "preliminary read", is usually set
manually, it does not computed automatically from the length of the buffer
used in that fread/fgets; therefore there is an obsvious possibility of
programmer's mistake, which will not be noticed by compiler;

2) sometimes there is no reasonable estimate for *guaranteed* maximum of
a string to be read, and therefore the length of the string can be greater
than already allocated buffer; reading a string in chunks can be inconvenient
for some reasons, and thus that double reading (first pass for determining
the length of string, then allocating the buffer, and then second pass with
filling the buffer).

So I find that claim far from bizarre, but rather practical. (Certainly in C++
it is possible to coordinate reading with the buffer size automatically, so I
don't speak about C++ here.)




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Brian May]

>>>>> "Alexander" == Alexander E Kopilovich <aek@VB1162.spb.edu> writes:

    Alexander> Well, for C, that is for fread and fgets I would say
    Alexander> that although these functions indeed have maximum
    Alexander> amount of bytes to be read onto a buffer as a
    Alexander> parameter, but:

    Alexander> 1) this maximum, if not computed from "preliminary
    Alexander> read", is usually set manually, it does not computed
    Alexander> automatically from the length of the buffer used in
    Alexander> that fread/fgets; therefore there is an obsvious
    Alexander> possibility of programmer's mistake, which will not be
    Alexander> noticed by compiler;

...not to mention older functions that don't support a string length
(eg. sprintf). Some have better versions (eg. snprintf or asprintf),
but such functions are often non-standard and non-portable extensions.

    Alexander> 2) sometimes there is no reasonable estimate for
    Alexander> *guaranteed* maximum of a string to be read, and
    Alexander> therefore the length of the string can be greater than
    Alexander> already allocated buffer; reading a string in chunks
    Alexander> can be inconvenient for some reasons, and thus that
    Alexander> double reading (first pass for determining the length
    Alexander> of string, then allocating the buffer, and then second
    Alexander> pass with filling the buffer).

Perhaps I am showing my ignorance, but do you read a string of
undefined length into an Ada program?

Isn't setting a maximum length of a string a good thing? eg. I don't
want my network daemon to try and allocate 1 gigabyte of memory just
because somebody sends it a line 1 gigabyte long, when the expected
maximum length was 80 bytes. This could be a security issue in itself
(Denial-of-service attack).

However, allocating lots of memory just in case the worst case
scenario occurs does sound wasteful to me, and perhaps this is what
you mean.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Frank J. Lhota]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4isdttufl.fsf@snoopy.apana.org.au...
> >>>>> "Alexander" == Alexander E Kopilovich <aek@VB1162.spb.edu> writes:
> Perhaps I am showing my ignorance, but do you read a string of
> undefined length into an Ada program?

Actually, GNAT includes a version of Get_Line that returns an unbounded
string, and that string can be a long as required (within the constraints of
available memory).

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Jeffrey Carter]

Brian May wrote:

> Perhaps I am showing my ignorance, but do you read a string of
> undefined length into an Ada program?

All the time:

with Ada.Text_IO;
with PragmARC.Get_Line;
procedure Get_Any_String is
    X : String := PragmARC.Get_Line;
begin -- Get_Any_String
    Ada.Text_IO.Put_Line (Item => '>' & X & '<');
end Get_Any_String;

Note that a similar technique may be used with an arbitrary buffer, 
allowing buffers of any length, eliminating buffer overflow.

The PragmAda Reusable Components, which include PragmARC.Get_Line, are 
available at

http://home.earthlink.net/~jrcarter010/pragmarc.htm

if you'd like to see how this is done, and experiment with it.

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Jeffrey Carter wrote:
> Brian May wrote:
>> Perhaps I am showing my ignorance, but do you read a string of
>> undefined length into an Ada program?
> All the time:
>    X : String := PragmARC.Get_Line;

That's not much of an answer. That's like saying that I can
generate the proof of the Riemann Hypothesis like this:
     with AdvancedMath; useAdvancedMath;
     procedure GenProof is begin Prove(Theorems.RH); end GenProof;

Obviously it's the inmplementation of the procedure that's of
interest, and presumably it does what we always see described
in c.l.a, which is to read a fixed size buffer and then return
that buffer concatenated with a recursive call if the first
read fills the buffer completely.

That's just copying and pasting bits together like you would do
anywhere else, except that Ada does the array manipulation as a
built-in operation.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Dave Thompson]

On Tue, 15 Jun 2004 12:40:46 +1000, Brian May
<bam@snoopy.apana.org.au> wrote:

> >>>>> "Alexander" == Alexander E Kopilovich <aek@VB1162.spb.edu> writes:
> 
>     Alexander> Well, for C, that is for fread and fgets I would say
>     Alexander> that although these functions indeed have maximum
>     Alexander> amount of bytes to be read onto a buffer as a
>     Alexander> parameter, but:
> 
>     Alexander> 1) this maximum, if not computed from "preliminary
>     Alexander> read", is usually set manually, it does not computed
>     Alexander> automatically from the length of the buffer used in
>     Alexander> that fread/fgets; therefore there is an obsvious
>     Alexander> possibility of programmer's mistake, which will not be
>     Alexander> noticed by compiler;
> 
Not fully automatic. You can and often should do e.g. 
fgets (buff, sizeof buff, in_file) -- but this is !silently! wrong if
buff is a function=routine parameter/formal declared as a char array
-- but due to C rules, actually a pointer -- rather than a local or
static/global variable.

You can write (and use) a macro that automatically supplies the sizeof
and even uses (unaesthetically) tricky code to diagnose nonarrays; 
or in C++ a clearer and more elegant inlined template that supplies
the size and diagnoses nonarray -- but in C++ it's more idiomatic to
use the stream >> operators instead, which can among other things read
into std::string which is dynamic comparable to Unbounded_String.

> ...not to mention older functions that don't support a string length
> (eg. sprintf). Some have better versions (eg. snprintf or asprintf),
> but such functions are often non-standard and non-portable extensions.
> 
snprintf is standard as of C99, although not fully compatible
(specifically return value) with some(?) pre-C99 extension versions.

- David.Thompson1 at worldnet.att.net

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Russ wrote:
> Marin David Condic <nobody@noplace.com> wrote in message news:<40CAF0E1.4000904@noplace.com>...
> 
>>While I'm a believer in Ada, I don't think that coding an app up in Ada 
>>somehow makes it *better* just by that very fact. Nobody buys programs 
>>just because it says "Ada Inside" - so its important to add something 
>>more. Given limited resources, it would seem more productive to come up 
>>with something new and innovative rather than take existing apps and 
>>recode them in Ada just to have an Ada version.
> 
> You seem to assume that the "recoding in Ada" is a labor-intensive
> manual process. But what if it could be automated? I'm an aerospace
> engineer, and I don't know much about automated C-to-Ada conversion,
> but I think its at least worth consdering. Certainly the resulting Ada
> code would have *some* of the benefits of Ada.

It is, because it needs to include "software engineering" as
well. If were simply a matter of using one compiler or
another, Ada would offer no advantage. But an engineered to
use Ada approach, offers many advantages.  For example:

If you translate values in C to Ada numeric constants, you
have just translated from C to Ada, with nothing gained.

If you develop an enumeration type in Ada (replacing C constants),
then case statements can be flagged for missing or incorrect
cases etc.

> I understand that a crappy design will still be a crappy design even
> in Ada, but if the original C application works reasonably well,
> perhaps the automated Ada conversion could be manually tweaked to
> improve security, reliability, or some other aspect. That certainly
> seems like a more attractive option than manually rewriting the whole
> thing.

The point is, people don't feel safe with the exploits that keep
coming up in BIND. Not to crap on anybody's C work in BIND, but
some folks think Ada _can_ offer better, if the project is
properly executed. I for one, think it is worth trying.

> Speaking of crappy designs, I sense some disdain for Linux here
> because it is written it C.

You're reading too much into it. Linux is great IMHO. I have it
running on 7 machines at home (only 2 instances of M$ remain
at home). Yet, I don't look at Linux in a religious way. I am
willing to admit that the evidence suggests that it is less
than secure (hence the continuous crop of exploit notices!)
Let's all recognize that M$ has their own problems as well.

If I were contracted to provide a safe/secure *NIX solution to
a university, I'd have some headscrating to do. This is because
Linux's root privilege is so frequently obtained by unprivileged
users. Other *NIX's have problems in this area too, though each
brand has its differing levels of security. None are immune
from what I can see.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Keep in mind that years ago when Unix was (ill?)conceived that it was 
not intended to be a high-security system. It was intended to provide 
enough security that a small development team using it could work 
together without hosing each other up. It wasn't designed to thwart all 
possible attacks by malicious intruders. Hence, additional security 
measures have, over time, continued to be piled on it to try to make it 
do something it wasn't intended to do. (A little like putting a GUI on 
top of MS DOS and trying to make it multitask.)

If what is wanted is a true high security OS, then it almost sounds like 
it would be better to start building one that had those concepts built 
in from the start. It could be a good market for Ada to address.

MDC



Warren W. Gay VE3WWG wrote:
> 
> If I were contracted to provide a safe/secure *NIX solution to
> a university, I'd have some headscrating to do. This is because
> Linux's root privilege is so frequently obtained by unprivileged
> users. Other *NIX's have problems in this area too, though each
> brand has its differing levels of security. None are immune
> from what I can see.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Keep in mind that years ago when Unix was (ill?)conceived that it was 
> not intended to be a high-security system. It was intended to provide 
> enough security that a small development team using it could work 
> together without hosing each other up. 

Actually, I believe that the first versions of UNIX were
totally lacking in security. After all, the system was
serving initially a very small group of researchers at
Bell labs. I seem to recall reading somewhere that there
was a fierce level of resistance to adding any restrictions
at all, to various users. Obviously, over time, it became
necessary as the use of the system became more widespread.

> It wasn't designed to thwart all 
> possible attacks by malicious intruders. Hence, additional security 
> measures have, over time, continued to be piled on it to try to make it 
> do something it wasn't intended to do. (A little like putting a GUI on 
> top of MS DOS and trying to make it multitask.)

And we remember well what that was like ;-)

> If what is wanted is a true high security OS, then it almost sounds like 
> it would be better to start building one that had those concepts built 
> in from the start. It could be a good market for Ada to address.
> 
> MDC
Agreed, that this is needed.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Frank J. Lhota]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:40CEE1BC.4000508@noplace.com...
> ... Hence, additional security
> measures have, over time, continued to be piled on it to try to make it
> do something it wasn't intended to do. (A little like putting a GUI on
> top of MS DOS and trying to make it multitask.)

LOL! To be honest, the only multitasking that existed in MS Windows in the
pre-95 days were pre-emptive multi-tasking, where each application was
expected to periodically call functions such as "GetMessage" and "Yield"
that would allow another application to get a chance to be scheduled. If an
application did not call such functions for a long time, all other
applications would be shut out. Not exactly the most stable platform!

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Björn Persson]

Frank J. Lhota wrote:

> LOL! To be honest, the only multitasking that existed in MS Windows in the
> pre-95 days were pre-emptive multi-tasking, where each application was
> expected to periodically call functions such as "GetMessage" and "Yield"
> that would allow another application to get a chance to be scheduled.

Um ... I thought that was called collaborative multitasking. Doesn't 
"pre-emptive" mean that anything can be interrupted at any time?

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Frank J. Lhota]

Frank J. Lhota wrote:

> LOL! To be honest, the only multitasking that existed in MS Windows in the
> pre-95 days were pre-emptive multi-tasking, where each application was
> expected to periodically call functions such as "GetMessage" and "Yield"
> that would allow another application to get a chance to be scheduled.

Sorry, I should have said "non-pre-emptive multi-tasking".

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Frank J. Lhota wrote:
> LOL! To be honest, the only multitasking that existed in MS Windows in the
> pre-95 days were pre-emptive multi-tasking, where each application was
> expected to periodically call functions such as "GetMessage" and "Yield"
> that would allow another application to get a chance to be scheduled. If an
> application did not call such functions for a long time, all other
> applications would be shut out. Not exactly the most stable platform!

Why exactly are you mocking this style of behavior? Isn't this a perfectly
valid tasking style for the Ada runtime? I don't know Ada, but I believe
it is perfectly legitimate that if an Ada task does not relinquish control
and no other higher priority task is ready to run, then no other equal
priority task need be given control.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Björn Persson]

Hyman Rosen wrote:

> Frank J. Lhota wrote:
> 
>> LOL! To be honest, the only multitasking that existed in MS Windows in 
>> the
>> pre-95 days were pre-emptive multi-tasking, where each application was
>> expected to periodically call functions such as "GetMessage" and "Yield"
>> that would allow another application to get a chance to be scheduled. 
>> If an
>> application did not call such functions for a long time, all other
>> applications would be shut out. Not exactly the most stable platform!
> 
> 
> Why exactly are you mocking this style of behavior? Isn't this a perfectly
> valid tasking style for the Ada runtime? I don't know Ada, but I believe
> it is perfectly legitimate that if an Ada task does not relinquish control
> and no other higher priority task is ready to run, then no other equal
> priority task need be given control.

That's fine for *threads* (for some applications), not for *processes* 
in a general-purpose operating system. If a buggy program enters an 
infinite loop you want to be able to kill it.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Bj�rn Persson wrote:
> That's fine for *threads* (for some applications), not for *processes* 
> in a general-purpose operating system. If a buggy program enters an 
> infinite loop you want to be able to kill it.

It's not unknown for this to happen when a buggy X Windows program grabs
the server and never lets go, and that's on a proper multitasking system.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Brian May]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

    Hyman> It's not unknown for this to happen when a buggy X Windows
    Hyman> program grabs the server and never lets go, and that's on a
    Hyman> proper multitasking system.

Even in this case, the web server, for example, continues to run just
fine (unless it is incredibly dodgy and requires X...).

Also, when it does happen, it is easy for an experienced user to
resolve by logging into the system via some other means (eg. text
console) and kill the offending process.

If on the other hand a buggy Windows application doesn't give up CPU
control when using co-oporative multitasking, rebooting is the only
option.

It is still possible for a single application to cause other
applications to hang, just not as easy to do accidently, by denial of
service attacks (depending on ulimits under Unix). Eg. by hogging all
available diskspace, or allocating all RAM, or spawning infinity
processes, flooding the network, etc. Eventually other processes will
no longer work as required.

All of this seems irrelevant to Ada though, I don't think that there
is anything unique to Ada which would solve any of these issues.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[tmoran]

>> in a general-purpose operating system. If a buggy program enters an
>> infinite loop you want to be able to kill it.
>
>It's not unknown for this to happen when a buggy X Windows program grabs
>the server and never lets go, and that's on a proper multitasking system.
  Also Windows 2000.  Its idea of "pre-emptive" is that the paper clip
can flash a new image once every 30 seconds or so, and in 5 or 10 minutes
you can get enough into Task Manager to tell it to kill the errant process.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Ludovic Brenta]

 writes:
>>> in a general-purpose operating system. If a buggy program enters an
>>> infinite loop you want to be able to kill it.
>>
>>It's not unknown for this to happen when a buggy X Windows program grabs
>>the server and never lets go, and that's on a proper multitasking system.
>   Also Windows 2000.  Its idea of "pre-emptive" is that the paper clip
> can flash a new image once every 30 seconds or so, and in 5 or 10 minutes
> you can get enough into Task Manager to tell it to kill the errant process.

In my experience, the paper clip is quite preemptive by itself.  At
seemingly random intervals, it will forcibly stop the user in the
middle of whatever they were doing :)

-- 
Ludovic Brenta.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Björn Persson]

Hyman Rosen wrote:

> Björn Persson wrote:
> 
>> That's fine for *threads* (for some applications), not for *processes* 
>> in a general-purpose operating system. If a buggy program enters an 
>> infinite loop you want to be able to kill it.
> 
> It's not unknown for this to happen when a buggy X Windows program grabs
> the server and never lets go, and that's on a proper multitasking system.

And you can't even switch virtual consoles since X has complete control 
of the keyboard, so the only way is to log in on another physical 
console or over the network. I guess it's a design problem in X, 
although it could be argued that a kernel should keep at least one key 
combination to itself.

I suppose the conclusion is that a process scheduler can't solve all the 
world's problems.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Dale Stanbrough]

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

In article <_NKzc.96059$dP1.312794@newsc.telia.net>,
 Bj�rn Persson <spam-away@nowhere.nil> wrote:

> Hyman Rosen wrote:

> That's fine for *threads* (for some applications), not for *processes* 
> in a general-purpose operating system. If a buggy program enters an 
> infinite loop you want to be able to kill it.

The differences between threads and processes is pretty limited in 
most modern operating systems.

Do a search on LWP or Light Weight Processes.


Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Dale Stanbrough wrote:
>>Hyman Rosen wrote:
> 
>>That's fine for *threads* (for some applications), not for *processes* 
>>in a general-purpose operating system. If a buggy program enters an 
>>infinite loop you want to be able to kill it.

Please watch your attribution. I did not write that.

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Dale Stanbrough]

In article <uwLzc.30032$mz.11931@nwrdny02.gnilink.net>,
 Hyman Rosen <hyrosen@mail.com> wrote:

> Dale Stanbrough wrote:
> >>Hyman Rosen wrote:
> > 
> >>That's fine for *threads* (for some applications), not for *processes* 
> >>in a general-purpose operating system. If a buggy program enters an 
> >>infinite loop you want to be able to kill it.
> 
> Please watch your attribution. I did not write that.

My apologies! A slip up with the editing.

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Björn Persson]

Dale Stanbrough wrote:

> The differences between threads and processes is pretty limited in 
> most modern operating systems.
> 
> Do a search on LWP or Light Weight Processes.

Yes, it's common to provide threading libraries with preemptive 
scheduling with help from the kernel, but you can still use a userspace 
threading library with cooperative scheduling in your program if that 
fits your needs better. With Gnat on Linux you can choose between native 
threads and FSU threads for example.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Ada BIND was: Improving Ada's image - Was: 7E7 Flight Controls

[Larry Kilgallen]

In article <7wKzc.29929$mz.28528@nwrdny02.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> Frank J. Lhota wrote:
>> LOL! To be honest, the only multitasking that existed in MS Windows in the
>> pre-95 days were pre-emptive multi-tasking, where each application was
>> expected to periodically call functions such as "GetMessage" and "Yield"
>> that would allow another application to get a chance to be scheduled. If an
>> application did not call such functions for a long time, all other
>> applications would be shut out. Not exactly the most stable platform!
> 
> Why exactly are you mocking this style of behavior? Isn't this a perfectly
> valid tasking style for the Ada runtime? I don't know Ada, but I believe
> it is perfectly legitimate that if an Ada task does not relinquish control
> and no other higher priority task is ready to run, then no other equal
> priority task need be given control.

A major difference would be that an operating system labelled as having
"cooperative multitasking" _has_ no higher priority tasks, so there is
no escape from the "wait until the piggy code cooperates" paridigm.

Ada operating systems.

[Peter C. Chapin]

> But MDC is right in the sense that it  _would_ be
> nice to be able to point to something (O/S) in Ada as evidence
> to its strengths. Then we'd have something more to compare
> with (operating system to operating system). As it stands, we
> can only speculate about how much better an Ada based
> O/S would be.

Does anyone know what the status is of this project:

    	http://www.adaos.net/

The web page appears to be a placeholder but it looks interesting.

Peter

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
 
: In c.l.a. you find many posts deriding managers who choose
: to implement systems in C or C++, as if it were somehow
: impossible to do such a thing. As MDC keeps saying, it would
: be nice if you could point to equivalent or equivalently
: large systems in Ada that would demonstrate the same thing
: that Linux and Microsoft do.

It won't help. BeOS has been said to be a good OS. It is written
in C++. It hasn't been a huge commercial success. Does the fact that it
hasn't supplanted either Windows or Linux say anything about
whether C++ is a suitable language for OS construction then?

When Plan 9 was planned, the plan included Modula 2 as the
programming language to be used for the kernel. One of the
developers didn't say No but that he was so familiar with C
that he wished the kernel to be written in C. At least this
is part of the story, afaik. Does this say something about
whether Modula-2 is a suitable language for OS construction?

I think this issue needs a multivariate analysis.


-- Georg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Georg Bauhaus wrote:
> It won't help. BeOS has been said to be a good OS. It is written
> in C++. It hasn't been a huge commercial success. Does the fact that it
> hasn't supplanted either Windows or Linux say anything about
> whether C++ is a suitable language for OS construction then?

No.

> When Plan 9 was planned, the plan included Modula 2 as the
> programming language to be used for the kernel. One of the
> developers didn't say No but that he was so familiar with C
> that he wished the kernel to be written in C. At least this
> is part of the story, afaik. Does this say something about
> whether Modula-2 is a suitable language for OS construction?

Yes.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> 
:> [BeOS: C++. Excellent OS] Does the fact that it
:> hasn't supplanted either Windows or Linux say anything about
:> whether C++ is a suitable language for OS construction then?
: 
: No.

:> [Plan 9: exceptional C, designer wanted Modula-2]
:> Does this say something about
:> whether Modula-2 is a suitable language for OS construction?
: 
: Yes.

O.K., what in the presence of operating systems written in Modula-2?

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

I don't know if that's *exactly* what I'm saying, but I think get your 
point - and probably agree with it. There *are* large, successful 
systems in Ada - but not "large" in the commercial sense of "large". Ada 
would be better off if it had some million-user sized systems out there 
with a little sticker on the bottom of the windowpane saying "Ada 
Inside". If that's what you mean, then I think I agree.

MDC

Hyman Rosen wrote:
> 
> In c.l.a. you find many posts deriding managers who choose
> to implement systems in C or C++, as if it were somehow
> impossible to do such a thing. As MDC keeps saying, it would
> be nice if you could point to equivalent or equivalently
> large systems in Ada that would demonstrate the same thing
> that Linux and Microsoft do.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Larry Kilgallen]

In article <1087325485.307616@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Warren W. Gay VE3WWG wrote:
>> Generally agreed. I think you would also agree that Ada forces
>> the writer to engineer the project better. You are forced to
>> do more planning with Ada. Compared this with C, where you
>> can always pass around void pointers, etc. to work around
>> things that you forgot to design for.
> 
> Forgetting to design things is obviously not a feature of
> the programming language.

But reminding you about such gaps _is_ a language-specific trait.

> So the flip side of what you are
> saying is that once you accidentally leave out a feature,
> Ada will make it difficult to add.

Certainly more difficult to add piecemeal, and thus more difficult
to forget half of the implementation of that feature.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Wes Groleau]

Warren W. Gay VE3WWG wrote:

> Hyman Rosen wrote:
>> By the way, to "beg the question" means to assume that which you
>> are trying to prove, not to force a question to be asked.
>
> in your subsequent post, BTW). So I stand by the original
> assertion that there are questions begging to be answered
> in this kind of a statement before it can be accepted as
> any level of proof.

"begging the question" and "questions begging to be answered"
are completely unrelated.  Hyman, you are correcting a mistake
that was never made.

-- 
Wes Groleau
Alive and Well
http://freepages.religions.rootsweb.com/~wgroleau/

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Wes Groleau wrote:
> "begging the question" and "questions begging to be answered"
> are completely unrelated.  Hyman, you are correcting a mistake
> that was never made.

I don't think your original sentence parses that way,
but fine. Grammar is off-topic anyway.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[I R T]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> The bottom line is that unless Linux is perfect, you
> cannot state that Ada could not have done better.

Or Smalltalk, Eifel , Lisp, CPL, APL , PLI or any other language.

So what is your point ?

Perhaps angels can be programmed in Ada too...

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Dmitry A. Kazakov]

On Wed, 09 Jun 2004 04:39:59 GMT, I R T <rambam@bigpond.net.au> wrote:

>"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>
>> The bottom line is that unless Linux is perfect, you
>> cannot state that Ada could not have done better.
>
>Or Smalltalk, Eifel , Lisp, CPL, APL , PLI or any other language.
>
>So what is your point ?

The point is that either revenues or number of customers tell very
little about technical merits of a software product. They are almost
uncorrelated. Talking about perfection people are quickly switching
from technical perfection to marketing one and back. Using an
appropriate period of oscillation one could prove anything...

>Perhaps angels can be programmed in Ada too...

But the fallen ones were in C++! (:-))

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Wed, 09 Jun 2004 04:39:59 GMT, I R T <rambam@bigpond.net.au> wrote:
>>"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>>The bottom line is that unless Linux is perfect, you
>>>cannot state that Ada could not have done better.
>>
>>Or Smalltalk, Eifel , Lisp, CPL, APL , PLI or any other language.
>>
>>So what is your point ?
> 
> The point is that either revenues or number of customers tell very
> little about technical merits of a software product. They are almost
> uncorrelated. Talking about perfection people are quickly switching
> from technical perfection to marketing one and back. Using an
> appropriate period of oscillation one could prove anything...

A case in point was the INFORMIX database software. It was
years ahead of DB2, before IBM bought the company. But
INFORMIX didn't manage to "sell" it well, and perhaps
there were customer service issues as well. But technically,
it was a nice clean relational database, compared to the
muddled Oracle database product. Yet, Oracle is accepted
as the "normal" choice for standardization in many places.

>>Perhaps angels can be programmed in Ada too...
> 
> But the fallen ones were in C++! (:-))

:)

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

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

I R T wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>The bottom line is that unless Linux is perfect, you
>>cannot state that Ada could not have done better.
> 
> Or Smalltalk, Eifel , Lisp, CPL, APL , PLI or any other language.
> 
> So what is your point ?

You'll recall that my point was:

  "you cannot state that Ada could not have done better."

Do I really need to explain that?
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

I R T wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
> 
>>The bottom line is that unless Linux is perfect, you
>>cannot state that Ada could not have done better.
> 
> 
> Or Smalltalk, Eifel , Lisp, CPL, APL , PLI or any other language.
> 
> So what is your point ?

Speaking from personal opinion, the operating systems that I used that 
were programmed in PL/I were much better than those I used that were 
written in C.  (I have significant personal experience with Multics and 
Stratus VOS, having used both for years and done some maintenance on 
both.  PrimOS was also written in PL/I, but I had little experience with 
it.  Just a data point...

> Perhaps angels can be programmed in Ada too...

I don't know about angels, but I have worked on real-time projects where 
the OS had to be developed in Ada because the existing C "hard real 
time" OSes were anything but.*   My experience -- remember this is a 
special purpose OS not a more general OS -- was that writing the kernel, 
given a good Ada compiler that targeted the bare metal was no big deal. 
  In fact we spent a lot more time (order of 10x) defining the kernel 
interface than in implementing it.

*We were real mad at Sun.  Solaris trumpeted the fact that it supported 
hard real time, and it took us days to find out that it didn't.  But 
once we did, it was easy to find the "bug report" that explained that 
the kernel did not correctly implement the real-time interface, and 
IGNORED some of the parameters dealing with timing.  When we contacted 
Sun, they confirmed that this 'bug' existed, and was not being fixed in 
the next OS release (Solaris 7).  For all I know that is still the state 
of affairs.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marius Amado Alves]

 > ... was that writing the kernel,
> given a good Ada compiler that targeted the bare metal was no big deal. 
>  In fact we spent a lot more time (order of 10x) defining the kernel 
> interface than in implementing it.

Is this work shareable? Does it have a name? Does AdaOS know it?

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Robert I. Eachus]

Marius Amado Alves wrote:
>  > ... was that writing the kernel,
> 
>> given a good Ada compiler that targeted the bare metal was no big 
>> deal.  In fact we spent a lot more time (order of 10x) defining the 
>> kernel interface than in implementing it.
> 
> 
> Is this work shareable? Does it have a name? Does AdaOS know it?


Short answer: No.

The work was done on a classified project, and although I was able to 
bring some of the work out from behind the veil, the kernel was a 
definite no-no.  The fear is that if bugs are found, then the bad guys 
could exploit them in a combat situation.  In practice that is much more 
applicable to the radar portion of the software, and I can't imagine 
that today's potential enemies have the technical knowhow to exploit any 
weaknesses, but rules are rules.

However, you could check on PCTE.  That is a published standard, and it 
could save you lots of effort on building a useful Ada only OS.  (Of 
course, any OS is going to need a few instructions that are not 
available in any programming language directly.  But I think GNAT will 
let you write them as code-inserts.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

There have been other RTOS's done in Ada that have been out and 
available. (RTEMS was one. MaRTE was another) Its been suggested that 
they might make a good starting point for developing something more 
along the lines of a PC/Workstation OS. Something like that would 
constitute "A Good Start" towards having a viable Ada operating system - 
and possibly one with product distinction. ("Sure you can use Windows, 
but it doesn't have a 'Realtime Mode', so it isn't suitable for a whole 
class of applications... Or, you could use this Ada OS I happen to have 
in my back pocket... ;-)

But as far as I can tell, AdaOS is a hobby and isn't making lots of 
headway. (Possibly setting its initial aims too high?) Someone would 
have to see either some academic research interest or commercial 
interest in trying to go build a working OS since it is a lot of work 
and isn't likely to show steady progress unless someone is getting paid 
to do it.

MDC


Marius Amado Alves wrote:
> 
> Is this work shareable? Does it have a name? Does AdaOS know it?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Larry Kilgallen]

In article <a%Fzc.16351$nY.585525@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> David Starner wrote:
> 
>> On Mon, 14 Jun 2004 14:30:08 +1200, Berend de Boer wrote:

>>>So far the real world has not produced a reliable secure OS in C. Can
>>>it be done? I doubt it.

But that does not mean the real world has not created such in other
languages.

>> What OSes are you looking at? You can't expect the major commercial
>> operating systems to be reliable and secure, because the public doesn't
>> want reliable and secure. 
> 
> Well, of course, it depends again on what you consider reliable
> and secure to mean (as Alexander Kopilovich has said).  Some of
> the public _does_ want reliable and secure (depending on what that
> means).

Three examples that seem to me "reliable and secure" are VMS, MVS and
Nonstop.

>> A reliable and secure operating system would run
>> on one standard set of simple predictable hardware. 
> 
> Predictable yes. Simple is what we would want, because
> simple is easier to validate. But I am not certain
> that simplicity must be a prerequisite.

VMS and Nonstop each run on two (in each case diverse) architectures,
going on three.  I don't know about MVS.

>> A reliable and secure
>> operating system would probably run everything in its own virtual machine
>> anyway; 
> 
> This only shifts responsibility from one layer to another. There
> still must be validation, just at a different level. The bottom
> line doesn't really change.
> 
>> the public wants things to go fast. 
> 
> Speed should not matter. Hardware is always run at suboptimal
> speed for reliability reasons. But this is a hardware tradeoff,
> not a software security issue (except possibly for complex
> timing issues).

The Multics ring architecture seems to offer protection without requiring
a virtual machine or emulation.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Richard Riehle]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1086630278.542788@master.nyc.kbcfp.com...
>
> In absolute terms. Linux systems, as well as BSD systems which
> are also written in C, stay up for long periods of time and work
> as they are supposed to. Various pieces are always being reworked
> and enhanced, apparently without much difficulty.

There is no reason why someone could not write an OS in Ada. There
is some reason to wonder whether this would be a good use of
programmer resources given the current state of the market for
Operating Systems.   C and C++ can be, and have been, used with
comparitively good success in writing Operating Systems.  Expert
programmers can do good work in nearly any language, even Ada,
Eiffel, D, Forth, Pascal, Assembler, or [your favorite goes here].

The operating systems written in C or C++ are well-known to be
vulnerable to security violations, some of which are directly related
to features of the languages in which they are written.  Those identical
violations would be impossible for an OS written in Ada.

On the other hand, one cannot predict what vulnerabilities would
be discovered for an OS written in Ada.  I have no doubt there
would be some vulnerabilities.  Would they be as severe as those
in OS's written in the C family of languages?  No one can answer
that for certain.

I happen to prefer Ada over C++ for most things.  The more time
I spend with C++ (alas, I am forced to do so part of the time) the
more I dislike it.   This is a personal preference, but one derived from
experience.  Ada too has features I dislike, but not as many of them
as C++.    So far, I have not discovered the perfect (or even the
ideal) programming language that fits every situation.   I don't expect
to during my few remaining years as a carbon-based, oxygen breathing
organism.

Richard Riehle

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

An OS targeted to some under-served segment of the market might make 
some sense. I've suggested that a Windows-ish thing that could run one 
or more processes in "Realtime" mode might find some use. Also, the OS's 
I've seen for Digital TV Settop Boxes were mostly pretty weak and its an 
emerging market that doesn't yet have an all-dominating standard. There 
might be other possibilities as well - such as an OS that caters to 
large numbers of multiprocessors, or an OS designed to take advantage of 
emerging technological possibilities with large non-volatile memories, 
or an OS aiming to take advantage of the merging of telecommunication 
technologies (you're home computer being your telephone and your tv set 
and maybe a few other things as well?) Find a way of saying that an Ada 
OS offers some functionality you don't already have available with 
Windows or Linux or MacOS (or whatever) and you have some possible 
direction to go down to justify why an Ada OS might work.

If someone is serious about making an Ada OS then I'd suggest finding 
one of these under-served segments, getting creative in how to address 
it and start working on something minimal enough to get out there and be 
usable in some regard. From a working prototype it might be possible to 
build a business - or a whole industry. But it won't happen by simply 
trying to supplant Windows and doing it as a hobby.

MDC


Richard Riehle wrote:
> 
> There is no reason why someone could not write an OS in Ada. There
> is some reason to wonder whether this would be a good use of
> programmer resources given the current state of the market for
> Operating Systems.   C and C++ can be, and have been, used with
> comparitively good success in writing Operating Systems.  Expert
> programmers can do good work in nearly any language, even Ada,
> Eiffel, D, Forth, Pascal, Assembler, or [your favorite goes here].


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Russ]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<CiNxc.8259$uX2.228@newsread2.news.pas.earthlink.net>...
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1086630278.542788@master.nyc.kbcfp.com...
> >
> > In absolute terms. Linux systems, as well as BSD systems which
> > are also written in C, stay up for long periods of time and work
> > as they are supposed to. Various pieces are always being reworked
> > and enhanced, apparently without much difficulty.
> 
> There is no reason why someone could not write an OS in Ada. There
> is some reason to wonder whether this would be a good use of
> programmer resources given the current state of the market for
> Operating Systems.   C and C++ can be, and have been, used with
> comparitively good success in writing Operating Systems.  Expert
> programmers can do good work in nearly any language, even Ada,
> Eiffel, D, Forth, Pascal, Assembler, or [your favorite goes here].
> 
> The operating systems written in C or C++ are well-known to be
> vulnerable to security violations, some of which are directly related
> to features of the languages in which they are written.  Those identical
> violations would be impossible for an OS written in Ada.
> 
> On the other hand, one cannot predict what vulnerabilities would
> be discovered for an OS written in Ada.  I have no doubt there
> would be some vulnerabilities.  Would they be as severe as those
> in OS's written in the C family of languages?  No one can answer
> that for certain.

Just for my own education, let me ask a few questions here.

What is the state of the art in automated conversion of C code to Ada?

If Linux could be automatically converted to Ada, would the security
benefits of Ada be realized automatically, or would manual
modifications be necessary? If the latter, how difficult would they
be?

> <cut> So far, I have not discovered the perfect (or even the
> ideal) programming language that fits every situation.   I don't expect
> to during my few remaining years as a carbon-based, oxygen breathing
> organism.

See http://juvenon.com for life extension technology. (I have no
connection with it.)

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Russ wrote:
> "Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<CiNxc.8259$uX2.228@newsread2.news.pas.earthlink.net>...
>>"Hyman Rosen" <hyrosen@mail.com> wrote in message
>>news:1086630278.542788@master.nyc.kbcfp.com...
...
>>On the other hand, one cannot predict what vulnerabilities would
>>be discovered for an OS written in Ada.  I have no doubt there
>>would be some vulnerabilities.  Would they be as severe as those
>>in OS's written in the C family of languages?  No one can answer
>>that for certain.
> 
> Just for my own education, let me ask a few questions here.
> 
> What is the state of the art in automated conversion of C code to Ada?

I can't really answer that, but I would guess that there are
no such products/tools for that. If there were, the result
would look like C, but be described in Ada terms. There would
be very little advantage to that.

The process would be similar to taking a thin Ada (to C) binding, and
creating a thick one in Ada terms. I don't believe you'll find
any software capable of that form of transformation at this time.

> If Linux could be automatically converted to Ada, would the security
> benefits of Ada be realized automatically, or would manual
> modifications be necessary? If the latter, how difficult would they
> be?

Ada itself is not a cure for all security problems. Some of the
responsibility rests with the design. However, many of the published
"exploits" tend to be about things that the C-design was never
designed to allow. In that sense, I think Ada can be helpful,
since it would tend to avoid exploitable buffer overflows and
such. However, it must be admitted, that exploits are possible
in any badly designed code, in C or otherwise.

One difficult to solve area is DOS attacks. Even Ada programs
can be vulnerable to this, if precautions surrounding stacks,
heap space and tasks are not enforced/checked.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Richard Riehle wrote:
 > One must ask what those reasons are.

The presumed reason, looked at from the outside, is "iconoclasm".
Lord knows that such views are endemic in computing.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics (why not Universities?)

[Warren W. Gay VE3WWG]

Per Dalgas Jakobsen wrote:

>>>>But how can we get the attention of the executives?
>>>>Let the brainstorm start ;-)
>>>
>>>That's the real problem :)
>>
>>No, the real problem is that executives = management and management =
>>morons and morons are in charge.
> 
> Well, I understand your view, but I have (almost) never seen a person that
> acted irrational, when seing things from a certain point of view.
> That view might not be yours for several reasons, one being that you know
> more about some stuff than they do or visa versa.

I would generally agree: its not about managers being morons,
but seeing things from a different point of view. Part of the
tension is that developers don't want to expend the effort
necessary to "sell the idea". They don't use the right
facts and presentation to "sell it" (developers know code,
but often fail to know how to sell or present an idea).
So that is part of it (some of the other part is below..)

> The problem being most project managers do not have the courage to put their
> reputation at stake to make an unorthodox decision, because all the other
> project managers will know immediately where to point fingers if the project
> runs off track, disregarding the real reason (the majority are right...).

Agreed - lack of courage is another factor. Its easy to
support a project that uses technology that you don't
have to "sell".  Project managers must also "sell the
idea" (Ada) to their upper management.  So even if the project
management is sold (because the developers helped sell
Ada), they must now expend energy with courage to upper
management. It is very tough to sell something, when
everyone else in the meeting room is against the idea.
It is even tougher, if the upper management has developed
a stronger level of trust with others in the room.

So as I see it, Ada right away has two major points of
failure in the corporate scene:

   1. Developers fail to sell Ada to their manager/project-manager
   2. Project managers fail to sell to their management/clients

Lack of effort and/or courage at either level, will cause
the path of least resistance to be used. Only a thick
skin and zeal can overcome it.

> Thats why it makes no sense to try forcing Ada from the bottom up (even
> though Linux seems to have accomplished that to a certain extend), but let
> it enter at top level and let the executives suggest it, so the project
> managers have their backs free.

I disagree with this. The developer leads need to convince
their managers/project managers, if Ada has any hope in
a shop that doesn't do any/much Ada. If the developer team
won't support it, then why would anyone above them support
it?

OTOH, if the developers don't support it, but the manager
does (because he knows about Ada from a prior life etc.),
then he must first get his team to buy into the idea.
Questions often get directed at the technical people for
their opinion. If they won't support Ada, then upper
management won't have the courage (no warm and fuzzies).

Once the "lower level" is behind the idea, then you might
have hope at convincing the upper level (but the project
manager will need courage and persistance).

So I would say it is _necessary_ to support Ada from the
bottom up. Without support from the bottom, why choose
an option that looks risky at the higher levels?

> One way to get their attention could be to suggest Berkeley or Oxford (or
> whoever makes these kinds of analyses) to make a thorough investigations
> based on real business cases, with help from "people in the business" = us,
> and make them do all the economical consequence maths, for very small
> projects with no safety critical issues, to very large projects with all the
> whistles and bells.

I think there is already enough "evidence". The problem as
I see it, is one of acceptance. But perhaps, Universities
can help some..

If more Universities would teach and use Ada in their
curriculum, then people would come out of them knowing
and preferring Ada.

In fact this is an area that surprises me most of all!

Why don't univesities naturally prefer Ada?!?!?

Ada is so nice in that it allows the writer to code the
program in terms that make sense to the algorithm. Array
bounds can be set to match the algorthm (like -3..3 for
example), without worrying about implementation issues.
In most other languages, you are constantly mapping
array indexes that the algorithm needs to 0..n-1 or
1..n etc., depending up the language chosen etc.  Generics
and other nice facilities in the Ada language would seem
to make it a natural for theoretical work and research.
Certainly correctness is important to research?

So what surprises me most, is why Universities
don't naturally prefer Ada, when it lets you abstract
your code to match the model in your mind?  Instead,
many profs seem to dismiss Ada in favour of trendy
things like Java. Yet evidence abounds in how well
students do with Ada, over other languages.

So I find this real hard to understand.

This leads me to conclude that most of these
people either just never came to know Ada
well enough, or have never understand the
benefits of the language. To me, Ada would
seem most natural fit for University work.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics (why not Universities?)

[Marius Amado Alves]

> In fact this is an area that surprises me most of all!
> 
> Why don't univesities naturally prefer Ada?!?!?

I can offer this recent experience. I was hired by a University to teach 
Imperative and Object-Oriented Languages in 2002/2003. The curriculum 
included Ada and Smalltalk. I was thrilled. For 2003/2004 another person 
was put in charge. The new person's background did not include Ada or 
Smalltalk. So they just changed the curriculum. (To Java and C I think.) 
Can you see the pattern here? The future teachers are today's students. 
If they don't have a background in Ada, they won't teach it. This began 
one generation ago, so Ada is not taught today, and never will be.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics (why not Universities?)

[Warren W. Gay VE3WWG]

Marius Amado Alves wrote:
> 
>> In fact this is an area that surprises me most of all!
>>
>> Why don't univesities naturally prefer Ada?!?!?
> 
> I can offer this recent experience. I was hired by a University to teach 
> Imperative and Object-Oriented Languages in 2002/2003. The curriculum 
> included Ada and Smalltalk. I was thrilled. For 2003/2004 another person 
> was put in charge. The new person's background did not include Ada or 
> Smalltalk. So they just changed the curriculum. (To Java and C I think.) 
> Can you see the pattern here? The future teachers are today's students. 
> If they don't have a background in Ada, they won't teach it. This began 
> one generation ago, so Ada is not taught today, and never will be.

I am not surprised at this. After all, the same problem occurs
in the business world. People recommend and use what they
already know.

Sounds like universities suffer from the chicken and egg
problem.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Ada in colleges and universities.

[Peter C. Chapin]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in news:iEZwc.6943
$8k4.235178@news20.bellglobal.com:

> Sounds like universities suffer from the chicken and egg
> problem.

In the late 1980's we taught Ada at Vermont Technical College (in the 
computer engineering technology classes) as the student's first exposure 
to programming. The language was then used in several other classes, 
including one low level interfacing class. The idea was that Ada would 
help teach the students good programming habits and help them develop a 
sense about how programs should be structured and organized. Of course 
such topics could be introduced using any language, but Ada put the ideas 
in the student's faces more and, hopefully, helped them to learn those 
ideas better.

This was all fine, but the reality was that a huge majority of third party 
programs the students had to read or modify were written in C. Also most 
text books contained C examples. It soon became clear that we were not 
properly preparing our students for the real world unless we taught them 
C. One obvious solution would be to teach both. Perhaps introduce them to 
programming using the discipline of Ada and then teach them C later with 
the hope that they would be better C programmers for their Ada background. 
Alas, there is only so much time in any curriculum. It was decided that C 
had to be in the program and that there wasn't enough time for both Ada 
and C. Thus Ada was dropped.

Today we do C and then C++. However, since C++ is a rough superset of C, 
the transition to it is relatively painless and efficient. Ada has not 
been in our program since about 1990 or so.

That's our story.

Peter

Re: Ada in colleges and universities.

[Marius Amado Alves]

>>Sounds like universities suffer from the chicken and egg
>>problem.
> 
> In the late 1980's we taught Ada at Vermont Technical College (in the 
> computer engineering technology classes) as the student's first exposure 
> to programming....

Was that a vocational training or a University degree? I can understand 
vocational training curricula bending to the job market demand to the 
point of excluding something theoretically better, but this should not 
happen in Universities. Make room!

Re: Ada in colleges and universities.

[Peter C. Chapin]

Marius Amado Alves <amado.alves@netcabo.pt> wrote in 
news:mailman.68.1086629374.391.comp.lang.ada@ada-france.org:

> Was that a vocational training or a University degree?

Something in between. The degree was a two year degree, but it wasn't exactly 
"vocational" in the sense one typically means by that term. However, because 
it was a two year program, the immediate needs of the job market figured more 
highly in it than might have been the case otherwise.

I use the past tense here because VTC currently has a four year computer 
engineering technology degree. This gives us more time to work with than we 
had before. Perhaps the question of introducing Ada to the students should be 
revisited.

Peter

Re: Ada in colleges and universities.

[Björn Persson]

Peter C. Chapin wrote:

> Alas, there is only so much time in any curriculum. It was decided that C 
> had to be in the program and that there wasn't enough time for both Ada 
> and C. Thus Ada was dropped.

That seems very strange to me. In the university courses in programming 
I've taken, they first taught us functional programming in Scheme and 
then imperative programming in Pascal. Then we moved on to 
object-oriented programming in Java, modelling in UML, and a kind of 
mathematical notation for data structures. There was even time for some 
BNF. That was all in courses intended to be equivalent to about 20 weeks 
of full time studying, and meant for students who hadn't programmed before.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Ada in colleges and universities.

[Marius Amado Alves]

>> Alas, there is only so much time in any curriculum. It was decided 
>> that C had to be in the program and that there wasn't enough time for 
>> both Ada and C. Thus Ada was dropped.
> 
> That seems very strange to me. In the university courses in programming 
> I've taken, they first taught us functional programming in Scheme and 
> then imperative programming in Pascal. Then we moved on to 
> object-oriented programming in Java, modelling in UML, and a kind of 
> mathematical notation for data structures. There was even time for some 
> BNF. That was all in courses intended to be equivalent to about 20 weeks 
> of full time studying, and meant for students who hadn't programmed before.

I bet that was in Europe. They're crazy in the USA :-) Sometime ago they 
entirely took out programming practice from the CS curriculum, can you 
imagine?

But there's no Ada being taught in Europe either.

Re: Ada in colleges and universities.

[Jerome Hugues]

In article <mailman.69.1086634524.391.comp.lang.ada@ada-france.org>, 
Marius Amado Alves wrote:

> But there's no Ada being taught in Europe either.

Not quite true, the following

http://www.ada-france.org/rubrique19.html

lists High School and Universities in France that provide Ada lessons.

http://d.feneuille.free.fr/enseignerada.htm

provides more information on that topic

-- 
Jerome

Re: Ada in colleges and universities.

[(see below)]

On 7/6/04 7:55 pm, in article
mailman.69.1086634524.391.comp.lang.ada@ada-france.org, "Marius Amado Alves"
<amado.alves@netcabo.pt> wrote:

> 
> But there's no Ada being taught in Europe either.
> 

Oh, yes there is!

Glasgow University uses Ada 95 as the foundation language for CS1 and CS2,
and has done since 1996.

FP using Haskell is added in CS2; C and Java are added in CS3 (it's a 4-year
program.)

When certain senior professors tried to have Ada replaced with Java,
the class head of CS1 threatened to resign. Ada 95 was retained.
In 2001 there was a curriculum review, at which Java was again touted.
Thanks to the staff teaching Ada, there was again no change of policy.
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Ada in colleges and universities.

[Marius Amado Alves]

> Glasgow University uses Ada 95 as the foundation language for CS1 and CS2,
> and has done since 1996.
> 
> FP using Haskell is added in CS2; C and Java are added in CS3 (it's a 4-year
> program.)
> 
> When certain senior professors tried to have Ada replaced with Java,
> the class head of CS1 threatened to resign. Ada 95 was retained.
> In 2001 there was a curriculum review, at which Java was again touted.
> Thanks to the staff teaching Ada, there was again no change of policy.

Great! Let's hope it's not just a matter of time before the Adaists retire.

Re: Ada in colleges and universities.

[Alexander E. Kopilovich]

"(see below)" wrote:

> Glasgow University uses Ada 95 as the foundation language for CS1 and CS2,
> and has done since 1996.
>
> FP using Haskell is added in CS2; C and Java are added in CS3 (it's a 4-year
> program.)

I believe that students have little difficulty with C and Java after Ada 95
and Haskell... and also that their C/Java code should be generally better
(cleaner and safer) comparing with an audience that was initiated with C or
Java. By the way, the latter seems to be a good argument for those who cares
for practical purposes and future careers.

> When certain senior professors tried to have Ada replaced with Java,
> the class head of CS1 threatened to resign. Ada 95 was retained.
> In 2001 there was a curriculum review, at which Java was again touted.
> Thanks to the staff teaching Ada, there was again no change of policy.

So they deserve to teach Ada as they were ready to fight for that.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ada in colleges and universities.

[Björn Persson]

Marius Amado Alves wrote:

> I bet that was in Europe.

Yes. Stockholm, Sweden.

> They're crazy in the USA :-) Sometime ago they 
> entirely took out programming practice from the CS curriculum, can you 
> imagine?

No, I can't. :-)


As a side note, one of the books we had in the first course was 
Programming Language Concepts and Paradigms by David A. Watt. The 
examples of exception handling in Ada in that book made me decide that I 
had to have a closer look at Ada, and here I am now.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Ada in colleges and universities.

[(see below)]

On 7/6/04 11:06 pm, in article GF5xc.95263$dP1.306414@newsc.telia.net,
"Bj�rn Persson" <spam-away@nowhere.nil> wrote:

> As a side note, one of the books we had in the first course was
> Programming Language Concepts and Paradigms by David A. Watt. The
> examples of exception handling in Ada in that book made me decide that I
> had to have a closer look at Ada, and here I am now.

Then you might like to have a look at his new opus, "Programming Language
Design Concepts", which, despite the publisher's blurb downplaying Ada,
makes even better use of it for significant examples.

(I wrote the concurrency chapters in the new book as well. 8-)
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Ada in colleges and universities.

[Adrian Knoth]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:

> But there's no Ada being taught in Europe either.

I don't know whether it's comparable at all, but we at university
don't care that much what is "used in the wild". We have no tuition fees.
Every time industry asks for teaching something they need we tell
them: "ok, pay us and we'll train our students for you. Otherwise shut up."

When you start studying CS you'll have the first programming-course.
You can't call it course because nothing is taught. There are some
tutorials for beginners but usually you'll receive your weekly jobs
to be done, you'll do them and mail the results.

The language used for that is Modula3. Reason: probably noone
has used Modula3 before, thus giving equal chances to everyone.

In addition, functional programming, some ASM and Java is taught
but not programmed.

One year later you'll have to do the second programming-course,
covering Ada95 and Java.

For "computer architecture & design" you'll do VHDL and later SystemC,
but also ASM for RISCs.

The lessons tackling "programming languages" focuss on special
concepts used in different languages.

The courses for compiler construction uses both Ada and Java
for writing parsers, scanners and so on.

The two last always emphasize that there are so many good things
in Ada not reached by any other language. ;)

Some other courses uses C or C++, e.g. "parallel algorithmns" (MPI),
"image manipulation" or "pattern recognition".

So to say: we do it all.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Windws is ine for backgroun comunicaions - Bll Gats

Re: Ada in colleges and universities.

[Jeffrey Carter]

Adrian Knoth wrote:
> Some other courses uses C or C++, e.g. "parallel algorithmns" (MPI),
> "image manipulation" or "pattern recognition".

It seems odd to use sequential languages for parallel algorithms, 
especially when you have concurrent languages available.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail
11

Re: Ada in colleges and universities.

[Adrian Knoth]

Jeffrey Carter <spam@spam.com> wrote:

>> Some other courses uses C or C++, e.g. "parallel algorithmns" (MPI),
>> "image manipulation" or "pattern recognition".
> It seems odd to use sequential languages for parallel algorithms, 
> especially when you have concurrent languages available.

Parallel algorithms is a theory-course without any programming.
Teaching is done for the pRAM. In addition a practical part is
offered by a student (dumbass) for those who don't want to
write a test. As far as I know MPI sucks. Quote:

"So to say, MPI is C++-encapsulated C?"
"No, MPI is C++-encapsulated Fortran"



-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

  Schlecht: Deine Kinder sind schon sexuell aktiv.
  Panik: Miteinander.

Re: Ada in colleges and universities.

[Jano]

> But there's no Ada being taught in Europe either.

Another counterexample: University of Zaragoza, Spain. Language of
choice for several courses (at least four that I can remember, and
tangencially used in several more).

Re: Ada in colleges and universities.

[Pascal Obry]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> But there's no Ada being taught in Europe either.

That's just plain wrong :( Please be careful when saying this kind of
thing. This will gladly be used by Ada detractors !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada in colleges and universities.

[Peter C. Chapin]

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

Bj�rn Persson <spam-away@nowhere.nil> wrote in news:zD2xc.95220$dP1.306334
@newsc.telia.net:

> That seems very strange to me. In the university courses in programming 
> I've taken, they first taught us functional programming in Scheme and 
> then imperative programming in Pascal. Then we moved on to 
> object-oriented programming in Java, modelling in UML, and a kind of 
> mathematical notation for data structures. There was even time for some 
> BNF. That was all in courses intended to be equivalent to about 20 weeks 
> of full time studying, and meant for students who hadn't programmed 
before.

You are probably talking about a computer science program, true? VTC 
offers computer engineering technology. It's more like computer 
engineering which, in turn, is more like electrical engineering than it is 
like computer science. Our students get a lot of hardware courses, 
including basic (and not so basic) electronics. The programming we are 
preparing them for is low level stuff... device drivers, embedded systems, 
specialized executives, etc. We tend to be relatively light on abstract 
theory and heavy on the "practical" construction of systems. If I suggest 
that we reintroduce Ada in the curriculum I know the question will be: 
"How much Ada is being used, relative to C, in the application domains we 
focus on?" How should I best answer a question like that?

Peter

Re: Ada in colleges and universities.

[Björn Persson]

Peter C. Chapin wrote:

> You are probably talking about a computer science program, true?

If I translate the terms right, yes.

> VTC 
> offers computer engineering technology. It's more like computer 
> engineering which, in turn, is more like electrical engineering than it is 
> like computer science. Our students get a lot of hardware courses, 
> including basic (and not so basic) electronics. The programming we are 
> preparing them for is low level stuff... device drivers, embedded systems, 
> specialized executives, etc. We tend to be relatively light on abstract 
> theory and heavy on the "practical" construction of systems.

I see. Then I can understand if you don't teach them functional 
programming. :-)

> If I suggest 
> that we reintroduce Ada in the curriculum I know the question will be: 
> "How much Ada is being used, relative to C, in the application domains we 
> focus on?" How should I best answer a question like that?

I think my best answer would be essentially what you already wrote in 
your earlier post - that if you expect that your students will write 
device drivers or embedded systems, then they will do enough programming 
that they will need to know good programming practice. And while Ada is 
better than C for teaching good programming practice, there's also a 
point in comparing languages. I'd say you're not a good programmer until 
you've tried at least two different languages, because only then will 
you be able to see the weaknesses in a language. (And C and C++ don't 
count as different languages in this case. Starting with C and 
proceeding to C++ is more like starting with the basic parts of Ada and 
introducing generics, tasks and tagged types later.)

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Ada in colleges and universities.

[I R T]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> I'd say you're not a good
> programmer until you've tried at least two different languages,
> because only then will you be able to see the weaknesses in a
> language. 

But ( to play devils advocate ) why should the second one be
Ada ?

Why not Java ( for practicality ) or Ocaml or Smalltalk ( for something totally
different) ?

Re: Ada in colleges and universities.

[Björn Persson]

I R T wrote:

> Björn Persson <spam-away@nowhere.nil> writes:
> 
> 
>>I'd say you're not a good
>>programmer until you've tried at least two different languages,
>>because only then will you be able to see the weaknesses in a
>>language. 
> 
> 
> But ( to play devils advocate ) why should the second one be
> Ada ?
> 
> Why not Java ( for practicality ) or Ocaml or Smalltalk ( for something totally
> different) ?

I know too little about Ocaml and Smalltalk to make any statements. As 
for Java, to some extent for the same reason why C++ doesn't count as a 
second language - that it is so similar to C. (It has inherited the 
switch-break idiocy and the if(a=0) bug for example.) And in this case, 
because Java isn't for low-level programming.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Ada in colleges and universities.

[Wes Groleau]

Bj�rn Persson wrote:
> I R T wrote:
>> Bj�rn Persson <spam-away@nowhere.nil> writes:
>>
>>> I'd say you're not a good
>>> programmer until you've tried at least two different languages,
>>> because only then will you be able to see the weaknesses in a
>>> language. 
>>
>> But ( to play devils advocate ) why should the second one be
>> Ada ?

It shouldn't.  The _first_ one should be Ada.  ;-)

-- 
Wes Groleau
Alive and Well
http://freepages.religions.rootsweb.com/~wgroleau/

Re: Ada in colleges and universities.

[Ludovic Brenta]

"Peter C. Chapin" writes:
> You are probably talking about a computer science program, true? VTC 
> offers computer engineering technology. It's more like computer 
> engineering which, in turn, is more like electrical engineering than it is 
> like computer science. Our students get a lot of hardware courses, 
> including basic (and not so basic) electronics. The programming we are 
> preparing them for is low level stuff... device drivers, embedded systems, 
> specialized executives, etc. We tend to be relatively light on abstract 
> theory and heavy on the "practical" construction of systems. If I suggest 
> that we reintroduce Ada in the curriculum I know the question will be: 
> "How much Ada is being used, relative to C, in the application domains we 
> focus on?" How should I best answer a question like that?

At Barco Avionics, it is roughly 85% Ada, 15% C.  The C is used for
some microcontrollers nor supported by the current Ada compiler, but I
suspect there must be a way to use Ada there too.

-- 
Ludovic Brenta.

Re: Ada in colleges and universities.

[Jeffrey Carter]

Ludovic Brenta wrote:
> 
> At Barco Avionics, it is roughly 85% Ada, 15% C.  The C is used for
> some microcontrollers nor supported by the current Ada compiler, but I
> suspect there must be a way to use Ada there too.

If nothing else, you could use the SofCheck compiler that produces ANSI 
C as its intermediate lanaguage.

-- 
Jeff Carter
"Gentlemen, you can't fight in here. This is the War Room!"
Dr. Strangelove
30

Re: Ada in colleges and universities.

[Ludovic Brenta]

Jeffrey Carter writes:
> Ludovic Brenta wrote:
>> At Barco Avionics, it is roughly 85% Ada, 15% C.  The C is used for
>> some microcontrollers nor supported by the current Ada compiler, but I
>> suspect there must be a way to use Ada there too.
>
> If nothing else, you could use the SofCheck compiler that produces
> ANSI C as its intermediate lanaguage.

Yes, I am aware of it.  The main problems are inertia and DO-178B
certification, not availability of compilers.  Also, no compiler
change can take place during a project; only between projects.

-- 
Ludovic Brenta.

Re: Ada in colleges and universities.

[Warren W. Gay VE3WWG]

Peter C. Chapin wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in news:iEZwc.6943
> $8k4.235178@news20.bellglobal.com:
>>Sounds like universities suffer from the chicken and egg
>>problem.
> 
> In the late 1980's we taught Ada at Vermont Technical College (in the 
> computer engineering technology classes) as the student's first exposure 
...
> This was all fine, but the reality was that a huge majority of third party 
> programs the students had to read or modify were written in C. Also most 
> text books contained C examples. It soon became clear that we were not 
...
> Peter

I think it has been recognized here, quite frequently, that
we basically live in a "C world". So I could see that being
a problem if you were continually interfacing with "the world"
from Ada. Some time ago, there was some discussion here about
how Ada binding could be more easily accomplished.

What I would have expected however, was that there would be
less need to bind to the "world" in academic exercises.

One solution would have been to create the necessary bindings
necessary for the students, to simplify that aspect. Of course,
that only works, if the "need" remains relatively static.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics (why not Universities?)

[Ralph W. Reid]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
[ . . . ]
> I think there is already enough "evidence". The problem as
> I see it, is one of acceptance. But perhaps, Universities
> can help some..
> 
> If more Universities would teach and use Ada in their
> curriculum, then people would come out of them knowing
> and preferring Ada.
> 
> In fact this is an area that surprises me most of all!
> 
> Why don't univesities naturally prefer Ada?!?!?

Around 12 years ago, I was working on my senior project in college,
which was to develope a class for Ada.  Ada had been used during the
previous semester for a class, but the HP-900/3XX system which housed
the compiler was heavily overloaded at times, causing compile and run
times to be annoyingly slow.  During my project, I asked the powers
that were if an Ada compiler could be put on a faster system.  The
response was that the cost of such a compiler then was $10,000--way
outside of any reasonable expense at the time.  As far as I know, I
was the last person to use Ada on any of the campus computers.  Gnat
has since come out, but once the Ada idea died due to cost, it was
never revived.

[ . . . ]

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics (why not Universities?)

[Robert I. Eachus]

Ralph W. Reid wrote:

> Around 12 years ago, I was working on my senior project in college,
> which was to develope a class for Ada.  Ada had been used during the
> previous semester for a class, but the HP-900/3XX system which housed
> the compiler was heavily overloaded at times, causing compile and run
> times to be annoyingly slow.  During my project, I asked the powers
> that were if an Ada compiler could be put on a faster system.  The
> response was that the cost of such a compiler then was $10,000--way
> outside of any reasonable expense at the time.  As far as I know, I
> was the last person to use Ada on any of the campus computers.  Gnat
> has since come out, but once the Ada idea died due to cost, it was
> never revived.

Around 12 years ago, many Ada compiler companies offered substantial 
discounts to educational institutions.  I wondered in part about the 
policy and got an interesting answer--that it was easier for many 
educational institutions to buy the software at a nominal price than to 
install free software on their systems.  So the nominal price about 
covered the paperwork, I think Verdix was $100.

It sounds like whoever checked prices didn't check the educational 
price, or that the current system was being used by students and 
research projects that didn't qualify for the discount.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Richard Riehle]

"Per Dalgas Jakobsen" <i@hate.spam> wrote in message
news:40b9c99e$0$268$edfadb0f@dread16.news.tele.dk...

> Instead of advertising for Ada in software magazines, web-sites, etc. I
> believe that Ada needs to get an "image-lift" at executive level. Imagine
if
> we could get to the point when project managers are suggesting C/C++ and
the
> executive asks: "Why not use Ada?" :-p

Sadly, there is no money available in the Ada community for advertising
or public relations.   The money we did have was squandered on silly
posters and ineffective advertising about the time Ada 95 appeared.  The
people charged with making the advertising decisions were inexperienced
in the ways of advertising and the ads had no appreciable effect.

Advertising is not a bad approach, but it needs to be done by people who
understand the product, the audience, and the mission.  It also needs to be
done by people who understand how to make an impact with advertising.
Just as there are lots of ineffective software managers, there is no
shortage
of stupid advertising executives.   To paraphrase Einstein, the two things
without boundary are space and human stupidity.

Actually Per, your idea sparks an image that might be an interesting Ad if
there were money for it.    A group of people sitting in a conference room,
a whiteboard with the words Java, C++, C#, and Eiffel written on it, and
someone in the meeting asking, "Why not just use Ada?"

Such an ad, place in the right journals would spark the debate once again,
if it were widely enough published.

But then, we have wasted all our money and resources on useless stuff so
there
is none left to produce such an ad.

Richard Riehle

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

Success breeds success. Advertising is a good idea but you have to have 
something to advertise with and about. That would be money and success. 
There are ways of getting attention on a product that don't necessarily 
involve lots of money, but I'd suggest that the absolute *best* way is 
to make some end products using Ada and successfully show that you did 
it with less cost and to better quality. Some real-world software 
product with an "Ada Inside" sticker on it that is selling like hotcakes 
because it works better and costs less is going to do far more for 
raising Ada's image than all the ads in all the journals in the world.

Or is it that Ada just doesn't bring enough advantage to a development 
effort and it wouldn't show on the bottom line? If that's true then we 
should all shut up about the "stupid" managers who pick other more 
popular languages. Either Ada pays or it doesn't. If it pays, then why 
not make it pay *us*?

We've got to quit trying to persuade the current 
language-decision-makers and *become* the language-decision-makers. 
That's done by building our own products in Ada and being successful 
with them.

MDC


Richard Riehle wrote:
> 
> 
> Sadly, there is no money available in the Ada community for advertising
> or public relations.   The money we did have was squandered on silly
> posters and ineffective advertising about the time Ada 95 appeared.  The
> people charged with making the advertising decisions were inexperienced
> in the ways of advertising and the ads had no appreciable effect.
> 
> Advertising is not a bad approach, but it needs to be done by people who
> understand the product, the audience, and the mission.  It also needs to be
> done by people who understand how to make an impact with advertising.
> Just as there are lots of ineffective software managers, there is no
> shortage
> of stupid advertising executives.   To paraphrase Einstein, the two things
> without boundary are space and human stupidity.
> 
> Actually Per, your idea sparks an image that might be an interesting Ad if
> there were money for it.    A group of people sitting in a conference room,
> a whiteboard with the words Java, C++, C#, and Eiffel written on it, and
> someone in the meeting asking, "Why not just use Ada?"
> 
> Such an ad, place in the right journals would spark the debate once again,
> if it were widely enough published.
> 
> But then, we have wasted all our money and resources on useless stuff so
> there
> is none left to produce such an ad.
> 
> Richard Riehle
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Berend de Boer]

>>>>> "Marin" == Marin David Condic <nobody@noplace.com> writes:

    Marin> Or is it that Ada just doesn't bring enough advantage to a
    Marin> development effort and it wouldn't show on the bottom line?

True, no proof exist for this. Competent programmers write good, clear
and maintainable programs regardless of the language (except Perl
perhaps).

There is no absolute, undeniable proof that using Eiffel or Ada does
make this process faster. There is no proof that debugging time is
drastically less. There is no proof that maintainance is lower.

There is no proof that even it it was the case it matters more than
10% of the total budget.

Don't get me wrong, I'm using Eiffel and believe that those languages
make a difference to the bottom line, but it is just belief.


And even if there were really hard facts, would that alter a lot? Just
look at other sciences and pseudo-sciences. Facts don't alter human
behaviour.

-- 
Regards,

Berend. (-:

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[tmoran]

> Facts don't alter human behaviour.
Humans whose behavior is not altered promptly when they are told facts,
eventually alter their behavior, more painfully, later.  Ask, eg, George Bush.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

I was wondering if anyone was going to say it. :-)

IMHO, Ada is a good language and it can make a difference in getting a 
system produced faster and of higher quality - all other things being 
equal. Since things are seldom equal, one can imagine scenarios wherein 
using C++ or something else might actually get the job done faster and 
of higher quality than with Ada.

Even if Ada is better at getting a system out the door quicker and with 
fewer bugs, is it *that* much better to justify its use over some other 
tool? Does it produce enough difference on the bottom line of the 
business to warrant using it in the face of all the negatives? (Lack of 
trained staff, lack of sufficient tools, lack of libraries, lack of 
industry support, lack of corporate experience, etc...) Whatever the 
objections are to using Ada, they can only be overcome if there is 
enough economic benefit to selecting that technology to outweigh the 
cost of doing so. Is it enough benefit to outweigh the risks? Does it 
impact the bottom line enough to justify swimming against the tide?

In other words, let's quit throwing spitballs at the project managers 
who pick something other than our favorite language and stop calling 
them idiots for doing so. Chances are, there is some reasonable 
justification behind their decision and if *we* would make a different 
decision then *we* should step up to the plate, take on the job of being 
a project manager, be responsible for the bottom line, put our jobs and 
the jobs of those who work for us on the line and make the decision 
ourselves. (Or is it just easier to sit on the sidelines and criticize 
those who actually *do* have to make those tough decisions and take 
those risks?)

If we're really convinced that we've got a better technology that is of 
sufficient benefit that it can show up on the bottom line of the 
financial report, then we ought to be dreaming up ways of using Ada in 
making and selling a product. Anybody who has an interesting venture 
they'd like to discuss can always talk to me about it & perhaps we come 
up with something. ;-)

MDC


Berend de Boer wrote:
>>>>>>"Marin" == Marin David Condic <nobody@noplace.com> writes:
>>>>>
> 
>     Marin> Or is it that Ada just doesn't bring enough advantage to a
>     Marin> development effort and it wouldn't show on the bottom line?
> 
> True, no proof exist for this. Competent programmers write good, clear
> and maintainable programs regardless of the language (except Perl
> perhaps).
> 
> There is no absolute, undeniable proof that using Eiffel or Ada does
> make this process faster. There is no proof that debugging time is
> drastically less. There is no proof that maintainance is lower.
> 
> There is no proof that even it it was the case it matters more than
> 10% of the total budget.
> 
> Don't get me wrong, I'm using Eiffel and believe that those languages
> make a difference to the bottom line, but it is just belief.
> 
> 
> And even if there were really hard facts, would that alter a lot? Just
> look at other sciences and pseudo-sciences. Facts don't alter human
> behaviour.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Wes Groleau]

Berend de Boer wrote:
> There is no absolute, undeniable proof that using Eiffel or Ada does
> make this process faster. There is no proof that debugging time is
> drastically less. There is no proof that maintainance is lower.

There is no "absolute, undeniable proof"--but there
IS credible empirical evidence.

http://www.adaic.org/whyada/index.html
http://www.adaic.org/whyada/ada-vs-c/cada_art.html

The latter is not the only such study.  But I am not sure
where the others are

-- 
Wes Groleau
    "Lewis's case for the existence of God is fallacious."
"You mean like circular reasoning?"
    "He believes in God.  Therefore, he's fallacious."

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Pascal Obry]

Berend de Boer <berend@xsol.com> writes:

> True, no proof exist for this. Competent programmers write good, clear
> and maintainable programs regardless of the language (except Perl
> perhaps).

There is definitly some reports about Ada that proves it costs less.

> Don't get me wrong, I'm using Eiffel 

I know :)

> and believe that those languages
> make a difference to the bottom line, but it is just belief.

For Eiffel maybe, it is indeed a very good language too. I regards Eiffel as
I do for Ada. Both are languages great to build large scaled softwares.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

Richard Riehle wrote:

> "Per Dalgas Jakobsen" <i@hate.spam> wrote in message
> news:40b9c99e$0$268$edfadb0f@dread16.news.tele.dk...
> 
>>Instead of advertising for Ada in software magazines, web-sites, etc. I
>>believe that Ada needs to get an "image-lift" at executive level. Imagine if
>>we could get to the point when project managers are suggesting C/C++ and
>>the executive asks: "Why not use Ada?" :-p
> 
> Sadly, there is no money available in the Ada community for advertising
> or public relations.   The money we did have was squandered on silly
> posters and ineffective advertising about the time Ada 95 appeared.  The
> people charged with making the advertising decisions were inexperienced
> in the ways of advertising and the ads had no appreciable effect.
...
> Richard Riehle

Well, if Open Source projects can receive funding through the
use of an Open Sourced (Penguin logo-ed) credit card (through
interest profits), then perhaps something similar could be used
to fund advertising for Ada. The largest problem might be to
attract enough card users, though they need not be software
people at all.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Marin David Condic]

I basically agree with your analysis. I'd suggest that the way to get 
executive level attention is by having companies that successfully build 
things with a large software component developed in Ada be successful in 
selling their wares. A company that makes some device or software 
product that gets it out the door faster/better/cheaper and does it in 
Ada is going to get attention.

Trying to persuade mid-level managers in existing companies that they 
should adopt Ada when the rest of the world is using C++ or Java is 
going to be an uphill, losing battle. Forget the frontal assault and do 
an end-run around them. Start a company that markets something built in 
Ada and *prove* it is better because you're getting stinking rich doing 
it. Or is Ada not that much better?

MDC


Per Dalgas Jakobsen wrote:
> 
> The good old story: "You don't get fired for choosing IBM".
> The good old story on a new bottle: "You don't get fired for choosing
> Microsoft".
> The good old story on a another new bottle: "You don't get fired for
> choosing C/C++".
> 
> One way to make Ada come through, is to make it visible to them. Not just to
> those at the "safety-critical" segment, but to the entire software segment.
> A couple of years ago I suggested changing from C/C++ to Ada on a company
> strategy meeting. The suggestion was met with comments like: "No real
> company is using Ada for anything", "Ada is a heavy/slow and expensive
> language", "Only projects with a *lot* of money can do that", "We are not
> building rockets or aeroplanes, we are just building ...".
> 
> Even though you can counter-argue most of their claims, they still have it
> in their stomach and won't make the leap.
> 
> Instead of advertising for Ada in software magazines, web-sites, etc. I
> believe that Ada needs to get an "image-lift" at executive level. Imagine if
> we could get to the point when project managers are suggesting C/C++ and the
> executive asks: "Why not use Ada?" :-p
> 
> It doesn't take many arguments to convince most serious programmers of the
> advantages in Ada (even though there *are* religious extremists around, that
> believe void-pointers and goto-statements are the only true way) - But it
> really doesn't matter if the project managers doesn't have the courage to
> even suggest it, because of the opinion of the executives.
> 
> Executives will like to hear:
> *) that the reusability factor of Ada is magnitudes higher than for C/C++.
> *) that Ada is much better suited than C/C++ for larger projects with
> several (potential distanced) developers. And by larger, I mean almost any
> project with a project manager.
> *) that Ada projects results in fewer bugs at the customer.
> I'll bet that this news-group can come up with a dozen or more easy-to-prove
> arguments...
> 
> But another important thing to nail into their heads are: It does *not* have
> to be expensive to choose Ada. Most visible projects are safety-critical
> once, with budgets in the "heavy league".
> We need to establish a common knowledge, that Ada is as cheap as choosing
> C/C++ (buying toolchains), and that even small projects will have a higher
> probability to complete on time with fewer bugs.
> The cost of sending people on Ada courses will be insignificant in anything
> but the narrowest view.
> 
> 
> But how can we get the attention of the executives?
> Let the brainstorm start ;-)
> 
> Per
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image

[Björn Persson]

I think Ada needs to be rebranded to get away from its disrepute. From 
my - admittedly not very experienced - point of view, far too many 
people seem to know Ada solely from the phrase "Oh no! Not Ada!". Free 
software started to get accepted when it was rebranded as Open Source. 
Maybe Ada 200Y should be given another name. Call it Ceylon for example, 
and introduce it as a brand new, modern, object oriented, Unicode 
enabled language.

Abandoning the name "Ada" would be a very small price to pay. I 
certainly don't care what the language is called as long as it's a good 
language.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Improving Ada's image

[Alexander E. Kopilovich]

Bj?rn Persson wrote:

> far too many 
> people seem to know Ada solely from the phrase "Oh no! Not Ada!". Free 
> software started to get accepted when it was rebranded as Open Source. 
> Maybe Ada 200Y should be given another name. Call it Ceylon for example, 

I'd like to note (following one old Russian anecdote), that this is not enough
to change the name once - you should do that at least twice, for a case when
someone suspiciously asks: "But what is the previous name?" . So you should,
after renaming Ada to Ceylon, not turn immediately to propaganda, but wait a
little, and then rename Ceylon to Sri Lanka - and only after that you may
begin you rebranding campaing.

> and introduce it as a brand new, modern, object oriented, Unicode 
> enabled language.

And also offshore-enabled (as the name gently suggests).



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Improving Ada's image

[Marin David Condic]

If Ada doesn't fix its core problems, changing the name won't make any 
difference. I think at the heart of its troubles is perhaps a cultural 
attitude that tends to work against it. We tend to get all wrapped up in 
various technical concerns and don't think about how it affects the net 
result. We want to write "perfect" software (not a bad goal) but neglect 
the concerns of the people who have to produce and sell an end product. 
They need things we're not giving them - or at least not addressing them 
as well as they can get elsewhere. Unless the focus shifts to one that 
truly emphasizes the needs of that end user and it gets more in line 
with making Ada a significant benefit to them and addresses their needs 
better, changing the name won't help much.

MDC


Bj�rn Persson wrote:
> I think Ada needs to be rebranded to get away from its disrepute. From 
> my - admittedly not very experienced - point of view, far too many 
> people seem to know Ada solely from the phrase "Oh no! Not Ada!". Free 
> software started to get accepted when it was rebranded as Open Source. 
> Maybe Ada 200Y should be given another name. Call it Ceylon for example, 
> and introduce it as a brand new, modern, object oriented, Unicode 
> enabled language.
> 
> Abandoning the name "Ada" would be a very small price to pay. I 
> certainly don't care what the language is called as long as it's a good 
> language.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Hyman Rosen]

Per Dalgas Jakobsen wrote:
> *) that the reusability factor of Ada is magnitudes higher than for C/C++.

Really? Why do you think so? What is it about Ada that would make a body
of code written for one purpose reusable for another, in a way that does
not apply to C or C++?

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Per Dalgas Jakobsen]

>> *) that the reusability factor of Ada is magnitudes higher than for
C/C++.
>
> Really? Why do you think so? What is it about Ada that would make a body
> of code written for one purpose reusable for another, in a way that does
> not apply to C or C++?

Reusability implies portability (at least for my case), since we are using
several platforms for a given system.
Generics/templates aids reusability


For generics/templates:

For C it gives itself: no generics/templates. You could use macros for some,
but they really doesn't do the job very nice.

For C++, templates should be the answer, but unfortunately quite a bit of
"implementation specific freedom" renders this feature "less useful".
http://www.mozilla.org/hacking/portable-cpp.html (a bit old, but still valid
to some extend).

For Ada, generics seems to work quite nicely.


For portability:

C and C++: I would almost call it non-existing. Try reading a binary
byte-aligned file into a C/C++ struct. It's fairly easy with one compiler
(if it's not the opposite endianess), but try make it work across different
compilers... :-(

Ada has the nice for-use statement that pretty much solves this mess.


And just exactly how big is an int? Well, we could define an int16 for a
signed 16 bit integer, int32 ..., etc. But how do you get it into your code:
You include a header-file with sized integer types.
Then another guy wants to use your code, but he has his own header-file with
sized integer types, unfortunately this guy has named his unsigned 8 bit as
uchar8, and you called it uint8. Now what? Things gets very messy, very
fast.

In Ada you just define a type with a suitable range and size.


C and C++ has conditional compiles, which very fast gets very messy.

No such thing in Ada.


I believe we could add quite a bit to this list.
Btw.: "Safer C" by Les Hatton is "fascinating" reading.


Did I miss the point here?

Per

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Ed Falis]

On Tue, 1 Jun 2004 23:14:11 +0200, Per Dalgas Jakobsen <i@hate.spam> wrote:

> Did I miss the point here?

I don't think you did.  These are not outstandingly strong arguments, but  
they are small-ish things that add together.  I've used a lot of languages  
(includng Java), and find Ada to be the most portable across  
implementations.  Part of that phrase "most portable" means "relatively  
easy to adapt" when it doesn't just work out of the box.

- Ed

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Stefan Nobis]

"Per Dalgas Jakobsen" <i@hate.spam> writes:

> For C++, templates should be the answer, but unfortunately quite a bit of
> "implementation specific freedom" renders this feature "less useful".
> http://www.mozilla.org/hacking/portable-cpp.html (a bit old, but still valid
> to some extend).

No, that's not valid today! The page is dated even before the
release of the official ISO Standard for C++ and that's over six
years since.

Today even MS Visual C++ supports templates quite good.

> And just exactly how big is an int? Well, we could define an int16 for a
> signed 16 bit integer, int32 ..., etc. But how do you get it into your code:
> You include a header-file with sized integer types.
> Then another guy wants to use your code, but he has his own header-file with
> sized integer types, unfortunately this guy has named his unsigned 8 bit as
> uchar8, and you called it uint8. Now what? Things gets very messy, very
> fast.

There are standard types for this kind of sizing quite a time
around now (see stdint.h -- OK, it's ISO C99 but most C++
compilers support this too and there's a cstdint.hpp from
boost.org for C++).

> Did I miss the point here?

No, but your information are a bit outdated in some areas.

-- 
Stefan.

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Jeffrey Carter]

Stefan Nobis wrote:

> "Per Dalgas Jakobsen" <i@hate.spam> writes:
> 
>> For C++, templates should be the answer, but unfortunately quite a
>> bit of "implementation specific freedom" renders this feature "less
>> useful". http://www.mozilla.org/hacking/portable-cpp.html (a bit
>> old, but still valid to some extend).
> 
> No, that's not valid today! The page is dated even before the release
> of the official ISO Standard for C++ and that's over six years since.
> 
Those are still the rules that Mozilla developers must adhere to today.

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Rod Chapman]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<oLwuc.17575$be.14510@newsread2.news.pas.earthlink.net>...

> As to other universities, there is currently no incentive for professors to
> carry out
> any kind of research that might favor Ada.   The scholarly journals prefer
> contributions
> that avoid Ada,  the textbook publishers edit out excessive references to
> Ada, and
> the DoD is not funding any Ada research projects anymore.

Richard and others,
  We have recently been rather successful (by our own modest
standards)
at getting Ada into University programmes...How?  The answer is
simple: SPARK!

 SPARK offers faculty some really interesting stuff to play with:
design-by-contract, program proof, static analysis, hard real-time,
embedded etc. etc.  Secondly, the professional toolset is free (as
in no dollars) to university faculty.

Off the top of my head, the following US
institutions have taught SPARK on advanced courses in the last 
couple of years: NYU, Northern Iowa, Virginia, JMU, Oakland,
USAFA, and NPGS.  Not a bad start.  Several others use SPARK in
research: MIT springs to mind, plus York, Birmingham, Heriot-Watt
in the UK.

 There's also a pretty darn good textbook about SPARK, which 
helps. :-)  

 At SIGCSE this year, the SIGAda and ARA people were cleaned out
of SPARK book samplers and CDROMs - we sent over 50 sets and
could have probably shifted double that.  We have subsequently
been contacted by other authors who want to include SPARK
in next editions of their programming languages textbook.
Not a bad sign.

 As for publications, we have some success - IEEE Transactions on SE,
IEEE Software, CrossTalk (a DoD sponsored journal!) hardly seem
like small-fry.  Heriot-Watt's current work on automated
proof is appearing in significant conferences and (soon) 
journals.

 Finally, the _really_ great thing about SPARK is that you can
tell your conference program committee, journal referees, and
board of studies all about it, WITHOUT MENTIONING THAT IT'S Ada!
(at least not until the light-bulb has gone on and people have
realised
how great it is...)  This really does work - honest.

 So here's a challenge for the Ada community: get SPARK into
your local university CS program, without telling 'em
it's Ada.  Go ahead - you know you want to!  When someone
asks what the language is like, tell 'em it's hard-real-time-
Eiffel-on-steroids.  When someone asks which compiler you use,
tell 'em "GCC of course"...go on give it a go - Praxis will
support your efforts...

 - Rod, SPARK Team

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Georg Bauhaus]

Rod Chapman <rod.chapman@praxis-cs.co.uk> wrote:
 
: tell your conference program committee, journal referees, and
: board of studies all about it, WITHOUT MENTIONING THAT IT'S Ada!
: (at least not until the light-bulb has gone on and people have
: realised
: how great it is...)  This really does work - honest.


Maybe one could add then that there is now what Tony Hoare
has been asking for for so song, a <your adjectives here>
Ada subset?



-- Georg

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[abrandon]

I can't figure out from his message how to write to Marin directly, so this 
has to be public correction: You're missing apostrophes in both your "it's" in 
your tagline. Also, your email address that's spaced out is incomplete, ending 
in ".r" rather than the usual ".com" or ".org".

"Face it, gentlemen, it's not the typos that make you look sloppy. . ."

Ann Brandon,
proof reader extraordinaire

Re: Improving Ada's image - Was: 7E7 Flight Controls Electronics

[Wes Groleau]

abrandon@sover.net wrote:
> your tagline. Also, your email address that's spaced out is incomplete, ending 
> in ".r" rather than the usual ".com" or ".org".

Read both lines "zigzag"

> "Face it, gentlemen, it's not the typos that make you look sloppy. . ."

I will not discuss the diplomacy and/or lack of it
in his sig quote.  :-)

-- 
Wes Groleau

A pessimist says the glass is half empty.

An optimist says the glass is half full.

An engineer says somebody made the glass
        twice as big as it needed to be.