Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Kent Paul Dolan]

[Sorry if you see this half a dozen times, groups.google.com was
having a senior moment, never confirmed the previous attempt to post
this article.]

Richard Riehle <richard@adaworks.com> wrote:
> soft-eng wrote:

>> If the DOD had its way, _everything_ would have been
>> written in Ada.

It helps to remember the context.  The DoD had, and has to
this day, a situation where battlefield computers programmed
in different languages couldn't talk to one another.  A
couple of obvious results of this kind of situation are that
people die from friendly fire problems, and that people die
from corrupted transmissions.  It was, and still is,
important that the computer software share a single
language, with that language's exact semantics for
primitives and user declared types, so that communication
succeeds and at least the people fighting on our side get to
claim they got killed by the enemy instead of friendly
forces or computer glitches.

One of the most direct ways to assure that software talent
for this common language was and remained available was to
make it the case that _all_ DoD software was written in this
same language, mandatorily.  Top Secret clearances are
expensive to produce, and keeping cleared people employed as
contractors is easier if their language skills translate
between application desmenes.

Beyond that, DoD had many languages that were in use nowhere
else, so finding programmers at all for any program on a
staffing up-curve was problematic; while having a DoD-wide
language also in widespread commercial use would have made the
programming staff-finding chore simpler.

Making the language mandatory DoD-wide made sense for other
reasons as well.  Logistics bobbles can kill people in
wartime at least as readily as howitzer aiming bobbles, it's
just usually less immediately obvious.

A side result of the need to have all kinds of applications
programmed in this common language is that the language had
to support the idioms of a wide varieties of applications:
to do scientific calculations like FORTRAN, business
calculations like COBOL, communications bit fiddling and
calculations like C, and so forth.  This _does_ tend to make
for a fairly large language, but various application areas
can pretty much stick to the subsets included for their
needs and ignore the parts they don't need, so the language
isn't so large from the viewpoint of any one programmer.

> In 1996, Assistant Secretary of Defense, Emmett Paige, an
> Ada advocate, decided that Ada had sufficient success in
> the projects where it had been used that it should stand
> on its own merits instead of being a part of a mandate. 

Which was total BS, and a whitewash besides.

BS because you don't "optionally" need battlefield
compatibility, "optionally" need programmer portability;
these are always needed, and the mandate should have been
strengthened and better enforced, not removed.

Whitewash, because what had actually happened was a
rebellion among the services, that should have had a large
number of officers cashiered if not court-martialed.  Abuse
of the exemption system had gutted the Ada mandate, and
commands, one where I worked among them, were scamming the
exemption system to get ongoing exemptions for problems they
caused themselves in the first place, in very
straightforward attempts to avoid converting software staff
to Ada software staff, and prolonged so long as they could
keep getting exemptions that let them avoid doing the hard
work needed to become unexemptable.

If the Ada mandate hadn't been dropped, the rebellion would
have to have been treated as what it was.  The DoD chose to
cave rather than apply military standards to a military
discipline problem.

> In the early days of Ada, the mid-1980's, when compilers
> were not adequate and people using the language did not
> understand how it was different from what they already
> knew, there were a fair number of failures.

> Since that time, and with the advent of the Ada 95
> standard, there have been significant successes with Ada.
> The compilers are as good as one will find with any other
> language.  The language supports an level of reliability
> not found in most other languages.   It turns out to be
> easier to understand and learn than seemed to be the case
> when it was an entirely new set of ideas.

This is way true.  As a statistic of one, I'm a much better
programmer in many other languages (C, C++, Pascal, Fortran,
Java, Perl, Modula-2, StarLogo, for examples), but I
_prefer_ programming in Ada. It is just a much better
programming language [and this isn't a casual comment; I say
this having committed software development professionally
that delivered code in a gross of programming languages and
dialects over a long career] than the others.

>> Theoretically, they are all working in Ada using very
>> strict procedures.  In actual practice, there are a lot of
>> people who are actually getting real things done!

The mythology of "people getting stuff done by ignoring the
rules" is that the bozos doing so only consider the short
term costs: what it takes to meet management's ridiculously
short milestones.  Factoring maintenance costs into the
picture, these people should be shot, but their managers
should preceed them to the firing squad for allowing what
they do to happen.  What you really have here is the
"programmer as prima donna" syndrome: rules are for other
people, "I'm a hacker!"

Indeed.

> And many of those people are getting real things done in
> Ada.

Especially in the transportation industries, worldwide.

> There is a long list of highly successful military and
> non-military software written in Ada.  Most of it is
> targeted to safety-critical software rather than the
> desktop.  We certainly can point to failures in projects
> that used Ada.   We can also point to failures in projects
> using any other language.  In my experience, the failures
> in which Ada was used had nothing to do with Ada.  In most
> cases, those failures had to do with poor management and
> poor engineering.

That, of course, can be said about software failures
independently of language issues: management is expected to
succeed given _any_ Turing complete language, but "software
management" is still mostly an oxymoron: the technically
incompetent leading the unherdable technocrats.

>> It keeps everybody happy.  The cushy-job crowd spends
>> years to do projects-that-will-go-nowhere using various
>> revisions of Ada, following very complicated specs.

It helps to remind those who think of programming as a
"cushy job" that programmer burnout rates are high,
programmer divorce rates extraordinary, programmer work
hours are obscene, programmer job security is next to
non-existent, programmers come home from long work weeks of
programming to spend hours more in unpaid self-training to
keep up with a field that abandons those who stop learning
for even six months.

> Those complicated specs are necessary because they are
> related to complicated systems.   Ada has been highly
> successful in uncomplicated systems, and also highly
> successful in some of the most complex safety-critical
> systems ever designed and deployed.    In case you did not
> know it, every time you board a commercial jetliner, there
> is a high probability you are depending on Ada at many
> levels, for your safety and dependability of arrival.

>> The get-the-job-done crowd, in the meanwhile, can get all
>> kinds of exemptions and stuff, and gets a lot of real
>> work done.  The real work can then even get some Ada
>> framework around it to keep the Ada people feeling
>> productive!

And now you have an unmanageable, unmaintainable mess that
should never have been allowed to happen: heads should roll.

> You either don't know much about the current state of Ada
> software practice, or you were on a project that was badly
> managed and are one of those who thinks the problem was
> Ada.  I recall a project at NASA Kennedy Space Center
> where I found a lot of people complaining about Ada.  It
> turned out that Ada was not the problem.   Rather, the
> management had insisted that all programming use a vi
> editor.   The engineers assumed this was inherent to Ada
> and constantly complained about Ada when the problem was
> that they hated the editor.

Which is hilarious; the vi(), nvi(), stevie(), vim(),
elvis(), and so on, family of editors were first written for
the use of _secretaries_; they are the easiest editors to
use imaginable, with wonderful ergonomic, navigation, and
search-and-replace mechanisms, and the more up-to-date
versions are far past wonderful, with text type specific
color syntax highlighting, Turing complete scripting
languages, and a wealth of special purpose features.  Like
any powerful tool, they take time and training to achieve
high skill levels and productivity though [for example, I'm
writing this article in vim(), from which I will then cut
and paste the whole article into my browser's utterly
incompetent editor widget, to avoid the pain of using that
widget), and many people, dropped into vi() unwarned, suffer
horribly.

> Another project was on a contact won by a large and
> overly-bureaucratic organization that staffed their
> leadership team with some of the most incompetent people I
> have ever seen in software development.

Given what I've seen at various employments, incompent
people doing software management is utterly the norm.

You get a combination of Peter Principle Promotions:
programmers with no leadership skills suddenly floundering
foolishly in jobs they should never have accepted; and
Lateral Ludicrousness: horizontal transfers of folks who
might be wonderful warehouse worker managers, arriving with
the idea that because you can manage something with
essentially no technical content, you have the skills to
manage something with intensly challenging technical
content, but where most of the management issues are
technical issues, and most of your decisions have to be made
having no idea what the disputing parties are saying.

> The programmers were relatively good, but they were
> saddled with this ineffe[c]tive management.  The project
> was delayed, delayed, delayed, and the complexity
> increased due to the meddling of these incompetent
> managers.  The contract was later won by another
> contractor that had better and more experienced
> leadership.   They did the job, in Ada, just fine after
> firing (should have set fire to) some of the deadwood that
> was keeping things from getting done.

Amen, except the second crowd is a fairy tale in my wide and
long experience.

> I have seen project after project completed successfully
> using Ada, often on-time and withing budget.

with budget; use budget;  burn_budget(); ???  ;-)

> Sorry your experience is different.   The issue is not the
> language, but the competence of the people using it.   I
> find Ada easy to understand, easy to use, and a great
> pleasure to engage for simple and complex programming
> tasks.  My experience is that people properly trained will
> find it as pleasant as I do.

As with vi(), as with ClearCase, if you don't _learn_ the
tool thoroughly _before_ forming your initial in-use
opinions of it, you'll hate it forever.

> When I compare it to the other languages I know, including
> Java and C++, I realize that Ada is still the best option
> for any real-time embedded software system where a high
> level of safety is required.  The concurrency features are
> far superior to those in Java, and the surprises far less
> frequent than one enjoys in C++.

True.

On the downside, as a no-longer-mandated and distinctly
fringe, almost "cult", language, Ada lacks the wide variety
of intensely useful and daily burgeoning libraries of
already invented wheels of Java, the programming hordes
willing to debug open source code of C and C++, the
just-for-fun applications and game authoring tools that make
other languages more able to attract young programmers to
become language-X junkies.

Mostly, this is due to conscious decisions, budget
shortsightedness or unconscious arrogance in the Ada
community: "our language is just so damned incredibly
superior in its serious applications, there is no need for
it to cater to the unwashed masses".

That way lies relegation to the dustbin of programming
languages history, the track down which Ada seems inexorably
headed to this day, whatever its admitted successes.

Ada was intended to replace obscure languages like Jovial.
Instead it has become one of them.  The Countess of Lovelace
should sue for damages to her good name.

> Richard Riehle

Crossposted to comp.lang.ada, which _really_ should add
comp.lang.ada.*, where * == {misc,gnat,advocacy,???}, to give
discussions like this a home.

the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kent Paul Dolan]

Richard Riehle <richard@adaworks.com> wrote:

> The Ada mandate was poorly managed by the DoD.

Talk about praising with faint damnation.  They couldn't
have done worse by avowedly working against adoption of Ada.

Creating an unenforced underfunded mandate only accomplished
sowing confusion and a burning desire to find a way around
the rules, which all services but the USMC then took up as
the latest "fun frustrating feeble feckless DoD management
by paid professional footdragging" game.  Which DoD lost to
its component parts.

> The language is structured around a few simple principles.

Which seem to be "simple" only in the minds of computer
language theorists, not in the minds of us mere programmers,
to whom the reasons for which these principles are
meritorious and why they should govern our lives are still
quite convincingly opaque.

> Some of those principles are more rigorously defined in
> Ada than in other languages.

If only the same rigor had been applied to furnishing
_readable explanations_ of these principles, in
self-contained, self-standing "why, not merely what" style,
in words clear enough to have been penned by Hemmingway, the
pain and suffering of programmers new to Ada might be much
diminished.

> One principle, separation of scope from visibility, is so
> different that even Ada programmers have difficulty with
> it at first.

Last time I checked by comp.lang.ada [which the mannerless
arrogance of certain posters there toward newbies finally
made unstomachable], this issue still seemed to consume the
bulk of the newsgroup.  Are the questions now settled, and
is there somewhere available an online tutorial explaining
the issues clearly enough for a sixth grader to read and
use?

> Once they stop fighting it and understand it, the rest of
> the language falls into place.

Much like certain editors better not brought up again, or
lots of other software cobbling tools, for that matter.

xanthian.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Hyman Rosen]

Kent Paul Dolan wrote:
> The DoD had, and has to this day, a situation where
 > battlefield computers programmed in different languages
 > couldn't talk to one another.

Good thing all those devices programmed in C have no problem
talking with each other. Every night, I hear my stove chatting
with my washing machine.

Soldiers are replacing army-issue gadgets with commercial
ones because all of the different military devices use
incompatible batteries, increasing the weight of spares
that have to be carried.

Programming language choice is so far from a factor in
interoperability and communications that your comments
are laughable.

RE: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Robert C. Leif]

DoD could have made Ada if they had only forbidden its use by the public.
Universities would then have been motivated to teach it.
Bob Leif

-----Original Message-----
From: Kent Paul Dolan [mailto:xanthian@well.com] 
Sent: Wednesday, February 26, 2003 2:49 PM
To: comp.lang.ada@ada.eu.org
Subject: the Ada mandate, and why it collapsed and died (was): 64 bit
addressing and OOP

Richard Riehle <richard@adaworks.com> wrote:

> The Ada mandate was poorly managed by the DoD.

Talk about praising with faint damnation.  They couldn't
have done worse by avowedly working against adoption of Ada.

Creating an unenforced underfunded mandate only accomplished
sowing confusion and a burning desire to find a way around
the rules, which all services but the USMC then took up as
the latest "fun frustrating feeble feckless DoD management
by paid professional footdragging" game.  Which DoD lost to
its component parts.

> The language is structured around a few simple principles.

Which seem to be "simple" only in the minds of computer
language theorists, not in the minds of us mere programmers,
to whom the reasons for which these principles are
meritorious and why they should govern our lives are still
quite convincingly opaque.

> Some of those principles are more rigorously defined in
> Ada than in other languages.

If only the same rigor had been applied to furnishing
_readable explanations_ of these principles, in
self-contained, self-standing "why, not merely what" style,
in words clear enough to have been penned by Hemmingway, the
pain and suffering of programmers new to Ada might be much
diminished.

> One principle, separation of scope from visibility, is so
> different that even Ada programmers have difficulty with
> it at first.

Last time I checked by comp.lang.ada [which the mannerless
arrogance of certain posters there toward newbies finally
made unstomachable], this issue still seemed to consume the
bulk of the newsgroup.  Are the questions now settled, and
is there somewhere available an online tutorial explaining
the issues clearly enough for a sixth grader to read and
use?

> Once they stop fighting it and understand it, the rest of
> the language falls into place.

Much like certain editors better not brought up again, or
lots of other software cobbling tools, for that matter.

xanthian.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Steve]

> Programming language choice is a factor.  If you have a skilled
programmer,
> language doesn't matter.  The problem is that it's far harder to find a
> truly skilled C++ master than it is a C one.  Both are many times harder
to
> find than a skilled Java guru.  Not sure about Ada.

While this is an interesting opinion,  there is a significant evidence the
choice of language does in fact matter.  A significant amount of work has
been done to determine factors that effect the cost of developing software,
defect rate, etc.

This information is usually ignored.

I'm not sure why this thread is cross posted to 3 newsgroups since it is
likely unproductive to all of them.

Steve
(The Duck)

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Hyman Rosen]

brougham3@yahoo.com wrote:
> Why ...

Why don't people read before writing?

The OP claimed that the reason various battlefield
communications systems didn't properly talk to each
other was that they were programmed in different
languages. This is utter nonsense. For systems to
interoperate, they either all have to adhere to a
rigorously defined protocol, or they have to be
developed in tandem.

The Ada web server that keeps getting mentioned here
has no trouble serving browsers written in C++, I'm
sure.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Karel Miklav]

Hyman Rosen wrote:
> The OP claimed that the reason various battlefield
> communications systems didn't properly talk to each
> other was that they were programmed in different
> languages. This is utter nonsense. For systems to
> interoperate, they either all have to adhere to a
> rigorously defined protocol, or they have to be
> developed in tandem.
> 
> The Ada web server that keeps getting mentioned here
> has no trouble serving browsers written in C++, I'm
> sure.

You're right; but significant if not the biggest part of my developing 
time consists of interfacing; forcing languages, application tires and 
platforms to cooperate. Deciphering truckloads of obscure protocol 
descriptions is the most wasted time of my life and my company's 
resources and I'd sure like to get rid of it.

I remember the time when programming was fun, when everything I wrote 
did something. Now it's all about policies, why don't computers take 
care of that? :)

Regards,
Karel Miklav

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Kent Paul Dolan]

Hyman Rosen <hyrosen@mail.com> wrote:
> Kent Paul Dolan wrote:

>> The DoD had, and has to this day, a situation where
>> battlefield computers programmed in different languages
>> couldn't talk to one another.

> Programming language choice is so far from a factor in
> interoperability and communications that your comments
> are laughable.

Interesting that your experience should be so in contrast
to the ten years of research and effort DoD put into studying
that very issue in their own shops using their own code
and repeated system interoperation experiences to the
contrary, in the work leading up to the first Ada language
standard.

I'm sure your correction to history will be of great value
to those who participated in it.

xanthian.

I can see them snorting coffee out their noses even as I
type this.  A little humor to lighten up the day is always
valuable.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Kent Paul Dolan]

"Steve" <nospam_steved94@attbi.com> wrote:

>> Programming language choice is a factor.  If you have a
>> skilled  programmer, language doesn't matter.  The problem
>> is that it's far harder to find a truly skilled C++ master
>> than it is a C one.  Both are many times harder to find
>> than a skilled Java guru.  Not sure about Ada.

> While this is an interesting opinion,  there is a
> significant evidence the choice of language does in fact
> matter.  A significant amount of work has been done to
> determine factors that effect the cost of developing
> software, defect rate, etc.

> This information is usually ignored.

> I'm not sure why this thread is cross posted to 3
> newsgroups since it is likely unproductive to all of them.

> Steve
> (The Duck)

More intriguing to me is where you got that quote, since you
removed the attribution.  Google Groups, which incorrectly
threads on subject line rather than reference header
entries, shows only two articles before yours, neither
containing what you quoted.

xanthian.

Umm, and the genesis was a discussion in comp.lang.java.advocacy,
which broadened to include computer addressing word width, and to
contrast that with the needs of object oriented programming languages
including Java, which got the posting widened to comp.object and
originally a couple of hardware design groups as well, which got
joined by a commentator from the Ada crowd, which got the now
Ada-oriented discussion targeted back toward comp.lang.ada, which then
devolved into a language versus language war.  Such is Usenet, which
is why more technical groups should defend themselves with *.advocacy
outliers where such discussions could live and be profoundly ignored
in the original groups.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Preben Randhol]

Robert C. Leif wrote:
> DoD could have made Ada if they had only forbidden its use by the public.
> Universities would then have been motivated to teach it.

Irony, right?

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Marin David Condic]

While I agree with much of this post, I've got to observe that
communications between systems or programs is *not* the issue. (Nor was it a
consideration when the DoD started down the path of Ada) Ada can no more
guarantee that data representation is consistent between applications than
anything else. Different compilers are free to implement primitive data
types in any way they like provided they meet certain criteria. Two
different versions of the same compiler might have different representations
for the same data. Machine architectures differ. Communications mechanisms
differ. A single programming language is *not* going to fix that.

The biggest consideration for the DoD initially was that they would get out
of spending money to support dozens or maybe even hundreds of different
languages in the various programs they funded. They would get some
transferability of skills from one project to the next and quit having to
pay for the learning curve. They also wanted higher reliability and other
noble objectives. Its just not the case that they expected to get
consistency in inter-process communications as part of the bargain and if
that *is* what they expected, they certainly didn't get it.

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Kent Paul Dolan <xanthian@well.com> wrote in message
news:a3eaa964.0302261422.4d166fa1@posting.google.com...
>
> It helps to remember the context.  The DoD had, and has to
> this day, a situation where battlefield computers programmed
> in different languages couldn't talk to one another.  A
> couple of obvious results of this kind of situation are that
> people die from friendly fire problems, and that people die
> from corrupted transmissions.  It was, and still is,
> important that the computer software share a single
> language, with that language's exact semantics for
> primitives and user declared types, so that communication
> succeeds and at least the people fighting on our side get to
> claim they got killed by the enemy instead of friendly
> forces or computer glitches.
>

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Colin Paul Gloster]

In article news:a3eaa964.0302261422.4d166fa1@posting.google.com , Kent
Paul Dolan wrote:

"[..]

Crossposted to comp.lang.ada, which _really_ should add
comp.lang.ada.*, where * == {misc,gnat,advocacy,???}, to give
discussions like this a home."

See how the proposal for a SPARK newsgroup was treated. As for GNAT: there
are email lists, and for advocay there is the Team Ada email list.

Using a less flaky news server than usual, I saw today that there is a
fairly new newsgroup news:alt.comp.lang.ada which does not seem to have
had any posts yet. Its description was similar to a lot of other
alt.comp.lang.* newsgroups launched at the same time. Why does it exist?

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[soft-eng]

xanthian@well.com (Kent Paul Dolan) wrote in message news:<a3eaa964.0302261422.4d166fa1@posting.google.com>...

> Whitewash, because what had actually happened was a
> rebellion among the services, that should have had a large
> number of officers cashiered if not court-martialed.  Abuse

Now wait a minute, I thought the "exemption" system
was fully authorized and legal.  Why should anybody
be court-martialed for taking advantage of
a feature of the system?

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Hyman Rosen]

Kent Paul Dolan wrote:
> Interesting that your experience should be so in contrast
> to the ten years of research and effort DoD put into studying
> that very issue in their own shops using their own code
> and repeated system interoperation experiences to the
> contrary, in the work leading up to the first Ada language
> standard.

Do you have any references to support this claim?
Eg., <http://archive.adaic.com/pol-hist/policy/3405-1.txt>
talks about ease of management and improvement of process
through use of Ada, but there is no mention of interproject
communications.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[CJT]

Mark Thornton wrote:
> "Kent Paul Dolan" <xanthian@well.com> wrote in message
> news:a3eaa964.0302261422.4d166fa1@posting.google.com...
> 
>>If the Ada mandate hadn't been dropped, the rebellion would
>>have to have been treated as what it was.  The DoD chose to
>>cave rather than apply military standards to a military
>>discipline problem.
> 
> 
> Surely most of the programmers and management involved would have been
> civilians with whom a military approach to discipline would have been
> ineffective.
> 
> Mark Thornton
> 
> 

... unless of course they wanted to be paid.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Mark Thornton]

"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:a3eaa964.0302261422.4d166fa1@posting.google.com...
>
> If the Ada mandate hadn't been dropped, the rebellion would
> have to have been treated as what it was.  The DoD chose to
> cave rather than apply military standards to a military
> discipline problem.

Surely most of the programmers and management involved would have been
civilians with whom a military approach to discipline would have been
ineffective.

Mark Thornton

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Mark Thornton]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0302270726.665fee77@posting.google.com...
> xanthian@well.com (Kent Paul Dolan) wrote in message
news:<a3eaa964.0302261422.4d166fa1@posting.google.com>...
>
> > Whitewash, because what had actually happened was a
> > rebellion among the services, that should have had a large
> > number of officers cashiered if not court-martialed.  Abuse
>
> Now wait a minute, I thought the "exemption" system
> was fully authorized and legal.  Why should anybody
> be court-martialed for taking advantage of
> a feature of the system?

For manufacturing bogus or inadequate excuses. It isn't illegal to run
aground either, but I believe a court martial is then mandatory and you had
better have damned good excuse. Keep in mind that the poster is apparently a
retired Naval officer and that military justice has significant differences
from the civilian legal system.

Mark Thornton

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Dr Chaos]

brougham3@yahoo.com <brougham3@yahoo.com> wrote:
> Hyman Rosen <hyrosen@mail.com> wrote:
> 
>>Programming language choice is so far from a factor in
>>interoperability and communications that your comments
>>are laughable.
> 
> Why are stack buffer overflow problems such an issue in C when programs
> receive communications that differ from what the programmer expected?  Yes,
> I'm aware this is a programmer deficiency.  Subscribe to something like
> Bugtraq for any length of time, and you'll see the same programmer problems
> over and over and over again.
> 
> Programming language choice is a factor.  If you have a skilled programmer,
> language doesn't matter.  

This is an assertion that is frequently made, but rather questionable
without empirical evidence one way or another. 

With persistence and skill, programmers can overcome many deficiencies, but 
deficiencies they still are. 

> The problem is that it's far harder to find a
> truly skilled C++ master than it is a C one.  

Why is that?  

Perhaps there is something intrinsic about the language design there because
it's not a lack of exposure.  

> Both are many times harder to
> find than a skilled Java guru.  Not sure about Ada.

Why is guru-ness so correlated with language now? 

My personal opinion is that good languages ought to, and do, bring up the 
average quality of the "30% to 98%" skill levels of programming.

My personal opinion is that C++ induces too much "risk" both in programs,
---where working programs and buggy programs are almost interlocking
dense sets {in the mathematical sense}---and among programmers.   That
is there is some non-zero chance that you might end up with a programmer,
perhaps good at lots of other things, who is just plain unable to be
reliably successful with C++. 

I think that would be much less likely with other programming languages. 

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[JXStern]

On Thu, 27 Feb 2003 22:06:20 +0000 (UTC), Dr Chaos
<mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote:
>> The problem is that it's far harder to find a
>> truly skilled C++ master than it is a C one.  
>
>Why is that?  

Because the language is a mess, and there is no objective measure of
who is a "master".  Is it someone who can make instant sense out of
the worst mess anyone hands him?  Then it ain't me.  Is it someone who
makes rather spare use out of obscure constructs?  That would be me,
but I would be down-rated because of it in many evaluation contexts.
That I do it on purpose, is generally not appreciated.  That I got
here via the other path, is not understood.

>> Both are many times harder to
>> find than a skilled Java guru.  Not sure about Ada.
>
>Why is guru-ness so correlated with language now? 

Because it's the machine and the tools that contain all the magic, the
programmer is just a necessary overhead and contributes nothing.
Obviously.  
</sarcasm>

>My personal opinion is that good languages ought to, and do, bring up the 
>average quality of the "30% to 98%" skill levels of programming.
>
>My personal opinion is that C++ induces too much "risk" both in programs,
>---where working programs and buggy programs are almost interlocking
>dense sets {in the mathematical sense}---and among programmers.   That
>is there is some non-zero chance that you might end up with a programmer,
>perhaps good at lots of other things, who is just plain unable to be
>reliably successful with C++. 
>
>I think that would be much less likely with other programming languages. 

In general, I agree.

J.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Kent Paul Dolan]

softeng3456@netscape.net (soft-eng) wrote:

> Now wait a minute, I thought the "exemption" system
> was fully authorized and legal.  Why should anybody
> be court-martialed for taking advantage of
> a feature of the system?

Well, in the case of a former DoD contract employer shop of
mine, because they deliberately, repeatedly, and with malice
aforethought _created_ the situation that _required_ the
exemption, specifically _for the purpose of_ being eligible
for the exemption, when the directive and intention was that
the exemptions be based on unavoidable hardship, and short
term while affirmative steps were taken to overcome the
reasons an exemption was needed.

In the case, they put out requests for proposal for
supercomputers for which no Ada compilers were then
available, knowing they were required to move to Ada
programming, and failed to include in those RFPs the
requirement, roughly a 10% add-on cost, that the
supercomputer be delivered with a working Ada compiler
installed.

They did this, and bragged internally on having done this,
specifically to escape having to convert a shop of die-hard
Fortran programmers to be Ada programmers.  Their exemption
requests were of course granted, there were indeed no Ada
compilers for the now-installed computers their work required.

The phrase "taking advantage of" answers your own question.

When I conveyed this scam-system to Emmett Paige, his
investigation was so clumsy I was quickly discovered and
equally quickly terminated by the furious and embarrassed
local O6 commanding officer who had been perpetrating the
hoax: 24 hours after my email was sent, I was unemployed.
There were no whistle-blower protections in those days, and
interest in the well being of the informant was naturally
absent.

xanthian, who wrote the only Ada code ever used in that shop,
up to then, so far as I know.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Kent Paul Dolan]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote:

> While I agree with much of this post, I've got to observe that
> communications between systems or programs is *not* the issue. (Nor was it a
> consideration when the DoD started down the path of Ada)

Your memory and mine differ rather profoundly on the issue, which as a
commissioned officer who was also employed hour-to-hour mostly as a
programmer up until 1981 I followed with rather intense interest at
the time in both the trade press and internal government documents.

xanthian.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Kent Paul Dolan]

Hyman Rosen <hyrosen@mail.com> wrote
> Kent Paul Dolan wrote:
>> Interesting that your experience should be so in contrast
>> to the ten years of research and effort DoD put into studying
>> that very issue in their own shops using their own code
>> and repeated system interoperation experiences to the
>> contrary, in the work leading up to the first Ada language
>> standard.

> Do you have any references to support this claim?
> Eg., <http://archive.adaic.com/pol-hist/policy/3405-1.txt>
> talks about ease of management and improvement of process
> through use of Ada, but there is no mention of interproject
> communications.

Nope, not a one, that was two decades ago and my notes from the period
have gone missing with a dozen changes of residence, just my memories
(of the then ongoing debate) as a commissioned officer (who worked day
to day as a computer programmer automating nautical chart making) and
interested bystander up to 1981, and after that as a student of the
eventual head of (one of?) the Ada Validation team(s), in 1984 when he
was using an Ada (subset) to Pascal source-to-source translater he had
written to teach the first US college Ada programming class, from his
class chat.  That, plus reading some of the precursor documents to the
first Ada standard, and the discussions that accompanied their
creation.

xanthian.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Karen]

Absolutely.

Anyway, processing comunications received from other systems is not trivial
even in Ada.  The inevitable issues of interface hardening, addition of
explicit prototols etc and problems with endianism means that interface
processing will always be difficult....

Unless...

You can standardise inter system protocols against families of languages
using code generation - the real benefit of ORBs.

Ada is without doubt a solid language.  Its the only language I have found
where you can teach it through the structure of teaching software
engineering.  (Teach s/w eng. goals -> principles -> language constructs, so
the students know why to do something, not simply the syntax).

The real benefit of other languages is the leverage it can give you to
interface / exploit COTS products that provide services in only another
language.  For ages the only way to integrate a commercial GUI into a
system, was to go via C and later C++.  We had to wait so long for native
Ada GUI services it was laughable.  Only with Ada 95 was the "Ada - I'm the
centre of the world and if you can't play Ada, I won't play with you" view
changed, and decent mixed langage systems could be built - openeing the way
to exploit commercial tools but still use a decent language for the
'business logic (e.g. defence) s/w.

My organisation routinley roll out multimillion lines systems (soft
real-time) for the defence industry - and it works.  Increasingly we exploit
commercial s/w products, embeded into out systems, but the core is Ada, and
we have no intention of changing that.
"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
news:b3l0oe$7to$1@slb9.atl.mindspring.net...
> While I agree with much of this post, I've got to observe that
> communications between systems or programs is *not* the issue. (Nor was it
a
> consideration when the DoD started down the path of Ada) Ada can no more
> guarantee that data representation is consistent between applications than
> anything else. Different compilers are free to implement primitive data
> types in any way they like provided they meet certain criteria. Two
> different versions of the same compiler might have different
representations
> for the same data. Machine architectures differ. Communications mechanisms
> differ. A single programming language is *not* going to fix that.
>
> The biggest consideration for the DoD initially was that they would get
out
> of spending money to support dozens or maybe even hundreds of different
> languages in the various programs they funded. They would get some
> transferability of skills from one project to the next and quit having to
> pay for the learning curve. They also wanted higher reliability and other
> noble objectives. Its just not the case that they expected to get
> consistency in inter-process communications as part of the bargain and if
> that *is* what they expected, they certainly didn't get it.
>
> MDC
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>     "Going cold turkey isn't as delicious as it sounds."
>         -- H. Simpson
> ======================================================================
>
> Kent Paul Dolan <xanthian@well.com> wrote in message
> news:a3eaa964.0302261422.4d166fa1@posting.google.com...
> >
> > It helps to remember the context.  The DoD had, and has to
> > this day, a situation where battlefield computers programmed
> > in different languages couldn't talk to one another.  A
> > couple of obvious results of this kind of situation are that
> > people die from friendly fire problems, and that people die
> > from corrupted transmissions.  It was, and still is,
> > important that the computer software share a single
> > language, with that language's exact semantics for
> > primitives and user declared types, so that communication
> > succeeds and at least the people fighting on our side get to
> > claim they got killed by the enemy instead of friendly
> > forces or computer glitches.
> >
>
>
>

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Dr Chaos]

On Thu, 27 Feb 2003 23:49:26 GMT, JXStern <JXSternChangeX2R@gte.net> wrote:
>>My personal opinion is that C++ induces too much "risk" both in programs,
>>---where working programs and buggy programs are almost interlocking
>>dense sets {in the mathematical sense}---and among programmers.   That
>>is there is some non-zero chance that you might end up with a programmer,
>>perhaps good at lots of other things, who is just plain unable to be
>>reliably successful with C++. 
>>
>>I think that would be much less likely with other programming languages. 
> 
> In general, I agree.

Unfortunately the debate is too often governed by anecdotal arguments
about the outliers: the extreme incompetents and the gurus. 

This is reinforced by natural human prejudices.  Managers may prefer
to blame an easily-fired "weakest link" rather than their, perhaps
popular, technology choice.  

Programmers think they are not only all above average, but even the
next superfreakish Johnny von Neumann.

And so often what should be more informative data----modest scientific
exploration of typical programmer capability versus technologies----is
ignored and studies hardly funded.

> J.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[JXStern]

On Fri, 28 Feb 2003 00:45:28 +0000 (UTC), Dr Chaos
<mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote:
>Programmers think they are not only all above average, but even the
>next superfreakish Johnny von Neumann.
>
>And so often what should be more informative data----modest scientific
>exploration of typical programmer capability versus technologies----is
>ignored and studies hardly funded.

Well, but let's not blame the programmers, for topics that academics
do not study.

J.

Re: the Ada mandate, and why it collapsed and died

[Richard Riehle]

Preben Randhol wrote:

> Robert C. Leif wrote:
> > DoD could have made Ada if they had only forbidden its use by the public.
> > Universities would then have been motivated to teach it.
>
> Irony, right?

The mismangement of the Ada initiative began early.   When the DoD
insisted that everyone had to use Ada even before there were good
compilers available, they opened the door for abuse of their own
policies.

The mandate itself encouraged compiler publishers and others to gouge
their principle client with prices so outrageous that commercial users
could not even consider Ada.

The quality of compilers in the early days was unpredictable and some
were quite horrid.

The quality of Ada education was not very good.  One Navy admiral
told me that they hired a "highly qualified" person to teach Ada at
the U.S. Naval Academy, and all she could do is confuse the students
and bring them to believe Ada was simply a large complex language
no one could use for anything practical.    This scenario occurred over
and over in many venues.

The waiver policy was a joke.  One Navy site was discovered to have
a safe full of waiver requests that had never been processed and the
contractors simply went forward using other languages anyway.

Many of the computer hardware vendors had what became known as
checkbox compilers.  No one was supposed to use them.  For example,
Tandem's Ada compiler was not intended for anyone to actually use,
only to satisfy the checkbox that said, "Validated Ada?"   They never
even tried to interface Ada to any of their essential development
environments.   This also happened over and over.

Project managers often made no effort to understand how developing
in Ada was different from any other language.  To them, it was just
another programming language.  That resulted in a lot of AdaTran,
and a lot of really dumb code being produced.   When the project
got in trouble, these same incompetent managers looked around
for somewhere to cast the blame and blamed Ada.   Their own
stupidity seemed strangely compatible with the stupidity of the
people they worked for.

The list of reasons goes on.    Even if Ada had been the greatest
technology ever invented,  the DoD's management would still have
ensured that no one would ever discover it.

Good people, doing real projects, did find the benefits of Ada
and they went ahead and built excellent software in spite of
their own management policies and DoD incompetence.

Ada is in something of a decline.  That is unfortunate.  However,
new people are discovering it and recognizing its expressive
power and its virtues over competing technologies.   If it is
to make a comeback, it will have to be because those who choose
to use it are able to create excellent software and the results of
their work is discovered by others.   This is possible because
Ada, in its current form, is still a better  technology for software
development than the competing technologies, the popularity
of those competing technologies notwithstanding.

Richard Riehle

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Marin David Condic]

If we assume for a moment that you are correct - that Ada was (at least
partially) invented so that inter-process communication would be less error
prone because of common data representation - then Ada is an abysmal
failure. The Ada standard has almost nothing at all to say about the
representation of data as it gets out of the program and it has gaping holes
within the standard with respect to exact representations so big you could
drive a truck through them. There is absolutely no reason to believe that if
I wrote data with one Ada program on one target machine with one version of
a compiler that it could be read back by another Ada program on a different
target machine with a different compiler. Nothing in the standard even
implies that this should work. Hence, if it *was* a goal, they never
achieved it.

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Kent Paul Dolan <xanthian@well.com> wrote in message
news:a3eaa964.0302271557.adba17e@posting.google.com...
>
> Your memory and mine differ rather profoundly on the issue, which as a
> commissioned officer who was also employed hour-to-hour mostly as a
> programmer up until 1981 I followed with rather intense interest at
> the time in both the trade press and internal government documents.
>
> xanthian.

Re: the Ada mandate, and why it collapsed and died

[Marin David Condic]

If we build things in Ada, this starts making it more viable. When you hack
tools for your job, use Ada. When you look at new startup projects, use Ada.
Go out and dream up a product you might sell to the world and use Ada to
develop it. Successful businesses that use Ada will do a lot more to spur
Ada usage than anything else. It would create *jobs* that use Ada and people
go where the money is. Most of us here believe in Ada as a better way. We
need to demonstrate that to the world by using it to build better mousetraps
rather than try to convince through academic arguments. I think that the
development of some real-world apps with a little "Ada Inside" sticker in
the corner would do a lot more to promote Ada than anything else. Is anybody
out there building products with Ada to sell to people and generate jobs? If
not, Ada will become just a language of academic interest with lots of
academic arguments surrounding it.

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Richard Riehle <richard@adaworks.com> wrote in message
news:3E5EDCB1.C841AFDD@adaworks.com...
>
> Ada is in something of a decline.  That is unfortunate.  However,
> new people are discovering it and recognizing its expressive
> power and its virtues over competing technologies.   If it is
> to make a comeback, it will have to be because those who choose
> to use it are able to create excellent software and the results of
> their work is discovered by others.   This is possible because
> Ada, in its current form, is still a better  technology for software
> development than the competing technologies, the popularity
> of those competing technologies notwithstanding.
>

Re: the Ada mandate, and why it collapsed and died

[Marin David Condic]

BTW: Just to follow-up on my own post and demonstrate that I practice what I
preach... :-) I do have Ada projects going on and am actively looking to
start new ones if I can sell the ideas to my customers. We are on the
lookout for qualified people so if someone is interested in a position in
South Florida, you can always send me your resume at mcondic (at) belcan
(dot) com

And Richard, I hope this didn't sound like I was in any way criticizing you.
I guess I have been as frustrated with the whole conduct of "The Mandate" as
any of us and I just see the proper response to the whole debacle as being
one of "Lets forget 'The Mandate' and go forth and demonstrate Ada is better
by building useful, successful products with it." If the DoD contractors had
quit whining about Ada and just gone forth figuring out how to use it
successfully to build *their* products, both they and Ada would have been
better off. If we're right and Ada *is* better at building apps, then we
ought to be able to make successful commercial products with it and
out-compete the folks using C/C++/Java/etc.

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Marin David Condic <mcondic.auntie.spam@acm.org> wrote in message
news:b3nkfo$r8e$1@slb9.atl.mindspring.net...
> If we build things in Ada, this starts making it more viable. When you
hack
> tools for your job, use Ada. When you look at new startup projects, use
Ada.
> Go out and dream up a product you might sell to the world and use Ada to
> develop it. Successful businesses that use Ada will do a lot more to spur
> Ada usage than anything else. It would create *jobs* that use Ada and
people
> go where the money is. Most of us here believe in Ada as a better way. We
> need to demonstrate that to the world by using it to build better
mousetraps
> rather than try to convince through academic arguments. I think that the
> development of some real-world apps with a little "Ada Inside" sticker in
> the corner would do a lot more to promote Ada than anything else. Is
anybody
> out there building products with Ada to sell to people and generate jobs?
If
> not, Ada will become just a language of academic interest with lots of
> academic arguments surrounding it.
>

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[soft-eng]

xanthian@well.com (Kent Paul Dolan) wrote in message news:<a3eaa964.0302271552.46079d1a@posting.google.com>...

> specifically to escape having to convert a shop of die-hard
> Fortran programmers to be Ada programmers.  Their exemption

Which is of course, a piece of cake.  To convert die-hard
Fortran programmers to be Ada programmers.

That's what I meant by the "get the task done" crowd.

The Fortran programmers didn't want to learn
Ada doesn't mean they were stupid.  It just
might mean they were very involved in the
equations and stuff, rather than the computer
language aspect of it.

Your way -- the group spends lots of time and
money on trying to teach Ada to Fortran programmers.
A lot of Fortran programmers move on, the
continuity is completely disrupted...  Just
so Xanthian can be happy that rules were
followed to the t.

Getting the task done, for a management level
personnel, means making sure he doesn't lose
half his staff and then has to hire and train
a whole lot of new people.  It also includes
making sure the staff is happy with the work.

It's like the seargent doing whatever it
takes, taking advantage of loopholes
in the well meaing but naive liuetenant's
orders.  And if some grunt then goes
around to complain to the lieutenant,
he better be ready to get chewed out.

If the army started court-marshalling
all those "get-the-job-done" seargents,
it would fall apart.

RE: the Ada mandate, and why it collapsed and died

[Robert C. Leif]

Marin is right. The example of a few Ada millionaires would greatly expand
its usage. The XML tide could carry us along.
Bob Leif

-----Original Message-----
From: Marin David Condic [mailto:mcondic.auntie.spam@acm.org] 
Sent: Friday, February 28, 2003 4:49 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: the Ada mandate, and why it collapsed and died

BTW: Just to follow-up on my own post and demonstrate that I practice what I
preach... :-) I do have Ada projects going on and am actively looking to
start new ones if I can sell the ideas to my customers. We are on the
lookout for qualified people so if someone is interested in a position in
South Florida, you can always send me your resume at mcondic (at) belcan
(dot) com

And Richard, I hope this didn't sound like I was in any way criticizing you.
I guess I have been as frustrated with the whole conduct of "The Mandate" as
any of us and I just see the proper response to the whole debacle as being
one of "Lets forget 'The Mandate' and go forth and demonstrate Ada is better
by building useful, successful products with it." If the DoD contractors had
quit whining about Ada and just gone forth figuring out how to use it
successfully to build *their* products, both they and Ada would have been
better off. If we're right and Ada *is* better at building apps, then we
ought to be able to make successful commercial products with it and
out-compete the folks using C/C++/Java/etc.

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Marin David Condic <mcondic.auntie.spam@acm.org> wrote in message
news:b3nkfo$r8e$1@slb9.atl.mindspring.net...
> If we build things in Ada, this starts making it more viable. When you
hack
> tools for your job, use Ada. When you look at new startup projects, use
Ada.
> Go out and dream up a product you might sell to the world and use Ada to
> develop it. Successful businesses that use Ada will do a lot more to spur
> Ada usage than anything else. It would create *jobs* that use Ada and
people
> go where the money is. Most of us here believe in Ada as a better way. We
> need to demonstrate that to the world by using it to build better
mousetraps
> rather than try to convince through academic arguments. I think that the
> development of some real-world apps with a little "Ada Inside" sticker in
> the corner would do a lot more to promote Ada than anything else. Is
anybody
> out there building products with Ada to sell to people and generate jobs?
If
> not, Ada will become just a language of academic interest with lots of
> academic arguments surrounding it.
>

Re: the Ada mandate, and why it collapsed and died

[Richard Riehle]

Marin David Condic wrote:

> And Richard, I hope this didn't sound like I was in any way criticizing you.

A lifetime of being criticized has not harmed me.  Rather, it has helped
me, I hope, learn a little bit now and then.   Anyone who wants to heap
criticism upon me is welcome to do so.  Someone once said, "I can deal
with it when you love me or when you hate me. I go really bonkers when
I am ignored."

> I guess I have been as frustrated with the whole conduct of "The Mandate" as
> any of us and I just see the proper response to the whole debacle as being
> one of "Lets forget 'The Mandate' and go forth and demonstrate Ada is better
> by building useful, successful products with it.

I fully agree.  I do believe I have posted similar encouragements over my
years as a member of this forum.


> " If the DoD contractors had
> quit whining about Ada and just gone forth figuring out how to use it
> successfully to build *their* products, both they and Ada would have been
> better off. If we're right and Ada *is* better at building apps, then we
> ought to be able to make successful commercial products with it and
> out-compete the folks using C/C++/Java/etc.

There is some indication, not authoritatively documented, that those very
DoD contractors had behind the scenes input, at the very top of their
organizations (sometimes at the CEO level) from powerful purveyors
of alternative technologies.  One could see this in terms of a conspiracy
theory, and I hate that kind of thing.  However,  I have been told of a
meeting between two powerful people, one of whom was a CEO of
a major defense corporation and the other a powerful person within
the DoD where the CEO made it clear they wanted no more Ada.

I wish I could validate this, but the DoD person in question will neither
confirm nor deny that such a meeting took place.  If the DoD had been
successful in converting all software to Ada, the economic impact on
other development technologies would have been quite significant.  Some
of the same forces that successfully thwarted Ada also tried to thwart
the Java initiative.  In the case of Java, Sun Microsystems was more
clever than the saboteurs, and have so far been able to parry the thrusts
made by the newer competing technologies.   Recently, even C++ has
been set on the run by Java.

Someone, about two years ago said, "The language wars are over and
C++ is the winner."    What we now realize is that the language wars
are not over, and no one is really the winner.   If there is a loser, it
is the Department of Defense which allowed its own successes with
the Ada policy to be squandered.  It is a clear case of the famous
expression, "... grabbing defeat from the jaws of victory."

The fact that Ada continues to be a better technology for a large
class of problems means that it is still there to be discovered.  Indeed,
we see more and more people rediscovering it even as some contractors,
ignorant of the gold that lies at their feet, abandon it in favor of less
worthy technologies.

Most recently, I became aware of an organization that has abandoned
both Ada and C++ in favor of Java.   Given the nature of their mission,
I find this an absurd decision.    There is no indication that Java is
anywhere close to being appropriate for real-time embedded military
systems.   Those of you who read my recent article in Crosstalk know
that I am skeptical of how well the DoD can manage a multiple-language
policy since it could not manage a single-language policy.  Things are
likely to get worse before they get better.   Of course, I hope I am
wrong about that.

Richard Riehle

Re: the Ada mandate, and why it collapsed and died

[Marin David Condic]

Well, the language wars are never really over, are they? Technology keeps
marching on, new projects get started with what is then the latest &
greatest technology. The world turns and the more things change the more
they look the same. :-)

What I would like to see is an army of small-time developers building better
products and shamelessly using Ada to do it. (Put that little "Ada Inside"
sticker on it! :-) One could think big, like an Ada-OS or an Ada version of
Star Office or an Ada version of Quicken (Is there a good open-source
checkbook/accounting program out there?) One could think small, like tools
for education (tutorial software for languages, math & statistics packages
for academic uses, etc.) or hacker tools within the organization. One could
think about the new products the company is planning and see how to get Ada
to fit in there. Whatever angle it goes, the objective is to build really
solid, reliable software and put that "Ada Inside" sticker on it.

The beauty of it is that if this army of small-timers goes out and makes
reliable products and Ada starts gaining some visibility & reputation as a
result, you'd have the DoD contractors looking at the "New Wave" and
wondering how they missed the boat the first time around. The irony of it
would be delicious, wouldn't it? :-)

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Richard Riehle <richard@adaworks.com> wrote in message
news:3E60215B.8E1CB727@adaworks.com...
>
> Someone, about two years ago said, "The language wars are over and
> C++ is the winner."    What we now realize is that the language wars
> are not over, and no one is really the winner.   If there is a loser, it
> is the Department of Defense which allowed its own successes with
> the Ada policy to be squandered.  It is a clear case of the famous
> expression, "... grabbing defeat from the jaws of victory."
>

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[AG]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0302280615.3f6640c3@posting.google.com...

> It's like the seargent doing whatever it
> takes, taking advantage of loopholes
> in the well meaing but naive liuetenant's
> orders.  And if some grunt then goes
> around to complain to the lieutenant,
> he better be ready to get chewed out.

See what ignoring the rules gets you?

There is no such thing as "seargent"
according to the Webster Dictionary.

Nor is there such a word as "meaing".

Any half (or quater)-way decent spell
checker (not to mention a compiler
which is supposed to know better)
should have shot that post down
at first sight. Before some "seargent"
went loose with it  :)

[Note that I may make spelling
mistakes too - it's just that I don't
claim that I'm always right. Some
automated checking would be
just great. And that's the whole point...]

>
> If the army started court-marshalling
> all those "get-the-job-done" seargents,
> it would fall apart.

What do you think the court-martial
is for then? Or MP?

RE: the Ada mandate, and why it collapsed and died

[Robert C. Leif]

Better yet, it could be very profitable. Ada allows efficient distributed
development and rational sharing of the profits. I suspect that XForms could
be a killer application. Although Microsoft will create a version, chances
are it will be nonstandard and limited to Windows. Once one has XForms in
Ada, then it will be possible to build truly portable, extensible
applications based on the combination of Ada and XML.
Bob Leif

-----Original Message-----
From: Marin David Condic [mailto:mcondic.auntie.spam@acm.org] 
Sent: Saturday, March 01, 2003 5:14 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: the Ada mandate, and why it collapsed and died

Well, the language wars are never really over, are they? Technology keeps
marching on, new projects get started with what is then the latest &
greatest technology. The world turns and the more things change the more
they look the same. :-)

What I would like to see is an army of small-time developers building better
products and shamelessly using Ada to do it. (Put that little "Ada Inside"
sticker on it! :-) One could think big, like an Ada-OS or an Ada version of
Star Office or an Ada version of Quicken (Is there a good open-source
checkbook/accounting program out there?) One could think small, like tools
for education (tutorial software for languages, math & statistics packages
for academic uses, etc.) or hacker tools within the organization. One could
think about the new products the company is planning and see how to get Ada
to fit in there. Whatever angle it goes, the objective is to build really
solid, reliable software and put that "Ada Inside" sticker on it.

The beauty of it is that if this army of small-timers goes out and makes
reliable products and Ada starts gaining some visibility & reputation as a
result, you'd have the DoD contractors looking at the "New Wave" and
wondering how they missed the boat the first time around. The irony of it
would be delicious, wouldn't it? :-)

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Richard Riehle <richard@adaworks.com> wrote in message
news:3E60215B.8E1CB727@adaworks.com...
>
> Someone, about two years ago said, "The language wars are over and
> C++ is the winner."    What we now realize is that the language wars
> are not over, and no one is really the winner.   If there is a loser, it
> is the Department of Defense which allowed its own successes with
> the Ada policy to be squandered.  It is a clear case of the famous
> expression, "... grabbing defeat from the jaws of victory."
>

Re: the Ada mandate, and why it collapsed and died

[John R. Strohm]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
news:b3qbpo$tq5$1@slb5.atl.mindspring.net...
> Well, the language wars are never really over, are they? Technology keeps
> marching on, new projects get started with what is then the latest &
> greatest technology. The world turns and the more things change the more
> they look the same. :-)
>
> What I would like to see is an army of small-time developers building
better
> products and shamelessly using Ada to do it. (Put that little "Ada Inside"
> sticker on it! :-) One could think big, like an Ada-OS or an Ada version
of
> Star Office or an Ada version of Quicken (Is there a good open-source
> checkbook/accounting program out there?) One could think small, like tools
> for education (tutorial software for languages, math & statistics packages
> for academic uses, etc.) or hacker tools within the organization. One
could
> think about the new products the company is planning and see how to get
Ada
> to fit in there. Whatever angle it goes, the objective is to build really
> solid, reliable software and put that "Ada Inside" sticker on it.
>
> The beauty of it is that if this army of small-timers goes out and makes
> reliable products and Ada starts gaining some visibility & reputation as a
> result, you'd have the DoD contractors looking at the "New Wave" and
> wondering how they missed the boat the first time around. The irony of it
> would be delicious, wouldn't it? :-)

Actually, there's a flip side.

If Ada really is as good as we all believe it is, if it really does offer
the productivity gains we all believe it does, then a company that took Ada
seriously for product development would quickly carve out a
price/performance/profitability niche that no one else could touch.  That
company would, out of enlightened self-interest, KEEP QUIET about the fact
that they were using Ada, treating it as competition-sensitive proprietary
information.  (To quote Mary Jane, "Does Macy's tell Gimbel's?")

On the gripping hand, at least some of those competitors would send their
development offshore to India, where programmers cost half as much (or less)
than they do in the U.S.  The recent Slashdot pieces about Microsoft come to
mind.

Re: the Ada mandate, and why it collapsed and died

[Robert A Duff]

"John R. Strohm" <strohm@airmail.net> writes:

>...That
> company would, out of enlightened self-interest, KEEP QUIET about the fact
> that they were using Ada, treating it as competition-sensitive proprietary
> information.

I don't agree with that kind of strategy.  The problem is that there is
a great value in standards.  If you're the last person on earth using
Ada, and Ada is a huge benifit over whatever language is the popular,
that benefit will be lost, because you're going to be providing all the
funding for Ada compiler delevopment, and all the training in Ada
programming.

Much better to get lots of folks (even your competitors) to use Ada, so
you can share the cost of Ada compilers and so forth.

In the United States, everybody drives on the right-hand side of the
road.  If I come up with some reason why driving on the left is
beneficial, it's no good if I just start driving on the left.  I have to
convince everybody else to do it, too, or it won't work.

- Bob

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[AG]

<brougham3@yahoo.com> wrote in message
news:gf906vsc9rt677tusubo3btsjmn1ev1sgm@4ax.com...
> "AG" <ang@xtra.co.nz> wrote:
>
> >See what ignoring the rules gets you?
>
> With apologies to Samuel Clemens, it's a darn unimaginative person who
only
> knows one way to spell a word.  :)

Well, yes true.

I'm not too sure about the copyright
issues on this one so I'll refrain from
posting the whole lot but here are
some fine examples of imaginative
spelling (it actually represents the
way it's spoken even if with a grain
of humour:) ...


The sky is the limpet ...


Got Bitten (for those not familiar
with the accent that means Great
Britain :)


Now then ...

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[soft-eng]

"AG" <ang@xtra.co.nz> wrote in message news:<pIT7a.112509$F63.2422365@news.xtra.co.nz>...
> "soft-eng" <softeng3456@netscape.net> wrote in message

> Any half (or quater)-way decent spell
> checker (not to mention a compiler
> which is supposed to know better)
> should have shot that post down
> at first sight. Before some "seargent"
> went loose with it  :)
> 
> [Note that I may make spelling
> mistakes too - it's just that I don't
> claim that I'm always right. Some

Thanks for illustrating that point
in this very post with your spelling
of "quater" :-)

Btw, did you find a claim from me somewhere
that I'm always right?  (I do, however,
claim to normally honor the netiquette of
ignoring minor spelling mistakes.)

Hide or reveal ? (Re: the Ada mandate, and why it collapsed and died)

[Faust]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:


> I don't agree with that kind of strategy.  The problem is that there is
> a great value in standards.  If you're the last person on earth using
> Ada, and Ada is a huge benifit over whatever language is the popular,
> that benefit will be lost, because you're going to be providing all the
> funding for Ada compiler delevopment, and all the training in Ada
> programming.

That is exactly why Ericcson made Erlang ( a distributed, concurrent, fault
tolerant , realtime language with faul tolerance support ) available
free and open sourced it.

They wanted the leverage that comes from having an active Erlang community.


-- 

natsu-gusa ya   / tsuwamono-domo-ga   / yume no ato
summer grasses  / strong ones         / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

Re: Hide or reveal ? (Re: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

Faust wrote:
> 
> That is exactly why Ericcson made Erlang ( a distributed, concurrent, fault
> tolerant , realtime language with faul tolerance support ) available
> free and open sourced it.

What does fault tolerant mean in this case?

-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: Hide or reveal ? (Re: the Ada mandate, and why it collapsed and died)

[Faust]

Preben Randhol <randhol+news@pvv.org> writes:

>> That is exactly why Ericcson made Erlang ( a distributed, concurrent, fault
>> tolerant , realtime language with faul tolerance support ) available
>> free and open sourced it.
>
> What does fault tolerant mean in this case?

"Joe Armstrong talked about the Erlang at the Lightweight Languages Workshop 
2002 (LL2).At the end of his talk he mentions a few products using Erlang, 
one of them an Ericsson ATM switch (AXD301). It's used by British Telecom and 
has a fault tolerance of 99.9999999% (9 nines!). That's 31 ms a year. 
As he said "Not bad"."

-- 

natsu-gusa ya   / tsuwamono-domo-ga   / yume no ato
summer grasses  / strong ones         / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Lloyd Bonafide]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0303021538.7e7cb00e@posting.google.com>...
> "AG" <ang@xtra.co.nz> wrote in message news:<pIT7a.112509$F63.2422365@news.xtra.co.nz>...
> > "soft-eng" <softeng3456@netscape.net> wrote in message
>  
> > Any half (or quater)-way decent spell
> > checker (not to mention a compiler
> > which is supposed to know better)
> > should have shot that post down
> > at first sight. Before some "seargent"
> > went loose with it  :)
> > 
> > [Note that I may make spelling
> > mistakes too - it's just that I don't
> > claim that I'm always right. Some
> 
> Thanks for illustrating that point
> in this very post with your spelling
> of "quater" :-)

Yep - never fails.  Point out somebody else's spelling errors and
you're sure to include some of your own.  Luckily, I'm smrater than
you rubes and would neevr do such a theeng.  ;-)

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[soft-eng]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0302280615.3f6640c3@posting.google.com>...
> xanthian@well.com (Kent Paul Dolan) wrote in message news:<a3eaa964.0302271552.46079d1a@posting.google.com>...
> 
> > specifically to escape having to convert a shop of die-hard
> > Fortran programmers to be Ada programmers.  Their exemption
> 
> Which is of course, a piece of cake.  To convert die-hard
> Fortran programmers to be Ada programmers.
> 
> That's what I meant by the "get the task done" crowd.
> 
> The Fortran programmers didn't want to learn
> Ada doesn't mean they were stupid.  It just
> might mean they were very involved in the
> equations and stuff, rather than the computer
> language aspect of it.
> 
> Your way -- the group spends lots of time and
> money on trying to teach Ada to Fortran programmers.
> A lot of Fortran programmers move on, the
> continuity is completely disrupted...  Just
> so Xanthian can be happy that rules were
> followed to the t.

Actually, come of the think of it, the rules
were undoubtedly followed to the crossing
of every t, and the dotting of every i.

Why?  Because you were displaced within 24 hours.
Given that you had lodged a complaint,
if the commanding officer had bent any rules on
which he could have been impaled, he would
not have been able to get away with removing you
that fast.

Probably the regulations did not require him to
order software that didn't exist, even
if it added only 10% to the overall cost.
So you could have bet your job (which you
did) that the commanding officer was no fool
about following all the rules.

Re: the Ada mandate, and why it collapsed and died

[Marin David Condic]

Keep in mind that there is a *lot* more that goes into profitability of a
company than just the language they use to build their software. There is
also a *lot* more that goes into "reliable" software than just the language
you use. Ultimately, you can't really cover up that you use Ada - someone
who works for you will likely spill the beans somewhere along the line. And
so what? Ada and its benefits aren't a secret, so you might as well use it
as a kind of "Product Distinction". You build a better product by more than
just the language, but you get the publicity and prestige of using Ada as
you build name recognition with other companies doing similar.

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

John R. Strohm <strohm@airmail.net> wrote in message
news:AC5A70708B0D5BD6.5F1D648C6442669C.B4530F6760F852E0@lp.airnews.net...
>
> Actually, there's a flip side.
>
> If Ada really is as good as we all believe it is, if it really does offer
> the productivity gains we all believe it does, then a company that took
Ada
> seriously for product development would quickly carve out a
> price/performance/profitability niche that no one else could touch.  That
> company would, out of enlightened self-interest, KEEP QUIET about the fact
> that they were using Ada, treating it as competition-sensitive proprietary
> information.  (To quote Mary Jane, "Does Macy's tell Gimbel's?")
>
> On the gripping hand, at least some of those competitors would send their
> development offshore to India, where programmers cost half as much (or
less)
> than they do in the U.S.  The recent Slashdot pieces about Microsoft come
to
> mind.
>
>
>

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Grant Wagner]

brougham3@yahoo.com wrote:

> Hyman Rosen <hyrosen@mail.com> wrote:
>
> >Programming language choice is so far from a factor in
> >interoperability and communications that your comments
> >are laughable.
>
> Why are stack buffer overflow problems such an issue in C when programs
> receive communications that differ from what the programmer expected?  Yes,
> I'm aware this is a programmer deficiency.  Subscribe to something like
> Bugtraq for any length of time, and you'll see the same programmer problems
> over and over and over again.

If two devices are attempting to talk to one another, and one continues to send
data which is not what the other expects, they would not be able to communicate
anyway.

So, let's consider your C program. It receives input it is not expecting, the
stack buffer overflows and something happens (perhaps the software issues an
error) and the device restarts. No communication has taken place.

Now let's consider a Java program. It receives input it is not expecting, there
is no buffer overflow, however the data is rejected as being invalid. No
communication has taken place.

Your choice of language has made little difference. The fact that the C
programmed device had to restart is irrelevant to the argument that the device
could not communicate with another device, because both devices were talking to
each other using a different dialect to begin with.

> Programming language choice is a factor.  If you have a skilled programmer,
> language doesn't matter.  The problem is that it's far harder to find a
> truly skilled C++ master than it is a C one.  Both are many times harder to
> find than a skilled Java guru.  Not sure about Ada.

It doesn't matter how skillful the programmer is. If a Java or Ada program
receives data is is not expecting, all it can do is reject that data and not
establish communication with the device which provided the data to it in the
first place. Again, choice of language has nothing to do with whether devices
can communicate or not.

What determines whether devices can communicate is whether a common set of
protocols (both high and low-level) have been established, and whether both
devices understand these protocols. If I wish to FTP a file to a device over
TCP/IP, the other device must understand TCP/IP and it must understand FTP. The
language those protocols are implemented in are irrelevant to whether I can FTP
the file to that device.

--
| Grant Wagner <gwagner@agricoreunited.com>

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[John R. Strohm]

<brougham3@yahoo.com> wrote in message
news:1quq5v0sb922r76rbpmcs2pe19dr4i5a2r@4ax.com...
> Hyman Rosen <hyrosen@mail.com> wrote:
>
> >Programming language choice is so far from a factor in
> >interoperability and communications that your comments
> >are laughable.
>
> Why are stack buffer overflow problems such an issue in C when programs
> receive communications that differ from what the programmer expected?
Yes,
> I'm aware this is a programmer deficiency.  Subscribe to something like
> Bugtraq for any length of time, and you'll see the same programmer
problems
> over and over and over again.
>
> Programming language choice is a factor.  If you have a skilled
programmer,
> language doesn't matter.  The problem is that it's far harder to find a
> truly skilled C++ master than it is a C one.  Both are many times harder
to
> find than a skilled Java guru.  Not sure about Ada.

What you miss in that statement is that it is nowhere near as necessary to
HAVE guru-level programmers when working in Ada.  The compiler catches many
of the problems that in C or C++ would normally require the guru to meditate
long and hard, and perhaps consult the entrails of a freshly-killed junior
programmer.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[soft-eng]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<A8586C51222985B9.50D4E3E5ED619D2D.66EBAD79FBE70B06@lp.airnews.net>...
...
> of the problems that in C or C++ would normally require the guru to meditate
> long and hard, and perhaps consult the entrails of a freshly-killed junior
> programmer.

Here is a quote for you :-)

  Any sufficiently advanced technology is indistinguishable from magic. 

  Arthur C. Clarke

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[John R. Strohm]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0303100722.3bc7adfa@posting.google.com...
> "John R. Strohm" <strohm@airmail.net> wrote in message
news:<A8586C51222985B9.50D4E3E5ED619D2D.66EBAD79FBE70B06@lp.airnews.net>...
> ...
> > of the problems that in C or C++ would normally require the guru to
meditate
> > long and hard, and perhaps consult the entrails of a freshly-killed
junior
> > programmer.
>
> Here is a quote for you :-)
>
>   Any sufficiently advanced technology is indistinguishable from magic.
>
>   Arthur C. Clarke

The standard rejoinder is "Any sufficiently advanced technology is
indistinguishable from a rigged demo."

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Tom Welsh]

In article <uDg7a.10931$ES3.5321@nwrddc04.gnilink.net>, Hyman Rosen
<hyrosen@mail.com> writes
>brougham3@yahoo.com wrote:
>> Why ...
>
>Why don't people read before writing?
>
>The OP claimed that the reason various battlefield
>communications systems didn't properly talk to each
>other was that they were programmed in different
>languages. This is utter nonsense. For systems to
>interoperate, they either all have to adhere to a
>rigorously defined protocol, or they have to be
>developed in tandem.
>
Unless, ho ho, they communicate using magic Web services. Then, because
all messages are expressed in terms of self-describing XML, the receiver
can always understand what the sender means.

Just think of all the fuss software engineers made about semantics,
before they realised that all you need is a few tags!

-- 
Tom Welsh

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Tom Welsh]

In article <3E68C3CF.D4414313@agricoreunited.com>, Grant Wagner
<gwagner@agricoreunited.com> writes
>
>So, let's consider your C program. It receives input it is not expecting, the
>stack buffer overflows and something happens (perhaps the software issues an
>error) and the device restarts. No communication has taken place.
>
>Now let's consider a Java program. It receives input it is not expecting, there
>is no buffer overflow, however the data is rejected as being invalid. No
>communication has taken place.
>
>Your choice of language has made little difference. The fact that the C
>programmed device had to restart is irrelevant to the argument that the device
>could not communicate with another device, because both devices were talking to
>each other using a different dialect to begin with.
>
Yeah, little difference except for the C program's buffer overflow which
allows an attacker to modify its code and, in the worst case, take over
the whole machine.
-- 
Tom Welsh

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Tom Welsh]

In article <a3eaa964.0302261448.6f38de58@posting.google.com>, Kent Paul
Dolan <xanthian@well.com> writes
>Richard Riehle <richard@adaworks.com> wrote:
>
>> The language is structured around a few simple principles.
>
>Which seem to be "simple" only in the minds of computer
>language theorists, not in the minds of us mere programmers,
>to whom the reasons for which these principles are
>meritorious and why they should govern our lives are still
>quite convincingly opaque.
>
Which "computer language theorists" are you talking about? Surely not
Jean D. Ichbiah, Bernd Krieg-Bruechner, Brian A. Wichmann, Henry F.
Ledgard, Jean-Claude Heliard, Jean-Loup Gailly, Jean-Ryanmond Abrial,
John G. P. Barnes, Mike Woodger, Olivier Roubine, Paul N. Hilfinger, and
Robert Firth.

Do you actually know any of these people? Have you heard of them?

Maybe very clever, experienced programmers sometimes seem like "computer
language theorists" to programmers who are not quite so clever or
experienced.

When you are programming away on your Intel-based or Sparc-based
computer, do you often pause to contemplate the foolishness of the chip
designers, who followed principles that are not entirely clear to you?
Or do you just learn how to use the results of their work?
-- 
Tom Welsh

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kent Paul Dolan]

Tom Welsh <news@tom-welsh.co.uk> wrote:
> Kent Paul Dolan <xanthian@well.com> writes:
>> Richard Riehle <richard@adaworks.com> wrote:

>>> The language is structured around a
>>> few simple principles.

>> Which seem to be "simple" only in the
>> minds of computer language theorists,
>> not in the minds of us mere
>> programmers, to whom the reasons for
>> which these principles are
>> meritorious and why they should
>> govern our lives are still quite
>> convincingly opaque.

> Which "computer language theorists"
> are you talking about? Surely not Jean
> D. Ichbiah, Bernd Krieg-Bruechner,
> Brian A. Wichmann, Henry F. Ledgard,
> Jean-Claude Heliard, Jean-Loup Gailly,
> Jean-Ryanmond Abrial, John G. P.
> Barnes, Mike Woodger, Olivier Roubine,
> Paul N. Hilfinger, and Robert Firth.

> Do you actually know any of these people?

Not a one, I participated in ANSI X3H3
computer graphics programming language
standards efforts, not the Ada ANSI
X3J-whatever standards efforts.

> Have you heard of them?

Jean Ichbiah, Jean-Loup Gailly, John
Barnes, Paul Hilfinger, and Robert Firth
are familiar names to me, the rest are
not. I twice owned a copies of John
Barnes textbooks on learning Ada
programming, but they were lost to me in
the disintegration of one marriage or
another.

> Maybe very clever, experienced
> programmers sometimes seem like
> "computer language theorists" to
> programmers who are not quite so
> clever or experienced.

Nice try, but with 41 years programming
experience and a wealth of algorithmic
inventions to my name, you'll have to
find someone else to slander.

I merely lack the level of specific
formal education in computer language
design that make most of what the OP
thinks of as "simple principles" look
simple when reduced to standards-ese, or
look simple when trying to convince
other mid-level and junior programmers
that Ada is an "easily understood
language".

If that claim were true, the years of
language lawyering that have filled and
continue to fill comp.lang.ada would not
have been necessary. In the case, Ada is
conceptually an extremely difficult
language to understand, and I'm not sure
why that needed to be so.  Pascal [from
which Ada mostly derives], at least in
its early incarnations, is in contrast
supremely easy to understand from the
practicing programmer's viewpoint, which
made it a splendid learning langauge and
quite fair in practice as well.

> When you are programming away on your
> Intel-based or Sparc-based computer,
> do you often pause to contemplate the
> foolishness of the chip designers, who
> followed principles that are not
> entirely clear to you?  Or do you just
> learn how to use the results of their
> work?

Well, no, I bothered to learn why and
how the chips work the way they do, down
to the gate level originally, in higher
level chunks more recently.

[Not all that many people in the world
have ever memorized the logic gates and
software running therein of an entire
computer, but I am one of that few [not
that it was all that complicated a
computer: the guidance computer for the
Polaris Missile; and I did it as a way
to gain promotion in my military
specialty, not for the sheer joy of the
task]].

[Do you often answer months-old articles
and expect current answers?  Are you not
often disappointed?]

xanthian.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Tom Welsh]

In article <a3eaa964.0304162216.60978001@posting.google.com>, Kent Paul
Dolan <xanthian@well.com> writes
>Tom Welsh <news@tom-welsh.co.uk> wrote:
>
>> Maybe very clever, experienced
>> programmers sometimes seem like
>> "computer language theorists" to
>> programmers who are not quite so
>> clever or experienced.
>
>Nice try, but with 41 years programming
>experience and a wealth of algorithmic
>inventions to my name, you'll have to
>find someone else to slander.
>
I think "slander" is an exaggeration; I didn't even specifically say my
comment applied to you. It was more along the lines of "if the cap
fits..."

Anyway, if you take it personally I apologise - I certainly didn't mean
to make an ad hominem remark. And I wrote in haste, before having a
chance to read enough of your articles and get a clear idea of your
experience. 

I also wrote emotionally, because I like Ada and think it is a valuable
contribution to software engineering. My introduction to it was reading
Grady Booch's "Software Engineering with Ada" in about 1983, and shortly
thereafter taking a two-week training course with Dee deCristofaro (sp?)
at DEC's Landover, MD offices. While I was by no means an effective Ada
programmer at that stage, I think I understand the basic principles of
the language. And I also believed that it was a big improvement on
languages like Fortran, Cobol and Basic.

The canard that Ada was designed by a committee, by the DoD, or by
ivory-tower academics, has been so widely promoted that I tend to have a
knee-jerk reaction to it by now.

>
>[Not all that many people in the world
>have ever memorized the logic gates and
>software running therein of an entire
>computer, but I am one of that few [not
>that it was all that complicated a
>computer: the guidance computer for the
>Polaris Missile; and I did it as a way
>to gain promotion in my military
>specialty, not for the sheer joy of the
>task]].
>
Touche! And congratulations. I think we would all be a lot better off it
more people had a wide and balanced understanding of computer systems.

>[Do you often answer months-old articles
>and expect current answers?  Are you not
>often disappointed?]
>
Only when they are interesting and I feel the need to speak up. And in
this case, you did not disappoint me!  8-)
-- 
Tom Welsh

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Richard Riehle]

Kent Paul Dolan wrote:

> I merely lack the level of specific
> formal education in computer language
> design that make most of what the OP
> thinks of as "simple principles" look
> simple when reduced to standards-ese, or
> look simple when trying to convince
> other mid-level and junior programmers
> that Ada is an "easily understood
> language".

I suppose I should interpret that as a response to my
contention that Ada is not as hard to learn as many
have suggested.    In fact,  Ada, once some fundamental
ideas are understood, is not that difficult.   However,
in its early days, when those fundamental ideas were
new, even  revolutionary, they were difficult for even
experienced programmers to grasp.    Now, so many of
those ideas have been adopted in the design of other
programming languages, that, when one mentions one
of them in the context of Ada, the response is often, "So
what?  Language XYZ has that feature too."

True, not all of the ideas have been adopted.  The most
difficult  idea for many programmers to grasp is the set
of visibility rules in Ada.   In my experience, once those
are understood, everything else falls into place.  Some
Ada programmers spend years fighting the visibility
rules, and continue to raise questions, debate, and
engage in endless language lawyering in an attempt to
subvert, thwart, or whine about them.

> If that claim were true, the years of
> language lawyering that have filled and
> continue to fill comp.lang.ada would not
> have been necessary. In the case, Ada is
> conceptually an extremely difficult
> language to understand, and I'm not sure
> why that needed to be so.  Pascal [from
> which Ada mostly derives], at least in
> its early incarnations, is in contrast
> supremely easy to understand from the
> practicing programmer's viewpoint, which
> made it a splendid learning langauge and
> quite fair in practice as well.

I disagree.  Ada is not conceptually difficult to
learn or understand.  It does include some new
ideas, and new ideas are sometimes difficult to
grasp at first.  That is quite different.

Again, many people who were required to learn
Ada for their work were resentful of the mandate
and spent their time inventing reasons why they
believed they could not do something instead of
discovering how easily they could do it.

If a programmer wants to fight the visibility rules,
for example, he can do so, can grumble about them,
find reasons why writing a particular program is so
hard,  and so on.   This attitude reminds me of my
first experience on a part-time high-school job in
which I was required to use a floor-buffer.   The
standard floor-buffer uses a large circulating brush
which, as it polishes the floor, can exert a powerful
thrust vectored over its clockwise motion.   A human,
regardless of their strength, cannot overcome the force
of the brush using brute strength.   That same human,
learning to gently balance the rotating brush, can make
it go anywhere.  I became quite skilled at controlling
the buffer and could eventually command it using a
single finger.

The Ada visibility rules are a powerful force in the language
design.  The programmer can exert all kinds of energy in
complaints about it.  However, once one understands this
feature, takes charge of its inherent force, and incoporates it
into a design and corresponding source code, it makes the
Ada programming (and especially the maintenance) process
much more pleasant than one might find in competing programming
languages.

Most of Ada is pretty simple.   Besides the visibility rules,
there are two other parts of the language that are a bit
difficult for some newcomers:  accessibility rules (for
objects and access types) which prevent many of the pointer
related mistakes so common in many languages,  and tasking,
a feature designed to incorporate concurrency in the language.

Most of the other features of the language, such as type safety rules,
separate compilation,  type derivation,  object aggregates, abstract
data types,  control over defined scope,  generic templates,  exception
handling,  packaging of common entities,  information hiding,
encapsulation, etc;  these features that once seemed so strange to
programmers experienced in procedural abstractions, are now
commonplace throughout the programming language community.
When introduced in Ada, they seemed strange, even bizzare. Now
they are accepted practice.

Even so, Ada is not intended for one-person, single program, projects
where an individual programmer can grasp every detail of the program.
It is intended for large-scale projects where many programmers and
designers must interact over a set of complex requirements and integrate

those requirements into a single, well-functioning whole.  Ada makes
that kind of project easier to develop, easier than one might experience

in most other languages.

One can make the case that Ada is not the best choice for certain
classes
of software.  I still believe it is not appropriate, using the current
compiler
technology, for eight-bit microcontrollers (e.g., I-8051),  but a subset
of
Ada might be.   Smalltalk is still a better language for some kinds of
software, especially where one needs a lot of dynamic properties and
frequent modification of the code.  Smalltalk is, however, a terrible
choice for the kinds of software Ada is targeted to build.

There are other languages one can compare to Ada that also have serious
potential for embedded-real-time safety-critical software.   As I
examine
them, in some detail, I keep discovering that they simply fall short.
It is
said, "The Devil is in the details."    C++, for example, when I look at
it
closely, seems inappropriate for developing software of the kind I just
described.   Each time I look for a competing technology, when compared
to Ada, it simply falls short.

A better Ada could be designed.   There are things about the language
that could be improved.   I hope someone will eventually design a
language that is better than the current Ada design.  At this point,
though,
when I am looking for a language that has a high regard for reliability
and dependability,  Ada still has the edge.

Richad Riehle

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EA04A1E.CAFC1FEF@adaworks.com>...
> Kent Paul Dolan wrote:
> 
> > I merely lack the level of specific
> > formal education in computer language
> > design that make most of what the OP
> > thinks of as "simple principles" look
> > simple when reduced to standards-ese, or
> > look simple when trying to convince
> > other mid-level and junior programmers
> > that Ada is an "easily understood
> > language".
> 
> I suppose I should interpret that as a response to my
> contention that Ada is not as hard to learn as many
> have suggested.    In fact,  Ada, once some fundamental
> ideas are understood, is not that difficult.   However,
> in its early days, when those fundamental ideas were
> new, even  revolutionary, they were difficult for even
> experienced programmers to grasp.    Now, so many of
> those ideas have been adopted in the design of other
> programming languages, that, when one mentions one
> of them in the context of Ada, the response is often, "So
> what?  Language XYZ has that feature too."

I think nobody complained about any particular
feature.  The major complaint was that it
had all the itsy-bitsy little ideas that anybody
had thought at the time.  And no truly innovative
or revolutionary ones.

Take something trivial, e.g. string slicing.
Not a terribly useful feature, but not entirely
useless either.  The trouble is, there was
a whole lot of such mildly useful features
that Ichbiah had seen somebody use somewhere
(this one from PL/1 I think), or was able to
think up.

Also, Ada proponents made much of its strong
typing.  But it was not at all novel or revolutionary.
It was a very common language idea
at that time, and then-popular Pascal had it too.
That wasn't bad by itself.  But from a practical
point of view, over-emphasizing strong typing made
interfacing to C a virtual necessity
for projects of any significant complexity.
(C and later C++ style of type-safety turned out to
be good enough for real-world projects.)

But the huge collection of mostly mildly useful
features made the language too large and complex, which
is what got Hoare and other lights of
the time (relatively unknown in the DoD
circle) upset with Ada.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Larry Kilgallen]

In article <9fa75d42.0304221126.7112b7d5@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:

> Also, Ada proponents made much of its strong
> typing.  But it was not at all novel or revolutionary.
> It was a very common language idea
> at that time, and then-popular Pascal had it too.

As a Pascal programmer I was thrilled to use Ada since the typing
system is so much stronger than in Pascal.

> That wasn't bad by itself.  But from a practical
> point of view, over-emphasizing strong typing made
> interfacing to C a virtual necessity
> for projects of any significant complexity.

Not at all.  I have a 180,000 line Ada project which does interface
to another language for other reasons (not to get weak typing). But
the language I chose was certainly not C.  Are you under the impression
there are only two languages in the world.

> (C and later C++ style of type-safety turned out to
> be good enough for real-world projects.)

Like Windows ?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <9fa75d42.0304221126.7112b7d5@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:
> 
> > Also, Ada proponents made much of its strong
> > typing.  But it was not at all novel or revolutionary.
> > It was a very common language idea
> > at that time, and then-popular Pascal had it too.
> 
> As a Pascal programmer I was thrilled to use Ada since the typing
> system is so much stronger than in Pascal.

Much more flexible, too.

- Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304221126.7112b7d5@posting.google.com...
> Take something trivial, e.g. string slicing.
> Not a terribly useful feature, but not entirely
> useless either.

Array slicing is a wonderfully useful feature.  I use this feature in almost
every program of mine.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

> Array slicing is a wonderfully useful feature.  I use this feature in almost
> every program of mine.

And I have lots of fun trying to code around the lack of it in Java.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Robert A Duff]

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0304221126.7112b7d5@posting.google.com...
> > Take something trivial, e.g. string slicing.
> > Not a terribly useful feature, but not entirely
> > useless either.
> 
> Array slicing is a wonderfully useful feature.  I use this feature in almost
> every program of mine.

Really!?  I think of array slicing as a pretty minor feature of Ada,
which causes a lot of trouble for compiler writers, that could be
dispensed with.  After all, you could write a function that grabs those
components.

I'm thinking particularly of slices as L-values.  Do you ever use that?

- Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Dale Stanbrough]

Robert A Duff wrote:

> > > Also, Ada proponents made much of its strong
> > > typing.  But it was not at all novel or revolutionary.
> > > It was a very common language idea
> > > at that time, and then-popular Pascal had it too.
> > 
> > As a Pascal programmer I was thrilled to use Ada since the typing
> > system is so much stronger than in Pascal.
> 
> Much more flexible, too.

If i'm asked to quickly describe Ada, I often say it is an
industrialised Pascal...


Dale

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccadeiglef.fsf@shell01.TheWorld.com...
> Really!?  I think of array slicing as a pretty minor feature of Ada,
> which causes a lot of trouble for compiler writers, that could be
> dispensed with.  After all, you could write a function that grabs those
> components.

> I'm thinking particularly of slices as L-values.  Do you ever use that?

Usually I pass slices of arrays as parameters to procedures and functions.
For example Ada.Strings.Fixed would be far less convenient without the
ability to pass part of an array to a procedure or function.  As for
L-values I assume you mean something like

x(1..80) := (others => y);
?
If so, I use slices less often for that purpose.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Dr Chaos]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> "Chad R. Meiners" <crmeiners@hotmail.com> writes:
>> Array slicing is a wonderfully useful feature.  I use this feature in almost
>> every program of mine.
> 
> Really!?  I think of array slicing as a pretty minor feature of Ada,
> which causes a lot of trouble for compiler writers, that could be
> dispensed with.  After all, you could write a function that grabs those
> components.
 
> I'm thinking particularly of slices as L-values.  Do you ever use that?

Ask everybody who likes MATLAB:

in other words "yes".

And it's in Fortran 90/95, for similar reasons.  Note that F90 was
designed after Ada.

Getting arrays right definitely helps lower bugs, because
off-by-one counting in iteration are frequent source of
errors.
 
> - Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Larry Kilgallen]

In article <wccadeiglef.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> "Chad R. Meiners" <crmeiners@hotmail.com> writes:

>> Array slicing is a wonderfully useful feature.  I use this feature in almost
>> every program of mine.
> 
> Really!?  I think of array slicing as a pretty minor feature of Ada,
> which causes a lot of trouble for compiler writers, that could be
> dispensed with.  After all, you could write a function that grabs those
> components.
> 
> I'm thinking particularly of slices as L-values.  Do you ever use that?

Yes, although in a minority of cases.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

> Really!?  I think of array slicing as a pretty minor feature of Ada,
> which causes a lot of trouble for compiler writers, that could be
> dispensed with.  After all, you could write a function that grabs those
> components.

Having used it a lot, I really appreciated the fact
that the compiler writers went to that trouble.

Now I'm finishing up a Java class, and I am getting tired
of repeating that same trouble in nearly every program.

> I'm thinking particularly of slices as L-values.  Do you ever use that?

I did that a lot in Ada days, too.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Richard Riehle]

soft-eng wrote:

> I think nobody complained about any particular
> feature.  The major complaint was that it
> had all the itsy-bitsy little ideas that anybody
> had thought at the time.  And no truly innovative
> or revolutionary ones.

There were a few itsy-bitsy ideas that were unique
in the language at the time of Ada's introduction.

> Take something trivial, e.g. string slicing.
> Not a terribly useful feature, but not entirely
> useless either.  The trouble is, there was
> a whole lot of such mildly useful features
> that Ichbiah had seen somebody use somewhere
> (this one from PL/1 I think), or was able to
> think up.

String slicing was unnecessary, still is, when one
used a Strings package.   In contemporary Ada, this
is handled quite nicely with language-defined packages.

However, aside from that, the interesting an powerful idea
in Ada was not the string slicing, but the array management
model.  A string, in Ada is a first class type.  It is a kind
of array type.   Arrays in Ada are quite powerful.  This is
one of the features I most like about the language at the
algorithm design level.   From my experience with C and
C++, I would much rather program with Ada arrays than
with C or C++ arrays.

> Also, Ada proponents made much of its strong
> typing.  But it was not at all novel or revolutionary.
> It was a very common language idea
> at that time, and then-popular Pascal had it too.

We  should probably re-phrase this phrase, "strong
typing" to type-safety.   Even though we saw some
movement in the direction of type-safety in Pascal,
PL/I, and other earlier languages, Ada went well
beyond those earlier attempts and actually achieved
what they did not.

> That wasn't bad by itself.  But from a practical
> point of view, over-emphasizing strong typing made
> interfacing to C a virtual necessity
> for projects of any significant complexity.

Well, this, of course is dead wrong.   Type safety did not
drive the move to interfacing with C.   Also, Ada was,
and is, designed to permit a programmer to get to a very
low-level of programming, even to the machine code
level, if it seems appropriate.

One can, in Ada, relax the type safety as necessary.  Some
organizations set up rules that prohibited using such features,
and opted, instead, for writing the code in C.   In such cases,
they gained nothing, lost a lot, and often created a mess.  If
they had remained with straight Ada, they would have been
better off.

That being said, there is a lot of operational code written in
C, C++, Fortran, Assembler, and other languages.   Contemporary
Ada is designed to make it easy to use existing code regardless
of how it is coded.   Mature code that works is often better than
new code that has not been tested in the real world, regardless
of what spiffy new language one might use.  Ada allows the
developer to leverage the best of existing code while building
better and more reliable code than would be likely in
C or C++.

> (C and later C++ style of type-safety turned out to
> be good enough for real-world projects.)

Once again, dead wrong.  C++ is not type-safe.  It offers
an illusion of type-safety under some circumstances, but
such oddities as type-promotion (also in Java) fly in the
face of type safety.   There all sorts of holes in C++ that
make the idea of type-safety there somewhat at odds with
what it ought to be.

> But the huge collection of mostly mildly useful
> features made the language too large and complex, which
> is what got Hoare and other lights of
> the time (relatively unknown in the DoD
> circle) upset with Ada.

Actually, Hoare later wrote a tribute to Ada in one of the
Ada 83 books.  His earliest criticism of Ada had to do
mostly with the inclusion of exception handling in the
language.   Ooooops!  We now have exception handling
in C++, Java, Eiffel, etc.    So when you mention  Hoare
and Ada, you need to understand that, subsequent to his
Turing lecture, he had some pretty nice things to say
about the language.

Richard Riehle

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Volkert]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EA62B54.49580F4F@adaworks.com>...
> soft-eng wrote:

 < deleted> 
> 
> Actually, Hoare later wrote a tribute to Ada in one of the
> Ada 83 books.  His earliest criticism of Ada had to do
> mostly with the inclusion of exception handling in the
> language.   
Yepp. The book was published in the famous prentice hall -
international series in computer science. The Series Editor 
was >> Tony Hoare <<.

Volkert

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EA62B54.49580F4F@adaworks.com>...

> drive the move to interfacing with C.   Also, Ada was,
> and is, designed to permit a programmer to get to a very
> low-level of programming, even to the machine code
> level, if it seems appropriate.

How many times in your whole life have you done this?
Or known of other people who have done this?

And how many instances do you know when this
was done by interfacing with C?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<b84gku$2i5l$1@msunews.cl.msu.edu>...
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0304221126.7112b7d5@posting.google.com...
> > Take something trivial, e.g. string slicing.
> > Not a terribly useful feature, but not entirely
> > useless either.
> 
> Array slicing is a wonderfully useful feature.  I use this feature in almost
> every program of mine.

Any itsy-bitsy feature *will* be found wonderful by somebody.

That's exactly the problem -- because there were so
many itsy-bitsy features in Ada, a novice needed to
learn all of them, because somebody somewhere finds
it useful and it will be found in real-world code.

Having tons of features in auxiliary libraries
in the "C" style make mastering the language much simpler
by chunking the task of learning without complicating
the syntax issues.

But having them directly in the language itself makes
just learning the basic language unnecessarily harder.
And the trouble is, you don't get anything really
worthwhile out of all the time you spend on
mastering all that syntax.  You would have
been better off mastering concepts instead.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Larry Kilgallen]

In article <9fa75d42.0304230439.55d28e70@posting.google.com>, softeng3456@netscape.net (soft-eng) introduces the term "itsy-bitsy feature":

> Any itsy-bitsy feature *will* be found wonderful by somebody.
> 
> That's exactly the problem -- because there were so
> many itsy-bitsy features in Ada, a novice needed to
> learn all of them, because somebody somewhere finds
> it useful and it will be found in real-world code.

Most shops restrict their usage of Ada (or any language) to the needs
of their particular domain.  I do not believe I have ever used floating
point in Ada, and for the first 10 years I did not use tasking.  I had
no trouble skipping over those parts of the documentation.

> Having tons of features in auxiliary libraries
> in the "C" style make mastering the language much simpler
> by chunking the task of learning without complicating
> the syntax issues.

I am sorry you had trouble learning Ada syntax, but rest assured there
are many others who have had no such problem.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<d3xFAUvBYizb@eisner.encompasserve.org>...
> In article <9fa75d42.0304221126.7112b7d5@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:
> 
> > Also, Ada proponents made much of its strong
> > typing.  But it was not at all novel or revolutionary.
> > It was a very common language idea
> > at that time, and then-popular Pascal had it too.
> 
> As a Pascal programmer I was thrilled to use Ada since the typing
> system is so much stronger than in Pascal.
> 
> > That wasn't bad by itself.  But from a practical
> > point of view, over-emphasizing strong typing made
> > interfacing to C a virtual necessity
> > for projects of any significant complexity.
> 
> Not at all.  I have a 180,000 line Ada project which does interface
> to another language for other reasons (not to get weak typing). But
> the language I chose was certainly not C.  Are you under the impression
> there are only two languages in the world.
> 
> > (C and later C++ style of type-safety turned out to
> > be good enough for real-world projects.)
> 
> Like Windows ?


You must live in a different world from me -- I look
around, and from the web-browser to the newsreaders
to the email software to the software transporting
your packets full of Ada praise to the software
controlling the switching stations enroute to...

You don't like Windows, so you must be using
what?  Unix and X-Windows?  Written/extended/in Ada?
Surely Ada was there when most of X-Windows
and Motif happened?  Or at least when the
CD-ROM device drivers were being written?

What now did you say these very expensive
Ada projects actually do?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Stephen Leake]

softeng3456@netscape.net (soft-eng) writes:

> Any itsy-bitsy feature *will* be found wonderful by somebody.
> 
> That's exactly the problem -- because there were so
> many itsy-bitsy features in Ada, a novice needed to
> learn all of them, because somebody somewhere finds
> it useful and it will be found in real-world code.

Um, the definition of a "novice" is "someone who doesn't yet know
everything they need to know". So they can't be expected to be reading 
"real-world code" yet.

If a "slice" is useful, "real-world code" will use it, whether it is
directly supported by the language or not. So any programmer will
eventually have to understand it.

In other words, the fact that Ada directly supports "slices" and other
"isty-bitsy" features does not impact how much of Ada a novice "must"
learn before writing programs. Instead, it impacts the productivity of
the expert; it is easier to use "slices" in Ada than in Java.

> Having tons of features in auxiliary libraries in the "C" style make
> mastering the language much simpler by chunking the task of learning
> without complicating the syntax issues.

Most people say you have to master the C libraries before you can be
called a C master, which is exactly my point.

You can write real programs in the C subset of Ada, just as you
can write real programs in C. It's just easier to write more complex
programs in full Ada.

> But having them directly in the language itself makes just learning
> the basic language unnecessarily harder. 

Not if I distinguish between "essential features" and "nice but
non-essential features". Any good book on Ada will start with the
essential features, and leave the non-essential features till later.

If I never learned what a slice was, I could still write good Ada code.

> And the trouble is, you don't get anything really worthwhile out of
> all the time you spend on mastering all that syntax. You would have
> been better off mastering concepts instead.

Right; concepts like "slice" :).

-- 
-- Stephe

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Larry Kilgallen]

In article <9fa75d42.0304230515.48064263@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<d3xFAUvBYizb@eisner.encompasserve.org>...
>> In article <9fa75d42.0304221126.7112b7d5@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:

>> > (C and later C++ style of type-safety turned out to
>> > be good enough for real-world projects.)
>> 
>> Like Windows ?

> You don't like Windows, so you must be using
> what?  Unix and X-Windows?  Written/extended/in Ada?

At this instant I am using VMS, which thankfully written mostly before
the current C-mania started.  Even when they use C on Alpha and Itanium
now, those who develop VMS tend to use the safer techniques they learned
with Bliss in place of the null-terminated strings and other garbage that
is encouraged by C.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[H. S. Lahman]

Responding to Kilgallen...

> At this instant I am using VMS, which thankfully written mostly before
> the current C-mania started.  Even when they use C on Alpha and Itanium
> now, those who develop VMS tend to use the safer techniques they learned
> with Bliss in place of the null-terminated strings and other garbage that
> is encouraged by C.

I agree that as a 3GL systems programming language Bliss is without 
peer.  It blows the socks off C for speed, power, and portability.

OTOH, if one doesn't need to count cycles or talk to individual bits, it 
has some problems.  It also offers the developer a lot more alternatives 
for foot-shooting.  I am reminded of a great quote from one of the 
designers of Bliss (Lahovsky), "When I program in Bliss I feel I am in 
complete control of the machine.  But when I program in Pascal my 
programs tend to work the first time."  B-)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindersol.com
Pathfinder Solutions  -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Georg Bauhaus]

In comp.lang.ada Richard Riehle <richard@adaworks.com> wrote:
:     In fact,  Ada, once some fundamental
: ideas are understood, is not that difficult. 
 
:  The most
: difficult  idea for many programmers to grasp is the set
: of visibility rules in Ada.

Could it be that rules like these are not enough at the
center of introductions to Ada? I remember an exposition
of child packages (somewhere in GNAT documentation?)
pointing readers to their relation to nested packages.
It does so at some length, and I think it was the length,
including examples, that I found so helpful.

-- Georg

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Marc A. Criley]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304230424.10612b1a@posting.google.com>...
> Richard Riehle <richard@adaworks.com> wrote in message news:<3EA62B54.49580F4F@adaworks.com>...
> 
> > drive the move to interfacing with C.   Also, Ada was,
> > and is, designed to permit a programmer to get to a very
> > low-level of programming, even to the machine code
> > level, if it seems appropriate.
> 
> How many times in your whole life have you done this?

Uh, like, lots.

> Or known of other people who have done this?

You mean the various coworkers of mine over the years?

> And how many instances do you know when this
> was done by interfacing with C?

Only when having to hook up to code written by others--whatever we
did, we did in Ada.  The only times we ever had to dip into C was when
some supplied function was defined as a macro and we had to put it
into a function wrapper so that it could be called.

Marc A. Criley
Quadrus Corporation
www.quadruscorp.com

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Stephen Leake <Stephe.Leake@nasa.gov> wrote in message news:<ufzo91fww.fsf@nasa.gov>...
> > And the trouble is, you don't get anything really worthwhile out of
> > all the time you spend on mastering all that syntax. You would have
> > been better off mastering concepts instead.
> 
> Right; concepts like "slice" :).

Uh, I meant something a little deeper...

(In fact, that was my whole point!)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[P S Norby]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304230439.55d28e70@posting.google.com...
> Any itsy-bitsy feature *will* be found wonderful by somebody.
>
> That's exactly the problem -- because there were so
> many itsy-bitsy features in Ada, a novice needed to
> learn all of them, because somebody somewhere finds
> it useful and it will be found in real-world code.
>
> Having tons of features in auxiliary libraries
> in the "C" style make mastering the language much simpler
> by chunking the task of learning without complicating
> the syntax issues.
>

But mastering just the "C" syntac is never enough... you will need to master
the libraries.  So why is that any easier?  And if it's so easy (to learn
"C"), Why do the ad's all want 5+ years experience?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[tmoran]

> > and is, designed to permit a programmer to get to a very
> > low-level of programming, even to the machine code
> > level, if it seems appropriate.
>
> How many times in your whole life have you done this?
> Or known of other people who have done this?
>
> And how many instances do you know when this
> was done by interfacing with C?
  My first real Ada program used some machine code inserts to control
a video capture card.  It also used tasking to interact with the user
and to control audio capture.  No C drivers were available.

Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[Tor Iver Wilhelmsen]

Tom Welsh <news@tom-welsh.co.uk> writes:

> Unless, ho ho, they communicate using magic Web services. Then, because
> all messages are expressed in terms of self-describing XML, the receiver
> can always understand what the sender means.

Wonderful. For your next task, have Delphi understand an Axis WSDL
with a method returning a collection.

SOAP is usable if all you have can be expressed as primitives or
String. But still way too much overhead for 99.9 % of cases.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Bill Findlay]

On 23/4/03 13:39, in article
9fa75d42.0304230439.55d28e70@posting.google.com, "soft-eng"
<softeng3456@netscape.net> wrote:
...
> 
> Any itsy-bitsy feature *will* be found wonderful by somebody.
> That's exactly the problem -- because there were so
> many itsy-bitsy features in Ada, a novice needed to
> learn all of them, because somebody somewhere finds
> it useful and it will be found in real-world code.

Novices in Ada, even programming novices learning through Ada,
do not need (note, present tense) to deal with any language features
apart from those that support the programming concepts
they are currently learning.

It is the experience of those who are teaching large numbers of novices
(400-500 per year) that they do better in Ada than in any previous language
of instruction. That includes Pascal, which was designed for teaching.

> Having tons of features in auxiliary libraries
> in the "C" style make mastering the language much simpler
> by chunking the task of learning without complicating
> the syntax issues.

And don't novices in C have to spend time learning about itsy-bitsy
libraries because somebody somewhere depends on them in 'real-world' code?

> But having them directly in the language itself makes
> just learning the basic language unnecessarily harder.

Syntax is (almost) completely irrelevant to learning programming or a
programming language, except insofar as a language actively undermines the
student's confidence by virtue of error-prone inconsistencies.


> And the trouble is, you don't get anything really
> worthwhile out of all the time you spend on
> mastering all that syntax.  You would have
> been better off mastering concepts instead.

You *do* get something that is very worthwhile for a minor investment
in learning a very consistent and robust syntactic framework.

What you get is compiler assistance with the much more difficult and
important issues of semantics.

Providing useful semantics via well-defined, built-in language features
makes those semantics accessible to the compiler, which can exploit them to
benefit the efficiency and the reliability of the object program.

No compiler can do this effectively with external library code, or with
programmer-constructed equivalents of Ada's built-in high level features.

I mention, at random: machine-independent integer types, for loops that
always terminate, secure dynamic arrays (including strings), secure variant
records, exceptions, tasks, automatic mutual exclusion ...

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Simon Wright]

softeng3456@netscape.net (soft-eng) writes:

> Richard Riehle <richard@adaworks.com> wrote in message news:<3EA62B54.49580F4F@adaworks.com>...
> 
> > drive the move to interfacing with C.   Also, Ada was,
> > and is, designed to permit a programmer to get to a very
> > low-level of programming, even to the machine code
> > level, if it seems appropriate.
> 
> How many times in your whole life have you done this?
> Or known of other people who have done this?
> 
> And how many instances do you know when this
> was done by interfacing with C?

The problem was to interface to the PPC timebase register (the mftb
instruction) which is not supported in C either. So the choice, learn
the asm features of GNAT vs learn the asm features of GCC (which are
of course very similar) seemed a no-brainer; we did the GNAT version.

Later I tried the GCC version (this was on VxWorks) and took a couple
of hours to realise that in that environment you need to say __asm,
because WindRiver use -ansi in C compilations.

Whereas the GNAT version worked first time (it took rather longer to
get the 64-bit version working, though).

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Dr Chaos]

On 23 Apr 2003 05:39:04 -0700, soft-eng <softeng3456@netscape.net> wrote:
> "Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<b84gku$2i5l$1@msunews.cl.msu.edu>...
>> "soft-eng" <softeng3456@netscape.net> wrote in message
>> news:9fa75d42.0304221126.7112b7d5@posting.google.com...
>> > Take something trivial, e.g. string slicing.
>> > Not a terribly useful feature, but not entirely
>> > useless either.
>> 
>> Array slicing is a wonderfully useful feature.  I use this feature in almost
>> every program of mine.
> 
> Any itsy-bitsy feature *will* be found wonderful by somebody.
> 
> That's exactly the problem -- because there were so
> many itsy-bitsy features in Ada, a novice needed to
> learn all of them, because somebody somewhere finds
> it useful and it will be found in real-world code.
> 
> Having tons of features in auxiliary libraries
> in the "C" style make mastering the language much simpler
> by chunking the task of learning without complicating
> the syntax issues.
> 
> But having them directly in the language itself makes
> just learning the basic language unnecessarily harder.
> And the trouble is, you don't get anything really
> worthwhile out of all the time you spend on
> mastering all that syntax.  You would have
> been better off mastering concepts instead.

It's not just syntax---which in Ada and similar languages (Eiffel) is
quite easy versus C and C++---but the semantical concepts. 

There's no substantial difference for a novice between learning new
language features, new concepts, and new libraries.

There's a certain quantity of knowledge necessary to learn.

The choice of what goes in a library and what is "in a language" is
important intellectually primarily to the more expert language
designers and implementors.

Once both a base language and libraries are assumed the precise point
of division has little substantial effect for typical programming tasks:
you have to know a both. 

If the goal is truly a minimal "core" language, then C is only barely
a contender (and C++ laughable)---Smalltalk and Lisp are the obvious
endpoints there.  They're great languages, but in design very
substantially different from C or C++ or Ada.  

What I find bizzare and remarkable is the consistent assumption by
many others (especially those that don't use languages like Ada,
Eiffel and post F77 Fortran) that "C" and "C++" are almost-by-default,
the "correct" choice not just economically but in engineering quality.

There's nothing kashrut about them there.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Dr Chaos]

On 23 Apr 2003 06:15:57 -0700, soft-eng <softeng3456@netscape.net> wrote:
> 
> You must live in a different world from me -- I look
> around, and from the web-browser to the newsreaders
> to the email software to the software transporting
> your packets full of Ada praise to the software
> controlling the switching stations enroute to...
> 
> You don't like Windows, so you must be using
> what?  Unix and X-Windows?  Written/extended/in Ada?
> Surely Ada was there when most of X-Windows
> and Motif happened?  Or at least when the
> CD-ROM device drivers were being written?

No, there were no free Ada compilers and the native
interface to the operating system (Unix) required
being able to parse not just syntax but semantics
of C include files. 

> What now did you say these very expensive
> Ada projects actually do?


-- 
---------------------------------------------
Matthew Kennel, mkennel@ucsd.edu
Institute For Nonlinear Science, UC San Diego
---------------------------------------------

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Samuel Tardieu]

>> Also, Ada was,
>> and is, designed to permit a programmer to get to a very
>> low-level of programming, even to the machine code
>> level, if it seems appropriate.
> 
> How many times in your whole life have you done this?

Many many times. And I hope my life is not over yet :)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kent Paul Dolan]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> "Chad R. Meiners" <crmeiners@hotmail.com> writes:

>> Array slicing is a wonderfully useful feature.  I use this feature
in almost
>> every program of mine.

> Really!?  I think of array slicing as a pretty minor feature of Ada,
> which causes a lot of trouble for compiler writers, that could be
> dispensed with.  After all, you could write a function that grabs those
> components.

> I'm thinking particularly of slices as L-values.  Do you ever use that?

It might be "minor" now, but if Ada is ever to stand beside Fortran as
a programming language for supercomputers, it is awfully nice that
this much of the needed semantics are "already in there"; they were a
huge shock when they first hit Fortran all in a lump.

[And by the way, since I've drifted away from Ada for lack of job
prospects for an Ada beginner without a current security clearance, is
there any effort underway to add the syntactic sugar for supercomputer
programming to Ada in an upcoming standard's language revision, or is
Ada down to "don't rock the boat" editorial cleanup standards (that
would eventually doom the language) for the foreseeable future, or is
there some big worthwhile effort but in another direction?]

xanthian.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Dr Chaos]

On 23 Apr 2003 16:06:58 -0700, Kent Paul Dolan <xanthian@well.com> wrote:
> [And by the way, since I've drifted away from Ada for lack of job
> prospects for an Ada beginner without a current security clearance, is
> there any effort underway to add the syntactic sugar for supercomputer
> programming to Ada in an upcoming standard's language revision,

It takes more than just syntacic surgar, it takes explicit
semantically important assertions and constructions, e.g. Fortran's
distinction between FORALL and DO loops.

> or is
> Ada down to "don't rock the boat" editorial cleanup standards (that
> would eventually doom the language) for the foreseeable future, or is
> there some big worthwhile effort but in another direction?]

I have no particular knowledge, but I think it's doubtful.

For massively parallel computation, modern Fortran (i.e. 95 and soon 200x) 
is where the compiler makers and the users are concentrating.

Modern Fortran is not substantially inferior as a language versus Ada 
in conventional "data structure ability" for such tasks, and there is
already substantial experience at parallelization.  Fortran 200x is
getting more Adaish anyway, and that's the future. 

Problems worthy of being solved on a large scale on a supercomputer
usually come with a long history of legacy code anyway.  A global
circulation model is not something to be whipped up in a week.  Also,
extreme embedded-system-quality reliability is less important there
than having the immediate researchers who know the subject
matter---scientists not full time programmers---running and modifying
the code.

> xanthian.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

tmoran@acm.org wrote in message news:<rVzpa.583781$3D1.323774@sccrnsc01>...
> > > and is, designed to permit a programmer to get to a very
> > > low-level of programming, even to the machine code
> > > level, if it seems appropriate.
> >
> > How many times in your whole life have you done this?
> > Or known of other people who have done this?
> >
> > And how many instances do you know when this
> > was done by interfacing with C?
>   My first real Ada program used some machine code inserts to control
> a video capture card.  It also used tasking to interact with the user
> and to control audio capture.  No C drivers were available.

Ok, I am sure a few instances happened.  But if you
had to develop device drivers for a living, and if
the language was truly your choice, would you chose Ada as
the language?

I think the only "yes" answers would be from
people who only know Ada and/or have never
written a device driver.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbadndp.o8q.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...

> The choice of what goes in a library and what is "in a language" is
> important intellectually primarily to the more expert language
> designers and implementors.

Syntax is core to the language.  So it should not be
unnecessarily overloaded.  Libraries can be learned
in specialized variations, as needed.  But every
programmer needs to know the syntax.  (Should anyway;
if people are chunking the language syntax so
their programmers can get their heads around it,
I think the syntax is too complex.)

> Once both a base language and libraries are assumed the precise point
> of division has little substantial effect for typical programming tasks:
> you have to know a both. 
> 
> If the goal is truly a minimal "core" language, then C is only barely
> a contender (and C++ laughable)---Smalltalk and Lisp are the obvious
> endpoints there.  They're great languages, but in design very
> substantially different from C or C++ or Ada.  
> 
> What I find bizzare and remarkable is the consistent assumption by
> many others (especially those that don't use languages like Ada,
> Eiffel and post F77 Fortran) that "C" and "C++" are almost-by-default,
> the "correct" choice not just economically but in engineering quality.

It's the other way around.  Software engineering is a fake field
full of charltans, simply because it stands on a false premise -- you
can take anybody and turn them into good disciplined programmers by 
applications of certain principles.  The actual fact is, results
in software are to a *very* large part related to aptitude.  If you
can't hire well, the project is doomed no matter how many software
engineering principles you apply.  Once you have the right people,
engineering quality will appear; you just need to make sure
the design is good, the management is good (which
often means not getting in the way of good quality),
there is good quality assurance, and such less-than-flashy things.

So there are no "engineering quality" correct choices.
Some languages with straight-jacket mentalities make people
think they are rigorous, disciplined tools that will
make quality magically appear.  That is deluded thinking.

If Ada projects had actually succeeded in producing good quality
software, it would have been everywhere today.

The real solution -- for a language -- is on the opposite tack.
You just need to find the tools that will fit best
the "right aptitude" people.  And that was C's success.

Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Jacob Sparre Andersen]

[ FUT comp.lang.ada ]

soft-eng wrote:

> But if you
> had to develop device drivers for a living, and if
> the language was truly your choice, would you chose Ada as
> the language?

Yes.

> I think the only "yes" answers would be from
> people who only know Ada and/or have never
> written a device driver.

Who would ever choose a language they didn't know for professional work?

Jacob
-- 
"Banning open source would have immediate, broad, and
  strongly negative impacts on the ability of many sensitive
  and security-focused DOD groups to protect themselves
  against cyberattacks"                        -- Mitre Corp.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Larry Kilgallen]

In article <9fa75d42.0304240446.493ca906@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:

> Ok, I am sure a few instances happened.  But if you
> had to develop device drivers for a living, and if
> the language was truly your choice, would you chose Ada as
> the language?
> 
> I think the only "yes" answers would be from
> people who only know Ada and/or have never
> written a device driver.

You would be wrong.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Vinzent Hoefler]

softeng3456@netscape.net (soft-eng) wrote:

>Ok, I am sure a few instances happened.  But if you
>had to develop device drivers for a living, and if
>the language was truly your choice, would you chose Ada as
>the language?

Yes.

>I think the only "yes" answers would be from
>people who only know Ada and/or have never
>written a device driver.

Well, I know Ada well enough to know that I can express low-level
hardware information definitely better, easier and safer than in C.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[John R. Strohm]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304240446.493ca906@posting.google.com...
> tmoran@acm.org wrote in message
news:<rVzpa.583781$3D1.323774@sccrnsc01>...
> > > > and is, designed to permit a programmer to get to a very
> > > > low-level of programming, even to the machine code
> > > > level, if it seems appropriate.
> > >
> > > How many times in your whole life have you done this?
> > > Or known of other people who have done this?
> > >
> > > And how many instances do you know when this
> > > was done by interfacing with C?
> >   My first real Ada program used some machine code inserts to control
> > a video capture card.  It also used tasking to interact with the user
> > and to control audio capture.  No C drivers were available.
>
> Ok, I am sure a few instances happened.  But if you
> had to develop device drivers for a living, and if
> the language was truly your choice, would you chose Ada as
> the language?
>
> I think the only "yes" answers would be from
> people who only know Ada and/or have never
> written a device driver.

Over the course of some 33 years spent in and around computers, I have
probably dealt with some twenty different computer instruction set
architectures and assembly languages (PDP-8, PDP-11, Nova, Intel 8080, 8086,
68000, 68020, CDC 6600, DEC-10, to name a few) and probably half a dozen or
more high-level languages (FORTRAN IV, FORTRAN 77, PASCAL, COBOL, LISP, Ada,
FORTH, C, JOVIAL J73, that I remember offhand), and I have written quite a
few device drivers in my day.

As a matter of fact, I *would* usually choose to do the driver in Ada.

From the sound of what you have said so far, I conjecture that you have
never in your life done any serious work in Ada, and that you intend to keep
it that way if you possibly can.  Am I correct?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

> It's the other way around.  Software engineering is a fake field
> full of charltans, simply because it stands on a false premise -- you
> can take anybody and turn them into good disciplined programmers by 
> applications of certain principles.  The actual fact is, results
> in software are to a *very* large part related to aptitude.  If you

That's _partly_ true.  No tool can turn an idiot into
a genius.  But no true genius would be stupid enough
to insist on using inferior tools.

> If Ada projects had actually succeeded in producing good quality
> software, it would have been everywhere today.

That's a crock.  The few times people have
bothered to make empirical comparisons, Ada
has come out ahead.

But why am I answering a troll?  (If you are
not merely trying to stir up a fight, why are
you cross-posting to "misc.misc" ?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3EA7E0E3.8020407@crs4.it>...
> [ FUT comp.lang.ada ]
> 
> soft-eng wrote:
> 
> > But if you
> > had to develop device drivers for a living, and if
> > the language was truly your choice, would you chose Ada as
> > the language?
> 
> Yes.
> 

Hmmm.  Very interesting.

But I am sure you folks couldn't come up with some similar
pronouncements for AI as well.  How many people out there who have
years and years of Artificial Intelligence experience and
who really think Ada is the best language for this purpose?

Any at all?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Mike Silva]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304240503.54dbc5d1@posting.google.com>...
> 
> If Ada projects had actually succeeded in producing good quality
> software, it would have been everywhere today.

Yeah, I see your point.  Kind of like why nobody runs Windows anymore.

Mike

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[tmoran]

>But I am sure you folks couldn't come up with some similar
>pronouncements for AI as well.  How many people out there who have
>years and years of Artificial Intelligence experience and
>who really think Ada is the best language for this purpose?
>
>Any at all?
  I recall seeing a book with a title like "Artificial Intelligence with
Ada" in Computer Literacy Bookstore some time ago.  Not being an AI person
(having spent my time with things like device drivers in multiple
languages and on multiple machines) I don't know if Ada is the best
language for AI, but clearly someone thought it a good enough idea to
write an entire book on the subject.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert Spooner]

soft-eng wrote:
> Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3EA7E0E3.8020407@crs4.it>...
> 
>>[ FUT comp.lang.ada ]
>>
>>soft-eng wrote:
>>
>>
>>>But if you
>>>had to develop device drivers for a living, and if
>>>the language was truly your choice, would you chose Ada as
>>>the language?
>>
>>Yes.
>>
> 
> 
> Hmmm.  Very interesting.
> 
> But I am sure you folks couldn't come up with some similar
> pronouncements for AI as well.  How many people out there who have
> years and years of Artificial Intelligence experience and
> who really think Ada is the best language for this purpose?
> 
> Any at all?

Yes. It's 10X the speed of lisp for our application.

-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Larry Kilgallen]

In article <9fa75d42.0304240950.45114a39@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:
> Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3EA7E0E3.8020407@crs4.it>...
>> [ FUT comp.lang.ada ]
>> 
>> soft-eng wrote:
>> 
>> > But if you
>> > had to develop device drivers for a living, and if
>> > the language was truly your choice, would you chose Ada as
>> > the language?
>> 
>> Yes.
>> 
> 
> Hmmm.  Very interesting.
> 
> But I am sure you folks couldn't come up with some similar
> pronouncements for AI as well.  How many people out there who have
> years and years of Artificial Intelligence experience and
> who really think Ada is the best language for this purpose?

Hopefully there is nobody who thinks that Ada is automatically the
best language for _everything_.  But to find people doing AI in Ada
(if any) please post directly to comp.lang.ada, without the crossposts.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kent Paul Dolan]

Wesley Groleau <wesgroleau@despammed.com> wrote

> But why am I answering a troll?  (If you are
> not merely trying to stir up a fight, why are
> you cross-posting to "misc.misc" ?

Because in the article at the top of the thread
_I_ crossposted it to misc.misc, the Net's all
purpose newsgroup, for reasons I've explained
half a dozen times at length elsewhere [not
having anything to do with trolling, and for
sure not trolling by the person you accuse], and
not worth repeating here, but a crosspost I try
_always_ to include in my postings.

Sheesh.

xanthian.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kaz Kylheku]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304240446.493ca906@posting.google.com>...
> Ok, I am sure a few instances happened.  But if you
> had to develop device drivers for a living, and if
> the language was truly your choice, would you chose Ada as
> the language?
> 
> I think the only "yes" answers would be from
> people who only know Ada and/or have never
> written a device driver.

For developing a device driver for an operating system, the best
language is that one which all the other drivers are written in and
consequently for which there is toolchain and run-time support.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message >
> Syntax is core to the language.

True.

>So it should not be
> unnecessarily overloaded.

Of course--please show how Ada is unnecessarily overloaded.  That was your
unsupported implication wasn't it?

>Libraries can be learned
> in specialized variations, as needed.

But then you can have competing and inconsistent libraries which is an issue
raised before that you failed to address.

>But every
> programmer needs to know the syntax.

A programmer only needs to know enough syntax of a language to be an
effective developer.

>(Should anyway;
> if people are chunking the language syntax so
> their programmers can get their heads around it,
> I think the syntax is too complex.)

You must realize that most languages fail this test since programmers often
only learn a subset of the language that they find useful.  If you are to
take your view seriously, then you will most likely have to declare all
languages too complex.

Re: Using Ada for device drivers?

[Vinzent Hoefler]

softeng3456@netscape.net (soft-eng) wrote:

>But I am sure you folks couldn't come up with some similar
>pronouncements for AI as well.

True. I would use Prolog for that. Or perhaps some functional language
like Lisp or Mercury.

I don't think, any procedural language would be best suited for such
task.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Richard Riehle]

soft-eng wrote:

> If Ada projects had actually succeeded in producing good quality
> software, it would have been everywhere today.

That is the silliest thing you have said so far.

      1)  Ada projects have succeeded in producing many millions
           of lines of quality software.

      2)  It is no more difficult to learn to write programs in Ada than
           it is in any other language.   I know this from experience,

      3) The fact that something is available in abundance has no relationship
           to its inherent quality.   For example, many low quality fast-food
           purveyors have managed to dominate the marketplace by distracting
           customers with all kinds of gimmicks that have nothing to do with
           the quality of their food.

       4) I suspect your knowledge about Ada is a little out-of-date.  This tends
           to make your observations somewhat irrelevant.

Richard Riehle

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Kaz Kylheku]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304240950.45114a39@posting.google.com>...
> Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3EA7E0E3.8020407@crs4.it>...
> > [ FUT comp.lang.ada ]
> > 
> > soft-eng wrote:
> > 
> > > But if you
> > > had to develop device drivers for a living, and if
> > > the language was truly your choice, would you chose Ada as
> > > the language?
> > 
> > Yes.
> > 
> 
> Hmmm.  Very interesting.
> 
> But I am sure you folks couldn't come up with some similar
> pronouncements for AI as well.  How many people out there who have
> years and years of Artificial Intelligence experience and
> who really think Ada is the best language for this purpose?
> 
> Any at all?


Ada is a high level assembly language like C, Pascal, Modula, PL/I and
so on. It's suitable only for stone age systems programming. It
doesn't matter at all which of these types of languages you use for
this kind of programming; the choice is purely pragmatic based on the
non-technical factors that make some languages more preferred than
other languages for programming some platforms.

All of these languages are really shades of the same language; they
are syntactic sugars for manipulating objects which are concrete
pieces of memory with explicit addresses, and have static types that
closely correspond to bitwise representations. With these languages,
you tell the machine what tiny word-sized quantities to funnel through
its processor and in what order, to get the job done.

Although Ada may be wonderful for device drivers in principle, in some
platforms you will only find the hooks, toolchain support and run-time
support for writing your driver in C. Boo hoo; you may have to trade
one idiotic language for another, what a loss!

Likewise, in some other platform, Ada may be the tool of choice,
because the whole kernel is already written in it, and the support
from that kernel that you need to use in your driver is already
expressed in terms of Ada. If you wanted to write in C, you would have
to do a bunch of work just to bootstrap yourself into being able to
write a "hello, world" driver, which could have been spent writing
half of the actual production driver in Ada.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Richard Riehle]

Georg Bauhaus wrote:

> In comp.lang.ada Richard Riehle <richard@adaworks.com> wrote:
> :     In fact,  Ada, once some fundamental
> : ideas are understood, is not that difficult.
>
> :  The most
> : difficult  idea for many programmers to grasp is the set
> : of visibility rules in Ada.
>
> Could it be that rules like these are not enough at the
> center of introductions to Ada? I remember an exposition
> of child packages (somewhere in GNAT documentation?)
> pointing readers to their relation to nested packages.
> It does so at some length, and I think it was the length,
> including examples, that I found so helpful.

In my experience, once the Ada programmer understands the
visibilty rules, everything else falls into place.  It is, therefore,
important to gently introduce some of those rules as part of
the learning process.  If one tries to introduce all of them at
once, it can overwhelm the student to the point where they
throw up their hands screaming things such as, "I hate this
f........ing bureaucratic language."

A programmer who learns to use the visibility rules to advantage
will eventually be an outstanding Ada programmer.

Richard Riehle

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304240503.54dbc5d1@posting.google.com...
> It's the other way around.  Software engineering is a fake field
> full of charltans, simply because it stands on a false premise -- you
> can take anybody and turn them into good disciplined programmers by
> applications of certain principles.

This is blatantly false!  While there might be a good deal of people that
claim to be software engineers that are charlatans, this fact (if true) does
not discredit the actually field of software engineering.  Furthermore,
your claim the software engineering stands upon a faulty premise is a
strawman argument.

>The actual fact is, results
> in software are to a *very* large part related to aptitude.  If you
> can't hire well, the project is doomed no matter how many software
> engineering principles you apply.

True, software engineering principles do not solve all problem (they don't
claim too either), but they are not worthless either, and yes, you need
competent people in order to succeed in anything.

> Once you have the right people,
> engineering quality will appear;

Eventually--the point of software engineering is to facilitate and teach
methodologies that help the right people work more effectively.

> you just need to make sure

I think your use of 'just' severely understates the difficulty of
accomplishing the below

> the design is good, the management is good (which
> often means not getting in the way of good quality),
> there is good quality assurance, and such less-than-flashy things.


> So there are no "engineering quality" correct choices.
> Some languages with straight-jacket mentalities make people
> think they are rigorous, disciplined tools that will
> make quality magically appear.  That is deluded thinking.

Nothing can prevent deluded thinking.  Just like nothing can prevent people
from making silly strawman arguments.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Tom Welsh]

In article <9fa75d42.0304240503.54dbc5d1@posting.google.com>, soft-eng
<softeng3456@netscape.net> writes
>
>If Ada projects had actually succeeded in producing good quality
>software, it would have been everywhere today.
>
Although I don't think this argument holds water, it raises an issue
which I think is very important. Perhaps the most important issue for
software development today.

Observation suggests that good software products do not necessarily
become popular; and the methods and processes adopted in successful
software projects do not necessarily get widely imitated. 

Why is this? Anecdotally, we have the old joke about how any project
failure is followed by steps including (but not limited to):

* Punishment of the innocent;
* Promotion of the guilty;
* Scattering of the project team to the four winds;

and (most significantly for our purposes)

* Burying of the evidence.

These steps are calculated to block dissemination of knowledge about
what works well, as opposed to what fails consistently. Feedback is
stifled, and learning prevented.

How about successful projects? Well, for a start these are in a small
minority - partly because of the syndrome described above. Moreover,
some of the most strikingly successful projects are considered strategic
(whether in government or business) and are therefore kept secret. Once
again, the feedback loops are blocked and learning does not take place
on any significant scale.

The Software Engineering Institute's Capability Maturity Model - while
arguably rather bureaucratic in its implementation - aims to strike at
the root of the problem, by prescribing mechanisms by which an
organization can ensure that it learns as much as possible from its own
experience, at least. The CMM sets out to institutionalize learning.

Of course, many people dislike the culture associated with initiatives
like the CMM (and Ada, for that matter). So it is lucky that the open
source movement is exerting a similar influence from the grass roots
level. Open source developers do not nurse secrets - technical or
otherwise - and, time permitting, are usually more than happy to discuss
the way they work.

There are, of course, many other reasons for the relatively low level of
software quality - notably the absence of explicit demand (as expressed
through the traditional medium of cash).
-- 
Tom Welsh

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[AG]

"Tom Welsh" <news@tom-welsh.co.uk> wrote in message
news:WLKGbLATlNq+EwiQ@nildram.co.uk...

> There are, of course, many other reasons for the relatively low level of
> software quality - notably the absence of explicit demand (as expressed
> through the traditional medium of cash).

That's true. There is also a small matter that no customer
is really interested in quality as such. As long as the software
performs as expected it's fine (as far as the user is concerned
it may be made of duct tape).

The quality as in language/methodology/process is or
should be a primary concern of the developer - since
it is  [a bit :-)]  involved in making a project a success
or not in the first place.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dmitry A. Kazakov]

soft-eng wrote:

> But I am sure you folks couldn't come up with some similar
> pronouncements for AI as well.  How many people out there who have
> years and years of Artificial Intelligence experience and
> who really think Ada is the best language for this purpose?
> 
> Any at all?

Me.

My PhD thesis work on fuzzy machine learning was in Ada 83, 10 years ago, 
but I still can run my code on practically any modern system. I also used 
Ada 95 for image pattern recognition, that's from production quality 
control systems to rain detection sensors.

The only reason I ever used a language other than Ada is when a customer 
required so.

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

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Tom Welsh <news@tom-welsh.co.uk> wrote in message news:<WLKGbLATlNq+EwiQ@nildram.co.uk>...
> In article <9fa75d42.0304240503.54dbc5d1@posting.google.com>, soft-eng
> <softeng3456@netscape.net> writes
> >
> >If Ada projects had actually succeeded in producing good quality
> >software, it would have been everywhere today.
> >
> Although I don't think this argument holds water, it raises an issue
> which I think is very important. Perhaps the most important issue for
> software development today.
> 
> Observation suggests that good software products do not necessarily
> become popular; and the methods and processes adopted in successful
> software projects do not necessarily get widely imitated. 

Where do you get this?  People in the industry adopt what
they see succeeding.  It's a feedback loop -- if a pilot
C project in a company succeeds wildly, everybody in the company
wants to do C projects.  If this happens in many companies,
C programmer demand goes up, salaries go up, more students
learn C, then other managers have to use C because all
college graduates know C...

Of course, the feedback loop could go much faster and
start fully grown in terms of rewards, if you have
billions of dollars backing up some language.
But Ada is proof that there has to be more than billions
of dollars.  There have to be _results_.

> Why is this? Anecdotally, we have the old joke about how any project
> failure is followed by steps including (but not limited to):
> 
> * Punishment of the innocent;
> * Promotion of the guilty;
> * Scattering of the project team to the four winds;
> 
> and (most significantly for our purposes)
> 
> * Burying of the evidence.
> 
> These steps are calculated to block dissemination of knowledge about
> what works well, as opposed to what fails consistently. Feedback is
> stifled, and learning prevented.
> 
> How about successful projects? Well, for a start these are in a small
> minority - partly because of the syndrome described above. Moreover,
> some of the most strikingly successful projects are considered strategic
> (whether in government or business) and are therefore kept secret. Once
> again, the feedback loops are blocked and learning does not take place
> on any significant scale.

So you are saying the Ada projects that succeeded were secret,
and the ones that were not secret did not succeed?

I suppose then commercial interests were right in leaving
Ada.  Unless they were going to keep their projects secret,
it would not have succeeded!!

It's probably nothing to do with Ada -- the secret projects
would have succeeded in any language because too much
money was going to be thrown at them in secret.  Believe
it or not, before Ada the DoD had many successful projects
in assembly language.  That doesn't mean assembly language
is the best tool.

Of course, perhaps a non-Ada language could have cut the project
costs and time to a quarter, but since the project was a secret,
there wasn't anybody around to point it out, was there?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

"AG" <ang@xtra.co.nz> wrote in message news:<k05qa.27935$mZ4.329924@news.xtra.co.nz>...
> "Tom Welsh" <news@tom-welsh.co.uk> wrote in message
> news:WLKGbLATlNq+EwiQ@nildram.co.uk...
> 
> > There are, of course, many other reasons for the relatively low level of
> > software quality - notably the absence of explicit demand (as expressed
> > through the traditional medium of cash).
> 
> That's true. There is also a small matter that no customer
> is really interested in quality as such. As long as the software
> performs as expected it's fine (as far as the user is concerned
> it may be made of duct tape).

So you think quality has nothing to do with performing as expected?

When I buy a car, I want it to perform as expected,
I don't CARE what methodology they used or didn't
use to get it to perform as expected.  If they
used a methodology that they though was the epitome
of perfection, but the car broke down every six months,
I would not buy it.  And if some other company
was able to use duct tape, but had a product
that ran for 20 years without maintenance, I would
buy it.  Whether they use duct tape or not
is not my concern.

Why should I expect software buyers to be any different?

(Thanks for illuminating the Ada advocates' mentality
perfectly, btw!)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

snarflemike@yahoo.com (Mike Silva) wrote in message news:<20619edc.0304240953.221ac70f@posting.google.com>...
> softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304240503.54dbc5d1@posting.google.com>...
> > 
> > If Ada projects had actually succeeded in producing good quality
> > software, it would have been everywhere today.
> 
> Yeah, I see your point.  Kind of like why nobody runs Windows anymore.
> 
> Mike

Works for me (plus several million other people.)

I even used Unix for years, even when it DIDN't
work 1/10th as reliably as today's Windows.

It's good to see operating systems progress to
the point where anybody off the streets can
realiably use them and the only people complaing
about the reliability are ones with axes to grind.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Robert Spooner <rls19@psu.edu> wrote in message news:<3EA836D4.1020004@psu.edu>...
> soft-eng wrote:
> > Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3EA7E0E3.8020407@crs4.it>...
> > 
> >>[ FUT comp.lang.ada ]
> >>
> >>soft-eng wrote:
> >>
> >>
> >>>But if you
> >>>had to develop device drivers for a living, and if
> >>>the language was truly your choice, would you chose Ada as
> >>>the language?
> >>
> >>Yes.
> >>
> > 
> > 
> > Hmmm.  Very interesting.
> > 
> > But I am sure you folks couldn't come up with some similar
> > pronouncements for AI as well.  How many people out there who have
> > years and years of Artificial Intelligence experience and
> > who really think Ada is the best language for this purpose?
> > 
> > Any at all?
> 
> Yes. It's 10X the speed of lisp for our application.
> 

All right!!  And now, can we have someone come up to
claim Ada is the best for rule-based applications?

How about it being the best teaching language?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Larry Kilgallen]

In article <9fa75d42.0304250501.2053ba4c@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:

> All right!!  And now, can we have someone come up to
> claim Ada is the best for rule-based applications?
> 
> How about it being the best teaching language?

If you are pursuing a course of baiting Ada supporters, please
restrict your posts to comp.lang.ada.

Re: Using Ada for device drivers?

[Georg Bauhaus]

In comp.lang.ada Kaz Kylheku <kaz@ashi.footprints.net> wrote:
 
: Ada is a high level assembly language like C, Pascal, Modula, PL/I and
: so on. It's suitable only for stone age systems programming. It
: doesn't matter at all which of these types of languages you use for
: this kind of programming; the choice is purely pragmatic based on the
: non-technical factors that make some languages more preferred than
: other languages for programming some platforms.
 
Wow. Generic polymorphic objects being high level assembly, and
modern LISPs proudly presenting bit manipulations. Interesting times
full of technical "arguments"...

- Georg

RE: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Kilgallen@SpamCop.net [mailto:Kilgallen@SpamCop.net]
..
| > All right!!  And now, can we have someone come up to
| > claim Ada is the best for rule-based applications?
| > 
| > How about it being the best teaching language?
| 
| If you are pursuing a course of baiting Ada supporters, please
| restrict your posts to comp.lang.ada.

Or better, just stop this troll.

Lionel Draghi

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<gpyti6DVkCKo@eisner.encompasserve.org>...
> In article <9fa75d42.0304240950.45114a39@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:
> > Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3EA7E0E3.8020407@crs4.it>...
> >> [ FUT comp.lang.ada ]
> >> 
> >> soft-eng wrote:
> >> 
> >> > But if you
> >> > had to develop device drivers for a living, and if
> >> > the language was truly your choice, would you chose Ada as
> >> > the language?
> >> 
> >> Yes.
> >> 
> > 
> > Hmmm.  Very interesting.
> > 
> > But I am sure you folks couldn't come up with some similar
> > pronouncements for AI as well.  How many people out there who have
> > years and years of Artificial Intelligence experience and
> > who really think Ada is the best language for this purpose?
> 
> Hopefully there is nobody who thinks that Ada is automatically the
> best language for _everything_.  But to find people doing AI in Ada
> (if any) please post directly to comp.lang.ada, without the crossposts.

I wasn't really trying to find anybody doing AI in Ada, just trying
to find exactly how degenerate the arguments can get :-)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EA87284.59CD9FA4@adaworks.com>...
> soft-eng wrote:
> 
> > If Ada projects had actually succeeded in producing good quality
> > software, it would have been everywhere today.
> 
> That is the silliest thing you have said so far.
> 
>       1)  Ada projects have succeeded in producing many millions
>            of lines of quality software.
> 
>       2)  It is no more difficult to learn to write programs in Ada than
>            it is in any other language.   I know this from experience,
> 
>       3) The fact that something is available in abundance has no relationship
>            to its inherent quality.   For example, many low quality fast-food
>            purveyors have managed to dominate the marketplace by distracting
>            customers with all kinds of gimmicks that have nothing to do with
>            the quality of their food.
> 
>        4) I suspect your knowledge about Ada is a little out-of-date.  This tends
>            to make your observations somewhat irrelevant.
> 
> Richard Riehle

*Any* observations about Ada, in 2003, are somewhat irrelevant :-)
But if we didn't want to discuss irrelevancies, we wouldn't
subscribe to a .advocay group, would we?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<b89nj1$1ikp$1@msunews.cl.msu.edu>...
> "soft-eng" <softeng3456@netscape.net> wrote in message >
> > Syntax is core to the language.
> 
> True.
> 
> >So it should not be
> > unnecessarily overloaded.
> 
> Of course--please show how Ada is unnecessarily overloaded.  That was your
> unsupported implication wasn't it?
> 
> >Libraries can be learned
> > in specialized variations, as needed.
> 
> But then you can have competing and inconsistent libraries which is an issue
> raised before that you failed to address.
> 
> >But every
> > programmer needs to know the syntax.
> 
> A programmer only needs to know enough syntax of a language to be an
> effective developer.
> 
> >(Should anyway;
> > if people are chunking the language syntax so
> > their programmers can get their heads around it,
> > I think the syntax is too complex.)
> 
> You must realize that most languages fail this test since programmers often
> only learn a subset of the language that they find useful.  If you are to
> take your view seriously, then you will most likely have to declare all
> languages too complex.

I think you need some actual experience with programmers
of different language.  Then you will be able to
make valid arguments on this.  E.g. how much of
the syntax of Java or VB the typical programmer
knows.  Language libraries are a (philosophically
and in practice) different issue, but most of the syntax
is well understood by most programmers.

Note that his argument does not apply to C++ -- most
C++ programmers only know a subset of the C++ syntax well.
(Specially since the syntax has been relentlessly expanded.)
But that's the reason for C++'s losing a lot
of ground.  Very soon advocates will start appearing
to claim C++ is the best thing since sliced bread,
and absolutely the best language for *everything*.
When that happens, C++ will be in the same
land where Ada is now.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304250443.47bd2aa9@posting.google.com...

> So you think quality has nothing to do with performing as expected?

That is not what AG said.  You are obviously mischaracterizing other's
arguments.

> (Thanks for illuminating the Ada advocates' mentality
> perfectly, btw!)

Ah, so you are a troll.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304250437.38893d8c@posting.google.com...
> Where do you get this?  People in the industry adopt what
> they see succeeding.  It's a feedback loop -- if a pilot
> C project in a company succeeds wildly, everybody in the company
> wants to do C projects.  If this happens in many companies,
> C programmer demand goes up, salaries go up, more students
> learn C, then other managers have to use C because all
> college graduates know C...

People feed money into slot machines because they see people winning money;
however, although a very few win most lose.  People rarely notice all those
that lose money.

> So you are saying the Ada projects that succeeded were secret,
> and the ones that were not secret did not succeed?

You're trolling.  You have mischaracterize yet another argument.  This
raises the question why you even bother to write such obviously nonsensical
arguments.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304250922.50104e0b@posting.google.com...
> I wasn't really trying to find anybody doing AI in Ada, just trying
> to find exactly how degenerate the arguments can get :-)

What are you bothing to see how degenerate your arguments can get?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304250937.36a7897e@posting.google.com...
>
> I think you need some actual experience with programmers
> of different language.

I have such experience; do you?

> Then you will be able to
> make valid arguments on this.  E.g. how much of
> the syntax of Java or VB the typical programmer
> knows.

I have work on projects in both VB and Java.  In both cases competent
programmers only knew subsets of the language's syntax.  This subsetting did
not hamper the projects' success.

> but most of the syntax
> is well understood by most programmers.

Ha!  Just the other day I ran into a competent programmer that never
realized that the {} defines a block in C that you can declare variables in.
Sure he used {}'s all the time, but he didn't understand their flexibility
until told him.  Still he produced acceptable work when he had to work in C.
How many competent Java programmers don't know about the synchronize keyword
because they never have writen a multithreaded application?

Also are you talking just about syntax or about both syntax and semantics?
If you are only concerned with syntax then we have an uninteresting
discussion, however, if you are interested in semantics, then almost all
programmers only know of subset of each programming language's syntax.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<kKoVGF55fYtj@eisner.encompasserve.org>...
> In article <9fa75d42.0304230515.48064263@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:
> > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<d3xFAUvBYizb@eisner.encompasserve.org>...
> >> In article <9fa75d42.0304221126.7112b7d5@posting.google.com>, softeng3456@netscape.net (soft-eng) writes:
>  
> >> > (C and later C++ style of type-safety turned out to
> >> > be good enough for real-world projects.)
> >> 
> >> Like Windows ?
>  
> > You don't like Windows, so you must be using
> > what?  Unix and X-Windows?  Written/extended/in Ada?
> 
> At this instant I am using VMS, which thankfully written mostly before
> the current C-mania started.  Even when they use C on Alpha and Itanium
> now, those who develop VMS tend to use the safer techniques they learned
> with Bliss in place of the null-terminated strings and other garbage that
> is encouraged by C.

You are living in a Jurassic Park world.

When VMS was first done, C was not on the lansdcape.
But as awareness of C grew, it was adopted very widely
within VMS Product Engineering.  Many of the products
in your VMS product-listing book were done in C!

But if you are complaining of null-terminated
strings, you couldn't have very well actually seen much
Bliss code now, could you?  It was hardly what you would
call a "safe" language.  Very far from it, it
didn't even have standard data types.  And you could
do all kinds of address arithmetic.  In fact, you 
had to be aware of memory address issues
all the time in Bliss. In Bliss, you don't
write (except when you mean it)

   A = B;

instead you write

   A = .B;

so the compiler knows that you want to store the contents of
memory address B into the contents of memory address A, (as
opposed to storing the memory address B into the contents of
memory address B, which is what it would happily do if
you forgot the dot!)  The rules got worse as you got into
procedure calls...  Soon you find yourself fixing bugs
involving wrong number of dots.  Bliss was certainly not
for the faint of heart!

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing a

[Dave Harris]

softeng3456@netscape.net (soft-eng) wrote (abridged):
> Note that his argument does not apply to C++ -- most
> C++ programmers only know a subset of the C++ syntax well.

Most compilers only implement a subset of it. I think there is only one 
compiler which claims to fully implement the "export" keyword, and that 
only in the last year or so. There's not much point learning syntax that 
doesn't work :-)

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Richard Riehle]

soft-eng wrote:

> So you are saying the Ada projects that succeeded were secret,
> and the ones that were not secret did not succeed?

Go to www.adaic.org.   There are plenty of case histories
of Ada projects that succeeded.    This includes a large
number of Air Traffic Control systems, commercial
aircraft avionics,  power industry systems,  manufacturing
process control systems,  transportation systems, the global
positioning satellites,  many communication satellites (Intelsat
VII, for one), and more.   They are not secret.   They are
simply not widely publicized.

Notice that these systems tend to be large-scale, safety-related,
and have long lifetimes.   The fact that you are personally ignorant
of Ada, its successes, and its benefits does not detract from its
history in the building of successful systems.   The fact that some
software developers have used Ada badly does not imply there
is a problem with the language.   Rather, it implies that those
developers are less competent than those who have used it
successfully.

I have seen people take on Ada projects and fail.   I have seen others
take on Ada projects and succeed beyond what they would have believed
possible when they first started.   Those who failed would probably
have failed using any other toolset or language.   More often than not,
the failure is due to stupid project management.  At least one huge
project in Ada failed because the people managing it were incompetent,
and Ada was their scapegoat.    All they could do, for years afterward,
was denigrate the language.   The programmers,  many of whom I know
quite well, knew the real cause was not Ada, but the people in charge
of making it work.

One well-known company, a manufacturer of office copying machines,
allowed one of its software development groups to build the embedded
software in Ada.   The group, and the manager, was amazed at their
success and decided they wanted to use Ada for future projects.  The
corporate level management of this company (a company already known
for its record of grabbing defeat from the jaws of victory) dictated that
all software would henceforth be written in C, this in spite of the
phenomenal success of Ada.

There are plenty of success stories outside the Department of Defense. In
fact, Ada in the hands of competent commercial developers may have been
more successful, if not more widespread, than in the weapon systems
area.

You may want to grouse about the language you seem not to understand,
and that is your right.   However, those of us who do understand it find
your deprecatory commentary to be the ranting of an uniformed person
whose opinion is based on nothing more than hot air or personal
failure.   When you look at the successes of those who do know how
to build software, you will find that Ada measures up quite well against
any competing technology.

Richard Riehle

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[AG]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:b8c07f$kot$1@msunews.cl.msu.edu...
>
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0304250937.36a7897e@posting.google.com...

> > Then you will be able to
> > make valid arguments on this.  E.g. how much of
> > the syntax of Java or VB the typical programmer
> > knows.
>
> I have work on projects in both VB and Java.  In both cases competent
> programmers only knew subsets of the language's syntax.  This subsetting
did
> not hamper the projects' success.

Just to take on the VB claim up there. How many
practicing VB programmers realise that this construct
(subject to typos and such) is a perfectly valid syntax:

select case true
case a = b
 ...
case a = c
 ...

[omittting the alphabet]

case a = z
...


It will even work if used.

>
> > but most of the syntax
> > is well understood by most programmers.

Is it?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

> Ah, so you are a troll.

Speaking of trolls, can someone other than
"Kent Paul Dolan" educate me on why we should
or should not keep cross-posting this to misc.misc ?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[AG]

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:YvmdnVI0i9K-YjSjXTWcrg@gbronline.com...
>
> > Ah, so you are a troll.
>
> Speaking of trolls, can someone other than
> "Kent Paul Dolan" educate me on why we should
> or should not keep cross-posting this to misc.misc ?

No idea. Is it where the bad bits go when they die?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Mike Silva]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304250448.5107afef@posting.google.com>...
> snarflemike@yahoo.com (Mike Silva) wrote in message news:<20619edc.0304240953.221ac70f@posting.google.com>...
> > softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304240503.54dbc5d1@posting.google.com>...
> > > 
> > > If Ada projects had actually succeeded in producing good quality
> > > software, it would have been everywhere today.
> > 
> > Yeah, I see your point.  Kind of like why nobody runs Windows anymore.
> > 
> > Mike
> 
> Works for me (plus several million other people.)
> 
> I even used Unix for years, even when it DIDN't
> work 1/10th as reliably as today's Windows.
> 
> It's good to see operating systems progress to
> the point where anybody off the streets can
> realiably use them and the only people complaing
> about the reliability are ones with axes to grind.

You are one funny guy!  In comedy a straight face is everything!  :-)

Gotta get back to those axes now...

Mike

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:YvmdnVI0i9K-YjSjXTWcrg@gbronline.com...
> Speaking of trolls, can someone other than
> "Kent Paul Dolan" educate me on why we should
> or should not keep cross-posting this to misc.misc ?

I thought it was so KPD could keep track of all the discussions he started
in different news groups.  At least that what he claimed before when he was
previously questioned about it.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Dale Stanbrough <dstanbro@bigpond.net.au> wrote in message news:<dstanbro-70C9D2.10010223042003@mec2.bigpond.net.au>...
> Robert A Duff wrote:
> 
> > > > Also, Ada proponents made much of its strong
> > > > typing.  But it was not at all novel or revolutionary.
> > > > It was a very common language idea
> > > > at that time, and then-popular Pascal had it too.
> > > 
> > > As a Pascal programmer I was thrilled to use Ada since the typing
> > > system is so much stronger than in Pascal.
> > 
> > Much more flexible, too.
> 
> If i'm asked to quickly describe Ada, I often say it is an
> industrialised Pascal...
> 

A better description would be "Pascal concepts taken to extreme".

Take highway lane dividing lines painted on the road, for
example.  These are a *good* idea and promote safety.  Now
give them to Jean Ichbiah, and instead of simple painted
lines, you would have brilliantly colered dividers that are
one foot high and electrically shock anybody who tries to cross
them except at approved lane crossing points.  It is not clear
that all concepts are helpful beyond a point.  In fact,
Ichbiah's dividers may deter safety, because many drivers
may accidentally run into the dividers, and once in a while
when to avoid running into the multi-car pileup you have
to change lanes *right now*, you wouldn't be able to do it.
All in the name of safety.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

snarflemike@yahoo.com (Mike Silva) wrote in message news:<20619edc.0304252116.621a4bf4@posting.google.com>...
> softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304250448.5107afef@posting.google.com>...
> > snarflemike@yahoo.com (Mike Silva) wrote in message news:<20619edc.0304240953.221ac70f@posting.google.com>...
> > > softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304240503.54dbc5d1@posting.google.com>...
> > > > 
> > > > If Ada projects had actually succeeded in producing good quality
> > > > software, it would have been everywhere today.
> > > 
> > > Yeah, I see your point.  Kind of like why nobody runs Windows anymore.
> > > 
> > > Mike
> > 
> > Works for me (plus several million other people.)
> > 
> > I even used Unix for years, even when it DIDN't
> > work 1/10th as reliably as today's Windows.
> > 
> > It's good to see operating systems progress to
> > the point where anybody off the streets can
> > realiably use them and the only people complaing
> > about the reliability are ones with axes to grind.
> 
> You are one funny guy!  In comedy a straight face is everything!  :-)

No, I am serious.  Many people who use computers today, simply
wouldn't have been able to, 20 years ago.  That's progress,
excpet if you have a personal reason to say "no, it's not.".

NOBODY except computer programmers complain about reliability
of Windows.  They might claim it's frustrating, but not
unreliable.

I think there used to be many complaints in this NG because Windows
crashed when somebody loaded a buggy device driver into it.
That kind of complaint HAS to come from a Computer Programmer
with an axe to grind.  Common people would NEVER complain
that Honda makes junk cars because they took out the batteries
and replaced it with experimental junk, and the car refused
to start!

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<b8c07f$kot$1@msunews.cl.msu.edu>...
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0304250937.36a7897e@posting.google.com...
> >
> > I think you need some actual experience with programmers
> > of different language.
> 
> I have such experience; do you?
> 
> > Then you will be able to
> > make valid arguments on this.  E.g. how much of
> > the syntax of Java or VB the typical programmer
> > knows.
> 
> I have work on projects in both VB and Java.  In both cases competent
> programmers only knew subsets of the language's syntax.  This subsetting did
> not hamper the projects' success.
> 
> > but most of the syntax
> > is well understood by most programmers.
> 
> Ha!  Just the other day I ran into a competent programmer that never
> realized that the {} defines a block in C that you can declare variables in.
> Sure he used {}'s all the time, but he didn't understand their flexibility
> until told him.  Still he produced acceptable work when he had to work in C.
> How many competent Java programmers don't know about the synchronize keyword
> because they never have writen a multithreaded application?
> 
> Also are you talking just about syntax or about both syntax and semantics?
> If you are only concerned with syntax then we have an uninteresting
> discussion, however, if you are interested in semantics, then almost all
> programmers only know of subset of each programming language's syntax.

I think you have to use common sense.

When I say most programmers know most of the syntax/semantics, it still
means most programmers might not know some of the syntax/semantics,
and some programmers might not know much of the syntax/semantics.
And we are comparing C vs Ada, so if you really want to be
fair, you have to compare how well the average programmer
knows the language details.  (But I think the key phrase is "really
want to be fair".  Do you?)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EA9E194.BAC2A2B6@adaworks.com>...
> soft-eng wrote:
> 
> > So you are saying the Ada projects that succeeded were secret,
> > and the ones that were not secret did not succeed?
> 
> Go to www.adaic.org.   There are plenty of case histories
> of Ada projects that succeeded.    This includes a large

Amazingly enough, I don't think there are any such sites for
C, C++, Java...

Instead, when you read my message and typed a respnse in your
newsreader, you provided testimony that these languages have been
used by actual people to provide actually useful software.

You may claim that these were all stupid people who couldn't
chose the right language for the tool, couldn't understand
Ada, or didn't realize they could have done a better job in Ada.

But given that Ada was not only available, but actively
supported by HUGE amounts of tax money, I may choose
to believe you are arguing from nothing but personal biases.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<b8a4jk$1v1t$1@msunews.cl.msu.edu>...
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0304240503.54dbc5d1@posting.google.com...
> > It's the other way around.  Software engineering is a fake field
> > full of charltans, simply because it stands on a false premise -- you
> > can take anybody and turn them into good disciplined programmers by
> > applications of certain principles.
> 
> This is blatantly false!  While there might be a good deal of people that
> claim to be software engineers that are charlatans, this fact (if true) does
> not discredit the actually field of software engineering.  Furthermore,
> your claim the software engineering stands upon a faulty premise is a
> strawman argument.
> 
> >The actual fact is, results
> > in software are to a *very* large part related to aptitude.  If you
> > can't hire well, the project is doomed no matter how many software
> > engineering principles you apply.
> 
> True, software engineering principles do not solve all problem (they don't
> claim too either), but they are not worthless either, and yes, you need
> competent people in order to succeed in anything.
> 
> > Once you have the right people,
> > engineering quality will appear;
> 
> Eventually--the point of software engineering is to facilitate and teach
> methodologies that help the right people work more effectively.
> 
> > you just need to make sure
> 
> I think your use of 'just' severely understates the difficulty of
> accomplishing the below
> 
> > the design is good, the management is good (which
> > often means not getting in the way of good quality),
> > there is good quality assurance, and such less-than-flashy things.
> 
> 
> > So there are no "engineering quality" correct choices.
> > Some languages with straight-jacket mentalities make people
> > think they are rigorous, disciplined tools that will
> > make quality magically appear.  That is deluded thinking.
> 
> Nothing can prevent deluded thinking.  Just like nothing can prevent people
> from making silly strawman arguments.

What strawman argument?

I presented my _conclusion_ regarding the underlying fallacy of
the various "Software Engineering Methodologies" and why
they have been continuously failing for more than two
decades, while tools and language improvements have
had amazingly great success in that timeframe.

I didn't say the Methodology people made this argument.  (That
would have made it a strawman.) I just saw it as the
underlying premise (which some Methodology
people may not even realize) which ends up turning
the Methodology people into charltans (because they are
forced to come up with more and more false reasons as to why
their Methodology didn't do what it claimed... as well
as newer improved claims...)

You may disagree with my conclusions, but questioning
my integrity because of that disagreement is disingenuous.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[AG]

"soft-eng" <softeng3456@netscape.net> wrote in message

> NOBODY except computer programmers complain about reliability
> of Windows.  They might claim it's frustrating, but not
> unreliable.

Really? How about some truck drivers who have
to be put on hold while the Windoze system
reboots, reloads, gets up to snuff and finally
prints that piece of paper that would have
taken about 20 seconds to write by hand?
Or the poor despatcher who wouldn't know
Windoze from bit-bucket except that he/she
needs to reboot it every half-hour or so just
to get rid of the frozen parts of it and get the
trucks moving.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

>>NOBODY except computer programmers complain about reliability
>>of Windows.  They might claim it's frustrating, but not
>>unreliable.
> 
> Really? How about some truck drivers who have
> to be put on hold while the Windoze system
> reboots, reloads, gets up to snuff and finally
> prints that piece of paper that would have
> taken about 20 seconds to write by hand?
> Or the poor despatcher who wouldn't know
> Windoze from bit-bucket except that he/she
> needs to reboot it every half-hour or so just
> to get rid of the frozen parts of it and get the
> trucks moving.

You people are talking about two different things.
There are TWO operating systems called Windows.

Windows 3.1 / 95 / 98 / ME crashes daily for many users

Windows NT / 2000 / XP is a completely different O.S.
It still crashes, but it is reliable enough for most
people.

Re: Using Ada for device drivers?

[Kent Paul Dolan]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote
> In comp.lang.ada Kaz Kylheku <kaz@ashi.footprints.net> wrote:

> : Ada is a high level assembly language like C, Pascal, Modula, PL/I and
> : so on. It's suitable only for stone age systems programming. It
> : doesn't matter at all which of these types of languages you use for
> : this kind of programming; the choice is purely pragmatic based on the
> : non-technical factors that make some languages more preferred than
> : other languages for programming some platforms.

Well, if that list were correct, Java, and every other third
generation
language would count as "high level assembly languages".  That term is
usually reserved for C, because C constructs typically map one for one
to assembly language instructions.  I seriously doubt that, say, Ada's
"rendezvous" construct has such a mapping.

> Wow. Generic polymorphic objects being high level assembly, and
> modern LISPs proudly presenting bit manipulations. Interesting times
> full of technical "arguments"...

Well, assembly languages are typically typeless, so _everything_ is
"polymorphic"; you aren't going to win many cigars with _that_
approach <grin>.

Tell me more about Lispy-Bits; sounds like a breakfast cereal.

xanthian.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Frank J. Lhota]

"Kaz Kylheku" <kaz@ashi.footprints.net> wrote in message
news:cf333042.0304241530.1e32ec98@posting.google.com...
> softeng3456@netscape.net (soft-eng) wrote in message
news:<9fa75d42.0304240950.45114a39@posting.google.com>...
> Although Ada may be wonderful for device drivers in principle, in some
> platforms you will only find the hooks, toolchain support and run-time
> support for writing your driver in C. Boo hoo; you may have to trade
> one idiotic language for another, what a loss!

You're right. From now on, I'm going to write all my drivers in Smalltalk.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Frank J. Lhota]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304260649.366530c5@posting.google.com...
> NOBODY except computer programmers complain about reliability
> of Windows.  They might claim it's frustrating, but not
> unreliable.

Complains about Windows hangs and reboots have made it to TV shows such as
"Saturday Night Live", comic strips like "Dilbert" and "Cathy", and even the
pages of "Mad" magazine. It would be comforting for us Software Engineers to
believe that the general public does not notice our errors, but I assure you
that would be delusional thinking.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Mike Silva]

"AG" <ang@xtra.co.nz> wrote in message news:<NXCqa.32967$mZ4.383971@news.xtra.co.nz>...
> "soft-eng" <softeng3456@netscape.net> wrote in message
> 
> > NOBODY except computer programmers complain about reliability
> > of Windows.  They might claim it's frustrating, but not
> > unreliable.
> 
> Really? How about some truck drivers who have
> to be put on hold while the Windoze system
> reboots, reloads, gets up to snuff and finally
> prints that piece of paper that would have
> taken about 20 seconds to write by hand?
> Or the poor despatcher who wouldn't know
> Windoze from bit-bucket except that he/she
> needs to reboot it every half-hour or so just
> to get rid of the frozen parts of it and get the
> trucks moving.

Obviously they're only drivers and dispatchers *by day*.  At night, in
the privacy of their own homes, I'll bet they're *computer
programmers*!  They can try to hide it, but Windows knows!

Mike

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Vinzent Hoefler]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> wrote:

>It would be comforting for us Software Engineers to
>believe that the general public does not notice our errors, but I assure you
>that would be delusional thinking.

At least we have an excuse:

<http://www.thinkgeek.com/tshirts/frustrations/5765/>

Yes, I wear this at work. :-P


Vinzent.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Steve]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304260644.764b8674@posting.google.com...
[snip]
>
> A better description would be "Pascal concepts taken to extreme".
>
> Take highway lane dividing lines painted on the road, for
> example.  These are a *good* idea and promote safety.  Now
> give them to Jean Ichbiah, and instead of simple painted
> lines, you would have brilliantly colered dividers that are
> one foot high and electrically shock anybody who tries to cross
> them except at approved lane crossing points.  It is not clear
> that all concepts are helpful beyond a point.  In fact,
> Ichbiah's dividers may deter safety, because many drivers
> may accidentally run into the dividers, and once in a while
> when to avoid running into the multi-car pileup you have
> to change lanes *right now*, you wouldn't be able to do it.
> All in the name of safety.

I prefer a different analogy.

Imagine having 100 different electronics devices, all which have 30 pin
ribbon cable connections.  Some of the devices have different pinouts, and
connecting two devices with different pinouts can either cause damage to the
devices or cause the devices to malfunction.

The typing mechanism in Ada is like keying all of the connectors such that
it is impossible to connect two devices in a way that will cause damage.

BTW: A better place to take this discussion would be team-ada@acm.org.

Steve
(The Duck)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[AG]

"Mike Silva" <snarflemike@yahoo.com> wrote in message
news:20619edc.0304261803.5d26f40e@posting.google.com...

> Obviously they're only drivers and dispatchers *by day*.  At night, in
> the privacy of their own homes, I'll bet they're *computer
> programmers*!

Well, no, not really :) In fact that almost always happens in
the middle of the night or wee hours of the morning (when
do you think the trucks get loaded for delivery?)

Unfortunately, most programmers and/or sys admins
have a bad habit of liking to sleep at that sort of time.

Which brings us back to the question of reliability:

- Option one: have a stand-up on-call professional
support with a pager available 24 by 7. Sort of
what fire brigades do [that will cost of course]

- Option two: have a reliable system with the chance
of catastrophic failure so low that you (or your clients)
are willing to risk it just on statistical basis.

Which one would you choose if you had to fund it?

[Besides, you've said "I'll bet". What do you bet?]

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kent Paul Dolan]

softeng3456@netscape.net (soft-eng) wrote:

> No, I am serious.

How sad for you then.

> Many people who use computers today, simply wouldn't have been
> able to, 20 years ago.  That's progress, exc[ep]t if you have
> a personal reason to say "no, it's not.".

Except that you are revising history beyond recognition: the
vi() editor was written for the use of secretaries, and it is
lots more than 20 years old. Visicalc, the first spreadsheet,
was a tool for managers, and it is over 20 years old.  Computers
have been used by non-programmer types pretty much since their
inception; we programmers have always worked as a service class
to the needs of end users, and there have always been end users
who were not computer sophisticates.

> NOBODY except computer programmers complain about reliability
> of Windows.  They might claim it's frustrating, but not
> unreliable.

That's not true either; my bookkeeper/secretary/billing clerk
wife regaled me with horror stories of time lost to Windows and
other M$ "productivity" tools for over a decade, and started
that period by saying "and thus it has always been". Among the
haters of MS-Windows, clerical types probably have pride of
place far ahead of mere knowledgable programmers, the latter
having the advantage of knowing not merely that MS-Windows is
unfit for use, but also why that is so, and so are not
inconsolable like the clerks.

> I think there used to be many complaints in this NG because
> Windows crashed when somebody loaded a buggy device driver
> into it.  That kind of complaint HAS to come from a Computer
> Programmer with an axe to grind.  Common people would NEVER
> complain that Honda makes junk cars because they took out the
> batteries and replaced it with experimental junk, and the car
> refused to start!

Except that what is really happening with MS-Windows has nothing
to do with "buggy device drivers" and everything to do with "bad
M$ OS writer design decisions that put the device drivers inside
the OS address space".  Your analogy is flawed, it is more like
Hondas refusing to start if the driver wears plaids with
stripes.

xanthian.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Robert A Duff]

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccadeiglef.fsf@shell01.TheWorld.com...
> > Really!?  I think of array slicing as a pretty minor feature of Ada,
> > which causes a lot of trouble for compiler writers, that could be
> > dispensed with.  After all, you could write a function that grabs those
> > components.
> 
> > I'm thinking particularly of slices as L-values.  Do you ever use that?
> 
> Usually I pass slices of arrays as parameters to procedures and functions.
> For example Ada.Strings.Fixed would be far less convenient without the
> ability to pass part of an array to a procedure or function.  As for
> L-values I assume you mean something like
> 
> x(1..80) := (others => y);
> ?
> If so, I use slices less often for that purpose.

Yes, by "L-value", I meant on the left-hand side of an assignment, or an
'out' parameter, or similar things.  If X(1..80) is just syntactic sugar
for a function call Slice(X, 1, 80) or Slice(X, First => 1, Last => 80),
then it would be little trouble for the Ada compiler.  And I would think
it would be but a minor convenience for the programmer.

But when slices are used as L-values, there are various interactions
with packing and whatnot that cause compiler complexity.

- Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Robert A Duff]

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> > "Chad R. Meiners" <crmeiners@hotmail.com> writes:
> >> Array slicing is a wonderfully useful feature.  I use this feature in almost
> >> every program of mine.
> > 
> > Really!?  I think of array slicing as a pretty minor feature of Ada,
> > which causes a lot of trouble for compiler writers, that could be
> > dispensed with.  After all, you could write a function that grabs those
> > components.
>  
> > I'm thinking particularly of slices as L-values.  Do you ever use that?
> 
> Ask everybody who likes MATLAB:
> 
> in other words "yes".

Sorry; I know nothing of MATLAB.  Perhaps you could give an example of
why array slicing (as an L-value!) is so useful.  I don't doubt that it
is (in MATLAB and Fortran).

> And it's in Fortran 90/95, for similar reasons.  

Well, Fortran's array-slicing capabilities are more powerful than Ada's.
My comment that slicing-as-L-value is a frill was specific to Ada.

>...Note that F90 was
> designed after Ada.

The latest version of Ada was designed in the period 1990 to 1995 or so.
I would think F90 is roughly the same vintage.

> Getting arrays right definitely helps lower bugs, because
> off-by-one counting in iteration are frequent source of
> errors.

Indeed.

- Bob

P.S. Sorry, I'm disobeying your followup-to.  I'm reading this in
comp.lang.ada, and would otherwise never see replies.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Robert A Duff]

Wesley Groleau <wesgroleau@despammed.com> writes:

> > I'm thinking particularly of slices as L-values.  Do you ever use that?
> 
> I did that a lot in Ada days, too.

An example, please?

- Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Robert A Duff]

xanthian@well.com (Kent Paul Dolan) writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> > "Chad R. Meiners" <crmeiners@hotmail.com> writes:
> 
> >> Array slicing is a wonderfully useful feature.  I use this feature
> in almost
> >> every program of mine.
> 
> > Really!?  I think of array slicing as a pretty minor feature of Ada,
> > which causes a lot of trouble for compiler writers, that could be
> > dispensed with.  After all, you could write a function that grabs those
> > components.
> 
> > I'm thinking particularly of slices as L-values.  Do you ever use that?
> 
> It might be "minor" now, but if Ada is ever to stand beside Fortran as
> a programming language for supercomputers, it is awfully nice that
> this much of the needed semantics are "already in there"; they were a
> huge shock when they first hit Fortran all in a lump.

I'm afraid that Ada's array-slicing capabilities are too restrictive
(compared to Fortran) to qualify for the "already in there".

> [And by the way, since I've drifted away from Ada for lack of job
> prospects for an Ada beginner without a current security clearance,

Sorry to hear that.  I've been working on-and-off on Ada-related stuff
for many years, with no security clearance.  It's not just military
stuff, you know.

>... is
> there any effort underway to add the syntactic sugar for supercomputer
> programming to Ada in an upcoming standard's language revision,

No, as far as I know, there is no serious work underway for such
syntactic sugar.  (Or, as Dr Chaos points out -- it's really semantic
sugar.)  Some proposals were made during the development of Ada 95.
It wouldn't take much...

But:

>... or is
> Ada down to "don't rock the boat" editorial cleanup standards (that
> would eventually doom the language) for the foreseeable future, or is
> there some big worthwhile effort but in another direction?]

No, it's not in "don't rock the boat" mode -- changes to Ada are being
made in other directions.

- Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing a

[Hyman Rosen]

Dave Harris wrote:
  > Most compilers only implement a subset of it. I think there is only one
> compiler which claims to fully implement the "export" keyword, and that 
> only in the last year or so. There's not much point learning syntax that 
> doesn't work :-)

The "export" concept was a pure invention of the standardization
committee, designed (poorly) to assuage those interests who demanded
some form of separate compilation of templates. The people who finally
implemented it think it's useless, but some of the rest of us aren't
so sure.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Eric G. Miller]

In article <d%Jqa.34014$mZ4.393336@news.xtra.co.nz>, AG wrote:
> "Mike Silva" <snarflemike@yahoo.com> wrote in message
> news:20619edc.0304261803.5d26f40e@posting.google.com...
> 
>> Obviously they're only drivers and dispatchers *by day*.  At night, in
>> the privacy of their own homes, I'll bet they're *computer
>> programmers*!
> 
> Well, no, not really :) In fact that almost always happens in
> the middle of the night or wee hours of the morning (when
> do you think the trucks get loaded for delivery?)

As a former truck driver, I have to say that loading/unloading occurs
all around the clock.  In my experience, it was as likely to be 3am as
1pm.  It really depends on the type of shipper and receiver, the type of
"trucks" your talking about (van, refrigerated van, flatbed, container, 
etc.), the type of load, and the distance involved.  There are a number
of niches in the trucking world.

Also, a number of larger shippers tend to have possession of a rotating
stock of various trucking companies' trailers.  In those cases, drivers
are often not present when the vans get loaded or unloaded.  It's sort
of an extended warehouse system.  Just In Time and all that...  The
driver shows up with an empty, exchanges it for a loaded trailer and is
gone in 15 minutes or so.

> Unfortunately, most programmers and/or sys admins
> have a bad habit of liking to sleep at that sort of time.
> 
> Which brings us back to the question of reliability:
> 
> - Option one: have a stand-up on-call professional
> support with a pager available 24 by 7. Sort of
> what fire brigades do [that will cost of course]
> 
> - Option two: have a reliable system with the chance
> of catastrophic failure so low that you (or your clients)
> are willing to risk it just on statistical basis.

The company I worked for ran much of their logistics system off an IBM 
main frame and trucks were satellite dispatched.  The shipper was 
responsible for preparing the bill of lading by whatever means.  I
suspect the company had 24/7 technical support (considering they had
24/7 dispatching).  I don't think this is unusual among the larger
freight haulers...  Smaller or local/regional companies may not need
such a system if the truck movement patterns are less dynamic than an
over-the-road company.  I haven't seen any satellite dispatched logging
trucks, for instance.

-- 
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

Robert A Duff wrote:
>>>I'm thinking particularly of slices as L-values.  Do you ever use that?
>>
>>I did that a lot in Ada days, too.
> 
> An example, please?

Replacing a section of an array with other values
instead of looping through it assigning one element
at a time.

Often, I also used the trick of declaring an
array that was actually a renaming of a slice
from another array.  The new name can be used
on either side of an assignment.

I have also often used a slice as an actual
for an out-mode parameter.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

Option three.  Have a redundant system, hoping that
only one will crash at a time.  Then network them
all together, so that the one that crashes will
take out the rest of them.  :-)

Re: [off-topic] electronic mismatch

[Wesley Groleau]

> Imagine having 100 different electronics devices, all which have 30 pin
> ribbon cable connections.  Some of the devices have different pinouts, and
> connecting two devices with different pinouts can either cause damage to the
> devices or cause the devices to malfunction.

I gave someone a Macintosh Quadra and told them
how to start it up.  Instead, they called someone
else, who brought over a Windows boot floppy and
a printer.  Plugged the printer into the external
hard drive port and put Windows 95 in the floppy
drive, and turned on the power.

Of course it wouldn't do anything, so they stuck
it out in the cabin.

After it went through a winter in the unheated
cabin, I rescued it and took it home.  It still
works!

It still pukes every time it sees a floppy disk,
but the SCSI bus was not damaged.  :-)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Peter Hermann]

In comp.lang.ada Richard Riehle <richard@adaworks.com> wrote:
Richard,
thank you for your contribution which found the way into my 
advocacy records.
BTW, it's a good feeling to use that wonderful kill-file mechanism.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Yes, by "L-value", I meant on the left-hand side of an assignment, or an
> 'out' parameter, or similar things.  If X(1..80) is just syntactic sugar
> for a function call Slice(X, 1, 80) or Slice(X, First => 1, Last => 80),
> then it would be little trouble for the Ada compiler.

Do you mean that Slice (...) would always have a copy semantics? 

> And I would think it would be but a minor convenience for the programmer.

> But when slices are used as L-values, there are various interactions
> with packing and whatnot that cause compiler complexity.

Isn't it already there because array elements can be also L-values? Or that 
objects of some types have to be constructed in-place? I mean, with or 
without slices, one cannot get rid of this problem anyway.

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

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[AG]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccn0ibnc5e.fsf@shell01.TheWorld.com...
> Wesley Groleau <wesgroleau@despammed.com> writes:
>
> > > I'm thinking particularly of slices as L-values.  Do you ever use
that?
> >
> > I did that a lot in Ada days, too.
>
> An example, please?

I can't say that I used that "a lot"
but one example does come to mind:
An existing interface which requires
a string with a number of (almost
unrelated) fields which must be
placed at given offsets with given
lengths. Since the fields are next
to non-related except that they
must fit into the same string it's
quite a bit tempting to implement
it as:

X(L1..H1) := F1;
X(L2..H2) := F2; etc

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

xanthian@well.com (Kent Paul Dolan) wrote in message news:<a3eaa964.0304262224.264593d4@posting.google.com>...
> softeng3456@netscape.net (soft-eng) wrote:
> 
> > No, I am serious.
> 
> How sad for you then.
> 
> > Many people who use computers today, simply wouldn't have been
> > able to, 20 years ago.  That's progress, exc[ep]t if you have
> > a personal reason to say "no, it's not.".
> 
> Except that you are revising history beyond recognition: the
> vi() editor was written for the use of secretaries, and it is

And you are accusing me of revising history!

When vi was the standard editor and unix was
the standard workstation, there was a thriving market
for specialized secretary-machines.  These used to be
called "word processors" and came with rulers
along the top etc.  DEC had them, Wang had
them (it was their specialty), many other companies did.

The term "word processor" slowly changed
its meaning and came to mean software,
because it became no longer necessary to
purchase specialized hardware for word processing
for use by secretaries.

> That's not true either; my bookkeeper/secretary/billing clerk
> wife regaled me with horror stories of time lost to Windows and
> other M$ "productivity" tools for over a decade, and started
> that period by saying "and thus it has always been". Among the
> haters of MS-Windows, clerical types probably have pride of
> place far ahead of mere knowledgable programmers, the latter
> having the advantage of knowing not merely that MS-Windows is
> unfit for use, but also why that is so, and so are not
> inconsolable like the clerks.

If people truly saved less time than they gained, they
would not use PCs.

It is always fun to joke about something or the
other.  But that still doesn't actually mean
any given set of "ethnic"s all behave the same way.

Btw,  emacs is better than vi :-)

(Well, at one point I used to think so.  Haven't bothered
with either since editing became so much simplified
that any tom-dick-harry's editor is highly
usable compared to either vi or emacs,
except for those who are religious about these things,
or highly un-retrainable.)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Mike Silva]

"AG" <ang@xtra.co.nz> wrote in message news:<d%Jqa.34014$mZ4.393336@news.xtra.co.nz>...
> "Mike Silva" <snarflemike@yahoo.com> wrote in message
> news:20619edc.0304261803.5d26f40e@posting.google.com...
> 
> > Obviously they're only drivers and dispatchers *by day*.  At night, in
> > the privacy of their own homes, I'll bet they're *computer
> > programmers*!
> 
> Well, no, not really :) In fact that almost always happens in
> the middle of the night or wee hours of the morning (when
> do you think the trucks get loaded for delivery?)
> 
> Unfortunately, most programmers and/or sys admins
> have a bad habit of liking to sleep at that sort of time.
> 
> Which brings us back to the question of reliability:
> 
> - Option one: have a stand-up on-call professional
> support with a pager available 24 by 7. Sort of
> what fire brigades do [that will cost of course]
> 
> - Option two: have a reliable system with the chance
> of catastrophic failure so low that you (or your clients)
> are willing to risk it just on statistical basis.
> 
> Which one would you choose if you had to fund it?

A lot of people would argue that the reliable system costs no more to
develop, when you factor in the higher costs of mid-stream redesign,
longer debugging and more customer support for the unreliable version.
 Then there's also the damage to the vendor's reputation, which can
translate into lost sales when it's time to buy new software.
> 
> [Besides, you've said "I'll bet". What do you bet?]

Hold on, I think I've got some change here in my car ashtray...  (Or
how about Easter candy that the kids got too much of and we're looking
for an excuse to throw out now?)  I mean, really, this is only usenet!
:)

Mike

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Randy Brukardt]

Robert A Duff wrote in message ...
>Yes, by "L-value", I meant on the left-hand side of an assignment, or
an
>'out' parameter, or similar things.  If X(1..80) is just syntactic
sugar
>for a function call Slice(X, 1, 80) or Slice(X, First => 1, Last =>
80),
>then it would be little trouble for the Ada compiler.  And I would
think
>it would be but a minor convenience for the programmer.
>
>But when slices are used as L-values, there are various interactions
>with packing and whatnot that cause compiler complexity.


I certainly agree with that, but slices as L-Values is one of the more
useful features of Ada, because they allow you to do efficient
operations safely that otherwise would have to be done much more
verbosely AND inefficiently.

Virtually any string manipulation needs L-Value slices. For instance, I
constructed a normalized URL by allocating a large string for the URL,
and then copying in the parts as they are identified:

   ...
   Len := Last - First + 1;
   if Next_Len > Final_URL'Last then Set_Bad_Command_Result; return; end
if;
   Final_URL(Next .. Next+Len) := Info.Command(First .. Last);
   ...

(Note that the check is needed only if we want to do something other
than raise Constraint_Error if the URL is excessively long. In this
case, we want to return a Bad_Command result to the client.)

Another example is using slices to expand a buffer (the Janus/Ada
compiler does this a lot):

     declare
           New_Buffer : Buffer_Type;
     begin
           New_Buffer := new Buffer_Contents(1 .. Buffer'Last +
Expansion_Amount);
           New_Buffer (1 .. Buffer'Last) := Buffer.all;
           Free (Buffer);
           Buffer := New_Buffer;
     end;

This generates some checking (all of which can be eliminated) and then
memory-to-memory copying, without any extra overhead. In theory, a
compiler could optimize a loop the same way, but I've never seen it done
for a case like this one (where both items are access to unconstrained
arrays, so there is a lot of descriptor manipulation and virtually all
of the values are not known at compile time). Eliminating the checking
in a loop is very hard (it requires algebraic propogation), and that's
necessary (but not sufficient) to convert the loop into direct memory
operations.

                   Randy.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kent Paul Dolan]

softeng3456@netscape.net (soft-eng) wrote:
> xanthian@well.com (Kent Paul Dolan) wrote:
>> softeng3456@netscape.net (soft-eng) wrote:

>>> No, I am serious.

>> How sad for you then.

>>> Many people who use computers today, simply wouldn't have been
>>> able to, 20 years ago.  That's progress, exc[ep]t if you have
>>> a personal reason to say "no, it's not.".

>> Except that you are revising history beyond recognition: the
>> vi() editor was written for the use of secretaries, and it is

> And you are accusing me of revising history!

> When vi was the standard editor and unix was
> the standard workstation, there was a thriving market
> for specialized secretary-machines.

So? It is still the case that your paragraph to which I disagreed
is plain wrong, and for the reasons I said: computers usable by
low skilled clerical employees have been the norm since the earliest
commercial computers: the IBM 1620 on which I programmer in 1961 was
primarily used by office staff, not programmers; so there isn't some
large class of people who have suddenly become capable of using
computers in the past 20 years that were not capable of so doing before,
invaliating your claim.

Please attempt to use sane methods of argumentation; this kind is
tedious, as you continue to trim away material which counters the
points you then insist on making incorrectly again and again.

xanthian.

There is a small class, however; computers catering especially to the
severely handicapped have probably mostly appeared in the last 20 years.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[The Ghost In The Machine]

In comp.lang.java.advocacy, Wesley Groleau
<wesgroleau@despammed.com>
 wrote
on Sun, 27 Apr 2003 16:40:55 -0500
<wBSdnTfmO5TK0zGjXTWcog@gbronline.com>:
> Option three.  Have a redundant system, hoping that
> only one will crash at a time.  Then network them
> all together, so that the one that crashes will
> take out the rest of them.  :-)
> 

I'll admit I wonder about this option, but, if one has
a system that's down 10% of the time (90% uptime), one
could in theory put 5 of those systems in back of a perfect
loadserver (well, OK, it's only a theory!) and get 99.999%
uptime -- the target for one of Microsoft's campaigns some
time back.

I think Windows can manage that, even if it crashes 3-4
times every 8-hour day: assuming a full reboot takes 2
minues, that would translate into 8 minutes down, out of
480 minutes, or a 98.3% uptime.  Of course, the user
having to use such a system may feel 90% aggravated... :-)

Of course, if one system can take out the webfarm,
all hope is lost.  And Microsoft has introduced a new
(or maybe not so new) idea: the "webgarden".  This idea
is to webfarms as threads are to processes, apparently.
I'll leave the possible problems as an exercise for the
interested reader... :-)

ObAda: I'll admit the closest I've come thereto is Modula-2,
       and the closest I've come coding is Pascal.

ObJava: JBOSS and Tomcat look like a webgarden to me, for example. :-)
        Apache does, too, as it can support multiple virtual hosts.

-- 
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Robert A Duff wrote:
> 
> > Yes, by "L-value", I meant on the left-hand side of an assignment, or an
> > 'out' parameter, or similar things.  If X(1..80) is just syntactic sugar
> > for a function call Slice(X, 1, 80) or Slice(X, First => 1, Last => 80),
> > then it would be little trouble for the Ada compiler.
> 
> Do you mean that Slice (...) would always have a copy semantics? 

Yes.

> > And I would think it would be but a minor convenience for the programmer.
> 
> > But when slices are used as L-values, there are various interactions
> > with packing and whatnot that cause compiler complexity.
> 
> Isn't it already there because array elements can be also L-values? Or that 
> objects of some types have to be constructed in-place? I mean, with or 
> without slices, one cannot get rid of this problem anyway.

No, I think slices-as-L-values cause compiler complexity beyond what
components-as-L-values do.

- Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

The Ghost In The Machine wrote:
> In comp.lang.java.advocacy, Wesley Groleau
> <wesgroleau@despammed.com>
>  wrote
> on Sun, 27 Apr 2003 16:40:55 -0500
> <wBSdnTfmO5TK0zGjXTWcog@gbronline.com>:
> 
>>Option three.  Have a redundant system, hoping that
>>only one will crash at a time.  Then network them
>>all together, so that the one that crashes will
>>take out the rest of them.  :-)
> 
> I'll admit I wonder about this option, but, .....
> 
> I think Windows can manage that, even if it crashes 3-4
> times every 8-hour day: assuming a full reboot takes 2

Even Windows 95/98 wasn't that bad on average (people
like me who make their machines work hard would probably
get crashes more than once a day).  But Windows NT/2000
are far more reliable.  HOWEVER, my comment was an allusion
to an actual event.  Someone will probably post a URI, but
here's the executive summary:  A program on a Windows NT
machine did a divide by zero.  The exception was propagated
to all other machines on the Windows LAN, and they all crashed.
Unfortunately, one of the undesirable results of this was
that the ship that was entrusted to these machines had to
be towed back to port.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Robert A Duff wrote:
>> 
>> > Yes, by "L-value", I meant on the left-hand side of an assignment, or
>> > an
>> > 'out' parameter, or similar things.  If X(1..80) is just syntactic
>> > sugar for a function call Slice(X, 1, 80) or Slice(X, First => 1, Last
>> > => 80), then it would be little trouble for the Ada compiler.
>> 
>> Do you mean that Slice (...) would always have a copy semantics?
> 
> Yes.

Ooch

>> > And I would think it would be but a minor convenience for the
>> > programmer.
>> 
>> > But when slices are used as L-values, there are various interactions
>> > with packing and whatnot that cause compiler complexity.
>> 
>> Isn't it already there because array elements can be also L-values? Or
>> that objects of some types have to be constructed in-place? I mean, with
>> or without slices, one cannot get rid of this problem anyway.
> 
> No, I think slices-as-L-values cause compiler complexity beyond what
> components-as-L-values do.

I suppose it is not a big problem to generate a loop, so it must be 
something else. Maybe you mean things like optimization of an assignment 
into a memory copy if no element finalization required? But we do need 
that! Randy Brukardt have already mentioned a buffer extension technique 
based on slices. I am using it all the time in generic containers in hope 
that for non-controlled types it will become just a memory copy. Now let we 
remove slices. Then to achive the same level of optimization, the compiler 
has to be able to redice a hand-written loop (+unpack/pack rubbish 
generated) to a memory copy. Is it easier?

From a global perspective. To me slices is a good example of how things 
*should* be done. I mean the issues like:

- unconstrained string vs. constrained string;
- unconstrained discriminated object vs. a dynamically constrained one;
- class-wide object vs. specific one

Only strings and slices have it right. The dope is used only when necessary. 
On contrary discriminants and tags are always there. Which makes, for 
instance, the problem of measurement units unsolvable. From this point of 
view removing slices would be a step back.

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

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Richard Riehle]

soft-eng wrote:

> Richard Riehle <richard@adaworks.com> wrote in message news:<3EA9E194.BAC2A2B6@adaworks.com>...
> > soft-eng wrote:
> >
> > > So you are saying the Ada projects that succeeded were secret,
> > > and the ones that were not secret did not succeed?
> >
> > Go to www.adaic.org.   There are plenty of case histories
> > of Ada projects that succeeded.    This includes a large
>
> Amazingly enough, I don't think there are any such sites for
> C, C++, Java...

So ....

> Instead, when you read my message and typed a respnse in your
> newsreader, you provided testimony that these languages have been
> used by actual people to provide actually useful software.

I also provided testimony that Ada has been used by intelligent
developers for successful projects.  In fact, there are so many
successful Ada projects that anyone who suggests it is useless
for developing software is simply not paying attention.

> You may claim that these were all stupid people who couldn't
> chose the right language for the tool, couldn't understand
> Ada, or didn't realize they could have done a better job in Ada.

People select programming languages for all kinds of reasons,
few of which have to do with the quality of the language.

> But given that Ada was not only available, but actively
> supported by HUGE amounts of tax money, I may choose
> to believe you are arguing from nothing but personal biases.

I am arguing, if you please, from personal/professional experience
with the language.  I am also arguing from the many successes
I know about.

As for that "HUGE amounts of tax money" much it was wasted
by bureaucrats shuffling paper around.   Few of them knew anything
about software.  The successes of Ada have been in spite of, not
because of, support from the government.   One reason why Ada is
enjoying a resurgence of interest in some quarters is because the
government is no longer mandating it.   People who use it now
are doing so because they see its virtues, not because they
are required to do so.

Those who have adopted Ada, in recent years, are enjoying its
benefits.  Those who have abandoned it are not doing  all that
well with, for example, C++ (a horrid language full of surprises
and gotchas).

Many of us continue to prefer Ada precisely because it is fun,
easy to use, and easy to develop software.   There are aspects
of the language that do not come easily.    However, most of
the language does come easily, and the advanced features are
not necessary for someone to enjoy it.

I am currently teaching an Ada class for a group of graduate
students.   Their responses, so far (many with C++ and Java
background), are quite favorable.    We write programs for
Windows, as well as for other environments in this class.

Sorry you had such bad Ada training.   There was a lot of that
going around at one time, perpetrated by people who simply
failed to understand some elementary ideas and made them
more complicated than necessary.

Richard Riehle

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Will]

Deep blue. Raw hardware power with some user interface written in C.
Try to beat that with Ada.




softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0304240950.45114a39@posting.google.com>...
> Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3EA7E0E3.8020407@crs4.it>...
> > [ FUT comp.lang.ada ]
> > 
> > soft-eng wrote:
> > 
> > > But if you
> > > had to develop device drivers for a living, and if
> > > the language was truly your choice, would you chose Ada as
> > > the language?
> > 
> > Yes.
> > 
> 
> Hmmm.  Very interesting.
> 
> But I am sure you folks couldn't come up with some similar
> pronouncements for AI as well.  How many people out there who have
> years and years of Artificial Intelligence experience and
> who really think Ada is the best language for this purpose?
> 
> Any at all?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

Apples and oranges, Will.

The interesting comparison would be to give both sides the same hardware
power, and do the UI software in Ada vs. C.

"Will" <wv9557@yahoo.com> wrote in message
news:4a885870.0304291909.300765f@posting.google.com...
> Deep blue. Raw hardware power with some user interface written in C.
> Try to beat that with Ada.
>
>
>
>
> softeng3456@netscape.net (soft-eng) wrote in message
news:<9fa75d42.0304240950.45114a39@posting.google.com>...
> > Jacob Sparre Andersen <sparre@crs4.it> wrote in message
news:<3EA7E0E3.8020407@crs4.it>...
> > > [ FUT comp.lang.ada ]
> > >
> > > soft-eng wrote:
> > >
> > > > But if you
> > > > had to develop device drivers for a living, and if
> > > > the language was truly your choice, would you chose Ada as
> > > > the language?
> > >
> > > Yes.
> > >
> >
> > Hmmm.  Very interesting.
> >
> > But I am sure you folks couldn't come up with some similar
> > pronouncements for AI as well.  How many people out there who have
> > years and years of Artificial Intelligence experience and
> > who really think Ada is the best language for this purpose?
> >
> > Any at all?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EAF3464.9E06145F@adaworks.com>...
> 
> Sorry you had such bad Ada training.   There was a lot of that
> going around at one time, perpetrated by people who simply
> failed to understand some elementary ideas and made them
> more complicated than necessary.

Do you really think my views on Ada are a result of
bad training?

I suppose that is a very fair representation of the
analysis and insight capabilities of those who
choose to espouse the cause you are championing here...

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Will]

Now if you want a challenge try to write an Ada chess program to beat
GNU chess. It's all C.

"John R. Strohm" <strohm@airmail.net> wrote in message news:<416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net>...
> Apples and oranges, Will.
> 
> The interesting comparison would be to give both sides the same hardware
> power, and do the UI software in Ada vs. C.
> 
> "Will" <wv9557@yahoo.com> wrote in message
> news:4a885870.0304291909.300765f@posting.google.com...
> > Deep blue. Raw hardware power with some user interface written in C.
> > Try to beat that with Ada.
> >
> >
> >
> >
> > softeng3456@netscape.net (soft-eng) wrote in message
>  news:<9fa75d42.0304240950.45114a39@posting.google.com>...
> > > Jacob Sparre Andersen <sparre@crs4.it> wrote in message
>  news:<3EA7E0E3.8020407@crs4.it>...
> > > > [ FUT comp.lang.ada ]
> > > >
> > > > soft-eng wrote:
> > > >
> > > > > But if you
> > > > > had to develop device drivers for a living, and if
> > > > > the language was truly your choice, would you chose Ada as
> > > > > the language?
> > > >
> > > > Yes.
> > > >
> > >
> > > Hmmm.  Very interesting.
> > >
> > > But I am sure you folks couldn't come up with some similar
> > > pronouncements for AI as well.  How many people out there who have
> > > years and years of Artificial Intelligence experience and
> > > who really think Ada is the best language for this purpose?
> > >
> > > Any at all?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[John R. Strohm]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0304300412.3c9f8157@posting.google.com...
> Richard Riehle <richard@adaworks.com> wrote in message
news:<3EAF3464.9E06145F@adaworks.com>...
> >
> > Sorry you had such bad Ada training.   There was a lot of that
> > going around at one time, perpetrated by people who simply
> > failed to understand some elementary ideas and made them
> > more complicated than necessary.
>
> Do you really think my views on Ada are a result of
> bad training?
>
> I suppose that is a very fair representation of the
> analysis and insight capabilities of those who
> choose to espouse the cause you are championing here...

Why don't you *tell* us where your views on Ada come from?

So far, you have said a great deal that suggests that you have NO actual
experience with Ada.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

xanthian@well.com (Kent Paul Dolan) wrote in message news:<a3eaa964.0304281225.3a52ebce@posting.google.com>...

> Please attempt to use sane methods of argumentation; this kind is
> tedious, as you continue to trim away material which counters the
> points you then insist on making incorrectly again and again.

I don't read tons of quoted material and I assume others
don't either -- your insistence that every triviality
be addressed, would make the thread extremely boring.
It is very much like the people who insist that
no off topic items ever be discussed.

So rather than refrain from trimming material, I would prefer
to trim it down to - in good faith - what I see is your objection.

You are saying that you have proved wrong the paragraph:

  Many people who use computers today, simply wouldn't have been
  able to, 20 years ago.

by claiming vi was written for secretaries.

This makes little sense to me, and I even fail to see
any serious argument here.  To remind you of the
actualities of history, I even mentioned the
Wang word processors in case you had forgotten.
But it seems you didn't forget, you simply
observed it very differently.

Today, computers are used in lots of places and
by lots of people (not just handicapped access)
that simply were not possible twenty years ago.

Even if you are living in a cardboard box, if
you have to go grocery shopping, probably your
cashier is doing the checkout using a Windows based
application.

So what I see is that I stated a fact from
observation, and you are disputing the fact.
At this point, there is no logic involved.
The best I could have done was little
memory joggers, not present any more logic.
If you still insist that no more people are
using computers today, there just isn't much
more to be said about it.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Kaz Kylheku]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net>...
> Apples and oranges, Will.
> 
> The interesting comparison would be to give both sides the same hardware
> power, and do the UI software in Ada vs. C.

Newsflash: ``Ada versus C'' is not interesting. Ada and C are much
more similar than they are different. If you don't think so, it's only
because you are too absorbed in the arcane details that separate your
favorite high level assembly language from the next one.

An Ada versus C programming context is the coding equivalent of a
three-legged race in which each side thinks that their particular
method of tying legs together gives them an advantage.

Writing UI in either Ada or C is a waste of productivity that could
only possibly be justified in a freeware project, or some
tax-dollar-supported researchy thing. (To be clear, I don't mean
*morally* justified, only economically).

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Chad R. Meiners]

The challenge would have nothing to do with the language used to implement
the algorithm.  The GNU chess algorithm is what determines its game playing
ability not its implementation language.

"Will" <wv9557@yahoo.com> wrote in message
news:4a885870.0304300431.49a61bfa@posting.google.com...
> Now if you want a challenge try to write an Ada chess program to beat
> GNU chess. It's all C.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Frank J. Lhota]

"Kaz Kylheku" <kaz@ashi.footprints.net> wrote in message
news:cf333042.0304300835.4800e03e@posting.google.com...
>  If you don't think so, it's only
> because you are too absorbed in the arcane details that separate your
> favorite high level assembly language from the next one.

??? A language with generics, exceptions and dispatching is still a
high-level assembly language???

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Rod Davison]

On Wed, 30 Apr 2003 10:48:25 -0400, soft-eng wrote:

> Even if you are living in a cardboard box, if you have to go grocery
> shopping, probably your cashier is doing the checkout using a Windows
> based application.
> 

Ah-hah!

That explains why upgrade my portabello mushrooms to the more expensive
Shitaki before they could be rung through.


-- 
====================================================
Rod Davison 
Critical Knowledge Systems Inc.
rod @ critsys . com
====================================================
Maybe, just once, someone will call me "sir" without 
adding, "you're making a scene."
====================================================

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

"Kaz Kylheku" <kaz@ashi.footprints.net> wrote in message
news:cf333042.0304300835.4800e03e@posting.google.com...
> "John R. Strohm" <strohm@airmail.net> wrote in message
news:<416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net>...
> > Apples and oranges, Will.
> >
> > The interesting comparison would be to give both sides the same hardware
> > power, and do the UI software in Ada vs. C.
>
> Newsflash: ``Ada versus C'' is not interesting. Ada and C are much
> more similar than they are different. If you don't think so, it's only
> because you are too absorbed in the arcane details that separate your
> favorite high level assembly language from the next one.
>
> An Ada versus C programming context is the coding equivalent of a
> three-legged race in which each side thinks that their particular
> method of tying legs together gives them an advantage.
>
> Writing UI in either Ada or C is a waste of productivity that could
> only possibly be justified in a freeware project, or some
> tax-dollar-supported researchy thing. (To be clear, I don't mean
> *morally* justified, only economically).

What such a comparison would yield is a data point on the graph of cost per
function point vs. choice of language.

There is considerable evidence that strongly suggests that Ada, all by
itself, makes a significant positive difference in programmer productivity
over the embedded software lifecycle, by reducing defect incidence and
promoting earlier defect detection (i.e., compile-time vs. run-time) and
easier debugging and correction (e.g., by a compiler error message vs. a
core dump), when one controls statistically for all other factors.  It must
be understood that the embedded software lifecycle is one or two orders of
magnitude longer than the typical commercial lifecycle, and the cost impact
of defects escaping into a fielded project is MUCH higher.  (Commercial web
applicatiosn don't kill people when they malfunction.  Computer-controlled
radiation therapy machines can, and have.  Do a search on "Therac-25".)

Or is it your belief that cost of software development, and cost of quality,
is immaterial?  If so, I recommend you read Phil Crosby's "Quality is Free",
where he advances the concept of cost of quality, by quantifying the cost of
reworking defective material and then showing that the added cost of NOT
generating defective material is generally MUCH lower than the cost of
rework.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Adam Ruth]

> Ok, I am sure a few instances happened.  But if you
> had to develop device drivers for a living, and if
> the language was truly your choice, would you chose Ada as
> the language?
> 
> I think the only "yes" answers would be from
> people who only know Ada and/or have never
> written a device driver.

I recently had the [mis]fortune of writing a device driver for
NetWare.  The only language choices are C and C++.  I used C, since
C++ support wasn't really up to snuff on NetWare and I'm more
comfortable in C.  At the time I was writing the driver, I was
learning Ada, and by the end of the project I really wish I could have
used it.  There were entire classes of error I encountered, and had a
hard time debugging, that would simply not have existed in Ada.  Of
course, there were plenty of bugs that would have existed regardless
of language, and I'm sure that there are new problems that the use of
Ada would introduce.  But I'm constantly amazed at the errors that are
so easy to avoid in Ada because they simply don't exist.

If I had it to do again (I hope I don't!) and Ada was a choice, I'd
give it a shot.  I'm convinced that the quality of the product would
have been superior.

Adam

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Adam Ruth]

> > > (C and later C++ style of type-safety turned out to
> > > be good enough for real-world projects.)
> > 
> > Like Windows ?
> 
> 
> You must live in a different world from me -- I look
> around, and from the web-browser to the newsreaders
> to the email software to the software transporting
> your packets full of Ada praise to the software
> controlling the switching stations enroute to...
> 
> You don't like Windows, so you must be using
> what?  Unix and X-Windows?  Written/extended/in Ada?
> Surely Ada was there when most of X-Windows
> and Motif happened?  Or at least when the
> CD-ROM device drivers were being written?
> 
> What now did you say these very expensive
> Ada projects actually do?

I always find it interesting how some people think that the software
they use is the only software in the world...  "If I haven't used it,
it doesn't exist!"  There's much more to life than desktop O/Ss, GUIs,
and productivity apps.

Adam

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Will]

According to Mr Meiners, Ada addicts should never attempt to rewrite 
any chess programs in Ada. Apparently if you do, your program will not 
do better than a C program with the same algorithm.




"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<b8p0of$pjs$1@msunews.cl.msu.edu>...
> The challenge would have nothing to do with the language used to implement
> the algorithm.  The GNU chess algorithm is what determines its game playing
> ability not its implementation language.
> 
> "Will" <wv9557@yahoo.com> wrote in message
> news:4a885870.0304300431.49a61bfa@posting.google.com...
> > Now if you want a challenge try to write an Ada chess program to beat
> > GNU chess. It's all C.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Chad R. Meiners]

Hello aspiring troll.  I never said that.  You will have be a little more
subtle with your mischaracterizations and vague statements if you ever hope
to become a real troll.

"Will" <wv9557@yahoo.com> wrote in message
news:4a885870.0304301937.b27ec47@posting.google.com...
> According to Mr Meiners, Ada addicts should never attempt to rewrite
> any chess programs in Ada. Apparently if you do, your program will not
> do better than a C program with the same algorithm.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Tom Welsh]

In article <uv2cnfY-WcxAjTajXTWcow@gbronline.com>, Wesley Groleau
<wesgroleau@despammed.com> writes
>
>You people are talking about two different things.
>There are TWO operating systems called Windows.
>
>Windows 3.1 / 95 / 98 / ME crashes daily for many users
>
>Windows NT / 2000 / XP is a completely different O.S.
>It still crashes, but it is reliable enough for most
>people.
>
That's because it is as close as they could get to VMS, under the
covers. 

It still crashes and hangs too much because the Windows GUI was a non-
negotiable legacy - which is probably harder to make reliable than a
conventional mainframe OS.

VMS used to be less than 10 million lines of code (C, Bliss, whatever).
DECwindows added another 5-7 million or so.

Windows 2000 is said to be in the region of 40 million LOC. If that's
true, I think it's an amazing accomplishment that it works at all. And
it is far more reliable than the older Windows variants.

But it still seems to me that much less reliable than VMS was 10-15
years ago. (And yes, that had a GUI too).
-- 
Tom Welsh

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marin David Condic]

Will <wv9557@yahoo.com> wrote in message
news:4a885870.0304301937.b27ec47@posting.google.com...
> According to Mr Meiners, Ada addicts should never attempt to rewrite
> any chess programs in Ada. Apparently if you do, your program will not
> do better than a C program with the same algorithm.
>
>
According to some experts (me), rewriting *any* program in *any* language is
mostly a waste of time. :-) You need to ask what is gained by building the
thing twice? Maybe, possibly, sometimes, you have a buggy program that might
benefit from being rewritten because you want the functionality but not the
bugs. Changing languages (to Ada) might also help reduce the bugs. But if
you are going to go that far, why not build a *new* program that does more
or otherwise grows from the experience.

And it also seems intuitively obvious that executing the same algorithm in a
different language ought to yield the same result, correct? So why would an
Ada addict want to rewrite a chess program that (presumably) already works
well?

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<C73FB1279386F1CD.BF0175B06B325A3F.212017A5819C3CBB@lp.airnews.net>...
> "Kaz Kylheku" <kaz@ashi.footprints.net> wrote in message
> news:cf333042.0304300835.4800e03e@posting.google.com...
> > "John R. Strohm" <strohm@airmail.net> wrote in message
>  news:<416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net>...
> > > Apples and oranges, Will.
> > >
> > > The interesting comparison would be to give both sides the same hardware
> > > power, and do the UI software in Ada vs. C.
> >
> > Newsflash: ``Ada versus C'' is not interesting. Ada and C are much
> > more similar than they are different. If you don't think so, it's only
> > because you are too absorbed in the arcane details that separate your
> > favorite high level assembly language from the next one.
> >
> > An Ada versus C programming context is the coding equivalent of a
> > three-legged race in which each side thinks that their particular
> > method of tying legs together gives them an advantage.
> >
> > Writing UI in either Ada or C is a waste of productivity that could
> > only possibly be justified in a freeware project, or some
> > tax-dollar-supported researchy thing. (To be clear, I don't mean
> > *morally* justified, only economically).
> 
> What such a comparison would yield is a data point on the graph of cost per
> function point vs. choice of language.
> 
> There is considerable evidence that strongly suggests that Ada, all by
> itself, makes a significant positive difference in programmer productivity
> over the embedded software lifecycle, by reducing defect incidence and
> promoting earlier defect detection (i.e., compile-time vs. run-time) and
> easier debugging and correction (e.g., by a compiler error message vs. a
> core dump), when one controls statistically for all other factors.  It must
> be understood that the embedded software lifecycle is one or two orders of
> magnitude longer than the typical commercial lifecycle, and the cost impact
> of defects escaping into a fielded project is MUCH higher.  (Commercial web
> applicatiosn don't kill people when they malfunction.  Computer-controlled
> radiation therapy machines can, and have.  Do a search on "Therac-25".)
> 
> Or is it your belief that cost of software development, and cost of quality,
> is immaterial?  If so, I recommend you read Phil Crosby's "Quality is Free",
> where he advances the concept of cost of quality, by quantifying the cost of
> reworking defective material and then showing that the added cost of NOT
> generating defective material is generally MUCH lower than the cost of
> rework.

But you are assuming a stricter type safety translates
to higher quality.

There is little evidence for that.  Type safety is
ONE thing that helps quality.  But if a little
bit of sugar in a recipe is good, ten times
the sugar will not make it taste ten times
tastier.  There are natural limits.

Ultimately, type safety only catches relatively minor
errors typically made by novice programmers.  It cannot
catch errors of design and logic, which are the more complex
sources of quality defects.

Most programmers do not stay novice for their
whole careers.  (If they do, they should consider
other careers too.)  So the role of type safety
in assuring quality is limited.

That having said, if you cannot hire well, a good type
safe language might help in eliminating smaller
errors.  But then, you are never going to have
anything working anyway, so what's the big deal
about eliminating smaller syntax-level errors?

If you can hire well, a super-strong type safe
language will only annoy your best programmers,
who don't need the type safety to avoid bugs
but have to work around it for all the things
that they do need to do.  You can still deliver
projects in that case, but your quality
will be poorer, not better, and you will
have taken much longer for no good reason.
(Though the relation to job-safety issues
is apparent, which is why bureaucrat types
might love such languages.)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<98BC68183770643E.43B22CFE5F4D5EFD.5566989BE627964B@lp.airnews.net>...
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0304300412.3c9f8157@posting.google.com...
> > Richard Riehle <richard@adaworks.com> wrote in message
>  news:<3EAF3464.9E06145F@adaworks.com>...
> > >
> > > Sorry you had such bad Ada training.   There was a lot of that
> > > going around at one time, perpetrated by people who simply
> > > failed to understand some elementary ideas and made them
> > > more complicated than necessary.
> >
> > Do you really think my views on Ada are a result of
> > bad training?
> >
> > I suppose that is a very fair representation of the
> > analysis and insight capabilities of those who
> > choose to espouse the cause you are championing here...
> 
> Why don't you *tell* us where your views on Ada come from?
> 
> So far, you have said a great deal that suggests that you have NO actual
> experience with Ada.

Mostly peripheral and theoretical.  Taught Ada to graduate students for
evening class.  Had to learn about it from an academic viewpoint.
Did have some previous familiarity during my own graduate
school work, because lots of people were thinking that's where
the grants would be coming from, and there was very high
academia interest in Ada.  I even owned a copy of the first language
manual sets, that came out right after the announcement
"Ada is green".  (Talking of "green", briefly also worked with
some ex-"red" team members.)  Also briefly worked with some
government Ada type people (my own project was a proof-of-concept
prototype for some small-potatoes $5 mill contract, and therefore
my project had an "exception" or something so I could work
in C, which was very much of a break and I could wrap it
up quickly), and got to observe their behaviors.

No recent experience at all, but of course, any recent
changes to Ada had little to do with the collapsing
of the Ada mandate.  These days, probably even Add-1-to-Cobol
is object oriented, and I would be surprised if
Ada-2002 (or whatever) weren't virtually a copy of Java
or C++.  I figure I already know Java and C++...

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

> And it also seems intuitively obvious that executing the same algorithm in a
> different language ought to yield the same result, correct? So why would an
> Ada addict want to rewrite a chess program that (presumably) already works

Maybe.  But it's possible that:

  - some of the features of Ada might allow greater optimization
    In the case of _some_ chess algorithms, a slightly faster
    execution could win the game, because they give up evaluating
    options when a certain wall-time limit is reached.

  - some of the features of Ada might detect bugs, causing them
    to be corrected.

On the other hand, as you said, there are various other reasons
why a rewrite is probably not a good idea.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

> That having said, if you cannot hire well, a good type
> safe language might help in eliminating smaller
> errors.  But then, you are never going to have

No, because the incompetent programmers will make everything
'int' or 'double' without taking steps to handle/catch the
problems this causes.

> If you can hire well, a super-strong type safe
> language will only annoy your best programmers,
> who don't need the type safety to avoid bugs
> but have to work around it for all the things
> that they do need to do.  You can still deliver

What a crock.  Nothing stops these guys from declaring
everything as "float" and wasting hours handling problems
that the compiler could have handled.  If there are no
such problems ....

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert A Duff]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> Will fed this fish to the penguins on Wednesday 30 April 2003 05:31 am:
> 
> > Now if you want a challenge try to write an Ada chess program to beat
> > GNU chess. It's all C.
> 
>         I presume you mean to black-box the development -- after all, it is 
> the /algorithms/ which make or break a chess program. Those algorithms 
> can be implemented in any language (though speed of execution may be 
> rather poor if one were to implement it in TCL <G>).

And the same exact algorithm running faster will play better chess,
since chess is a timed game.

- Bob

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Hyman Rosen]

Wesley Groleau wrote:
>> If you can hire well, a super-strong type safe
>> language will only annoy your best programmers,
>> who don't need the type safety to avoid bugs
>> but have to work around it for all the things
>> that they do need to do.  You can still deliver
> 
> What a crock.  Nothing stops these guys from declaring
> everything as "float" and wasting hours handling problems
> that the compiler could have handled.  If there are no
> such problems ....

I don't know where this notion arose that a "super-strong"
type system is just for preventing bugs. I know that in C++
the type system is an essential part of programming, given
the various static (templates) and dynamic (dispatching)
ways that types guide what code is executed. I'm sure it's
that way in Ada as well.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marc A. Criley]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305010621.55e99deb@posting.google.com>...
> That having said, if you cannot hire well, a good type
> safe language might help in eliminating smaller
> errors.  But then, you are never going to have
> anything working anyway, so what's the big deal
> about eliminating smaller syntax-level errors?
> 
> If you can hire well, a super-strong type safe
> language will only annoy your best programmers,
> who don't need the type safety to avoid bugs
> but have to work around it for all the things
> that they do need to do.  You can still deliver
> projects in that case, but your quality
> will be poorer, not better, and you will
> have taken much longer for no good reason.
> (Though the relation to job-safety issues
> is apparent, which is why bureaucrat types
> might love such languages.)

This is one of the biggest misconceptions about type-safety and the
languages that utilize it: that its primary purpose is just to help
avoid bugs.  (And this is a misconception held by many Ada programmers
as well.)

Ada is a language whose definition is built around the concept of a
"type model".

The proper definition of types for an application allows the embedding
of vast quantities of information that is there just for the asking by
the application.  One doesn't "work around it" because the "best
programmers...don't need the type safety", one _exploits_ the
information that the type definitions encode.

For example, say you have a scalar C or C++ type, called Altitude; to
what information about that type and its objects does the application
have direct access?  Pretty much just "sizeof()" and the address of a
variable of that type.

Now for a comparable properly defined Ada type, one has the following:

- The first and last values ('First and 'Last)
- Access to the previous and next valid values ('Pred and 'Succ)
- Conversion of the type to a string--without having to know its
  size or whether it's floating, numeric, or enumeration ('Image
  and 'Wide_Image)
- The maximum number of characters such a string representation can
  take ('Width and 'Wide_Width)
- Ability to convert a string representation of that type--whatever
  kind it is--back to a value--with range checking! ('Value,
 'Wide_Value)
- The number of bits required to hold the type's largest value ('Size)

If you have a variable of that type, at the very least you get:
- The number of bits actually allocated for that value ('Size)
- It's address ('Address)

If you know a little bit more about your type, specifically whether
it's a discrete or floating point type, what else do you get with
C/C++?  Nothing.

With Ada (discrete):
- 'Pos, the ordinal position of an enumeral (or number)
- 'Val, convert an ordinal position into a value of the type

(floating):
- 'Machine_Mantissa
- 'Machine_Radix
     and it goes on...

(And yes, one could write a CAltitude class that provides all this
information, but one would have to implement and debug
_all_of_those_functions.  In Ada you write:

  type Altitude is digits 6.0 range -100.0 .. 50_000.0;

and you get access to all that information for free!)

I've seen that one of the critical requirements of an effective Ada
program is getting the types well and correctly defined.  Then
exploiting that information as needed throughout the application.  The
identification of object and interface type mismatches (your nominal
"type safety") is then just a welcome addition, it's the exploitation
of the application's type model that gives the bang for the buck.

And I give Hyman a lot of credit for figuring this out as well,
despite his peripheral familiarity with Ada.  If more programmers
understood the motivation for, and power of, strong typing (such as it
is in C++, Java, or Ada) much better software would get written, and
the "best" programmers wouldn't be struggling to work around it.

Marc A. Criley

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Kaz Kylheku]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<qDTra.23221$xw4.9186@nwrdny01.gnilink.net>...
> "Kaz Kylheku" <kaz@ashi.footprints.net> wrote in message
> news:cf333042.0304300835.4800e03e@posting.google.com...
> >  If you don't think so, it's only
> > because you are too absorbed in the arcane details that separate your
> > favorite high level assembly language from the next one.
> 
> ??? A language with generics, exceptions and dispatching is still a
> high-level assembly language???

Ada exceptions are a laughably low-level mechanism, that is about as
powerful as some of the feeble C macro packages that wrap up setjmp
and longjmp. Some of those packages are more powerful because they can
subclass errors into categories. Modern languages represent errors
using class hierarchies, allowing handlers to express more or less
specific matches.

Ada's exception system is not useful for much more than containing
errors. It pales in comparison to Common Lisp's conditions and
restarts. The correct design for error handling is to unwind to an
outer dynamic context *as a the very last step*, after an analysis is
performed and the proper place to unwind to has been chosen. Ada's
exception system is more like that of C++; when an exception is
raised, it starts discarding dynamic frames until a handler is found.

An error handler should preserve the full dynamic context of the
situation---this is how exception vectors in processor architectures
work. When an interrupt happens, the currently running thread is not
unwound all the way back to the operating system! No, the exception
pushes new information onto the stack, and can later restart the task
exactly where it left off.  For example, you hit a page fault, the
operating system's handler makes the page available, and then restarts
the process, so the access instuction is tried again and succeeds this
time. Unwinding on error is the stupidest possible thing to do; it
allows for containment, but not recovery.

I would be tempted to hack up my own error system based on registering
handler *functions*, and using the exceptions as the final step in
error handling, to unwind to a restart point. The Ada exception
handlers resemble Common Lisp's restarts in some ways, most notably
that they are points in the dynamic context identified by symbols.
But, sadly, there is no way to introspect over them; in other words,
to compute a list or otherwise enumerate or iterate over the handlers
that are visible in a given dynamic context. So you can't implement
logic like ``if there is a handler for Foo exception, then raise it''
which would represent the idea ``if a Foo way of continuing is
available at this point, let's choose it''. A WHEN clause in the
exception block also has no way of returning back to the raise point
to show that it's declining to handle the error. Nevertheless, with
this approach, one could perhaps implement some rudimentary error
recovery protocols.

For example, suppose that we agree on a very simple convention that we
will have two ways of continuing after an error: an Abort and Retry.
When I call your module and it encounters a problem, it calls a
handler callback in my module. No unwinding takes place yet. In my
module I then decide (perhaps with the help of a user) whether to
retry the operation or abort, and raise the appropriate exception,
which passes back to your code. If I raise Retry, then the operation
which failed will be tried again. Of course, I can raise some third
exception that your module doesn't know about, to obtain a non-local
exit that bypasses your module entirely. In other words, exceptions
are really restart choices; the last step in the protocol for
recovering from an error situation, based on making some sort of
informed decision at a higher layer combined with advice at the lower
layer.

I would want this formalized into a language feature which supports
the dynamic registration and automatic deregistration of handlers,
association of handlers with some symbols or whatnot to support exact
or inexact searching and so on. A decent macro system would go a long
way. Oops!

Interestingly, I see in Ada's exception system an attempt to reinvent
the idea of a symbolic data type. When you write Foo : exception; to
introduce a new exception symbol, this is very much like symbol
interning, except that it's conflated into a subcomponent of the
language rather than standing alone. From Ada95 we have:

 Each distinct exception is represented by a distinct value of type 
 Exception_Id. Null_Id does not represent any exception, and is the
 default initial value of type Exception_Id. Each occurrence of an
 exception is represented by a value of type Exception_Occurrence.
 Null_Occurrence does not represent any exception occurrence, and
 is the default initial value of type Exception_Occurrence. 

And of Common Lisp we could write:

 Each identifier scanned by the reader is interned in the current
package;
 distinct names give rise to distinct symbols, which are objects that
 are useful for their unique identity, and various properties that can
be
 associated with them. The symbol NIL (in the "COMMON-LISP" package)
is not
 equal to any other symbol.

Funny to see Greenspun's Tenth Rule of Programming at work in Ada
also!

I'm warmly entertained, by the way, by how the string returned by
Exception_Message may be truncated to 200 characters. Ah, assembly
language and its fixed buffers.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Gautier]

softeng3456:

> But you are assuming a stricter type safety translates
> to higher quality.
> 
> There is little evidence for that.  Type safety is
> ONE thing that helps quality.  But if a little
> bit of sugar in a recipe is good, ten times
> the sugar will not make it taste ten times
> tastier.  There are natural limits.

That's right. There are upper _and_ lower limits, by the way...

> Ultimately, type safety only catches relatively minor
> errors typically made by novice programmers.  It cannot
> catch errors of design and logic, which are the more complex
> sources of quality defects.
> 
> Most programmers do not stay novice for their
> whole careers.  (If they do, they should consider
> other careers too.)  So the role of type safety
> in assuring quality is limited.

... if you assume that the programmers will always do novice-
sized programs. With the scale of projects the usefulness
of type safety grows. Type safety is annoying on small
programs and comfortable for large ones.

> That having said, if you cannot hire well, a good type
> safe language might help in eliminating smaller
> errors.  But then, you are never going to have
> anything working anyway, so what's the big deal
> about eliminating smaller syntax-level errors?

It is not only on syntax-level (then it would be just
for the pleasure of it), it prevents lots of run-time
errors that would not appear immediately. So, eliminating them
_is_ a big deal, because, you can concentrate on refining
the design and logic issues instead of chasing these errors.

> If you can hire well, a super-strong type safe
> language will only annoy your best programmers,
> who don't need the type safety to avoid bugs
> but have to work around it for all the things
> that they do need to do.  You can still deliver
> projects in that case, but your quality
> will be poorer, not better, and you will
> have taken much longer for no good reason.
> (Though the relation to job-safety issues
> is apparent, which is why bureaucrat types
> might love such languages.)

You simply ignore the huge debugging time provided
by poorly-typed languages and its effective relation to
job safety. So what ?
It's a question of a good proportion of sugar:
not too much, not too few :-)
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On 1 May 2003 07:21:49 -0700, soft-eng <softeng3456@netscape.net> wrote:
> 
> But you are assuming a stricter type safety translates
> to higher quality.
> 
> There is little evidence for that.  Type safety is
> ONE thing that helps quality.  But if a little
> bit of sugar in a recipe is good, ten times
> the sugar will not make it taste ten times
> tastier.  There are natural limits.
 
> Ultimately, type safety only catches relatively minor
> errors typically made by novice programmers.  It cannot
> catch errors of design and logic, which are the more complex
> sources of quality defects.

I think minor errors are made by even experienced programmers
frequently.

Novice programmers cannot really correct errors of design and
logic as well as experienced programmers can.

> Most programmers do not stay novice for their
> whole careers.  (If they do, they should consider
> other careers too.)  So the role of type safety
> in assuring quality is limited.

What it can do is ensure the proper use of code designed
by the more experienced programmers. 

> That having said, if you cannot hire well, a good type
> safe language might help in eliminating smaller
> errors.  But then, you are never going to have
> anything working anyway, so what's the big deal
> about eliminating smaller syntax-level errors?
> 
> If you can hire well, a super-strong type safe
> language will only annoy your best programmers,
> who don't need the type safety to avoid bugs
> but have to work around it for all the things
> that they do need to do.  

And how often is it really necessary to 'work around it'? 

The question is what happens with the typical level
of programmer that typically good people can hire.

I've personally found in my own work that static strict typing is not
so enormously helpful in initial development when I have everything
still "in my mind". 

It is extremely helpful when I return back to a project after many
months, and I have noticed many times when prevented me from making
dumb mistakes by accident, and informed me about what I was
supposed to be doing.  I greatly preferred that to run-time errors. 

Inevitably, people do take other jobs, and having code that
is somewhat resilient to new programmers can be a good idea. 

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert A Duff]

mcq95@earthlink.net (Marc A. Criley) writes:

> This is one of the biggest misconceptions about type-safety and the
> languages that utilize it: that its primary purpose is just to help
> avoid bugs.  (And this is a misconception held by many Ada programmers
> as well.)

Well said.  Strong compile-time typing is not a burden, is not
constricting -- it's liberating!

- Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Richard Riehle]

soft-eng wrote:

> "John R. Strohm" <strohm@airmail.net> wrote in message news:<98BC68183770643E.43B22CFE5F4D5EFD.5566989BE627964B@lp.airnews.net>...
>
> > Why don't you *tell* us where your views on Ada come from?
> >
> > So far, you have said a great deal that suggests that you have NO actual
> > experience with Ada.
>
> Mostly peripheral and theoretical.  Taught Ada to graduate students for
> evening class.  Had to learn about it from an academic viewpoint.

One more amateur teaching Ada with no experience using it on
projects.   There was so much of this going around that no one
should be suprised that so many students came away from their
Ada classes with a distorted view of the language.

Richard Riehle

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Richard Riehle]

Will wrote:

> Now if you want a challenge try to write an Ada chess program to beat
> GNU chess. It's all C.

This is an absurd observation.   The quality of the chess game is not
a function of the language.  The same quality program can be written
in Ada.   Howabout, a commercial aircraft with two million lines of
code that transports many thousands of people all over the world
daily  where all the software is written in Ada.   Try to achieve
this in C.   You will take longer to do it, have more defects in the
software and crash a couple of airplanes before you get it right,
if ever.

Richard Riehle

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

mcq95@earthlink.net (Marc A. Criley) wrote in message news:<254c16a.0305011035.13133e8d@posting.google.com>...

> Ada is a language whose definition is built around the concept of a
> "type model".

Yes, it used the then modern concepts of type definition.
(Later superseded by notions of object-oriented type definitions.)

> Now for a comparable properly defined Ada type, one has the following:
> 
> - The first and last values ('First and 'Last)
> - Access to the previous and next valid values ('Pred and 'Succ)
> - Conversion of the type to a string--without having to know its
>   size or whether it's floating, numeric, or enumeration ('Image
>   and 'Wide_Image)
> - The maximum number of characters such a string representation can
>   take ('Width and 'Wide_Width)
> - Ability to convert a string representation of that type--whatever
>   kind it is--back to a value--with range checking! ('Value,
>  'Wide_Value)
> - The number of bits required to hold the type's largest value ('Size)
> 
> If you have a variable of that type, at the very least you get:
> - The number of bits actually allocated for that value ('Size)
> - It's address ('Address)

Yes, Ada extended Pascal very strongly in this regards,
without any particular consideration of how useful
these extensions would actually turn out to be.

> If you know a little bit more about your type, specifically whether
> it's a discrete or floating point type, what else do you get with
> C/C++?  Nothing.
> 
> With Ada (discrete):
> - 'Pos, the ordinal position of an enumeral (or number)
> - 'Val, convert an ordinal position into a value of the type
> 
> (floating):
> - 'Machine_Mantissa
> - 'Machine_Radix
>      and it goes on...
> 
> (And yes, one could write a CAltitude class that provides all this
> information, but one would have to implement and debug
> _all_of_those_functions.  In Ada you write:
> 
>   type Altitude is digits 6.0 range -100.0 .. 50_000.0;
> 
> and you get access to all that information for free!)

Like I said, Ada has amazing amounts of itsy-bitsy stuff.
Now which of these features, if missing, would take you
more than a minor effort to provide yourself?  If and
when necessary, rather than present by default all the time?

> understood the motivation for, and power of, strong typing (such as it
> is in C++, Java, or Ada) much better software would get written, and
> the "best" programmers wouldn't be struggling to work around it.

You misunderstand.  Nobody needs to "work around" the type-safety
of C++ or Java.  Though this was a problem with Pascal, which
was the premier contender at one time.  The need to "work around"
Pascal's type safety was a big problem, and that helped C become
much more popular.  Ada didn't just inherit Pascal's problems,
it enthusiastically extended them.

The type safety in C++ and therefore in Java has evolved slowly
and naturally.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305011727.5eae0222@posting.google.com...
> mcq95@earthlink.net (Marc A. Criley) wrote in message
news:<254c16a.0305011035.13133e8d@posting.google.com>...
>
> > Ada is a language whose definition is built around the concept of a
> > "type model".
>
> Yes, it used the then modern concepts of type definition.
> (Later superseded by notions of object-oriented type definitions.)

Not superseded, extended.

> > Now for a comparable properly defined Ada type, one has the following:
> >
> > - The first and last values ('First and 'Last)
> > - Access to the previous and next valid values ('Pred and 'Succ)
> > - Conversion of the type to a string--without having to know its
> >   size or whether it's floating, numeric, or enumeration ('Image
> >   and 'Wide_Image)
> > - The maximum number of characters such a string representation can
> >   take ('Width and 'Wide_Width)
> > - Ability to convert a string representation of that type--whatever
> >   kind it is--back to a value--with range checking! ('Value,
> >  'Wide_Value)
> > - The number of bits required to hold the type's largest value ('Size)
> >
> > If you have a variable of that type, at the very least you get:
> > - The number of bits actually allocated for that value ('Size)
> > - It's address ('Address)
>
> Yes, Ada extended Pascal very strongly in this regards,
> without any particular consideration of how useful
> these extensions would actually turn out to be.

Actually, it turns out that those extensions proved to be quite useful.
'first and 'last are necessary if you want to write loops over an arbitrary
index type.  'succ and 'pred are absolutely critical if you want to step
from one enumerated value to another.

Conversion to/from string form is just sprintf() in a cleaner form.

'size is critical, for the same reason that sizeof() is critical.

> > If you know a little bit more about your type, specifically whether
> > it's a discrete or floating point type, what else do you get with
> > C/C++?  Nothing.
> >
> > With Ada (discrete):
> > - 'Pos, the ordinal position of an enumeral (or number)
> > - 'Val, convert an ordinal position into a value of the type
> >
> > (floating):
> > - 'Machine_Mantissa
> > - 'Machine_Radix
> >      and it goes on...
> >
> > (And yes, one could write a CAltitude class that provides all this
> > information, but one would have to implement and debug
> > _all_of_those_functions.  In Ada you write:
> >
> >   type Altitude is digits 6.0 range -100.0 .. 50_000.0;
> >
> > and you get access to all that information for free!)
>
> Like I said, Ada has amazing amounts of itsy-bitsy stuff.
> Now which of these features, if missing, would take you
> more than a minor effort to provide yourself?  If and
> when necessary, rather than present by default all the time?

The key is that, by putting them in the language, it is absolutely
guaranteed that they will be implemented CORRECTLY, every time, with NO
programmer workload involved.

And the actual executable code for the feature may not actually be present
in the final system.  It is utterly trivial to hide those features under an
external name interface, and let the linker cull out unused items.  (This
USED to be standard behavior for linkers, back before memories got "large"
and utility programmers got criminally lazy.)  For some reason, linkers used
by common C toolsets generally don't bother to do this: they treat
executables as shovelware repositories.

> > understood the motivation for, and power of, strong typing (such as it
> > is in C++, Java, or Ada) much better software would get written, and
> > the "best" programmers wouldn't be struggling to work around it.
>
> You misunderstand.  Nobody needs to "work around" the type-safety
> of C++ or Java.  Though this was a problem with Pascal, which
> was the premier contender at one time.  The need to "work around"
> Pascal's type safety was a big problem, and that helped C become
> much more popular.  Ada didn't just inherit Pascal's problems,
> it enthusiastically extended them.

Observe that there is actually relatively little difference between the
basic type system enforced by PASCAL and the basic type system enforced by
C++.  I can't speak to Java.  The C hackers (I hesitate to dignify them with
the term "programmers") screamed bloody murder about the strong typing in
PASCAL and Ada.  When C++ came out, and it was strongly typed, the silence
from that corner of the auditorium was absolutely deafening.

> The type safety in C++ and therefore in Java has evolved slowly
> and naturally.

Hardly.  Stroustrup took type safety in C++ from Simula 67, which actually
predated PASCAL.

And note that Stroustrup himself admits that adding strong typing to C was
one of his earliest goals for C++.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[James S. Rogers]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1051804573.732603@master.nyc.kbcfp.com...
> I don't know where this notion arose that a "super-strong"
> type system is just for preventing bugs. I know that in C++
> the type system is an essential part of programming, given
> the various static (templates) and dynamic (dispatching)
> ways that types guide what code is executed. I'm sure it's
> that way in Ada as well.
>

I agree. There is also an underlying assumption in the original
troll that the only distinguishing feature of Ada is strong typing.
This opinion can clearly only come from somebody who does
not understand Ada's scope and visibility rules.

Those rules, combined with intelligent use of user-defined types,
will allow the compiler to detect an amazing range of logic
errors. For instance, Ada scoping rules make it very difficult to
access an out of scope reference object (Ada calls them
access variables). Many languages have less strict scoping
rules, providing the opportunity of inappropriate access to out
of scope pointers.

Jim Rogers

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

> I don't know where this notion arose that a "super-strong"
> type system is just for preventing bugs. I know that in C++

I didn't say that it was only for preventing bugs.
I said it's a crock that it requires programmers
to do a lot of allegedly unnecessary workarounds.

For me, preventing bugs is the second biggest benefit
of Ada's type system.  The bigger one is that it
allows you to define things in terms of your
abstraction instead of your implementation.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[James S. Rogers]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305011727.5eae0222@posting.google.com...
> mcq95@earthlink.net (Marc A. Criley) wrote in message
news:<254c16a.0305011035.13133e8d@posting.google.com>...
>
> Yes, Ada extended Pascal very strongly in this regards,
> without any particular consideration of how useful
> these extensions would actually turn out to be.

Nonsense. The Ada designers knew very well how useful those
extensions would turn out to be. After all, Ada was not designed
by a committee.

> Like I said, Ada has amazing amounts of itsy-bitsy stuff.
> Now which of these features, if missing, would take you
> more than a minor effort to provide yourself?  If and
> when necessary, rather than present by default all the time?

So, are you arguing against the sizeof operator in C and C++?
Are you arguing against the Length field of an Java array?
Are you arguing against C pointer arithmetic?

What feature of a high level language cannot be created with an
individual effort from an assembler programmer?

> You misunderstand.  Nobody needs to "work around" the type-safety
> of C++ or Java.  Though this was a problem with Pascal, which
> was the premier contender at one time.  The need to "work around"
> Pascal's type safety was a big problem, and that helped C become
> much more popular.  Ada didn't just inherit Pascal's problems,
> it enthusiastically extended them.

Absolutely wrong. Ada did not extend Pascal. It simply belongs to
the same syntax family, which is not rooted in Pascal. Algol came
long before Pascal.

The Ada type system is both stronger than the Pascal type system
and more flexible. It is designed to do its work and keep out of your
way.

>
> The type safety in C++ and therefore in Java has evolved slowly
> and naturally.

There is nothing natural about the development of a language. Classes
belonged to C++ from the very beginning. The same is true of Java.
Those languages are not evolutionary developments. They were discrete
attempts to create languages in the B (yes, the precursor to C) family
with stronger typing and greater support for Object Oriented Programming
than exist in C.

Java is not an evolved C++. The design goals of the two languages are
far different. C++, despite its name, is not merely a superset of C.
If it were the C++ standard would need to subsume the C standard.
It does not. The C++ standard exists independent of the C standard.

Your basic assumptions are invalid. This forces your conclusions to be
invalid also.

Jim Rogers

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Will]

There is no algorithm. Most chess programs uses alpha beta pruning or some
variation of it.
Unfortunately there is only so much that alpha can help speed up the
search. They employ other heuristics like killer moves, null moves. Techniques
like hashing greatly speed things up. Most will also have a quiescent search,
which basically search fully all the capture moves until there is no more
captures, this is to avoid the horizon effect. Chess software is really
more like  combination of techniques and intution than an exact algorithm.
Apparently the more positions you can look at an infinite amount of time
the stronger  your program is. Therefore an optimized assembly language
program will beat the same C program, even if they use the same techniques.
Just because the assembly language can look at more positions than
the C program. Implementation language DOES matters.
Now does anybody else still want to write an Ada chess program to beat
GNU Chess? For your information, GNU Chess is one of the weakest program
out there. Thank God the IBM researches went ahead with creating
Deep Blue instead of speculating raw speed will outsmart human creativity.
Maybe Ada addicts should try to beat GNU chess instead of offering
speculations.


"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:<b8r3hu$m8$1@slb4.atl.mindspring.net>...
> Will <wv9557@yahoo.com> wrote in message
> news:4a885870.0304301937.b27ec47@posting.google.com...
> > According to Mr Meiners, Ada addicts should never attempt to rewrite
> > any chess programs in Ada. Apparently if you do, your program will not
> > do better than a C program with the same algorithm.
> >
> >
> According to some experts (me), rewriting *any* program in *any* language is
> mostly a waste of time. :-) You need to ask what is gained by building the
> thing twice? Maybe, possibly, sometimes, you have a buggy program that might
> benefit from being rewritten because you want the functionality but not the
> bugs. Changing languages (to Ada) might also help reduce the bugs. But if
> you are going to go that far, why not build a *new* program that does more
> or otherwise grows from the experience.
> 
> And it also seems intuitively obvious that executing the same algorithm in a
> different language ought to yield the same result, correct? So why would an
> Ada addict want to rewrite a chess program that (presumably) already works
> well?
> 
> MDC
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/
> 
> Send Replies To: m c o n d i c @ a c m . o r g
> 
>     "Going cold turkey isn't as delicious as it sounds."
>         -- H. Simpson
> ======================================================================

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dmitry A. Kazakov]

Kaz Kylheku wrote:

> Ada exceptions are a laughably low-level mechanism, that is about as
> powerful as some of the feeble C macro packages that wrap up setjmp
> and longjmp. Some of those packages are more powerful because they can
> subclass errors into categories.

Can those macros finalize things going out of scope? 

> Modern languages represent errors
> using class hierarchies,

Probably, what is actually needed, is just an order relation on the 
exception type. A subclassing relation induces an order, but isn't it a bit 
too much for that?

> allowing handlers to express more or less specific matches.

It is arguable whether exceptions should to be of any type. C++ way to do it 
has a heavy price. C++ exceptions are very inefficient and there are 
problems with dynamic memory allocation when an exception happens. Consider 
all issues which might appear in a multitasking and/or multiprocessor 
environment.

> An error handler should preserve the full dynamic context of the
> situation---this is how exception vectors in processor architectures
> work. When an interrupt happens, the currently running thread is not
> unwound all the way back to the operating system!

Ada's exception propagation mechanism is far more complex than you describe 
it. For example, when an exception is raised at a rendezvous point it is 
propagated in both the caller and the callee. Let you want to return 
exactly to the point where it was thrown, how could you do it?

> No, the exception
> pushes new information onto the stack, and can later restart the task
> exactly where it left off.  For example, you hit a page fault, the
> operating system's handler makes the page available, and then restarts
> the process, so the access instuction is tried again and succeeds this
> time.

... resuming a real-time task after 1.5 hours of trying to read a bad block!

> Unwinding on error is the stupidest possible thing to do; it
> allows for containment, but not recovery.

What can be recovered needs no exception. Exceptional state is when 
*nothing* useful can be done in the current context. The word nothing 
excludes any "recovery" for the given context. It is gone and dead.

> I would be tempted to hack up my own error system based on registering
> handler *functions*, and using the exceptions as the final step in
> error handling, to unwind to a restart point. The Ada exception
> handlers resemble Common Lisp's restarts in some ways, most notably
> that they are points in the dynamic context identified by symbols.
> But, sadly, there is no way to introspect over them; in other words,
> to compute a list or otherwise enumerate or iterate over the handlers
> that are visible in a given dynamic context. So you can't implement
> logic like ``if there is a handler for Foo exception, then raise it''
> which would represent the idea ``if a Foo way of continuing is
> available at this point, let's choose it''.

This has nothing to do with exceptions. It is rather a typical case for a 
dispatching subroutine = "handler". Again, the decision whether "a Foo way 
is available" *can* be made in the current context. So it is *not* an 
exceptional state at all. It would be just a bad design to try to express 
it in exceptions.

> A WHEN clause in the
> exception block also has no way of returning back to the raise point
> to show that it's declining to handle the error. Nevertheless, with
> this approach, one could perhaps implement some rudimentary error
> recovery protocols.
> 
> For example, suppose that we agree on a very simple convention that we
> will have two ways of continuing after an error: an Abort and Retry.
> When I call your module and it encounters a problem, it calls a
> handler callback in my module. No unwinding takes place yet. In my
> module I then decide (perhaps with the help of a user) whether to
> retry the operation or abort, and raise the appropriate exception,
> which passes back to your code. If I raise Retry, then the operation
> which failed will be tried again. Of course, I can raise some third
> exception that your module doesn't know about, to obtain a non-local
> exit that bypasses your module entirely. In other words, exceptions
> are really restart choices; the last step in the protocol for
> recovering from an error situation, based on making some sort of
> informed decision at a higher layer combined with advice at the lower
> layer.

If this is just a callback, then everything is already here. If it is 
something else, which has to run on both contexts, then how it is supposed 
to work? Consider a callee and a caller of one of its entry points running 
on different processors ...

> I'm warmly entertained, by the way, by how the string returned by
> Exception_Message may be truncated to 200 characters. Ah, assembly
> language and its fixed buffers.

Of course heap allocation of an Out_Of_Memory exception object would be much 
better ...

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

RE: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: mcq95@earthlink.net [mailto:mcq95@earthlink.net]
...
| This is one of the biggest misconceptions about type-safety and the
| languages that utilize it: that its primary purpose is just to help
| avoid bugs.  (And this is a misconception held by many Ada programmers
| as well.)
....
| The proper definition of types for an application allows the embedding
| of vast quantities of information that is there just for the asking by
| the application.
Not just application, but also code reader.

...
|   type Altitude is digits 6.0 range -100.0 .. 50_000.0;
For me, the main point here in this declaration is to move more programmer's
knowledge into the code than possible in any other comparable language.
This knowledge will otherwise resides in the comments, or some doc, or just
nowhere.

In consequence:
- the language is able to provide usefull attributes,
- code readability improve,
- one will reduce documentation/comments, avoid incoherencies between those
and code, avoid knowledge vanishing when the coder leave your company, etc.
- and yes, an Ada compiler provides compilation/execution time checks that
other compiler can't provide, and this is in my opinion by far more usefull
than attributes. 
- etc.

Despite this, i agree with you that type compilation/execution time checks
are just the most visible consequence of the powerfull Ada typing.
When i hear an Ada programmer saying that "its primary purpose is just to
help avoid bugs", i suggest the more general "its primary purpose is to
reduce development cost", and let's go for discussion! 

-- 
Lionel Draghi

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marin David Condic]

This is all some variation of the "Any *Competent* Programmer...." argument.
("Any *competent* programmer doesn't need type safety, etc...") It really
doesn't hold water. Just as competent writers still make spelling and
typographical errors, competent programmers make mistakes with in all sorts
of other ways. Sure, there are errors a compiler can't catch such as logic
and design errors, but there are numerous errors made by competent
programmers every day that a compiler *can* catch and this is a big help.

I collected data over a ten year stretch that involved productivity and
defects on jet engine control software. The results were that where Ada was
used we doubled productivity and reduced defects by a factor of four. I'd
like to think that the folks I worked with in developing controls were
"competent" and most had many years of experience, but still, the language
made a difference to the bottom line. My competitors are still using C. I
say "Good for them!" My improved productivity and reduced defects translates
into a better engine control at less cost. I'll take that benefit any time.

MDC


soft-eng <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305010621.55e99deb@posting.google.com...
>
> But you are assuming a stricter type safety translates
> to higher quality.
<snip>


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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marc A. Criley]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305011727.5eae0222@posting.google.com>...
> Like I said, Ada has amazing amounts of itsy-bitsy stuff.
> Now which of these features, if missing, would take you
> more than a minor effort to provide yourself?  If and
> when necessary, rather than present by default all the time?

As someone else noted, it requires _zero_ effort on my part to have
access to these standardized, portable, correctly implemented,
features.

Out of curiousity I did a quick scan of a little throwaway utility I
wrote to find out which attributes it utilizes.  Here's the list: 
'Range, 'Pos, 'Value, 'Read, 'Last, and 'Image.

Could I have still written the program using mechanisms other than
those attributes to accomplish their purpose?  Of course.  But I
didn't have to.  This was a throwaway program so I didn't want to
spend much time on it.  And all those attributes will continue to work
even if I alter the type definitions to which they're applied (which
can happen a lot when hacking out something quick and dirty).  Again,
I could have ensured that when I implemented their equivalents that
they would be flexible enough to handle that kind of modification. 
But this was a throwaway program, so why go to all that effort when I
can write:

   for H in Capped_Header'Range loop

With 'Range in particular, I didn't have to hardcode the array
bounds--it's just as "cheap" to type 'Range, and 'Range automatically
adapts to changed bounds.  I didn't have to define and maintain
#define's or consts to define those bounds, whose updating could be
overlooked.  I didn't have to write a CCappedHeader class with data
members and member functions first() and last(), or an iterator.

I typed one line of code in less than three seconds that was portable,
correct, and automatically adapted to changes in the array's type
definition.

How many portable, correct, and adaptable functions and classes can
you write in less than three seconds?

Marc A. Criley

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<4F03C83A9C6A478F.688C62D70A2EADA3.068FE6EB5E241C3B@lp.airnews.net>...

> 'first and 'last are necessary if you want to write loops over an arbitrary
> index type.  'succ and 'pred are absolutely critical if you want to step

Yes, each and every single itsy-bitsy feature of Ada can be justified in some
way or the other.

> The key is that, by putting them in the language, it is absolutely
> guaranteed that they will be implemented CORRECTLY, every time, with NO

The key is that by putting all these large number of trivialities in
the language, you make sure the language will be very large.

> PASCAL and Ada.  When C++ came out, and it was strongly typed, the silence
> from that corner of the auditorium was absolutely deafening.

Because C++ type safety allowed them to do whatever
they had been doing all along, while saving them
from the typos in what they had been doing all along.
If it hadn't, there would have been absolutely no hue
and cry over it -- because C++ would have remained an
obscure research project.

> Hardly.  Stroustrup took type safety in C++ from Simula 67, which actually
> predated PASCAL.

The Object Oriented architecture came from Simula 67 (I
am sure he must have been influenced by Smalltalk et al too.)

But the strong typing of C++ was designed to fit
well the existing C style of programming.  In fact,
it was later retrofitted into C (without breaking most
existing code.)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Martin Dowie]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305020507.6d071f2b@posting.google.com...
> > Hardly.  Stroustrup took type safety in C++ from Simula 67, which
actually
> > predated PASCAL.
>
> The Object Oriented architecture came from Simula 67 (I
> am sure he must have been influenced by Smalltalk et al too.)

Well, I doubt Alan Kay would agree with you "I invented the
term Object-Oriented, and I can tell you I did not have C++ in mind."

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message news:<ODlsa.134571$ja4.6028499@bgtnsc05-news.ops.worldnet.att.net>...
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0305011727.5eae0222@posting.google.com...
> > mcq95@earthlink.net (Marc A. Criley) wrote in message
>  news:<254c16a.0305011035.13133e8d@posting.google.com>...
> >
> > Yes, Ada extended Pascal very strongly in this regards,
> > without any particular consideration of how useful
> > these extensions would actually turn out to be.
> 
> Nonsense. The Ada designers knew very well how useful those
> extensions would turn out to be. After all, Ada was not designed

So why do you think Ada failed?

> > Like I said, Ada has amazing amounts of itsy-bitsy stuff.
> > Now which of these features, if missing, would take you
> > more than a minor effort to provide yourself?  If and
> > when necessary, rather than present by default all the time?
> 
> So, are you arguing against the sizeof operator in C and C++?
> Are you arguing against the Length field of an Java array?
> Are you arguing against C pointer arithmetic?
> 
> What feature of a high level language cannot be created with an
> individual effort from an assembler programmer?

Obviously, there is a middle ground.  If one feature
in a language is good, ten features aren't ten
times as good.  (Which I stated before in another form,
but apparently it is hard to understand.)

> Absolutely wrong. Ada did not extend Pascal. It simply belongs to
> the same syntax family, which is not rooted in Pascal. Algol came
> long before Pascal.

I suppose you could make that point theoretically.  But
at the time Ada came out, Pascal was very popular.

> There is nothing natural about the development of a language. Classes
> belonged to C++ from the very beginning. The same is true of Java.
> Those languages are not evolutionary developments. They were discrete

Ideas evolve -- someone sees something working in Simula, thinks
about it, and comes up with a new variation of the idea.
The new variation might work or not work.  It competes
against other new variations...

Same way, there exists a type system in C, and it
absolutely *has* to be kept.  But it needs fixing.
So ideas are kicked around how to fix it without
breaking too much.

That's what I meant by "natural development".

> Java is not an evolved C++. The design goals of the two languages are

Java takes a lot of ideas from C++.

> far different. C++, despite its name, is not merely a superset of C.
> If it were the C++ standard would need to subsume the C standard.
> It does not. The C++ standard exists independent of the C standard.
> 
> Your basic assumptions are invalid. This forces your conclusions to be
> invalid also.
> 
> Jim Rogers

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[soft-eng]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EB1C603.7788E194@adaworks.com>...
> soft-eng wrote:
> 
> > "John R. Strohm" <strohm@airmail.net> wrote in message news:<98BC68183770643E.43B22CFE5F4D5EFD.5566989BE627964B@lp.airnews.net>...
> >
> > > Why don't you *tell* us where your views on Ada come from?
> > >
> > > So far, you have said a great deal that suggests that you have NO actual
> > > experience with Ada.
> >
> > Mostly peripheral and theoretical.  Taught Ada to graduate students for
> > evening class.  Had to learn about it from an academic viewpoint.
> 
> One more amateur teaching Ada with no experience using it on
> projects.   There was so much of this going around that no one
> should be suprised that so many students came away from their
> Ada classes with a distorted view of the language.
> 
> Richard Riehle

There weren't any Ada projects at that time to have experience in!
Believe it or not, that's how teaching of new languages has to start,
particularly of languages like Ada with no existing industrial base.

But you are still insisting on arguing by insult, which I have little
interest in because it merely shows to me you have nothing valid to say.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Chad R. Meiners]

"Will" <wv9557@yahoo.com> wrote in message
news:4a885870.0305012015.7bea7358@posting.google.com...
> There is no algorithm. Most chess programs uses alpha beta pruning or some
> variation of it.

I hate to say it, but by definition if there is a program, then there is an
algorithm ;)

> Unfortunately there is only so much that alpha can help speed up the
> search. They employ other heuristics like killer moves, null moves.
Techniques
> like hashing greatly speed things up. Most will also have a quiescent
search,
> which basically search fully all the capture moves until there is no more
> captures, this is to avoid the horizon effect. Chess software is really
> more like  combination of techniques and intution than an exact algorithm.

Thus a better algorithm would have better heuristics to prune the search.

> Apparently the more positions you can look at an infinite amount of time

I think you meant a finite amount of time.  With in infinite amount of time
in chess you should be able to find a winning solution with an unoptimized
search ;)

> the stronger  your program is. Therefore an optimized assembly language
> program will beat the same C program, even if they use the same
techniques.
> Just because the assembly language can look at more positions than
> the C program. Implementation language DOES matters.

Implementation always matters; no one said that it did not matter.  Modern
Ada compilers are pretty good at optimizations so I would expect that there
should not be much of a difference between the run times of comparable C and
Ada programs.

> Now does anybody else still want to write an Ada chess program to beat
> GNU Chess? For your information, GNU Chess is one of the weakest program
> out there.

If a chess program is implemented in Ada that beats GNU Chess, what does it
prove?  It proves nothing interesting.  We already know that is possible to
write faster programs in Ada than C.  Interesting enough we also know that
is possible to write faster programs in C than Ada.  Implementation language
does not necessarily impact the speed of the resultant machine code.

>Thank God the IBM researches went ahead with creating
> Deep Blue instead of speculating raw speed will outsmart human creativity.
> Maybe Ada addicts should try to beat GNU chess instead of offering
> speculations.

False analogy--We have evidence for cases where similar algorithms result in
similar times; whereas, we have plenty of evidence that best guess
algorithms produce non-optimal results.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305020507.6d071f2b@posting.google.com...
> Yes, each and every single itsy-bitsy feature of Ada can be justified in
some
> way or the other.

This statement demonstrates your unwillingness to have a reasonable
discussion.

> The key is that by putting all these large number of trivialities in
> the language, you make sure the language will be very large.

Define large language and large number of trivialities.  For that matter
define trivial language feature.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305020516.bdba239@posting.google.com...

> So why do you think Ada failed?

It did not fail.  Why do you continue to ignore sound arguments and to spout
ignorance?

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Chad R. Meiners]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305020520.20859901@posting.google.com...

> But you are still insisting on arguing by insult,

It is more likely that Richard did not intend it to be insulting;  it is
just that you have demonstrated that you lack to ability to form sound
argument, to listen reasonability to others viewpoint and that you do not
understand Ada very well.  This qualifies you for the title of amateur along
with all the implication.  You dug your own ditch, and you should not be
insulted because someone points out that you are still in it.

> which I have little
> interest in because it merely shows to me you have nothing valid to say.

This too is a very foolish argument since Richard often has many valid
things to say ;)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Martin Dowie]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305020520.20859901@posting.google.com...
> > One more amateur teaching Ada with no experience using it on
> > projects.   There was so much of this going around that no one
> > should be suprised that so many students came away from their
> > Ada classes with a distorted view of the language.
>
> There weren't any Ada projects at that time to have experience in!

However, there are projects now and plenty of people continuing to
use it (and not just militery types either - networking, digital tv,
financial
services, etc). The language you are describing doesn't match very well
with what my experiences (particularly *recent* experiences) have been.

I've had experience of a couple of pretty awful Ada83 compilers and
one good one but my experience of Ada95 compilers is that they are
hugely improved and amoung the best compilers out there - in any
language. Perhaps this isn't too surprising - a lot was being asked of
the Ada83 compilers. Suddenly compiler writers were being asked
to include a lot of the work of an OS (in particular tasks).

The language itself has undergone one large increment from
Ada83 -> Ada95. It sounds to me like you haven't seen or used
much Ada95.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kevin Cline]

Richard Riehle <richard@adaworks.com> wrote in message news:<3EB1C603.7788E194@adaworks.com>...
> soft-eng wrote:
> 
> > "John R. Strohm" <strohm@airmail.net> wrote in message news:<98BC68183770643E.43B22CFE5F4D5EFD.5566989BE627964B@lp.airnews.net>...
> >
> > > Why don't you *tell* us where your views on Ada come from?
> > >
> > > So far, you have said a great deal that suggests that you have NO actual
> > > experience with Ada.
> >
> > Mostly peripheral and theoretical.  Taught Ada to graduate students for
> > evening class.  Had to learn about it from an academic viewpoint.
> 
> One more amateur teaching Ada with no experience using it on
> projects.   There was so much of this going around that no one
> should be suprised that so many students came away from their
> Ada classes with a distorted view of the language.

Do you think the situation is better for other languages?  It
certainly isn't for C++.  I've interviewed people who taught evening
classes in C++ and OOP at the university level and they were
hopelessly confused.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Graham Perkins]

"Kevin Cline" <kcline17@hotmail.com> wrote in message
news:ba162549.0305020720.4da44159@posting.google.com...
> > One more amateur teaching Ada with no experience using it on
> > projects.   There was so much of this going around that no one
> > should be suprised that so many students came away from their
> > Ada classes with a distorted view of the language.
>
> Do you think the situation is better for other languages?  It
> certainly isn't for C++.  I've interviewed people who taught evening
> classes in C++ and OOP at the university level and they were
> hopelessly confused.

The text books don't help.  So hard to find the
wheat amongst the chaff.

I once found a C++ book which doesn't start on classes
until chapter nine!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Mark]

Chad R. Meiners wrote:

> 
> Implementation always matters; no one said that it did not matter.  Modern
> Ada compilers are pretty good at optimizations so I would expect that there
> should not be much of a difference between the run times of comparable C and
> Ada programs.
> 

I would expect that GNU Chess is compiled with GNU gcc. GNAT uses the 
same technology. They are probably using the same optimizer since both 
are run through the same 'back-end'.

If the programs are 'comparable' there might not be any differences in 
run time!

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Richard Riehle]

soft-eng wrote:

> There weren't any Ada projects at that time to have experience in!
> Believe it or not, that's how teaching of new languages has to start,
> particularly of languages like Ada with no existing industrial base.
>
> But you are still insisting on arguing by insult, which I have little
> interest in because it merely shows to me you have nothing valid to say.

OK.  Not intending to insult you.   My point was that there was a lot
of Ada teaching going on by people with little experience in it.  You
were not the only one, and you may have been better than most.

This was also true of C++ in the beginning, so it is not unique to Ada.
And you are probably correct that any new technology with a minimal
installed base will take time for those teaching it to get up to speed.

Today, there is such a large number of successful Ada projects that
we would hope the quality of teaching it would be better.   However,
for both C++ and Ada (and probably other languages) I still see
people teaching them who have not written any serious programs,
have not stretched themselves in their learning how to make the
languages work well for real programming.

When Ada was first introduced, there were a lot of ideas that
were foreign to the programming community as a whole.  The
most important of these, one that is still not understood by a
lot of educators, is the importance of the visibility rules.  This
is one of Ada's most unique and powerful features, one that
lends itself to taking an engineering view of the software
process, but those teaching Ada (and many who are using it)
miss out on valuable opportunities by overlooking it.  Many
of the early Ada trainers totally missed the point  with regard
to this capability.   Many still do.

Richard Riehle

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Richard Riehle]

soft-eng wrote:

> The key is that by putting all these large number of trivialities in
> the language, you make sure the language will be very large.

1)  I suspect your understanding of the visibility rules in Ada is not
     well-developed.

2) Those itsy-bitsy features actually exist in most other languages, in one
     way or another.  They are the rules the compiler must follow to achieve
     reliable results.  In Ada, the rules are carefully defined.   In many other
     languages, they are carefully assumed.   For example, in C++, one still
     enjoys little surprises from time to time because some feature was not
     as rigorously specified (although this is getting better with time).

3) Because those rules are carefully and thoroughly specified, we can rely
    on the compiler to detect errors in our programs that we would not expect
    from compilers for other languages.   This may not be important for most
    software. However, the targeted domain for Ada is safety-critical software.
    Those who build software in that domain enjoy the benefits of a specification
    that is complete, thorough, and reliable.

4) When developing with a language not as carefully specified, one can achieve
     perfectly good results when there is an understanding that quality is dependent
     on understanding those open-ended items not specified by the language design.

5)  I recommend you choose a language other than Ada for your work.  However,
     I also suggest you might appreciate the fact that the airplane on which you
     travel from one coast to the other is programmed in Ada, that the GPS
     satellite that helps you find your way when lost is programmed in Ada, and
     the communication satellite that brings you your Monday night football is
     programmed in Ada.

Richard Riehle

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Richard Riehle]

soft-eng wrote:

> So why do you think Ada failed?

Ada has not failed.  It has been successful in a large number of
military and non-military projects.   You may want to read my
article on the abrogation of the Ada mandate in the February issue
of Crosstalk.

                  http://stsc.hill.af.mil/Crosstalk

Actually, there are several excellent articles on programming languages
in that issue of Crosstalk.

Regards,

Richard Riehle

Re: Using Ada for device drivers?

[Georg Bauhaus]

In comp.lang.ada Kaz Kylheku <kaz@ashi.footprints.net> wrote:
: 
: Newsflash: ``Ada versus C'' is not interesting. Ada and C are much
: more similar than they are different. If you don't think so, it's only
: because you are too absorbed in the arcane details that separate your
: favorite high level assembly language from the next one.

 Care to give some substantiation, or a pointer to some substantiation?

 Since you give no details, let me take this argument one step
further. It doesn't make much difference what class of languages
one uses, because it all runs on plain old sequential processors,
even if there are many, and interrupts... See?

If you look at some of the more recent non-EVAL languages
(C++/STL, Eiffel, Ada 95) then, yes, certainly there are things
in these languages that just cannot be done without EVAL, and
therefore they could be said to be similar. But that view misses
some aspects of the economic software world you mention. 
Choosing the right tool for the job, for one thing. Now make the
job include distributed execution on heterogenous hardware, or
changing operating systems.

As to C vs Ada, how well defined are the distributed facilities
of the languages in question? What does that mean for a large
distributed application, running on not-just-one-PC-and-one-OS?
Answer: There is no trace of "distribution", not even of concurrency,
in C. I wonder how that distinct feature of Ada vs C can be
discarded, economically.

If you subtract, from the "non-C-class" languages,
the facilities that make them run fast enough in not more memory
than is available (FFIs, SETF like constructs), what remains?
Languages that are very interesting but not necessarily viable for
projects where non-EVAL languages are viable solutions.

Why is it that Erlang stresses a feature that allowes speedy things
to be written not in Erlang but linked to the resulting Erlang-program?

: Writing UI in either Ada or C is a waste of productivity that could
: only possibly be justified in a freeware project, or some
: tax-dollar-supported researchy thing. (To be clear, I don't mean
: *morally* justified, only economically).

What is the alternative, in general?
There are many cases where spending a lot of time on the UI is
deemed extremely important, economically. Games come to mind,
Office programs, Film+Music software, mobile gimicks.
Can this be done using a quickly programmed (and dirty, in a sense)
UI toolkits?
Computer buyers are very sensitive to UIs. For the technical users,
think of language syntax (interface to a language ;-), for the non-technical
think of Word's animated paper clip, which is certainly of economical
importance to the producers of Word.
So there is economic reason to make these things both speedy enough and
well fitting with the system's appearance. Can this be achieved in Tcl/Tk,
for example? No.
A whole industry makes profit producing user interfaces that are as
fine tuned as budget allows and these budgets are most generous:
Advertising, and marketing.
For another economically important UI, how much time can
justifiably be spent on the design of display UIs in ticket vending
machines, in laundromats, in car navigation systems?
What do you use in such systems?


Georg

Re: Using Ada for device drivers?

[Robert A Duff]

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

> think of Word's animated paper clip, which is certainly of economical
> importance to the producers of Word.

There ought to be a law saying no programmer may work on animated paper
clips until the software has exactly zero bugs.  ;-)

- Bob

Re: Using Ada for device drivers?

[Georg Bauhaus]

In comp.lang.ada Kaz Kylheku <kaz@ashi.footprints.net> wrote:
: Ada's exception system is not useful for much more than containing
: errors.

Which is what is is made for?

: The correct design for error handling is to unwind to an
: outer dynamic context *as a the very last step*, after an analysis is
: performed and the proper place to unwind to has been chosen.

Correct WRT what? This computation will certainly take some time,
which may be a completely incorrect choice given some desired run
time behaviour. (For example, a retry a la Eiffel, without analysis,
might be just quick enough.)

: I'm warmly entertained, by the way, by how the string returned by
: Exception_Message may be truncated to 200 characters. Ah, assembly
: language and its fixed buffers.

Where in assembly language is there a requirement for fixed buffers?
Where in assembly language are there buffers at all, for a start?

Oh these darn fixed buffers. Can't we compute on an infinite tape?

Seriously, I think these interesting thoughts deliberately hide
their assumptions about the prerequisites for execution of the program.
Otherwise we might as well introduce dynamic programming into error
handling. Which is certainly quite interesting.


Georg

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Hyman Rosen]

In tribute to Ada, my C++ code usually contains

template<typename T>
std::string image(const T &value)
{
     std::ostringstream o;
     o << value;
     return o.str();
}

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Tom Welsh]

In article <9fa75d42.0305020507.6d071f2b@posting.google.com>, soft-eng
<softeng3456@netscape.net> writes
>"John R. Strohm" <strohm@airmail.net> wrote in message news:<4F03C83A9C6A478F.68
>8C62D70A2EADA3.068FE6EB5E241C3B@lp.airnews.net>...
>
>> 'first and 'last are necessary if you want to write loops over an arbitrary
>> index type.  'succ and 'pred are absolutely critical if you want to step
>
>Yes, each and every single itsy-bitsy feature of Ada can be justified in some
>way or the other.
>
>> The key is that, by putting them in the language, it is absolutely
>> guaranteed that they will be implemented CORRECTLY, every time, with NO
>
>The key is that by putting all these large number of trivialities in
>the language, you make sure the language will be very large.
>

That is a tradeoff that each language designer has to make. In the case
of Ada, it was desirable to include a large set of features because one
of the language's main objectives was to support programming in the
large, including realtime and concurrent programmming. Then there is the
compilation system...

Pascal, for example, is much smaller and tidier. That makes it more
suitable as a first language for students to learn - which was one of
its design goals. On the other hand, its very simplicity has sometimes
made unextended Pascal inappropriate for production systems.
-- 
Tom Welsh

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Tom Welsh]

In article <9fa75d42.0305020516.bdba239@posting.google.com>, soft-eng
<softeng3456@netscape.net> writes
>
>So why do you think Ada failed?
>

What makes you think Ada failed?

It doesn't get a lot of publicity compared with C++, C sharp or Java.

Then again, neither do CICS, IMS, Tandem NonStop, VMS or CORBA - all of
which are involved to a greater or lesser extent in driving a lot of the
amenities we take for granted every day.
-- 
Tom Welsh

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Jim Rogers]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305020516.bdba239@posting.google.com>...
> "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message news:<ODlsa.134571$ja4.6028499@bgtnsc05-news.ops.worldnet.att.net>...
> > "soft-eng" <softeng3456@netscape.net> wrote in message
> > news:9fa75d42.0305011727.5eae0222@posting.google.com...
> > > mcq95@earthlink.net (Marc A. Criley) wrote in message
>  news:<254c16a.0305011035.13133e8d@posting.google.com>...
> > >
> > > Yes, Ada extended Pascal very strongly in this regards,
> > > without any particular consideration of how useful
> > > these extensions would actually turn out to be.
> > 
> > Nonsense. The Ada designers knew very well how useful those
> > extensions would turn out to be. After all, Ada was not designed
> 
> So why do you think Ada failed?

I see. Let's change the subject.

How do you determine the success or failure of a language?
Did Cobol succeed or fail?
Did Fortran succeed or fail?
Did Bourne Shell succeed or fail?
How about Common Lisp, smalltalk, or eiffel?

> 
> > > Like I said, Ada has amazing amounts of itsy-bitsy stuff.
> > > Now which of these features, if missing, would take you
> > > more than a minor effort to provide yourself?  If and
> > > when necessary, rather than present by default all the time?
> > 
> > So, are you arguing against the sizeof operator in C and C++?
> > Are you arguing against the Length field of an Java array?
> > Are you arguing against C pointer arithmetic?
> > 
> > What feature of a high level language cannot be created with an
> > individual effort from an assembler programmer?
> 
> Obviously, there is a middle ground.  If one feature
> in a language is good, ten features aren't ten
> times as good.  (Which I stated before in another form,
> but apparently it is hard to understand.)

Are you saying that high level features are good but only if
the language has very few of them?

What is the opitimal number? How is that number determined?

> 
> > Absolutely wrong. Ada did not extend Pascal. It simply belongs to
> > the same syntax family, which is not rooted in Pascal. Algol came
> > long before Pascal.
> 
> I suppose you could make that point theoretically.  But
> at the time Ada came out, Pascal was very popular.

What has popularity got to do with truth?
By the way, did Pascal succeed or fail?

> 
> > There is nothing natural about the development of a language. Classes
> > belonged to C++ from the very beginning. The same is true of Java.
> > Those languages are not evolutionary developments. They were discrete
> 
> Ideas evolve -- someone sees something working in Simula, thinks
> about it, and comes up with a new variation of the idea.
> The new variation might work or not work.  It competes
> against other new variations...

Gee. That sounds a lot like the way Ada was developed.
The ideas and accomplishments of many languages were considered
during the development of the language. By your definition, Ada
was an evolutionary development.

> 
> Same way, there exists a type system in C, and it
> absolutely *has* to be kept.  But it needs fixing.
> So ideas are kicked around how to fix it without
> breaking too much.

So, did the type system succeed or fail? Did it succeed because
it was broken? Will C enjoy greater success with a fixed type
system?

> 
> That's what I meant by "natural development".

So unnatural development would be the invention of something
completely new. Interesting. Would that require some form of
devine intervention?

How would you describe the invention of the punch cards used in
the Jacquard loom? Would that be natural or not? Does "natural
development" imply a virtue not found in other kinds of 
development?

> 
> > Java is not an evolved C++. The design goals of the two languages are
> 
> Java takes a lot of ideas from C++.

It also takes a lot of ideas from smalltalk. Why not call it an
evolved smalltalk?

Jim Rogers

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Will]

I hate to say it but your definition of algorithm is wrong. Algorithm
is an established and provable way to  solve a problem. There are
steps you can follow to solve a Rubik cube. Now that is an algorithm.
There is no documented way, that I know of, to win a chess game.
Therefore there is not a chess algorithm.



"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<b8u0u5$2ere$1@msunews.cl.msu.edu>...
> "Will" <wv9557@yahoo.com> wrote in message
> news:4a885870.0305012015.7bea7358@posting.google.com...
> > There is no algorithm. Most chess programs uses alpha beta pruning or some
> > variation of it.
> 
> I hate to say it, but by definition if there is a program, then there is an
> algorithm ;)
> 
> > Unfortunately there is only so much that alpha can help speed up the
> > search. They employ other heuristics like killer moves, null moves.
>  Techniques
> > like hashing greatly speed things up. Most will also have a quiescent
>  search,
> > which basically search fully all the capture moves until there is no more
> > captures, this is to avoid the horizon effect. Chess software is really
> > more like  combination of techniques and intution than an exact algorithm.
> 
> Thus a better algorithm would have better heuristics to prune the search.
> 
> > Apparently the more positions you can look at an infinite amount of time
> 
> I think you meant a finite amount of time.  With in infinite amount of time
> in chess you should be able to find a winning solution with an unoptimized
> search ;)
> 
> > the stronger  your program is. Therefore an optimized assembly language
> > program will beat the same C program, even if they use the same
>  techniques.
> > Just because the assembly language can look at more positions than
> > the C program. Implementation language DOES matters.
> 
> Implementation always matters; no one said that it did not matter.  Modern
> Ada compilers are pretty good at optimizations so I would expect that there
> should not be much of a difference between the run times of comparable C and
> Ada programs.
> 
> > Now does anybody else still want to write an Ada chess program to beat
> > GNU Chess? For your information, GNU Chess is one of the weakest program
> > out there.
> 
> If a chess program is implemented in Ada that beats GNU Chess, what does it
> prove?  It proves nothing interesting.  We already know that is possible to
> write faster programs in Ada than C.  Interesting enough we also know that
> is possible to write faster programs in C than Ada.  Implementation language
> does not necessarily impact the speed of the resultant machine code.

Every now and then, I see people trying things like rewriting OS in
Ada
(the Marte project) or doing DirectX in Ada. Despite of my profound
aversion
for Ada, I am impressed by what they are trying to do. I don't think 
they are out to prove a thing

> 
> >Thank God the IBM researches went ahead with creating
> > Deep Blue instead of speculating raw speed will outsmart human creativity.
> > Maybe Ada addicts should try to beat GNU chess instead of offering
> > speculations.
> 
> False analogy--We have evidence for cases where similar algorithms result in
> similar times; whereas, we have plenty of evidence that best guess
> algorithms produce non-optimal results.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote:
> 
> How do you determine the success or failure of a language?

A) how many people use it and for what magnitude of tasks, and 

B) how influential its design and ideas were intellectually,
and how many other languages were influenced by it and
how many times it itself gets revised with new ideas

> Did Cobol succeed or fail?

succeed / fail 

> Did Fortran succeed or fail?

succeed / succeed

> Did Bourne Shell succeed or fail?

succeed / fail 

> How about Common Lisp, smalltalk, or eiffel?

fail/succeed
partial succeed/partial succeed
fail/partial succeed

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On 2 May 2003 06:07:52 -0700, soft-eng <softeng3456@netscape.net> wrote:
> 
> But the strong typing of C++ was designed to fit
> well the existing C style of programming. 

nay. 

the clash between those and the existence of the "&" operator
is responsible for many crimes.

> In fact,
> it was later retrofitted into C (without breaking most
> existing code.)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Chad R. Meiners]

"Will" <wv9557@yahoo.com> wrote in message
news:4a885870.0305021913.31ffb745@posting.google.com...
> I hate to say it but your definition of algorithm is wrong. Algorithm
> is an established and provable way to  solve a problem.

An algorithm is any sequence of well defined instructions that halt.
Whether or not an algorithm solves a problem is irrelevant.

> There is no documented way, that I know of, to win a chess game.
> Therefore there is not a chess algorithm.

There are a finite number of states in which a chessboard can be configured.
Thus, the existence of a winning strategy can be determined in a finite
amount of time.  Unfortunately the cost in time is rather large, but it is
finite; thus, an optimal chess algorithm exists.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

> I once found a C++ book which doesn't start on classes
> until chapter nine!

I own a "C Primer" which NEVER informs the reader that
C is case-sensitive.  And the only hint I could find
(and I was hunting for one) was a code snippet

void funcname (FILE file)
{
.....

and this was in chapter eleven!

If you're thinking that case-sensitivity is something
the reader already knew... this book was allegedly aimed
at beginners in the MSDOS world!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Bill Findlay]

On 2/5/03 22:20, in article 34Y+3LACEus+EwF5@nildram.co.uk, "Tom Welsh"
<news@tom-welsh.co.uk> wrote:
 
> 
> That is a tradeoff that each language designer has to make. In the case
> of Ada, it was desirable to include a large set of features because one
> of the language's main objectives was to support programming in the
> large, including realtime and concurrent programmming. Then there is the
> compilation system...
> 

What you don't know about Ada does not hurt you, so its absolute size is
pretty irrelevant to a teaching argument.

Once you get past the basics, Ada's strong support for OOP, programming in
the large, concurrent programming, and consistency-enforcing compilation are
all major assets of Ada as a teaching language.

> Pascal, for example, is much smaller and tidier. That makes it more
> suitable as a first language for students to learn - which was one of
> its design goals. On the other hand, its very simplicity has sometimes
> made unextended Pascal inappropriate for production systems.

Pascal is certainly smaller than Ada, but it is NOT tidier.
Both the syntax and the semantics of Ada are much more consistent, and
therefore easier to learn.

I was formerly at a university that has been teaching 400-500 novices a year
in Ada 95 since 1997. More students become able to write working code with
confidence, sooner, and more consistently, than they ever did with Pascal
(the previous teaching language).

The staff teaching those courses have successful beaten off an attempt to
replace Ada 95 with Java, and are set to go on with Ada for another 5 years.

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Hyman Rosen]

Wesley Groleau wrote:
> I own a "C Primer" which NEVER informs the reader that
> C is case-sensitive.
> 
> If you're thinking that case-sensitivity is something
> the reader already knew... this book was allegedly aimed
> at beginners in the MSDOS world!

MS-DOS had case-insensitive file names, but that doesn't mean
that case-insensitivity is an assumed default. If it was, so
many people on c.l.a wouldn't complain when people discuss ADA.

Re: Using Ada for device drivers?

[Hyman Rosen]

Georg Bauhaus wrote:
> Answer: There is no trace of "distribution", not even of concurrency,
> in C. I wonder how that distinct feature of Ada vs C can be
> discarded, economically.

Because people have in fact written multithreaded and distributed
programs in C and in C++, so it's not exactly a mystery how to do
it. Furthermore, that Ada 95 had to come up with a new concurrency
mechanism (protected objects) is evidence that people were unhappy
with the facilities available in Ada 83, at least for some uses.
One could then make an argument against Ada by asking whether it
is certain that Ada got it right this time.

Re: Using Ada for device drivers?

[Georg Bauhaus]

In comp.lang.ada Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> Answer: There is no trace of "distribution", not even of concurrency,
:> in C. I wonder how that distinct feature of Ada vs C can be
:> discarded, economically.
 
: Because people have in fact written multithreaded and distributed
: programs in C and in C++, so it's not exactly a mystery how to do
: it.

Because people have done something means what?
Because people have not done something means what?
Q: with ease, at what cost, portably, with predictable outcome?
I'll concede that not every multihreaded and distributed program
needs to be portable to be economically worth something.
Does that mean anything in a general language comparison?

: Furthermore, that Ada 95 had to come up with a new concurrency
: mechanism (protected objects) is evidence that people were unhappy
: with the facilities available in Ada 83, at least for some uses.

That is easy to say, as there have been few alternatives if you
wanted tasking as part of a pratically portable, language. Am I wrong?

: One could then make an argument against Ada by asking whether it
: is certain that Ada got it right this time.

It is made, prominently, and for different reasons, by Bertrand
Meyer in OOSC2; he now has, in his position of professor at
ETH Zuerich, asked for collaborators to get concurrency right
in Eiffel one could say. It has been there for some time, though
not really... 


Georg

Re: Using Ada for device drivers?

[Hyman Rosen]

Georg Bauhaus wrote:
> Because people have done something means what?
It means that it can be done.

> Because people have not done something means what?
That we do not yet know whether it can be done.

> Does that mean anything in a general language comparison?
We're not talking about general language comparisons.
We're talking about a company choosing an implementation
language for a project.

> That is easy to say, as there have been few alternatives if you
> wanted tasking as part of a pratically portable, language. Am I wrong?

See above. The desire is for tasking/distribution in a particular
project.

Re: Using Ada for device drivers?

[Peter Hermann]

it
> is certain that Ada got it right this time.

look at the lyrics of my signature.                 :-)
what a coincidence (like a hand in the glove)

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[The Ghost In The Machine]

In comp.lang.java.advocacy, Wesley Groleau
<wesgroleau@despammed.com>
 wrote
on Fri, 02 May 2003 23:24:38 -0500
<MdmdnaZFI5fz2S6jXTWcpA@gbronline.com>:
> 
>> I once found a C++ book which doesn't start on classes
>> until chapter nine!
> 
> I own a "C Primer" which NEVER informs the reader that
> C is case-sensitive.  And the only hint I could find
> (and I was hunting for one) was a code snippet
> 
> void funcname (FILE file)
> {
> .....
> 
> and this was in chapter eleven!

It's also wrong; it should be

void funcname(FILE * file)

:-)

Sounds like that C Primer is better used in making primer
than in being one... :-)

> 
> If you're thinking that case-sensitivity is something
> the reader already knew... this book was allegedly aimed
> at beginners in the MSDOS world!
> 

-- 
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message news:<82347202.0305021418.4719da45@posting.google.com>...

> How do you determine the success or failure of a language?
> Did Cobol succeed or fail?
> Did Fortran succeed or fail?
> Did Bourne Shell succeed or fail?
> How about Common Lisp, smalltalk, or eiffel?

I suppose you could define success as "having a name
that starts and ends with the letter a" and then claim
Ada as being wildly successful.

However, by more objective criteria, the language
failed to meet most of its expectations.  It was
expected to be used primarily in ALL government
work within a few years, and there was a general
expectation that it will also become very
popular outside the government.  (Sorry, not
going to define "general", "expectation", "will",
"government"...)

> Are you saying that high level features are good but only if
> the language has very few of them?
> 
> What is the opitimal number? How is that number determined?

Ah, we need more strict definitions!  Sorry, this is common
sense.  If you take sugar in your coffee,
too little is going to taste bad and so is too much.
Exact counting of granules is not necessary or relevant.
(Though maybe someone could do a study on ranges
where a language might become "feature-heavy", but
it's very difficult, because first you have to rank
features and separate "deep concept"s from "itsy-bitsy-feature"s,
from "nice-to-have-feature"s and so on...)

> > > Absolutely wrong. Ada did not extend Pascal. It simply belongs to
> > > the same syntax family, which is not rooted in Pascal. Algol came
> > > long before Pascal.
> > 
> > I suppose you could make that point theoretically.  But
> > at the time Ada came out, Pascal was very popular.
> 
> What has popularity got to do with truth?

Simply that Ada designers were much more likely to have
been exposed in depth to Pascal, than to the "Algol family tree".

> By the way, did Pascal succeed or fail?

Depends upon your definitions, but by normal definitions
it was very successful until early 80s, then was
replaced as C became very successful.

> Gee. That sounds a lot like the way Ada was developed.
> The ideas and accomplishments of many languages were considered
> during the development of the language. By your definition, Ada
> was an evolutionary development.

No, you need to learn the history of Ada.
Ada was not a slow natural development.  It was artificially
developed at the behest of, and following the requirements of,
the DoD.

> So, did the type system succeed or fail? Did it succeed because
> it was broken? Will C enjoy greater success with a fixed type
> system?

C type-sytem was more useful, and that's why C succeeded and
replaced Pascal even though Pascal had a strict and
theoretically better (according to some definitions)
type system.

> So unnatural development would be the invention of something
> completely new. Interesting. Would that require some form of
> devine intervention?
> How would you describe the invention of the punch cards used in
> the Jacquard loom? Would that be natural or not? Does "natural
> development" imply a virtue not found in other kinds of 
> development?

I think there was an actual point I made.
Witticisms are nice, but sound even better if you
understand and actually refute the point wittily.

Re: Using Ada for device drivers?

[Georg Bauhaus]

In comp.lang.ada Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> Because people have done something means what?
: It means that it can be done.

SPITBOL (and SNOBOL4) has been written in assembly
language. Can be done. Are languages of its type written
in assembly language?
 
You can write functions working on trees or graphs in 
Fortran 77. Can be done. Do you prefer choosing a language
for your recursive matters such that you will have the freedom
of managing the stack yourself?

:> Because people have not done something means what?
: That we do not yet know whether it can be done.
 
Or that they have known it was not a good idea to do it.

:> Does that mean anything in a general language comparison?
: We're not talking about general language comparisons.
: We're talking about a company choosing an implementation
: language for a project.

So narrow general down to what is best for some project.
In particular, the projects mentioned here recently.

Re: Using Ada for device drivers?

[Hyman Rosen]

Georg Bauhaus wrote:
> So narrow general down to what is best for some project.
> In particular, the projects mentioned here recently.

You said "There is no trace of "distribution", not even of
concurrency,in C. I wonder how that distinct feature of Ada
vs C can be discarded, economically." and I told you.

Why do you assume that the people who narrowed down to C
instead of Ada didn't do it because it was best for their
project?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Jim Rogers]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305060521.400f1d80@posting.google.com>...
> jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message news:<82347202.0305021418.4719da45@posting.google.com>...
> 
> > How do you determine the success or failure of a language?
> > Did Cobol succeed or fail?
> > Did Fortran succeed or fail?
> > Did Bourne Shell succeed or fail?
> > How about Common Lisp, smalltalk, or eiffel?
> 
> I suppose you could define success as "having a name
> that starts and ends with the letter a" and then claim
> Ada as being wildly successful.

Nope.
I never claimed any language has been successful or
unsuccessful. I only want to understand how you arrive
at your conclusions.

> 
> However, by more objective criteria, the language
> failed to meet most of its expectations.  It was
> expected to be used primarily in ALL government
> work within a few years, and there was a general
> expectation that it will also become very
> popular outside the government.  (Sorry, not
> going to define "general", "expectation", "will",
> "government"...)

Expectations are a marketing issue. Language design goals
are a technical issue. Ada meets its language design goals
very well, as do most languages. Ada has had some remarkably
bad marketing.

> 
> > Are you saying that high level features are good but only if
> > the language has very few of them?
> > 
> > What is the opitimal number? How is that number determined?
> 
> Ah, we need more strict definitions!  Sorry, this is common
> sense.  If you take sugar in your coffee,
> too little is going to taste bad and so is too much.

You are willing to accept that a proper number of high level
features is, to expand on your analogy, a matter of taste.

(one lump or two?)

> Exact counting of granules is not necessary or relevant.
> (Though maybe someone could do a study on ranges
> where a language might become "feature-heavy", but
> it's very difficult, because first you have to rank
> features and separate "deep concept"s from "itsy-bitsy-feature"s,
> from "nice-to-have-feature"s and so on...)

And you have to determine which feature is a deep concept and
which is "itsy-bitsy". Again, this becomes a matter of personal
judgement rather than an objective measure.

> > Gee. That sounds a lot like the way Ada was developed.
> > The ideas and accomplishments of many languages were considered
> > during the development of the language. By your definition, Ada
> > was an evolutionary development.
> 
> No, you need to learn the history of Ada.
> Ada was not a slow natural development.  It was artificially
> developed at the behest of, and following the requirements of,
> the DoD.

I am quite familiar with the history of Ada. It is every bit
as evolutionary as C, C++, Java, or Eiffel. All these languages
were built borrowing ideas from existing languages. Each of these
languages was built with a particular set of design goals. Each
of these languages was built by the primary efforts of an
individual or small team.

C was built to satisfy the requirements of Bell Laboratories.
C++ was built to satisfy another set of requirements at Bell
Laboratories.
Java was built to satisfy a set of requirements from Sun.
Ada was built to satisfy a set of requirements from the U.S. DoD.

Nothing in that history points to a difference in how the language
was developed. I suppose you will state that the DoD was more 
specific in their requirements definition than were the other
organizations. That may be so. Requirements, however, are not
implementation. The implementation was supplied by a the team
that developed Ada, working for Thompson CSF of France.

> 
> > So, did the type system succeed or fail? Did it succeed because
> > it was broken? Will C enjoy greater success with a fixed type
> > system?
> 
> C type-sytem was more useful, and that's why C succeeded and
> replaced Pascal even though Pascal had a strict and
> theoretically better (according to some definitions)
> type system.

Pascal's type system was also inconsistent and contradictory.
Remember Pascal's design goal. It was designed to be a teaching
language, not a language used for commercial production. In fact
Pascal did very well for many decades, dominating all languages
used as a first programming language in colleges and universities
around the globe.

C has never achieved a similar acceptance as a first teaching
language. On the other hand, C was never designed to be a teaching
language. It was designed to provide a high level assembler with
what was at the time an unprecedented level of portability.

> 
> > So unnatural development would be the invention of something
> > completely new. Interesting. Would that require some form of
> > devine intervention?
> > How would you describe the invention of the punch cards used in
> > the Jacquard loom? Would that be natural or not? Does "natural
> > development" imply a virtue not found in other kinds of 
> > development?
> 
> I think there was an actual point I made.
> Witticisms are nice, but sound even better if you
> understand and actually refute the point wittily.

I am sure you think you made a point. I am also sure that I do
not clearly understand your point. 

Since a number of your metrics for language success are subjective,
I currently conclude that your overall assessment is also 
subjective. Subjective assessments are fine. They can also be very
difficult to clearly explain to others.

Jim Rogers

Re: Using Ada for device drivers?

[Jim Rogers]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<G1dta.37139$D%4.27228@nwrdny03.gnilink.net>...
> Georg Bauhaus wrote:
> > Answer: There is no trace of "distribution", not even of concurrency,
> > in C. I wonder how that distinct feature of Ada vs C can be
> > discarded, economically.
> 
> Because people have in fact written multithreaded and distributed
> programs in C and in C++, so it's not exactly a mystery how to do
> it. Furthermore, that Ada 95 had to come up with a new concurrency
> mechanism (protected objects) is evidence that people were unhappy
> with the facilities available in Ada 83, at least for some uses.
> One could then make an argument against Ada by asking whether it
> is certain that Ada got it right this time.

And people have made pictures by glueing colored stones to a
background. This does not make the use of C or C++ either a
best technical choice or a best economical choice for multithreaded
designs.

In fact there were some problems with the original Ada design for
task communication. Under certain conditions the rendezvous
mechanism encountered race conditions. This problem was fixed in
Ada 95. Additionally, the protected object mechanism was added.

Note that C and C++ concurrency must be explicitly based upon
multiprocessing or multithreading. The Ada model is not so
explicit. Operating systems supporting threading are relatively
new compared to the languages C, C++, and Ada. Most commercial
operating systems prior to 1994 provided no support for what is
now called threads. Ada compilers would implement concurrency
using multiple processes. Currently many commercial operating
systems support some flavor of threads. The same Ada code can
be recompiled with a current compiler targeted at a modern
operating system. It would then use threads instead of processes.
C and C++ provide no comperable source code portability across
operating system generations.

It turns out that the Ada protected object is both highly
reliable and highly efficient. The relatively high level of
design abstraction allowed by Ada protected objects results in
correct, efficient code much faster than can be achieved using
the low level threading libraries available to C and C++.

One of the areas of particular difficulty using C and C++
thrading libraries is dealing with operating system interrupts.
The general consenus in comp.programming.threads is that one
should avoid mixing interrupts and threads using C or C++.
Ada 95 provides a very clean interrupt handling model that takes
advantage of concurrency and tasking. This is possible because
the solution is part of the language syntax, not simply an
external library. The compiler can actually understand what
you are creating and provide the correct level of optimization
and isolation.

Compare the Ada protected object to the Java monitor. Both
are supposed to be used for the same purposes. The Java monitor
employs a lower level of abstraction. It also provides a less
efficient and less deterministic implementation. By comparison
Ada got it right and Java got it wrong. Even worse, Java has
deprecated some of its Thread class methods because they have been
found to create deadlocks. Java is not even in the position to
correct the problem. It now expects the programmer to develop a
correct way to stop a thread without specific help from the
language. The rules about creating Java monitors result in awful
violations of class coupling and encapsulation rules. In this 
manner Java threads are bad citizens within Java itself.

Jim Rogers

Re: Using Ada for device drivers?

[Hyman Rosen]

Jim Rogers wrote:
> And people have made pictures by glueing colored stones to a
> background. This does not make the use of C or C++ either a
> best technical choice or a best economical choice for multithreaded
> designs.

I didn't say that C or C++ was the best choice. I just said that since
it is possible to write multithreaded and distributed programs in C and
C++ (and these are in fact written all the time), the fact that Ada has
these features built in to the language while C and C++ require libraries
is not enough in itself to dismiss C and C++ from consideration.

Re: Using Ada for device drivers?

[Larry Kilgallen]

In article <82347202.0305061140.53347ae1@posting.google.com>, jimmaureenrogers@worldnet.att.net (Jim Rogers) writes:

> Note that C and C++ concurrency must be explicitly based upon
> multiprocessing or multithreading. The Ada model is not so
> explicit. Operating systems supporting threading are relatively
> new compared to the languages C, C++, and Ada. Most commercial
> operating systems prior to 1994 provided no support for what is
> now called threads. Ada compilers would implement concurrency
> using multiple processes.

Or by supporting threads in their run-time library, like VAX Ada from DEC.

Re: Using Ada for device drivers?

[Georg Bauhaus]

In comp.lang.ada Hyman Rosen <hyrosen@mail.com> wrote:
: You said "There is no trace of "distribution", not even of
: concurrency,in C. I wonder how that distinct feature of Ada
: vs C can be discarded, economically." and I told you.
 
You said that "people have in fact written multithreaded and
distributed programs in C", to which I could, perhaps boringly,
reply that "people have in fact written multithreaded
and distributed programs in Ada". Reopening the question.

: Why do you assume that the people who narrowed down to C
: instead of Ada didn't do it because it was best for their
: project?

Well, I think I haven't, really.

Anyway, I feel like I am reiterating some old subject and
stop now.

Regards, Georg

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Wesley Groleau]

>>I own a "C Primer" which NEVER informs the reader that
>>C is case-sensitive.  And the only hint I could find
>>(and I was hunting for one) was a code snippet
>>
>>void funcname (FILE file)
>>and this was in chapter eleven!
> 
> It's also wrong; it should be
> void funcname(FILE * file)

I think that's my mistake, not the book
(not handy to look up right now)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message news:<82347202.0305061103.2ddd98e4@posting.google.com>...

> C was built to satisfy the requirements of Bell Laboratories.

Ah, I see.  You have no experience with actual
research environments!

That's not work it works.  Bell Labs did not come
up with something like "now this set of research engineers
will design a language, as per this set of requirements".
Research labs can't get very many useful results that way.

Ken Thompson in fact started working on developing a
Fortran compiler for his project's needs, but
didn't like it and instead ended up creating a
language called "B", based upon something
called "BCPL".

People at Bell Labs liked "B", and started using it.  It
picked up direction and momentum, and with some work
from Dennis Ritchie, ended up as as "NB" (new "B")
and then "C".  Even "C" didn't start off in any
kind of stable form.  There were many early changes
and revisions.

In fact, that may have been the major underlying
strength of C -- it was designed by people who
were also using it.  They *had* to make it usable.
(As opposed to Ichbiah, who *had* to make it impressive
to a committee.)  In fact, the languages B and C were
so evolution driven that they did not have a chicken-and-egg
problem of compilers-and-language variety.  From the
early stages, the languages had compilers written in
themselves!  If you are doing something complex enough
like writing a compiler in a language you are designing, you
will of course end up making the language usable.

So all future users of "C" found it usable, rather
than impressive.  And when you have to get actual
projects done in a short time, theoretical considerations
weigh little in the end, actual usability looms large.

Giving people a set of requirements and saying
"now go design a perfect language" is the
opposite of how such things evolve naturally.

Here is a link from the author of "C" on
how "C" evolved:

  http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

soft-eng wrote:
> In fact, that may have been the major underlying
> strength of C -- it was designed by people who
> were also using it.  They *had* to make it usable.

Well, that is also the flaw of C in that the usage requirements are too
weak today.

> (As opposed to Ichbiah, who *had* to make it impressive
> to a committee.)

No, he had to design a language from the requirements given. Many of these
requirements C does not meet.

> So all future users of "C" found it usable, rather
> than impressive.  And when you have to get actual
> projects done in a short time, theoretical considerations
> weigh little in the end, actual usability looms large.

If you look at studies you will see that C is not a cost efficient
language. Here is an study that compare the old Ada83 language to C and
you can see that even this version is more cost efficient than C.
http://www.adaic.com/whyada/ada-vs-c/cada_art.pdf

Other comparisons can be found here: http://archive.adaic.com/intro/c.html

> Giving people a set of requirements and saying
> "now go design a perfect language" is the
> opposite of how such things evolve naturally.

That C is evolving is an overstatment. C has not evolved to deal with
it's flaws and problems. 

I don't think the reason for the high usage of C is only a merit of the
language itself, but also to a great extent the inertia.

   LinuxWorld.com: Five or ten years from now, will C still be as
   popular [...]

   Dennis Ritchie: I really don't know the answer to this, except to
   observe that software is much harder to change en masse than
   hardware. [...]

http://www.linuxworld.com/linuxworld/lw-2000-12/lw-12-ritchie.html
http://www.linuxfocus.org/English/July1999/article79.html

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

> and then "C".  Even "C" didn't start off in any
> kind of stable form.  There were many early changes

Now the definition is fairly stable, but the language
still is not.  :-)

> themselves!  If you are doing something complex enough
> like writing a compiler in a language you are designing, you
> will of course end up making the language usable.

What does that say about Ada 95, which had it's first
compiler written in Ada 83 and it's second in Ada 95 ?

Or COBOL (which had what some say is its best compiler
written in COBOL)?

> Giving people a set of requirements and saying
> "now go design a perfect language" is the
> opposite of how such things evolve naturally.

Maybe that's why the natural state of software
is so pitiful.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Preben Randhol <randhol+news@pvv.org> wrote in message news:<slrnbbi4li.9l5.randhol+news@kiuk0152.chembio.ntnu.no>...


> I don't think the reason for the high usage of C is only a merit of the
> language itself, but also to a great extent the inertia.

No doubt, but how do you think C became popular in the
first place, overcoming the inertia (that was then) in favor
of Fortran, Cobol, and Pascal?

C++ actually took this inertia into account, but what
about Java which did not retain backward compability
with C?

Inertia explains the continued usage of languages
well past the time that they have become obsolete.
It even explains how 20 years after its trumpet-and-fanfare
inception, people who got hooked into it are still trying
to explain how wonderful Ada is.  But it does not
explain how new languages come into popularity.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Jim Rogers]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305070504.6866e7a3@posting.google.com>...
> jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message news:<82347202.0305061103.2ddd98e4@posting.google.com>...
> 
> > C was built to satisfy the requirements of Bell Laboratories.
> 
> Ah, I see.  You have no experience with actual
> research environments!
> 
> That's not work it works.  Bell Labs did not come
> up with something like "now this set of research engineers
> will design a language, as per this set of requirements".
> Research labs can't get very many useful results that way.
> 
> Ken Thompson in fact started working on developing a
> Fortran compiler for his project's needs, but
> didn't like it and instead ended up creating a
> language called "B", based upon something
> called "BCPL".

Ken Thompson may not have had a formal requirements document,
but he did have a clear understanding of his project's needs.
Designing a language to satisfy a set of needs is the same as
designing a language to satisfy a set of requirements.
Requirements are a formal notation of needs.

It is clear that Ken Thompson had determined a set of needs not
met by the compiler or language his team was originally using, 
or considering. It was those needs that provided the motivation
to develop another language. Even in a research environment you
must be able to justify your use of time. You are not paid to
act without reason or motivation.

> 
> People at Bell Labs liked "B", and started using it.  It
> picked up direction and momentum, and with some work
> from Dennis Ritchie, ended up as as "NB" (new "B")
> and then "C".  Even "C" didn't start off in any
> kind of stable form.  There were many early changes
> and revisions.

The set of requirements changed during the development of
the language. This is standard on most software projects.

> 
> In fact, that may have been the major underlying
> strength of C -- it was designed by people who
> were also using it.  They *had* to make it usable.
> (As opposed to Ichbiah, who *had* to make it impressive
> to a committee.)  In fact, the languages B and C were
> so evolution driven that they did not have a chicken-and-egg
> problem of compilers-and-language variety.  From the
> early stages, the languages had compilers written in
> themselves!  If you are doing something complex enough
> like writing a compiler in a language you are designing, you
> will of course end up making the language usable.

There are several ways to arrive at a final set of project
requirements. One way is to start with a short list of
requirements, and then refine those requirements in response
to a set of prototype development efforts.

Another way is to study and analyze the requirements in a formal
process. The goal of this approach is to produce a more stable
set of requirements before project design and implementation begin.

Both approaches are subject to feature creap.

In the case of C, the set of language features was "specified" by
a committee consisting of the first users of the language. In the
case of Ada the set of language features was "specified" by a
committee consisting of software experts from many domains, including
military, industry, and academia.

The processes to create C and Ada were different. Both efforts 
resulted in usable languages.

> 
> So all future users of "C" found it usable, rather
> than impressive.  And when you have to get actual
> projects done in a short time, theoretical considerations
> weigh little in the end, actual usability looms large.

Ada was not designed to be impressive. It was designed to 
meet a set of requirements. During the development of the
requirements that eventually lead to the creation of Ada, 
existing languages were evaluated in an effort to find a
language satisfying those requirements. C did not meet the
requirements.

This does not label C as deficient. It only states that C
does not meet the requirements developed by the team that
eventually generated the requirements satisfied by Ada.

> 
> Giving people a set of requirements and saying
> "now go design a perfect language" is the
> opposite of how such things evolve naturally.

I would state that differently. I would say that giving
people a set of requirements and then charging them with
developing a language satisfying those requirements is the
way you work when you contract the work to an outside
developer.

The approach taken by Mr Thompson and Mr Ritchie is one
frequently used for internal development. This is what
the people at Hewlett-Packard company called "next bench"
development. You look over at the engineer at the next
work bench, see him or her struggling with a technical
problem, and design a solution for that problem.

Jim Rogers

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Gautier]

softeng:

[...]

> Giving people a set of requirements and saying
> "now go design a perfect language" is the
> opposite of how such things evolve naturally.

Your demonstration about the successful bottom-up
evolution of C and the failure of the top-down Ada
83 is bright.

Well, in the nature, some species do survie well
without evolving anymore - maybe this is why a lot
of programmers have to cope with included headers
files fighting each others with messy conditional
defines and so on, or need to bracket every group
of more that one instruction... all these things
that were surely fine for programming small tools
on a PDP-11.

Of course the "image" that was behind Ada 83 is
comitees, a military style of communication,
absence of contacts with programmers, expensive
and bad compilers, rigidity, bureaucracy.
There is surely some truth behind it.

But, in the nature, there are surprises.
First, excepted some non-neglitible details,
Ada 83 (even it!) is usable. It is even unexpectedly
professional and performance-friendly.
It is obvious that the people behind Ada 83 were
not amateurs or poseurs, since it is impressive _and_
quite usable.

The present Ada (Ada 95), more usable, left in the nature
without official support, follows (is forced to) a natural
evolution for 5 years.
My impression is that the removal of the artificial
constraint from the US DoD has had rather overall positive
effects up to now.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Mark Thornton]

soft-eng wrote:
> Preben Randhol <randhol+news@pvv.org> wrote in message news:<slrnbbi4li.9l5.randhol+news@kiuk0152.chembio.ntnu.no>...
> 
> 
> 
>>I don't think the reason for the high usage of C is only a merit of the
>>language itself, but also to a great extent the inertia.
> 
> 
> No doubt, but how do you think C became popular in the
> first place, overcoming the inertia (that was then) in favor
> of Fortran, Cobol, and Pascal?

None of those langauges competed in the area in which C initially gained 
popularity --- systems programming. The main system programming language 
at the time was probably still assembler. The more general use of C came 
later --- after it had established a foothold.

Mark Thornton

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On 7 May 2003 06:04:07 -0700, soft-eng <softeng3456@netscape.net> wrote:
> People at Bell Labs liked "B", and started using it.  It
> picked up direction and momentum, and with some work
> from Dennis Ritchie, ended up as as "NB" (new "B")
> and then "C".  Even "C" didn't start off in any
> kind of stable form.  There were many early changes
> and revisions.
 
And there weren't for other languages?  That's silly.

> In fact, that may have been the major underlying
> strength of C -- it was designed by people who
> were also using it.  They *had* to make it usable.
> (As opposed to Ichbiah, who *had* to make it impressive
> to a committee.)  In fact, the languages B and C were
> so evolution driven that they did not have a chicken-and-egg
> problem of compilers-and-language variety.  From the
> early stages, the languages had compilers written in
> themselves!  If you are doing something complex enough
> like writing a compiler in a language you are designing, you
> will of course end up making the language usable.

No, you will end up with a language which is good for writing its own
compiler in if the mindset of the users is similar to the language
developer.

There are many cases where that is wildly inappropriate: Ada is
one of those. 

Bell Labs researchers set out to design an operating system.  That
was pretty good.  They made a language along the way.  It was OK
for writing the operating system. 

That which they intentionally designed and thought was important
came out better than stuff that happens along the way.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On 7 May 2003 10:29:10 -0700, soft-eng <softeng3456@netscape.net> wrote:
> Preben Randhol <randhol+news@pvv.org> wrote in message news:<slrnbbi4li.9l5.randhol+news@kiuk0152.chembio.ntnu.no>...
> 
> 
>> I don't think the reason for the high usage of C is only a merit of the
>> language itself, but also to a great extent the inertia.
> 
> No doubt, but how do you think C became popular in the
> first place, overcoming the inertia (that was then) in favor
> of Fortran, Cobol, and Pascal?

A) C came attached to Unix.  The native operating system interface, i.e.
the definition of the data structures and the calls and everything
wrapped up in the .h files, was, and still is, essentially only 
defined by parsing and interpreting actual C language syntax and
semantics.    That was just laziness. 

By contrast, VMS was explicitly designed to NOT be like this.

B) Unix was very open to experimentation and reprogramming by academic
groups with hardworking cheap gradstudent and postdoc labor because
the source was available.  And it came with a C compiler. 

C) That was because of government regulation of AT&T as opposed to DEC or
IBM, which had full control over their own operating systems. 

D) As a result, TCP/IP became attached to Unix first in the Berkeley
System Development laboratories, and TCP/IP hardware was attached to
each other nationally because of DARPA government funding.  TCP/IP was
a Very Very Good Thing.

E) Soon, in large part because of C) (not the C programming language),
Unix became attached to powerful, but *much* less expensive hardware
than its proprietary-OS competitors.  This permitted the Stanford
University Network startup corporation to license some version of Unix
with TCP/IP in it on those really cool Motorola 68000 microprocessors
that Andy Bechtolsheim found, giving VAX-like performance at 1/10th
the cost.

F) The C programming language rode the wave of economics and the intrinsic
coolness of the Internet. 

G) The End. 

> Inertia explains the continued usage of languages
> well past the time that they have become obsolete.
> It even explains how 20 years after its trumpet-and-fanfare
> inception, people who got hooked into it are still trying
> to explain how wonderful Ada is.  But it does not
> explain how new languages come into popularity.

the become popular when they come attached to something
else which is really cool. 

If Unix had been written in Ada, then Ada would be wildly popular
today, and software would be significantly less buggy.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Gautier]

softeng3456@netscape.net (soft-eng):

[Ada attributes]

> Yes, Ada extended Pascal very strongly in this regards,
> without any particular consideration of how useful
> these extensions would actually turn out to be.

[other Ada attributes]

> Like I said, Ada has amazing amounts of itsy-bitsy stuff.
> Now which of these features, if missing, would take you
> more than a minor effort to provide yourself?  If and
> when necessary, rather than present by default all the time?

If I had to reproduce them each time I use them, it would sum
up to a lot of time... and there are more interesting to do
in life than reprogramming them.

No, you are right. Back to the roots. Hey, there are more.
Are these fluffy gadgets like the "for" or "while" loops really
useful ? Of course not, it is better with IF's good ol' GOTO's.
And these "case", "else". For novice youngsters who didn't
even see a true punched card. They should use their "hard drives"
only for downloading music or so what. Long life to PDP-11 !
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marin David Condic]

soft-eng <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305070929.2d7a0d4c@posting.google.com...
>
> No doubt, but how do you think C became popular in the
> first place, overcoming the inertia (that was then) in favor
> of Fortran, Cobol, and Pascal?
>
Simple: AT&T practically gave away Unix to anybody that wanted it and it
came with a C compiler. Computer manufacturers didn't want to invent their
own OS's and used Unix as a cost savings. Universities had freebie Unix
floating around on thousands of computers in their various labs. Hence there
were millions of C compilers out there just native on a bunch of machines.
What would someone with one of those machines use to write their programs? A
Fortran compiler that they had to buy or the native C compiler that they got
as a freebie with the machine?

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[The Ghost In The Machine]

In comp.lang.java.advocacy, Wesley Groleau
<wesgroleau@despammed.com>
 wrote
on Tue, 06 May 2003 20:28:09 -0500
<m9SdndluvPKW_CWjXTWcpw@gbronline.com>:
> 
>>>I own a "C Primer" which NEVER informs the reader that
>>>C is case-sensitive.  And the only hint I could find
>>>(and I was hunting for one) was a code snippet
>>>
>>>void funcname (FILE file)
>>>and this was in chapter eleven!
>> 
>> It's also wrong; it should be
>> void funcname(FILE * file)
> 
> I think that's my mistake, not the book
> (not handy to look up right now)
> 

No problem, the C compiler would have caught it. :-)

-- 
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Mark Thornton <m.p.thornton@ntlworld.com> wrote in message news:<b9bnab$hnai1$1@ID-139894.news.dfncis.de>...
> soft-eng wrote:
> > Preben Randhol <randhol+news@pvv.org> wrote in message news:<slrnbbi4li.9l5.randhol+news@kiuk0152.chembio.ntnu.no>...
> > 
> > 
> > 
> >>I don't think the reason for the high usage of C is only a merit of the
> >>language itself, but also to a great extent the inertia.
> > 
> > 
> > No doubt, but how do you think C became popular in the
> > first place, overcoming the inertia (that was then) in favor
> > of Fortran, Cobol, and Pascal?
> 
> None of those langauges competed in the area in which C initially gained 
> popularity --- systems programming. The main system programming language 
> at the time was probably still assembler. The more general use of C came 
> later --- after it had established a foothold.
> 
> Mark Thornton

Yes, some sort of an initial entry point seems necessary.

Java perhaps repeated the pattern, by being branded as
the "language for the web".  Even though the initial
claim was wrong (J2EE wasn't available at the time,
and applets never proved to be very popular), the
branding helped it gain a foothold.  From there,
its good library, GC, and other features helped
it become popular.

I think Ada already had a similar foothold, though, by
virtue of its defense backing.  Several projects had
already started in Ada, and there was big motivation
for Ada projects.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbbj3sf.2o1.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> On 7 May 2003 10:29:10 -0700, soft-eng <softeng3456@netscape.net> wrote:
> > Preben Randhol <randhol+news@pvv.org> wrote in message news:<slrnbbi4li.9l5.randhol+news@kiuk0152.chembio.ntnu.no>...
> > 
> > 
> >> I don't think the reason for the high usage of C is only a merit of the
> >> language itself, but also to a great extent the inertia.
> > 
> > No doubt, but how do you think C became popular in the
> > first place, overcoming the inertia (that was then) in favor
> > of Fortran, Cobol, and Pascal?
> 
> A) C came attached to Unix.  The native operating system interface, i.e.
> the definition of the data structures and the calls and everything
> wrapped up in the .h files, was, and still is, essentially only 
> defined by parsing and interpreting actual C language syntax and
> semantics.    That was just laziness. 
> 
> By contrast, VMS was explicitly designed to NOT be like this.
> 
> B) Unix was very open to experimentation and reprogramming by academic
> groups with hardworking cheap gradstudent and postdoc labor because
> the source was available.  And it came with a C compiler. 
> 
> C) That was because of government regulation of AT&T as opposed to DEC or
> IBM, which had full control over their own operating systems. 
> 
> D) As a result, TCP/IP became attached to Unix first in the Berkeley
> System Development laboratories, and TCP/IP hardware was attached to
> each other nationally because of DARPA government funding.  TCP/IP was
> a Very Very Good Thing.
> 
> E) Soon, in large part because of C) (not the C programming language),
> Unix became attached to powerful, but *much* less expensive hardware
> than its proprietary-OS competitors.  This permitted the Stanford
> University Network startup corporation to license some version of Unix
> with TCP/IP in it on those really cool Motorola 68000 microprocessors
> that Andy Bechtolsheim found, giving VAX-like performance at 1/10th
> the cost.
> 
> F) The C programming language rode the wave of economics and the intrinsic
> coolness of the Internet. 
> 
> G) The End. 
> 
> > Inertia explains the continued usage of languages
> > well past the time that they have become obsolete.
> > It even explains how 20 years after its trumpet-and-fanfare
> > inception, people who got hooked into it are still trying
> > to explain how wonderful Ada is.  But it does not
> > explain how new languages come into popularity.
> 
> the become popular when they come attached to something
> else which is really cool. 
> 
> If Unix had been written in Ada, then Ada would be wildly popular
> today, and software would be significantly less buggy.

PC's don't show this.  CP/M and MS/DOS etc were written
in assembler, and the field was open for other languages.
At first Basic and Turbo Pascal were the most popular
high-level language on the PC.  C compilers started
arriving later, but became popular quickly.  There
were at least three Ada compilers, but the quality
of these may have been questionable, and the
price was definitely high by PC standards.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

soft-eng wrote:
> Inertia explains the continued usage of languages
> well past the time that they have become obsolete.

Yes and C is obsolete in many of the areas it is used today. One being
application development.

> It even explains how 20 years after its trumpet-and-fanfare
> inception, people who got hooked into it are still trying
> to explain how wonderful Ada is.  But it does not
> explain how new languages come into popularity.

I didn't get hooked on Ada 20 years ago. It was about 3 years ago. And
contrary to C Ada evolved into something better (Ada 95).

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Frank J. Lhota]

"The Ghost In The Machine" <ewill@sirius.athghost7038suus.net> wrote in
message news:83jno-vjm.ln1@lexi2.athghost7038suus.net...
> No problem, the C compiler would have caught it. :-)

Not necessarily! Most C compilers will compile the following code without
warning, although actually calling this version of funcname is bound to
cause trouble.

/**************************************/
#include <stdio.h>

void funcname (FILE file)
{
   fprintf( &file, "Hello, World!\n" );
}

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Thant Tessman]

soft-eng wrote:

[...]

> Java perhaps repeated the pattern, by being branded as
> the "language for the web".  Even though the initial
> claim was wrong (J2EE wasn't available at the time,
> and applets never proved to be very popular), the
> branding helped it gain a foothold.  From there,
> its good library, GC, and other features helped
> it become popular.

You're right about the "language for the web" marketing propaganda, but 
Java's good library was a product of its popularity, not the other way 
around. Also, there were plenty of other languages that already had GC 
and could have done Java's job as good if not better than Java. What 
Java did have was a somewhat superficial, but otherwise very deliberate 
resemblance to C++. Also, Netscape chose Java as the language for applet 
support as a way to soften their (then) image as a company that had too 
much weight to throw around as far as setting industry standards were 
concerned.

I'm not qualified to defend Ada, and of course if a programming language 
simply doesn't work for a task it won't be used, but the notion that a 
language's (or OS's) popular success is primarily due to its tecnhical 
appropriateness is flat-out absurd. The main factor that determines the 
popularity of a programming language that I can detect is simply fear of 
the loss of capital investment--not just monetary capital, but human 
capital. C became popular because it was part of the payload of a virus 
known as Unix. C++ became popular because it was deliberately designed 
as an object-oriented extension of C. Java became popular because it was 
deliberately designed to give C and C++ programmers features (like GC) 
that had already been around in other languages for years.

-thant

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On 8 May 2003 07:06:36 -0700, soft-eng <softeng3456@netscape.net> wrote:
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbbj3sf.2o1.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
>> 
>> If Unix had been written in Ada, then Ada would be wildly popular
>> today, and software would be significantly less buggy.
> 
> PC's don't show this.  CP/M and MS/DOS etc were written
> in assembler, and the field was open for other languages.
> At first Basic and Turbo Pascal were the most popular
> high-level language on the PC.  C compilers started
> arriving later, but became popular quickly.  

> There
> were at least three Ada compilers, but the quality
> of these may have been questionable, and the
> price was definitely high by PC standards.

Right. 

I think at the time of the early-mid 1980's the computational power of
a PC was not really sufficient to host a successful Ada compiler,
whereas it could do so for a simple C compiler.  

The PC's were about on par in power with a mid 1970's PDP-11, an early
host for Unix and Bell Labs's portable C compiler.  64 to 128k of
memory, floppy disks, physical addressing only.  

VAX-11's had 768k to 1M of memory with much more sophisticated
operating systems with virtual memory, typically with hard disk
storage as well.

I think C is actually was good language for systems programming in the
mid 1980's environment.  It isn't any more for applications
programming and wasn't a suitable base for one.


-- 
---------------------------------------------
Matthew Kennel, mkennel@ucsd.edu
Institute For Nonlinear Science, UC San Diego
---------------------------------------------

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

Preben Randhol <randhol+abuse@pvv.org> wrote:
> 
> I didn't get hooked on Ada 20 years ago. It was about 3 years ago. And
> contrary to C Ada evolved into something better (Ada 95).

As for myself, I learned ancient Fortran, C and C++ first, and have
switched to Fortran 95 and Eiffel.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[tmoran]

>> were at least three Ada compilers, but the quality
>> of these may have been questionable, and the
>> price was definitely high by PC standards.
  IIRC, I purchased both BDS-C and later Janus Ada for $100.
The former ran on CP/M and the latter on MSDOS, both on 286s.
The latter was, of course, much more powerful and infinitely
better for debugging.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:<b9dij7$9ra$1@slb4.atl.mindspring.net>...
> soft-eng <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0305070929.2d7a0d4c@posting.google.com...
> >
> > No doubt, but how do you think C became popular in the
> > first place, overcoming the inertia (that was then) in favor
> > of Fortran, Cobol, and Pascal?
> >
> Simple: AT&T practically gave away Unix to anybody that wanted it and it
> came with a C compiler. Computer manufacturers didn't want to invent their
> own OS's and used Unix as a cost savings. Universities had freebie Unix
> floating around on thousands of computers in their various labs. Hence there
> were millions of C compilers out there just native on a bunch of machines.
> What would someone with one of those machines use to write their programs? A
> Fortran compiler that they had to buy or the native C compiler that they got
> as a freebie with the machine?
> 
> MDC
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/
> 
> Send Replies To: m c o n d i c @ a c m . o r g
> 
>     "Going cold turkey isn't as delicious as it sounds."
>         -- H. Simpson
> ======================================================================


Free compilers for other languages were available, too.
And Unix was never the only OS around (in its range), there
were OS's from DEC, DG etc.  Many of these were
popular at unis.   And I could be mistaken, but I
thought even Unix had an "f77" compiler included in
the distribution, there was no need to buy it separately.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert A Duff]

softeng3456@netscape.net (soft-eng) writes:

> Free compilers for other languages were available, too.
> And Unix was never the only OS around (in its range), there
> were OS's from DEC, DG etc.

Most of those were tied to particular hardware.
I think Unix succeeded, in part, because it was more portable.

I think it's fair to say that a large part of the success of C was in
riding on the coattails of Unix.

>...  Many of these were
> popular at unis.   And I could be mistaken, but I
> thought even Unix had an "f77" compiler included in
> the distribution, there was no need to buy it separately.

Unix was written in C.  The language in which an OS is written
_shouldn't_ matter, but in the case of Unix it does.  All the interfaces
to the OS are defined in C (as .h files).  And they use data structures
that are natural to define in C.  So if you choose a different language,
you have extra headaches interfacing to the OS.

Some of those interfaces are macros.  It's not that easy to call a C
macro from a Fortran or Ada program!  (Actually, one of our (SofCheck's)
Ada compiler's generates C, and in that compiler, you *can* call C
macros from Ada, using pragma Import.  But most compilers don't support
that.)

- Bob

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[Kevin Cline]

"Graham Perkins" <gperkins@gperkins.co.uk> wrote in message news:<b8u3m2$emd$1@south.jnrs.ja.net>...
> "Kevin Cline" <kcline17@hotmail.com> wrote in message
> news:ba162549.0305020720.4da44159@posting.google.com...
> > > One more amateur teaching Ada with no experience using it on
> > > projects.   There was so much of this going around that no one
> > > should be suprised that so many students came away from their
> > > Ada classes with a distorted view of the language.
> >
> > Do you think the situation is better for other languages?  It
> > certainly isn't for C++.  I've interviewed people who taught evening
> > classes in C++ and OOP at the university level and they were
> > hopelessly confused.
> 
> The text books don't help.  So hard to find the
> wheat amongst the chaff.

That's the instructor's responsibility, but an instructor with minimal
knowledge is likely to choose poorly.  OTOH, Lippman's _C++ Primer_,
and Koenig's & Moo's _Accelerated C++_ have been well-reviewed.

The confusion of my interviewees was directly attributable to their
poor choice of a textbook.  They learned C++ about as well as it was
presented in their text book.
 
> I once found a C++ book which doesn't start on classes
> until chapter nine!

There are a LOT of bad books covering any popular technology.  I have
discovered that book quality is inversely proportional to the
garishness of the cover.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Thu, 08 May 2003 18:27:47 -0500 (CDT)
NNTP-Posting-Host: !\THX1k-VKme$@< (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305080606.70eebec@posting.google.com...
> PC's don't show this.  CP/M and MS/DOS etc were written
> in assembler, and the field was open for other languages.

Unfortunately, the facts do not agree with you.

CP/M was written in PL/M, a variant of PL/I developed by Dr. Gary Kildall.

The exact genesis of MS-DOS is not completely known.  It is known that it
started out as QDOS from Seattle Computer Products.  Anecdotal evidence
exists to show that QDOS was a mechanical translation (translation: "theft")
of CP/M to 8086, with some hand fixups.  Supposedly (as the story goes), a
Digital Research lawsuit against Microsoft was settled VERY quickly, with
Digital Research receiving MUCH money *AND* the right to clone MS-DOS, when
Gary Kildall typed a "secret code" into an MS-DOS PC and let the Microsoft
attorneys read the Digital Research copyright notice that was still embedded
deep inside MS-DOS.  (Such "secret codes" were quite common in those days.
They persist, as "Easter Eggs", today.)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Thu, 08 May 2003 18:27:48 -0500 (CDT)
NNTP-Posting-Host: !\THX1k-VKme$@< (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106


"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305081222.623e0b31@posting.google.com...
> "Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
news:<b9dij7$9ra$1@slb4.atl.mindspring.net>...
> > soft-eng <softeng3456@netscape.net> wrote in message
> > news:9fa75d42.0305070929.2d7a0d4c@posting.google.com...
> > >
> > > No doubt, but how do you think C became popular in the
> > > first place, overcoming the inertia (that was then) in favor
> > > of Fortran, Cobol, and Pascal?
> > >
> > Simple: AT&T practically gave away Unix to anybody that wanted it and it
> > came with a C compiler. Computer manufacturers didn't want to invent
their
> > own OS's and used Unix as a cost savings. Universities had freebie Unix
> > floating around on thousands of computers in their various labs. Hence
there
> > were millions of C compilers out there just native on a bunch of
machines.
> > What would someone with one of those machines use to write their
programs? A
> > Fortran compiler that they had to buy or the native C compiler that they
got
> > as a freebie with the machine?
> >
> > MDC
> > --
> > ======================================================================
> > Marin David Condic
> > I work for: http://www.belcan.com/
> > My project is: http://www.jsf.mil/
> >
> > Send Replies To: m c o n d i c @ a c m . o r g
> >
> >     "Going cold turkey isn't as delicious as it sounds."
> >         -- H. Simpson
> > ======================================================================
>
>
> Free compilers for other languages were available, too.
> And Unix was never the only OS around (in its range), there
> were OS's from DEC, DG etc.  Many of these were
> popular at unis.   And I could be mistaken, but I
> thought even Unix had an "f77" compiler included in
> the distribution, there was no need to buy it separately.

Yes, there were operating systems from DEC, DG, and others.  They all
carried prices greater than zero dollars.  Unix was fairly unique in that
the price was zero dollars.  This made it uniquely attractive to
universities.

At that time, as others have pointed out, C was the most practical choice of
programming language for doing systems and applications programming on Unix.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

> as an object-oriented extension of C. Java became popular because it was 
> deliberately designed to give C and C++ programmers features (like GC) 
> that had already been around in other languages for years.

No, Java became popular partly from hype and partly
because it is better than C and C++ but not enough
to intimidate users of those languages.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[apm]

kcline17@hotmail.com (Kevin Cline) wrote in message > There are a LOT of bad books covering any popular technology.  I have
> discovered that book quality is inversely proportional to the
> garishness of the cover.

Oh? I thought it was inversely proportional to the weight.

-apm

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marshall Spight]

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message news:qaOcnZhr4PwRvyajXTWcoA@gbronline.com...
>
> > as an object-oriented extension of C. Java became popular because it was
> > deliberately designed to give C and C++ programmers features (like GC)
> > that had already been around in other languages for years.
>
> No, Java became popular partly from hype and partly
> because it is better than C and C++ but not enough
> to intimidate users of those languages.

Don't forget anti-Microsoft sentiment! That has been
a powerful force in Java's favor.


Marshall

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Tom Welsh]

In article <9fa75d42.0305081222.623e0b31@posting.google.com>, soft-eng
<softeng3456@netscape.net> writes
>
>Free compilers for other languages were available, too.
>And Unix was never the only OS around (in its range), there
>were OS's from DEC, DG etc.  Many of these were
>popular at unis.   And I could be mistaken, but I
>thought even Unix had an "f77" compiler included in
>the distribution, there was no need to buy it separately.

I can confirm that, when I was working at DEC in the 1980s, we saw Unix
first of all as a nuisance, then a threat, and finally as a scourge. The
reason was its low cost.

As of about 1981-2, a few of our customer showed up using Unix. At the
time I was working in the UK Remote Diagnosis Centre, where we could run
automated tests on remote computers - basically letting our computers
interrogate the diagnostic consoles. The leading edge of our efforts was
in looking at the operating system and using it, as well as hardware
registers, to diagnose problems that could be either hardware or
software. I remember being able to tell a field service tech, when he
arrived on site, which fuse to replace in which magtape drive to stop
the whole system from hanging (bad design, I agree).

All of this broke down with Unix, because we weren't trained on it and
had no clue how it worked. (Also, its troubleshooting features at that
time were rudimentary compared to VMS).

It was annoying to us that more and more customers - starting with
universities and other research organisations that couldn't afford our
usual "corporate" rates - were taking up Unix. VMS was designed
simultaneously with the VAX architecture, and they had a lot of synergy.
Unix threw a lot of that away, from our point of view.

What we didn't understand was that, from the users' point of view, Unix
gave them 80 percent (at least) of the benefits for 20 percent (at most)
of the cost.

Later DEC executives (a remarkable number of whom now work for
Microsoft) thought up a new line, which went something like this. Unix
is OK if all you want is a basic LCD OS. But VMS will always have the
really valuable extras that help give you competitive differentiation
(Michael Porter came along just in time for them to grab that straw).
So, for the extra cost, VMS keeps you 2-3 years ahead of the curve.

Heard something similar to that lately?
-- 
Tom Welsh

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<b9ep5j$bkd@library1.airnews.net>...
> X-A-Notice: References line has been trimed due to 512 byte limitation
> Abuse-Reports-To: abuse at airmail.net to report improper postings
> NNTP-Proxy-Relay: library1-aux.airnews.net
> NNTP-Posting-Time: Thu, 08 May 2003 18:27:47 -0500 (CDT)
> NNTP-Posting-Host: !\THX1k-VKme$@< (Encoded at Airnews!)
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> 
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0305080606.70eebec@posting.google.com...
> > PC's don't show this.  CP/M and MS/DOS etc were written
> > in assembler, and the field was open for other languages.
> 
> Unfortunately, the facts do not agree with you.
> 
> CP/M was written in PL/M, a variant of PL/I developed by Dr. Gary Kildall.

Any URL, quote or something for this "fact"?

While Gary Kildall did write both the language PL/M and also CP/M for
8086 machines, that doesn't mean he wrote CP/M in PL/M!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<qaOcnZhr4PwRvyajXTWcoA@gbronline.com>...
> > as an object-oriented extension of C. Java became popular because it was 
> > deliberately designed to give C and C++ programmers features (like GC) 
> > that had already been around in other languages for years.
> 
> No, Java became popular partly from hype and partly
> because it is better than C and C++ but not enough
> to intimidate users of those languages.

But to intimidate Ada advocates you only
need to mention the word "pointers" :-)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"Marshall Spight" <mspight@dnai.com> wrote in message news:<9IIua.780556$3D1.429428@sccrnsc01>...
> "Wesley Groleau" <wesgroleau@despammed.com> wrote in message news:qaOcnZhr4PwRvyajXTWcoA@gbronline.com...
> >
> > > as an object-oriented extension of C. Java became popular because it was
> > > deliberately designed to give C and C++ programmers features (like GC)
> > > that had already been around in other languages for years.
> >
> > No, Java became popular partly from hype and partly
> > because it is better than C and C++ but not enough
> > to intimidate users of those languages.
> 
> Don't forget anti-Microsoft sentiment! That has been
> a powerful force in Java's favor.
> 
> 
> Marshall

Yes, I thought so too.  Whatever the reasons, the
language does work well for a large domain!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Tom Welsh <news@tom-welsh.co.uk> wrote in message news:<vgS4RJAic2u+EwXL@nildram.co.uk>...
> In article <9fa75d42.0305081222.623e0b31@posting.google.com>, soft-eng
> <softeng3456@netscape.net> writes
> >
> >Free compilers for other languages were available, too.
> >And Unix was never the only OS around (in its range), there
> >were OS's from DEC, DG etc.  Many of these were
> >popular at unis.   And I could be mistaken, but I
> >thought even Unix had an "f77" compiler included in
> >the distribution, there was no need to buy it separately.
> 
> I can confirm that, when I was working at DEC in the 1980s, we saw Unix
> first of all as a nuisance, then a threat, and finally as a scourge. The
> reason was its low cost.
> 

But there was the Ultrix group at DEC -- and DEC should have
been the least concerned of all companies about Unix.
That's because BSD was developed on Vax machines, and people
using Unix bought Vax machines to run it on.  So
Unix was free, but people bought Vax hardware
from DEC so they could throw away VMS and run Unix on it!

That changed as Sun started becoming popular, though,
which might have been when your problems with
Unix must have gotten really serious!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

tmoran@acm.org wrote in message news:<Edxua.536070$Zo.114252@sccrnsc03>...
> >> were at least three Ada compilers, but the quality
> >> of these may have been questionable, and the
> >> price was definitely high by PC standards.
>   IIRC, I purchased both BDS-C and later Janus Ada for $100.
> The former ran on CP/M and the latter on MSDOS, both on 286s.
> The latter was, of course, much more powerful and infinitely
> better for debugging.

Oh, right!  The Ada compilers ranged as high as $1500s iirc,
but Janus had a low cost one.  But if the quality was
so good, and the cost was so low (right in line
with Turbo Pasca, Quick C etc), the incentives
so high (defense contracts) it just proves
that the language was found un-usable
by programmers.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

gautier_niouzes@hotmail.com (Gautier) wrote in message news:<17cd177c.0305011129.2eab5fb8@posting.google.com>...

> You simply ignore the huge debugging time provided
> by poorly-typed languages and its effective relation to
> job safety. So what ?

No -- having worked on reasonably large projects
in C, I can say that with professional programmers
with experience in a language like C, this
simply ceases to be an issue.  *MOST* bugs
in a professional C project have nothing to do
with type safety.  The bugs would have happened
in any language, because they involved logic issues.
So the advantages of a fully type-safe language
are small, perhaps 5%.  And that's very easily
offset by the disadvantages (extra time, effort,
debugging for the situations that _require_ getting
around the type-safety, loss of the automatic
programmer-pruning that "hard" languages such
as C/C++ bring...)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

gautier_niouzes@hotmail.com (Gautier) wrote in message news:<17cd177c.0305072114.24f04783@posting.google.com>...
> softeng3456@netscape.net (soft-eng):
> 
> [Ada attributes]
> 
> > Yes, Ada extended Pascal very strongly in this regards,
> > without any particular consideration of how useful
> > these extensions would actually turn out to be.
> 
> [other Ada attributes]
> 
> > Like I said, Ada has amazing amounts of itsy-bitsy stuff.
> > Now which of these features, if missing, would take you
> > more than a minor effort to provide yourself?  If and
> > when necessary, rather than present by default all the time?
> 
> If I had to reproduce them each time I use them, it would sum
> up to a lot of time... and there are more interesting to do
> in life than reprogramming them.

Do you really need your own sub-range of integers
very often?  Arrays with variable index ranges?
You must do a very different type of programming
from what I do.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Vinzent Hoefler]

softeng3456@netscape.net (soft-eng) wrote:

>Do you really need your own sub-range of integers
>very often?

Yes.

>  Arrays with variable index ranges?

This comes handy quite often. But more important is the type safety
that comes with them.

>You must do a very different type of programming
>from what I do.

Well, I do some embedded stuff and application software. It always
seems to be a lack of imagination when someone claims, he'd never need
it.

Well, I don't *need* it either, I am mentally able to address arrays
with zero-based indices, too, even if this does not look very
naturally, but to do it can make the life a whole lot easier.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Frank J. Lhota]

> Do you really need your own sub-range of integers
> very often?

Yes.

>  Arrays with variable index ranges?

Yes.

> You must do a very different type of programming
> from what I do.

I guess so.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1051901740.277992@master.nyc.kbcfp.com>...
> In tribute to Ada, my C++ code usually contains
> 
> template<typename T>
> std::string image(const T &value)
> {
>      std::ostringstream o;
>      o << value;
>      return o.str();
> }

That should be "in tribute to CLU".

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Tom Welsh]

In article <9fa75d42.0305090518.513731f4@posting.google.com>, soft-eng
<softeng3456@netscape.net> writes
>
>But there was the Ultrix group at DEC -- and DEC should have
>been the least concerned of all companies about Unix.
>That's because BSD was developed on Vax machines, and people
>using Unix bought Vax machines to run it on.  So
>Unix was free, but people bought Vax hardware
>from DEC so they could throw away VMS and run Unix on it!
>
It's more a case of "then there was the Ultrix group at DEC".
In the manner of dominant vendors, DEC was extremely reluctant
to believe that customers could prefer an "alien" product -
still more, one written by hackers in their spare time (as
DEC saws it) and given away free or as good as. Same response
MS had to open source, really.

So Ultrix was only launched (or at least, supported from the
top) once the Unix breakthrough was well developed. But it
was *never* loved. In fact, at one point a bit later on there
were three corporate camps supporting VMS, Unix and Windows
respectively. (I know Windows has never run on VAX - it's a
long and tedious tale of pointy-haired folk).

>That changed as Sun started becoming popular, though,
>which might have been when your problems with
>Unix must have gotten really serious!

Exactly. But Ken Olsen and his smarter executives could
see that coming as soon as Unix became popular. Cheap
software - expensive hardware - duh!

-- 
Tom Welsh

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Thant Tessman]

Wesley Groleau wrote:
> 
>> as an object-oriented extension of C. Java became popular because it 
>> was deliberately designed to give C and C++ programmers features (like 
>> GC) that had already been around in other languages for years.
> 
> 
> No, Java became popular partly from hype and partly
> because it is better than C and C++ but not enough
> to intimidate users of those languages.
> 

Java has advantages over C++ and C++ has advantages over Java. But my 
point was actually that neither C++ nor Java are all that great.

-thant

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Hyman Rosen]

soft-eng wrote:
> That should be "in tribute to CLU".

Well, *I* write it in tribute to Ada, regardless of whether
it has its origins in a different language.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Fri, 09 May 2003 11:24:33 -0500 (CDT)
NNTP-Posting-Host: !b]\%1k-W<Vhm_" (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106


"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305090424.45b522b5@posting.google.com...
> "John R. Strohm" <strohm@airmail.net> wrote in message
news:<b9ep5j$bkd@library1.airnews.net>...
> > X-A-Notice: References line has been trimed due to 512 byte limitation
> > Abuse-Reports-To: abuse at airmail.net to report improper postings
> > NNTP-Proxy-Relay: library1-aux.airnews.net
> > NNTP-Posting-Time: Thu, 08 May 2003 18:27:47 -0500 (CDT)
> > NNTP-Posting-Host: !\THX1k-VKme$@< (Encoded at Airnews!)
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> >
> > "soft-eng" <softeng3456@netscape.net> wrote in message
> > news:9fa75d42.0305080606.70eebec@posting.google.com...
> > > PC's don't show this.  CP/M and MS/DOS etc were written
> > > in assembler, and the field was open for other languages.
> >
> > Unfortunately, the facts do not agree with you.
> >
> > CP/M was written in PL/M, a variant of PL/I developed by Dr. Gary
Kildall.
>
> Any URL, quote or something for this "fact"

http://www.maxframe.com/GARY&CPM.HTM

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Fri, 09 May 2003 11:24:34 -0500 (CDT)
NNTP-Posting-Host: !b]\%1k-W<Vhm_" (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106


"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305090612.261d5a5c@posting.google.com...
> gautier_niouzes@hotmail.com (Gautier) wrote in message
news:<17cd177c.0305072114.24f04783@posting.google.com>...
> > softeng3456@netscape.net (soft-eng):
> >
> > [Ada attributes]
> >
> > > Yes, Ada extended Pascal very strongly in this regards,
> > > without any particular consideration of how useful
> > > these extensions would actually turn out to be.
> >
> > [other Ada attributes]
> >
> > > Like I said, Ada has amazing amounts of itsy-bitsy stuff.
> > > Now which of these features, if missing, would take you
> > > more than a minor effort to provide yourself?  If and
> > > when necessary, rather than present by default all the time?
> >
> > If I had to reproduce them each time I use them, it would sum
> > up to a lot of time... and there are more interesting to do
> > in life than reprogramming them.
>
> Do you really need your own sub-range of integers
> very often?  Arrays with variable index ranges?
> You must do a very different type of programming
> from what I do.

Let me guess, you're one of these people who believes that only freshmen
need subscript range checking, aren't you?  You're one of these people who'd
rather debug a segmentation fault from a core dump than see a message
"Subscript out of range in <FILE> at <LINE NUMBER>", right?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Fri, 09 May 2003 11:24:35 -0500 (CDT)
NNTP-Posting-Host: !b]\%1k-W<Vhm_" (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305090536.49431321@posting.google.com...
> gautier_niouzes@hotmail.com (Gautier) wrote in message
news:<17cd177c.0305011129.2eab5fb8@posting.google.com>...
>
> > You simply ignore the huge debugging time provided
> > by poorly-typed languages and its effective relation to
> > job safety. So what ?
>
> No -- having worked on reasonably large projects
> in C, I can say that with professional programmers
> with experience in a language like C, this
> simply ceases to be an issue.  *MOST* bugs
> in a professional C project have nothing to do
> with type safety.  The bugs would have happened
> in any language, because they involved logic issues.
> So the advantages of a fully type-safe language
> are small, perhaps 5%.  And that's very easily
> offset by the disadvantages (extra time, effort,
> debugging for the situations that _require_ getting
> around the type-safety, loss of the automatic
> programmer-pruning that "hard" languages such
> as C/C++ bring...)

Let me see if I understand this.

You WANT to predicate your systems development work, on all problems, on
being able to hire only wizards who can handle the hard language, in
quantity.

Isn't that mostly like using only expert neurosurgeons to stitch up paper
cuts?

I observe that you say *MOST* bugs, not *ALL* bugs.  That implies that SOME
of those bugs would not have occurred in a type-safe language.

My personal experience in type-safe languages are that you only RARELY have
to get around the type system, and the mere existence of the hackarounds
warns the maintenance programmer that something is going on here.  Of
course, you've probably NEVER had to contemplate doing maintenance on code
that was written ten years ago, much less code that might have been written
before you were born.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

> Do you really need your own sub-range of integers

yes

> very often?  Arrays with variable index ranges?

yes

> You must do a very different type of programming
> from what I do.

Apparently.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

"John R. Strohm" <strohm@airmail.net> wrote in message
news:b9gko1$pub@library1.airnews.net...
> X-A-Notice: References line has been trimed due to 512 byte limitation
> Abuse-Reports-To: abuse at airmail.net to report improper postings
> NNTP-Proxy-Relay: library1-aux.airnews.net
> NNTP-Posting-Time: Fri, 09 May 2003 11:24:33 -0500 (CDT)
> NNTP-Posting-Host: !b]\%1k-W<Vhm_" (Encoded at Airnews!)
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
>
>
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0305090424.45b522b5@posting.google.com...
> > "John R. Strohm" <strohm@airmail.net> wrote in message
> news:<b9ep5j$bkd@library1.airnews.net>...
> > > X-A-Notice: References line has been trimed due to 512 byte limitation
> > > Abuse-Reports-To: abuse at airmail.net to report improper postings
> > > NNTP-Proxy-Relay: library1-aux.airnews.net
> > > NNTP-Posting-Time: Thu, 08 May 2003 18:27:47 -0500 (CDT)
> > > NNTP-Posting-Host: !\THX1k-VKme$@< (Encoded at Airnews!)
> > > X-Priority: 3
> > > X-MSMail-Priority: Normal
> > > X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> > > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> > >
> > > "soft-eng" <softeng3456@netscape.net> wrote in message
> > > news:9fa75d42.0305080606.70eebec@posting.google.com...
> > > > PC's don't show this.  CP/M and MS/DOS etc were written
> > > > in assembler, and the field was open for other languages.
> > >
> > > Unfortunately, the facts do not agree with you.
> > >
> > > CP/M was written in PL/M, a variant of PL/I developed by Dr. Gary
> Kildall.
> >
> > Any URL, quote or something for this "fact"
>
> http://www.maxframe.com/GARY&CPM.HTM

And this one http://www.cpm.z80.de/source.html contains, among other things,
the original CP/M source code.  In PL/M.  Complete with Gary Kildall's
copyright notice.

Here are the first few lines.
$Q=1
$RIGHTMARGIN=80
/* FDOS LLL V.3  11/21/75
   CON DEVICE 3 IS TI SILENT 700.
   OCT IS READER DEVICE 3 OR 4. */
3200H: DECLARE BOOT LITERALLY '0H';


 /* C P / M   B A S I C   I / O    S Y S T E M    (B I O S)

                    COPYRIGHT (C) GARY A. KILDALL
                             JUNE, 1975

                                                          */

DECLARE CONSOLE LITERALLY '00$00$10$00B'; /* READER IS OCT CHANNEL A. */
DECLARE ECHO BYTE INITIAL (0FFH); /* ECHO CALL NO. 1.  SEE CALL 30 */


DISKMON: PROCEDURE(FUNC,INFO) ADDRESS;
    DECLARE FUNC BYTE,
        LINFO BYTE,       /* LOW ORDER INFO */
       INFO ADDRESS,
       ARET ADDRESS, RET BYTE;

    /* FUNC IS THE DISK MONITOR FUNCTION NUMBER AS SHOWN BELOW:
        0:   SYSTEM RESET
        1:   READ CONSOLE DEVICE
        2:   WRITE CONSOLE DEVICE
        3:   READ OCTOPUS
        4:   WRITE OCTOPUS
        5:   WRITE LIST DEVICE
        6:   INTERROGATE MEMORY SIZE
        7:   INTERROGATE DEVICE STATUS
        8:   CHANGE DEVICE STATUS
        9:   PRINT BUFFER ON CONSOLE
       10:   READ BUFFER FROM CONSOLE
       11:   CONSOLE CHARACTER READY
       12:   LIFT HEAD (NO OPERATION ON CPM 16D2JUN75)
       13:   RESET DISK SYSTEM - SELECT DISK 0
       14:   SELECT DISK 'INFO'
       15:   OPEN FILE
       16:   CLOSE FILE
       17:   SEARCH FOR FIRST OCCURRENCE
       18:   SEARCH FOR NEXT OCCURRENCE
       19:   DELETE A FILE
       20:   READ A FILE
       21:   WRITE A FILE
       22:   CREATE A FILE
       23:   RENAME A FILE
       24:   RETURN LOGIN VECTOR - EACH BIT CORRESPONDS TO
             A DISK NUMBER, FROM LSB TO MSB.  1 INDICATES
             THE DISK IS LOGGED IN.
       25:   RETURN CURRENTLY SELECTED DISK NUMBER
       26:   SET SUBSEQUENT DMA ADDRESS
       27:   RETURN BASE ADDRESS OF ALLOCATION VECTOR
             (USED TO DETERMINE REMAINING SPACE)
       28:   UNUSED
       29:   UNUSED
       30:   CONTROL ECHO FOR CALL 1
    */

 /* CONSOLE COMMUNICATION PROCEDURES */

DECLARE
    /* TELETYPE DECLARATIONS */
    TTI LITERALLY '0',
    TTO LITERALLY '0',
    TTS LITERALLY '1',
    TTC LITERALLY '1',
    /* CRT DECLARATIONS (NOTE CONFLICT WITH OCTOPUS)*/
    CTI LITERALLY '4',
    CTO LITERALLY '4',
    CTS LITERALLY '5',
    /* OCTOPUS DECLARATIONS */
    /* (CHECK WITH TORODE FOR CHANNEL B ASSIGNMENTS) */
    OAI LITERALLY '4',
    OAO LITERALLY '4',
    OAS LITERALLY '5',
    OBI LITERALLY '6',
    OBO LITERALLY '6',
    OBS LITERALLY '7',

    /* SPECIAL CHARACTERS */
    ALT LITERALLY '7DH',
    ESC LITERALLY '1BH',
    TAB LITERALLY '09H',
    BEL LITERALLY '07H',
    LF  LITERALLY '10',
    CR  LITERALLY '13';

DECLARE COLUMN BYTE INITIAL(0); /* CURRENT CONSOLE COLUMN */
DECLARE OCT$TIMEOUT LITERALLY '65000';


DECLARE IOSTAT BYTE INITIAL(CONSOLE);
    /* IOSTAT DEFINES THE CURRENT DEVICE ASSIGNMENT
    0-1 CONSOLE
        0 TTY
        1 CRT
        2 BATCH (USE READER DEFINITION)
        3 USER (1) TI SILENT 700
    2-3 READER
        0 TTY
        1 PTR
        2 USER (1)OCTOPUS CHANNEL A
        3 USER (2)OCTOPUS CHANNEL B
    4-5 PUNCH
        0 TTY
        1 PTP
        2 USER (1)
        3 USER (2)
    6-7 LIST
        0 TTY
        1 CRT
        2 USER (1)
        3 USER (2)
    */

CONSTAT: PROCEDURE BYTE;
    RETURN IOSTAT AND 11B;
    END CONSTAT;

CONBRK: PROCEDURE BYTE;
    /* LOOK FOR CHARACTER AT CONSOLE PORT */
    DECLARE I BYTE;
    IF (I:=CONSTAT) = 0 OR I = 3 THEN RETURN NOT INPUT(TTS);
    RETURN NOT INPUT(CTS);
    END CONBRK;

TTYOUT: PROCEDURE(CHAR);
    DECLARE CHAR BYTE;
        DO WHILE ROR(INPUT(TTS),2);
        END;
    OUTPUT(TTO) = NOT CHAR;
    END TTYOUT;

CRTOUT: PROCEDURE(CHAR);
    DECLARE CHAR BYTE;
        DO WHILE ROR(INPUT(CTS),2);
        END;
    OUTPUT(CTO) = NOT CHAR;
    END CRTOUT;

TTYIN: PROCEDURE BYTE;
        DO WHILE INPUT(TTS);
        END;
    RETURN NOT INPUT(TTI) AND 07FH;
    END TTYIN;

CRTIN: PROCEDURE BYTE;
        DO WHILE INPUT(CTS);
        END;
    RETURN NOT INPUT(CTI) AND 07FH;
    END CRTIN;



As I said, get your facts straight.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:<b8toba$79o$1@slb0.atl.mindspring.net>...

> "competent" and most had many years of experience, but still, the language
> made a difference to the bottom line. My competitors are still using C. I
> say "Good for them!" My improved productivity and reduced defects translates

If you can indeed have improved productivity and reduced defects,
it stands to reason that your competitor will not be doing very
well versus you!

Bottom lines do count.  If time after time it so happened
that people using Ada out-competed the ones using C,
others would start taking notice.

But in fact time after time it has failed to happen, and the only
successful cases in Ada usage come from the situations
where it was mandated and no competition existed at all,
and money was no object.  If you have a business
like that, sure, use whatever language you like.

Otherwise, it might be worthwhile looking carefully at
situation, and not just basing things on a study or two.

Studies, in general, can prove all kinds of amazingly
interesting things.  Sometimes even six before breakfast.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305090536.49431321@posting.google.com>...
> gautier_niouzes@hotmail.com (Gautier) wrote in message news:<17cd177c.0305011129.2eab5fb8@posting.google.com>...
> 
> > You simply ignore the huge debugging time provided
> > by poorly-typed languages and its effective relation to
> > job safety. So what ?
> 
> No -- having worked on reasonably large projects
> in C, I can say that with professional programmers
> with experience in a language like C, this
> simply ceases to be an issue.  *MOST* bugs
> in a professional C project have nothing to do
> with type safety.  The bugs would have happened
> in any language, because they involved logic issues.
> So the advantages of a fully type-safe language
> are small, perhaps 5%.  And that's very easily
> offset by the disadvantages (extra time, effort,
> debugging for the situations that _require_ getting
> around the type-safety, loss of the automatic
> programmer-pruning that "hard" languages such
> as C/C++ bring...)

PS:  Now if Ada had GC, that could have changed
things a lot.  People would have used it despite
all the warts.

A LARGE amount of debugging time in C/C++ is spent
dealing with dynamic memory bugs!  But Ada had
only a half-hearted nod to GC, no actual GC support.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Jim Rogers]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305090612.261d5a5c@posting.google.com>...
> Do you really need your own sub-range of integers
> very often?  Arrays with variable index ranges?
> You must do a very different type of programming
> from what I do.

Perhaps not so different as you think.
User defined numeric types have a very convenient set
of behaviors in Ada. Those behaviors become even more
convenient when user defined discrete types are created
for array indexing.

The most convenient feature when dealing with arrays is
Ada's ability to efficiently deal with array bounds 
checking. 

For example, if I define an Ada string with a length
of 10 characters:

   Name : String(1..10);

I can then perform I/O using that string object and
never need to worry about array bounds violations.

Ada.Text_Io.Get_Line(Item => Name, Last => Count);

The Get_Line procedure will read from standard input
and place the characters read into the variable "Name".
It will record the number of characters read in the
variable "Count". The input routine will not overflow
the array. It will assign no more characters than can
fit into the receiving array.

In C I would need to do something like the following:
   char name[11];

   scanf("%.10s", name);

The point here is that I must hardcode the size limit
into the scanf format string. If I change the size of
the array then I must also change the scanf format 
string.

Unfortunately, array bounds violations are still a common
failure mode in C programs. The techniques for avoiding 
array bounds violations are well known. Unfortunately
they are not used as frequently as one would like.

Another issue with Ada arrays is iterating through the
array elements. This is also much easier to do safely than
in C.

In Ada one could safely iterate through the above defined 
string as follows:

   for index in Name'Range loop
      Ada.Text_IO.Put(Item => Name(Index));
   end loop;


Using C you could do the following:

   int i;
   for(i = 0; name[i]; ++i)
   {
     putc(name[i]);
   }

This relies upon having a properly formatted, null-
terminated string. If, however, the string is not
properly null-terminated, or the character array was
a victim of bounds violation, the loop can easily
read beyond the end of the character array. Now a
bounds violation in one part of the program is
propogated into other parts of the program. Detecting
and correcting this fault is not fun.

The Ada model of allowing array indices to start at
any discrete value is very convenient for array slicing.
If I wanted to create my own procedure to print an array
character by character, I could do the following:

procedure My_Print(Item : in String) is
begin
   for i in Item'Range loop
      Ada.Text_IO.Put(Item(i));
   end loop;
end My_Print;

I could then successfully call this procedure either
with an entire string object or with a slice of a 
string object:

My_Print(Name);
My_Print(Name(3..6));

The first call would print the entire 10 characters in
the Name string. The second call would print only the
3rd, 4th, 5th and 6th characters in the string.

An eqivalent C function would be:

  void myPrint(char *c, int l)
  {
     int i;
     for(i = 0; i < l; ++i)
     {
        putc(c[i]);
     }
  }

The problem here is that neither the run time code nor
the compiler will know if the parameter c actually points
to a character in a character array. Neither can it tell
if the second parameter "l" will cause an array bounds
violation during the iteration.

The Ada solution is entirely safe in this regard. An array
slice cannot reference elements outside the array bounds.
An array parameter must reference an actual array. There is
no masking caused by pointer referencing.

Jim Rogers

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marc A. Criley]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305090612.261d5a5c@posting.google.com>...

> Do you really need your own sub-range of integers
> very often?  Arrays with variable index ranges?
> You must do a very different type of programming
> from what I do.

Several others have answered this as "Yes, yes, and Apparently"--as I
would--but I'm not so sure about that last one.

So here's a situation where I use integer subranges regularly: 
arrays!  I virtually never declare an array where the bounds are
explicitly specified as part of the _array_ definition.  I always do
something like this:

   Max_Items : constant := 100;

   type Item_Count is range 0 .. Max_Items;
   subtype Item_Index is Item_Count range 1 .. Item_Count'Last;

   type Item_Array is array(Item_Index) of Some_Type;
   Items : Item_Array;

So of course I now have full range checking on my indexing and item
counting, and reduce the risk of trying to index it with an "alien"
index.

By that I mean that if Items has been declared as

   Items : array(1..100) of Some_Type;

It could be indexed by any of:

   Widget_Count : Integer;
   Population_Count : Integer;
   Item_Count_A : Integer;
   Item_Count_B : Integer;
   Item_Count_C : Integer;

For none of which are there any constraints on the values they take,
but all are legal array indexers given the latter Items definition. 
(And this is in effect what you get with C/C++ when it comes to
arrays.)

Obviously I've written a few extra lines of code for my array
declaration, what with the three type definitions, but the ROI is that
I've embedded lots of information into my code (which I can extract
with Ada's attributes), plus I get range checking, count and index
verification, and reduced the risk of indexing with the wrong index
variable.

Again, do I or anyone _need_ to do it this way?  No, of course not, I
can be very careful, or be a preternatually gifted programmer that
rarely makes such mistakes, but the latter are rather rare, and don't
you want them focusing their skills on bigger and better things than
keeping array indices straight?

Marc A. Criley

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Gautier]

> > [Ada attributes]
> > ...
> > [other Ada attributes]
> > ...
> > If I had to reproduce them each time I use them, it would sum
> > up to a lot of time... and there are more interesting to do
> > in life than reprogramming them.

softeng:

> Do you really need your own sub-range of integers
> very often?  Arrays with variable index ranges?
> You must do a very different type of programming
> from what I do.

Did I mention "sub-range of integers" ? I did mention
attributes (the things with that symbol: ').
I use 'image, 'value, 'pos, 'val, 'range, 'length very often.
Of course, you'll say "sour grapes", these are useless gadgets
so easy to reproduce.
I say they are very handy, bring clarity and along with subtypes
and enumerated types spares nights with a debugger
- life is too short for it, isn't it ?

Here is a good bunch of these gadgets (in a device driver, BTW!)
-> http://www.mysunrise.ch/users/gdm/e3d_html/multkeys__adb.htm
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On Fri, 9 May 2003 09:30:26 +0100, Tom Welsh <news@tom-welsh.co.uk> wrote:
> 
> I can confirm that, when I was working at DEC in the 1980s, we saw Unix
> first of all as a nuisance, then a threat, and finally as a scourge. The
> reason was its low cost.
> 
> As of about 1981-2, a few of our customer showed up using Unix. At the
> time I was working in the UK Remote Diagnosis Centre, where we could run
> automated tests on remote computers - basically letting our computers
> interrogate the diagnostic consoles. The leading edge of our efforts was
> in looking at the operating system and using it, as well as hardware
> registers, to diagnose problems that could be either hardware or
> software. I remember being able to tell a field service tech, when he
> arrived on site, which fuse to replace in which magtape drive to stop
> the whole system from hanging (bad design, I agree).
> 
> All of this broke down with Unix, because we weren't trained on it and
> had no clue how it worked. (Also, its troubleshooting features at that
> time were rudimentary compared to VMS).
> 
> It was annoying to us that more and more customers - starting with
> universities and other research organisations that couldn't afford our
> usual "corporate" rates - were taking up Unix. VMS was designed
> simultaneously with the VAX architecture, and they had a lot of synergy.
> Unix threw a lot of that away, from our point of view.

Yes that's right.  To a large degree, that was the entire point, and
the attraction.

Nobody cared about the Vax architecture that much.  

I remember academic computing at that time.  People liked the
reliability of the VMS compilers.  Everything else about VMS seemed
constraining and plodding.

Here is one key example.  VMS didn't have a shell where actual
ordinary users could write programs which functioned like the built in
ones.  It was "RUN MY_USER_PROGRAM" versus the huge hairball of "SHOW
THIS/THAT" or "SET THIS TO THAT".

If you wanted to have your own software work like that it was a huge
rigamarole poring through one of the 20 or 30 orange covered
notebooks.

Unix had argc and argv, and a simple library that you didn't even
need to use if you didn't want to.

It was like Alexander cutting the Gordian knot. 

DCL was completely cognitively opaque.  What exactly was it doing, what
programs is it running when?

Unix was dumb, and smart at the same time.

Simply: 

      Unix *felt* like freedom.  
      VMS didn't.

> What we didn't understand was that, from the users' point of view, Unix
> gave them 80 percent (at least) of the benefits for 20 percent (at most)
> of the cost.

It was more than that.  It was fast.  

I knew it was over for DEC the first day the lab I worked in got a Sun
3/260 (?) with a bitmapped terminal, as opposed to the serial
VT220/240's going into the VAX.  The difference was huge: you type
"DIR" and you watch as the system emitted the listing of files, line
by line.  About 15 seconds to complete.  On the Sun, one 'ls' and the
entire home directory listing just *appeared* the moment the return
key returned.

And then when the first MIPS and SPARCs offered an enormous 4-5x VAX
performance at a very much lower cost it was over.

The VAX microstations were pathetic next to their competing Sun 4's. 

> Later DEC executives (a remarkable number of whom now work for
> Microsoft) thought up a new line, which went something like this. Unix
> is OK if all you want is a basic LCD OS. But VMS will always have the
> really valuable extras that help give you competitive differentiation
> (Michael Porter came along just in time for them to grab that straw).
> So, for the extra cost, VMS keeps you 2-3 years ahead of the curve.

> Heard something similar to that lately?

Yeah.  The difference was that DEC was profoundly misguided but ethical,
and DEC never had a substantial monopoly.  

Microsoft has taken the lesson of the IBM anti-trust trial to heart: NEVER
give in to anything.

> -- 
> Tom Welsh

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<b9gldl$9d3@library1.airnews.net>...
...
> 
> As I said, get your facts straight.

This is listed as "early CP/M" source.  The later CP/M
sources are in assembler.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<b9gko2$pub@library1.airnews.net>...

> Let me guess, you're one of these people who believes that only freshmen
> need subscript range checking, aren't you?  You're one of these people who'd
> rather debug a segmentation fault from a core dump than see a message
> "Subscript out of range in <FILE> at <LINE NUMBER>", right?

Well, no.  When I was a freshman and in the habit of making
too many such mistakes, I would indeed have preferred the
latter messages.  Even to the extent of making it the primary
criteria for choosing a language.

But for how long can you keep on making the same type
of mistakes?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Fri, 09 May 2003 21:50:28 -0500 (CDT)
NNTP-Posting-Host: !dQgP1k-XV\OHm? (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305091545.3338f5d5@posting.google.com...
> "John R. Strohm" <strohm@airmail.net> wrote in message
news:<b9gldl$9d3@library1.airnews.net>...
> ...
> >
> > As I said, get your facts straight.
>
> This is listed as "early CP/M" source.  The later CP/M
> sources are in assembler.

Kildall originally wrote CP/M at least partially to demonstrate that PL/M
was powerful enough to write a complete single-user operating system.

The listing I extracted was for CP/M 1.4, the first commonly-available
version.  CP/M 1.4 and CP/M 2.0 were written in PL/M.  The BDOS for CP/M
2.2, by far the most common version, was rewritten in assembler, but the
common utilities (PIP, STAT, and the like) were STILL in PL/M.  CP/M 3.0 did
not see nearly as wide use as CP/M 2.2, as it came out around the same time
as the IBM PC and MS-DOS.

And why the heck am I wasting my time feeding a troll?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Fri, 09 May 2003 21:50:29 -0500 (CDT)
NNTP-Posting-Host: !dQgP1k-XV\OHm? (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305091549.48b9c5d9@posting.google.com...
> "John R. Strohm" <strohm@airmail.net> wrote in message
news:<b9gko2$pub@library1.airnews.net>...
>
> > Let me guess, you're one of these people who believes that only freshmen
> > need subscript range checking, aren't you?  You're one of these people
who'd
> > rather debug a segmentation fault from a core dump than see a message
> > "Subscript out of range in <FILE> at <LINE NUMBER>", right?
>
> Well, no.  When I was a freshman and in the habit of making
> too many such mistakes, I would indeed have preferred the
> latter messages.  Even to the extent of making it the primary
> criteria for choosing a language.
>
> But for how long can you keep on making the same type
> of mistakes?

It only takes one such error in commercial code to create a buffer overrun
vulnerability.  Haven't we seen enough of those?  (Was it Edsger Dijkstra
who compared testing with subscript checking enabled and running production
with it disabled to sailing in the harbor with a life jacket and then taking
the jacket off when you ventured out onto the open ocean?  Maybe it was Tony
Hoare.  I've sailed on the Pacific, in 10-foot seas as I recall; I have a
LOT of respect for open ocean.)

It only takes one such error in safety-critical code to kill someone.  (To
the best of my knowledge, the actual code error behind the Therac-25
fatalities has never been explained.  I would not be at all surprised to
learn that it was a buffer indexing problem that could have been caught
automatically by a type-safe language used properly.)  I take
safety-critical code very seriously.  (Maybe it comes from working on F-16,
knowing that friends of mine would be flying those airplanes, betting their
lives on that code.)

And then there was image processing on the TI 320C80, where you HAD to do it
in assembly language, and the first warning that you'd overrun your buffer
was that the processor (and emulator) hung up hard, waiting for a memory
fetch that would never finish...

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Jim Weirich]

John R. Strohm wrote:

> And this one http://www.cpm.z80.de/source.html contains, among other
> things,
> the original CP/M source code.  In PL/M.  Complete with Gary Kildall's
> copyright notice.
> 
> Here are the first few lines.

Wow ... this brings back memories.  PL/M was the system programming 
language for Intel's iRMX real timg system back in the 80s.  We used iRMX 
as a basis for a real time data acquisition system for digital jet engine 
controllers.  All the programming was done in PL/M, including interrupt 
handlers and device drivers.  No assembly code anywhere.  (C was used in 
some later systems.)

However, I didn't know that CP/M was written in it.  Thanks for the info.

One minor quibble ... 

  > CP/M was written in PL/M, a variant of PL/I developed by Dr. Gary
  > Kildall.

PL/M certainly owed its syntactic heritage to PL/I (that's obvious from 
looking at the code), but semantically it was much closer to C (which is 
appropriate given its target platform).

-- 
-- Jim Weirich     jweirich@one.net    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Tim Ottinger]

soft-eng wrote:
> 
> But to intimidate Ada advocates you only
> need to mention the word "pointers" :-)

I never try to intimidate Ada programmers.
Some wonderful programmers have been Ada
guys. I once saw a project for the army
written in Ada (of course) with no comments
at all. And it didn't need them. If you
could read Ada, you could tell what it was
doing.

But if you try to intimidate Ada guys, they'll
let you know that their data types and generics
can beat up your data types and templates.

Any day.

I don't remember much about my Ada training.
That's sad. I wish I did. Of course, now I'm
migrating toward more Python and Perl than even
C++, and PHP on the side for fun.  I can't be
a language bigot, because I use more than one.

When I only knew C and BASIC, it was easy to
be biased toward C.  But you live and you learn.

Oh, the only SERIOUSLY multi-lingual (software-wise)
people I know who are seriously bigoted are bigoted
towards Mod3 or Smalltalk.

And I suspect that they're right.

Tim

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Tom Welsh]

In article <9fa75d42.0305090937.2bbe1238@posting.google.com>, soft-eng
<softeng3456@netscape.net> writes
>"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:<b8toba
>$79o$1@slb0.atl.mindspring.net>...
>
>> "competent" and most had many years of experience, but still, the language
>> made a difference to the bottom line. My competitors are still using C. I
>> say "Good for them!" My improved productivity and reduced defects translates
>
>If you can indeed have improved productivity and reduced defects,
>it stands to reason that your competitor will not be doing very
>well versus you!
>
>Bottom lines do count.  If time after time it so happened
>that people using Ada out-competed the ones using C,
>others would start taking notice.
>
Such "bottom-line" comparisons are usually vitiated by failure to
account for total lifetime costs (total cost of ownership). 

Having followed the software development industry for the last 20 years,
I have been struck time and again by the short-term nature of buying
decisions. Usually, people simply do not take into account how much it
will cost to maintain and/or extend an application over 10, 20 or 30
years. Indeed, these lifetimes themselves are often grossly
underestimated - one of the reasons for the Y2K panic.

It's not surprising, as decision-makers are usually not technically
knowledgeable - and even if they were, it's more art than science.
But how many times have we heard of projects going to the low bidder,
who ends up (surprise, surprise!) costing far more than the higher
bidder with a better grip on quality? And that's just for
implementation!

One of the main reasons for the whole Ada initiative was to reduce the
cost of the whole software lifecycle - not just initial development. But
because that TCO is so hard to measure, Ada has not been given credit
for reducing it.

-- 
Tom Welsh

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

soft-eng wrote:
> gautier_niouzes@hotmail.com (Gautier) wrote in message news:<17cd177c.0305011129.2eab5fb8@posting.google.com>...
> 
>> You simply ignore the huge debugging time provided
>> by poorly-typed languages and its effective relation to
>> job safety. So what ?
> 
> No -- having worked on reasonably large projects
> in C, I can say that with professional programmers
> with experience in a language like C, this
> simply ceases to be an issue.  *MOST* bugs
> in a professional C project have nothing to do
> with type safety.  

This is utter hogwash and it is a great folly to depend on the
infallibility of humans!

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

soft-eng wrote:
> PS:  Now if Ada had GC, that could have changed
> things a lot.  People would have used it despite
> all the warts.

And what warts might that be?

> A LARGE amount of debugging time in C/C++ is spent
> dealing with dynamic memory bugs!  But Ada had
> only a half-hearted nod to GC, no actual GC support.

http://www.datanation.com/fallacies/

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dale Stanbrough]

soft-eng wrote:

> But for how long can you keep on making the same type
> of mistakes?

Forever, if we examine software faults. What's your point?
That people -shouldn't-? I would agree with that. That people
can learn to be 100% accurate in everything they do? I don't
think i'll agree on that.

dale

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marin David Condic]

I think this is an execlent illustration of a point you made elsewhere. Ada
types and checks are nice for avoiding errors, but an even bigger benefit is
that they allow you to express the solution to a problem in a manner that is
reflective of the problem. Sort of like the difference between a language
that allowed only 1 character for variable names (or 6 or 8 or some limited
number) versus a language that has unlimited length identifiers. Sure, you
can program a solution to something using names like X and Y and Z and one
might argue that "Any Competent Programmer" would document the meanings of
X, Y and Z with comments and be able to follow the "intuitively obvious"
meaning of the code from there (to *competent* programmers, of course). But
given unlimited length identifiers, would not the solution be more
reflective of the problem at hand? The same thing goes for use of type
definitions. You can get there with int and float and char and bool, but
isn't it a lot more expressive of the problem when you can define types that
reflect the intent behind what you're trying to solve? Wasn't that one of
the incentives behind the whole OO thing?

MDC



Marc A. Criley <mcq95@earthlink.net> wrote in message
news:254c16a.0305091127.42ec7b21@posting.google.com...
> softeng3456@netscape.net (soft-eng) wrote in message
news:<9fa75d42.0305090612.261d5a5c@posting.google.com>...
>
> So here's a situation where I use integer subranges regularly:
> arrays!  I virtually never declare an array where the bounds are
> explicitly specified as part of the _array_ definition.  I always do
> something like this:
>
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marin David Condic]

There were at least two formal studies I've seen comparing Ada and C. One
was as close to a controlled scientific experiment as you can get with
software development as I've ever seen. Both showed that when all other
factors were held equal, Ada came out significantly more productive & less
defective than C. In particular, it appeared that Ada got its best
improvements against C when it came to realtime, embedded work. (Dr.
McCormac's railroad experiments). This validates my own study, so I'm happy
to rest with that conclusion. There are probably other studies of which I'm
not aware. It would be highly unscientific to neglect what they demonstrate,
but I'm sure that there are folks who will not be satisfied that this is the
case even if you showed them 100 studies. When someone doesn't want to
believe something, they will inevitably find reasons to do so.

The problems Ada has encountered in gaining market acceptance don't have
much to do with either lack of real productivity improvements nor with lack
of technical merit. It has plenty more to do with the "all other things
being equal" part. In the real world, all other things are seldom equal.
When most RTOS's, support tools, embedded target hardware, prefabricated
libraries, etc., are all oriented towards C, its tough to consider some
other language because it lacks the same development leverage. If Ada wants
to be competitive against C, C++, Java and others, it has to look to provide
similar or more leverage than one gets with these other environments.

In the mean time, I'll keep using Ada in my little world and, yes, we have
kicked our competitor's butts using it. :-)

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

soft-eng <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305090937.2bbe1238@posting.google.com...
> "Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
news:<b8toba$79o$1@slb0.atl.mindspring.net>...
>
> If you can indeed have improved productivity and reduced defects,
> it stands to reason that your competitor will not be doing very
> well versus you!
>
> Bottom lines do count.  If time after time it so happened
> that people using Ada out-competed the ones using C,
> others would start taking notice.
>
> But in fact time after time it has failed to happen, and the only
> successful cases in Ada usage come from the situations
> where it was mandated and no competition existed at all,
> and money was no object.  If you have a business
> like that, sure, use whatever language you like.
>
> Otherwise, it might be worthwhile looking carefully at
> situation, and not just basing things on a study or two.
>
> Studies, in general, can prove all kinds of amazingly
> interesting things.  Sometimes even six before breakfast.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marin David Condic]

While I agree with the sentiment here, I ought to toss out a couple of
cautionary notes. First off, remember that most software projects don't have
the lifespan of your typical DoD project. The programming for this year's
model of VCR or Accounting Package or Video Game can become pretty much
obsolete within one to two years. The programming for the JSF engine control
will pretty much have to stick around for 30 or more years. In the former
case "Time To Market" is everything, so you'd better look at development
leverage and to hell with long term cost of ownership. In the latter case,
the metal-benders will still be trying to figure out how to cut a turbine
blade while you're getting a part number for the first validated release of
your software, so you need not worry about development leverage so much as
the long term costs of cutting software releases over 30 years.

Another cautionary note is that all too often we engineers tend to see a
cost savings in some area and latch onto that as if it were the whole
picture. I believe that Ada saves long-term development and maintenance
costs because I've seen the metrics to demonstrate this within the realm I
deal in. However, the maintenance is not the *only* factor in the whole
economic equation, and I have seen other software developments in other
disciplines where this can be shown to be minimal in comparison to other
cost drivers. Hence we need to always be careful to do a real assessment of
all the costs and not assume that Ada is an automatic winner. Ada can often
lose because it doesn't provide as much leverage or costs more to get the
support tools needed. You need to do the math.

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Tom Welsh <news@tom-welsh.co.uk> wrote in message
news:5s29SIA1KKv+EwcU@nildram.co.uk...
>
> One of the main reasons for the whole Ada initiative was to reduce the
> cost of the whole software lifecycle - not just initial development. But
> because that TCO is so hard to measure, Ada has not been given credit
> for reducing it.
>

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1052495061.43545@master.nyc.kbcfp.com>...
> soft-eng wrote:
> > That should be "in tribute to CLU".
> 
> Well, *I* write it in tribute to Ada, regardless of whether
> it has its origins in a different language.

Oh!  That's all right then -- I misread that as you not having
any clu about the source of generics in Ada!!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Tom Welsh <news@tom-welsh.co.uk> wrote in message news:<5s29SIA1KKv+EwcU@nildram.co.uk>...
> In article <9fa75d42.0305090937.2bbe1238@posting.google.com>, soft-eng
> <softeng3456@netscape.net> writes
> >"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:<b8toba
> >$79o$1@slb0.atl.mindspring.net>...
> >
> >> "competent" and most had many years of experience, but still, the language
> >> made a difference to the bottom line. My competitors are still using C. I
> >> say "Good for them!" My improved productivity and reduced defects translates
> >
> >If you can indeed have improved productivity and reduced defects,
> >it stands to reason that your competitor will not be doing very
> >well versus you!
> >
> >Bottom lines do count.  If time after time it so happened
> >that people using Ada out-competed the ones using C,
> >others would start taking notice.
> >
> Such "bottom-line" comparisons are usually vitiated by failure to
> account for total lifetime costs (total cost of ownership). 
> 
> Having followed the software development industry for the last 20 years,
> I have been struck time and again by the short-term nature of buying
> decisions. Usually, people simply do not take into account how much it
> will cost to maintain and/or extend an application over 10, 20 or 30
> years. Indeed, these lifetimes themselves are often grossly
> underestimated - one of the reasons for the Y2K panic.

Y2K impact was overestimated!

> It's not surprising, as decision-makers are usually not technically
> knowledgeable - and even if they were, it's more art than science.
> But how many times have we heard of projects going to the low bidder,
> who ends up (surprise, surprise!) costing far more than the higher
> bidder with a better grip on quality? And that's just for
> implementation!

And how many times exactly, has this not happened due to Ada?

> One of the main reasons for the whole Ada initiative was to reduce the
> cost of the whole software lifecycle - not just initial development. But
> because that TCO is so hard to measure, Ada has not been given credit
> for reducing it.

I agree that total cost is hard to measure.  My point was that
a language like Ada SEEMs like it is great for software
development.  And it is indeed great for academic exercises.
But actual software development doesn't suffer much from
the maladies Ada targets (it suffers from different ones.)
So a cost-benefit analysis would have to assign some slight
benefits to Ada but much other costs.  So if you are
willing to put up with lots of costs for little benefit
(e.g. if you have a bottomless pit to draw funds from),
Ada might be excellent.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbbpe3n.3o1.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> soft-eng wrote:
> > gautier_niouzes@hotmail.com (Gautier) wrote in message news:<17cd177c.0305011129.2eab5fb8@posting.google.com>...
> > 
> >> You simply ignore the huge debugging time provided
> >> by poorly-typed languages and its effective relation to
> >> job safety. So what ?
> > 
> > No -- having worked on reasonably large projects
> > in C, I can say that with professional programmers
> > with experience in a language like C, this
> > simply ceases to be an issue.  *MOST* bugs
> > in a professional C project have nothing to do
> > with type safety.  
> 
> This is utter hogwash and it is a great folly to depend on the
> infallibility of humans!

Thanks for proving my point!

Here we have a clearly novice user, who has been fed
the impression Ada solves the problem of fallible humans.

Imagine his surprise when he slowly progresses to serious
programming, and starts to discover that all of his logic
errors will continue to stay logic errors, Ada or no Ada.
And the ultimate solution for those logic errors will
come from -- horrors, fallible humans.

Of course, for freshmen programmers whose biggest problem is
getting the types right, Ada is clearly useful.  No doubts
about that.  Also for those who are never going to
progress to any programming that requires something more
complex than getting the types right.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:<b9j17h$svj$1@slb6.atl.mindspring.net>...
> reflect the intent behind what you're trying to solve? Wasn't that one of
> the incentives behind the whole OO thing?

Yes.  OO solves the problem using a new model.  Ada solves
the problem by collecting numerous small solutions.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Vinzent Hoefler]

softeng3456@netscape.net (soft-eng) wrote:

>Yes.  OO solves the problem using a new model.

And introduces new ones as well... instead of tracing a function with
the debugger like one did in the old days, we now look at an
inheritance graph and try to guess which method may do the unexpected
thing the customer encountered. :)

>  Ada solves
>the problem by collecting numerous small solutions.

Not exactly. Ada95 has complete OO, although its syntax might be a
little bit, mmh... unusual[0] (but this has even other advantages) -
but it still has all the type information features that makes portable
and dynamic (in the sense of requirements changes) programming much
more easier.

I may state John Barnes from his "High Integrity Software" talking
about the lack of enumeration types in Java (but this applies to C++
as well because the enumeration model there is still just based on
integer constants):

"The wave of enthusiasm for Object Orientation (OO) in all its dynamic
glory (which indeed has its uses but by its very dynamic nature can
create difficult problems) appears to have caused other established
language features to be neglected with the consequence that many
programmers no longer have the benefits of simple language-based
debugging aids."

I think, he's right. My question would be: What use is OOP when the
only objects I can have are chars, ints and doubles?


[0] Well, let's talk about the syntax of Smalltalk, then... ;-) 


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP

[The Ghost In The Machine]

In comp.lang.java.advocacy, Frank J. Lhota
<NOSPAM.lhota.adarose@verizon.net>
 wrote
on Thu, 08 May 2003 15:21:37 GMT
<5Cuua.10$tc5.3@nwrdny03.gnilink.net>:
> "The Ghost In The Machine" <ewill@sirius.athghost7038suus.net> wrote in
> message news:83jno-vjm.ln1@lexi2.athghost7038suus.net...
>> No problem, the C compiler would have caught it. :-)
> 
> Not necessarily! Most C compilers will compile the following code without
> warning, although actually calling this version of funcname is bound to
> cause trouble.
> 
> /**************************************/
> #include <stdio.h>
> 
> void funcname (FILE file)
> {
>    fprintf( &file, "Hello, World!\n" );
> }
> 

Ewww.  Buffer loss, memory leak.  Not good.  :-)

-- 
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Sat, 10 May 2003 20:57:27 -0500 (CDT)
NNTP-Posting-Host: !^4pV1k-WRrN-n` (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305100927.422ffb88@posting.google.com...
> I agree that total cost is hard to measure.  My point was that
> a language like Ada SEEMs like it is great for software
> development.  And it is indeed great for academic exercises.
> But actual software development doesn't suffer much from
> the maladies Ada targets (it suffers from different ones.)

How about you cite a few URLs to back up this claim?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

Wesley Groleau wrote:
> 
>> I don't know where this notion arose that a "super-strong"
>> type system is just for preventing bugs. I know that in C++
> 
> 
> I didn't say that it was only for preventing bugs.
> I said it's a crock that it requires programmers
> to do a lot of allegedly unnecessary workarounds.
> 
> For me, preventing bugs is the second biggest benefit
> of Ada's type system.  The bigger one is that it
> allows you to define things in terms of your
> abstraction instead of your implementation.

I think my first deep insight into the implications of Ada programming 
came in 1983, just after Ada 83 became an ANSI standard.  I told someone 
working on our (Ada) compiler: "No, in Ada you model the problem space, 
not the solution space."  I then excused myself for a minute to write it 
on my office whiteboard.

The reasons this works so well are twofold.  First it makes code much 
more understandable to the reader--and therefore logic bugs are much 
more obvious.  But the second and more powerful reason is that 
requirements change.  If your abstraction model is close to the "real" 
world problem space, then changing requirements have no effect on most 
of the code.

My favorite example is a program I wrote in a few hours to demonstrate 
the "right" way to generate random permutations in Ada.  The main loop 
of the program looks like:

for I in 0..Number_of_Hands - 1 loop
         Text_IO.New_Page;
-- Print header
     --  Put_Line calls to output Board number, Dealer and
     --  Vulnerability omitted.
     Shuffle(Deck, Gen);
     Deal;

-- Print hands.
    --  More Put_Line calls with arguments like Cards(North, Spades)
    --  omitted.
   end loop;

The type declarations are also very closely bound to the problem space, 
a deck of cards:

   type Suits is (Spades, Hearts, Diamonds, Clubs);
   type Ranks is (Ace, King, Queen, Jack, Ten, Nine, Eight, Seven,
                 Six, Five, Four, Three, Deuce);
   ...
   type Card is record
     Suit: Suits;
     Rank: Ranks;
   end record;

   type Card_Array is array (Natural range <>) of Card;

   Deck: Card_Array(0..51);

It is really, really hard to have bugs in code that is as unsubtle as 
that.  And even if the universe changes, the changes are pretty 
localized.  For example, it would take just a few minutes to change the 
code to deal Pinochle hands, or even to switch to a Tarot deck.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

Tim Ottinger wrote:

> Oh, the only SERIOUSLY multi-lingual (software-wise)
> people I know who are seriously bigoted are bigoted
> towards Mod3 or Smalltalk.
> 
> And I suspect that they're right.

I won't argue against either language.  And I think if you study the 
people who are considered Ada language bigots, you will find that by and 
large, they have written a lot more code in other languages than you 
have.  In my case, I have used APL, Lisp, C, Fortran, Cobol, Pascal and 
perhaps a dozen other languages on significant projects.  Due to working 
at Honeywell and Stratus, over my career, I have probably written more 
lines of PL/I than Ada or any other language.  In any case, I am 
probably most fluent in BNF.  (Backus-Naur Form, used for specifying 
grammars.)

The original purpose of the HOLWG (High Order Language Working Group) 
that eventually created Ada was to reduce the number of programming 
languages used by the DoD.  At one point this was over 800.

When they studied the problem the biggest problems were in embedded 
software and there was no single high-level language that could deal 
with all of the DoD's embedded programming needs.  Ada was created to be 
that language, and the first DoD mandage was to use one of 17 (I think) 
high-level languages.  When Ada became available that list was prunded 
further, and the misunderstood Ada madate (for large programs) cut that 
to one.

So almost every Ada advocate will tell you that this language or that 
language is better for this particular purpose.  What we agree strongly 
on is that when "programming in the large" the only language to consider 
is Ada, even if most of the low-level modules are written in C, Fortran, 
or whatever.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Hyman Rosen]

Robert I. Eachus wrote:
>     Shuffle(Deck, Gen);
> 
> It is really, really hard to have bugs in code that is as unsubtle as 
> that.  And even if the universe changes, the changes are pretty 
> localized.  For example, it would take just a few minutes to change the 
> code to deal Pinochle hands, or even to switch to a Tarot deck.

I think this is a perfect example of the blind spot of Ada programmers.
You are so enamored of enumerations and perfectly indexed arrays and
lack of buffer overflows that you will probably miss the most likely
and subtle bug of this kind of code, which is that the Shuffle routine
fails to produce each possible permutation with uniform probability!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Richard Riehle]

soft-eng wrote:

> Oh, right!  The Ada compilers ranged as high as $1500s iirc,
> but Janus had a low cost one.  But if the quality was
> so good, and the cost was so low (right in line
> with Turbo Pasca, Quick C etc), the incentives
> so high (defense contracts) it just proves
> that the language was found un-usable
> by programmers.

It was not the language that was un-usable, but the
implementations often fell short of what was necessary
for a given platform.

Turbo Pascal was popular because it had a good development
environment.  No one ever developed anything as good for
Ada that was reasonably priced.    Ada was a better language
design, and could be used with the same ease as Pascal, but
those who published compilers seemed to overlook the need
for ordinary programmers to be able to create code easily.

Meridian Ada had a set of very nice packages that made DOS
programming a little easier.  It was even priced so it could
be used.  Meridian also, finally, produced a development
environment.    Then, Meridian sold itself to Verdix,  which
did nothing much with it, which finally became absorbed
by Rational which quietly euthanized it by selling it to a
publisher who had no idea what to do with it.  Had Meridian
been allowed to migrate to Ada 95, it might have done well,
even in competition with GNAT and ObjectAda.

It is not enough to create a better language.  These days, the
development environment and libraries are as important as
the language.   If I have some really excellent seeds that will
grow into great flowers,  those seeds are no good to me unless
I have suitable soil, climate, and growing conditions for them.
And, if I have no tools for plowing, planting, tending, and
harvesting, even the best of plants will be starved out by the
weeds.

One of the best examples was the Tandem Computers Ada
compiler.  The small group within Ada that developed the
compiler did a pretty good job.   They produced a compiler
that could be validated by the then standard validation suite.
Once that was done, Tandem executives halted all additional
work.   There was no effort to ensure the Tandem Ada compiler
could work in conjunction with the other Tandem products.
There was not effort to take advantage of Tandem's excellent
non-stop environment (still an superior product even today),
or distribute tasks across its dynabus architecture.  One
Tandem executive quietly confided to one of my (now-deceased)
colleagues, that Tandem Ada was intended to be a "checkbox"
product so they could check off the box on a procurement
RFP's, "Yes" for validated Ada.   No one was expected to
actually use it for anything.   I did have a chance to use it,
and even talked with one of the programmers who wrote the
compiler.   A medical group in Salt Lake City used Tandem
Ada but finally gave up on it because it was so hard to
interface it to the rest of Tandem's products.

The Tandem story illustrates the attitude of a lot of people
throughout the 1980's regarding Ada.   Although Tandem could
not be accused of "malicious compliance" the ultimate effect
was the same.   Perhaps it was more like "indifferent compliance,"
a more insidious path to destruction.    Other hardware vendors
were as guilty (some more so) in their attitude toward Ada.  At
least one gigantic company, after being awarded a huge contract
for an Air Traffic Control project, blamed Ada for their failure,
their own Ada compiler it seems,  even though many of the
programmers on the project knew  that the failure originated
in the incompetence of those assigned to manage the project.
This included the fact that they never created development
tools to support their own Ada compiler.

Most of the project failures with Ada happen for the same reasons
projects fail using other languages:  managerial incompetence.  While
I believe Ada is more appropriate for certain kinds of software
applications than some competing technologies, it is not more appropriate
if it is handicapped by a lack of development tools.   The best seeds
will not grow without  water and good soil.

Java succeeds for a variety of reasons, none of which has anything to do
with its qualities as a programming language design.   Someone mentioned
the anti-Microsoft sentiment.  This is often justified since Microsoft seems
to have become someone arrogant about the developer community.  Sun
did an excellent job of publicizing Java's benefits, if not its drawbacks. Of
real importance is the the sustained availability of libraries, development
tools, and infrastructure.   None of the administrators of the DoD AJPO
initiatives could ever do as well.  They never had the funding, the
entrepreneurial leadership, nor the experience to make AJPO really
strong and vital.   Some intitiatives, in the mid-Nineties, including
an idiotic Ad campaign, simply evoked derisive chuckles.

Now that Ada must stand on its own, newer initiatives are emerging
that can make it a viable choice for certain classes of software
development.  CLAW, GWindows, GtkAda, and even JEWL open
new avenues for people who want to do GUI programming.  This
was never Ada's strong suit before, but it can be now.   Development
environments from companies such as Green Hills demonstrate how
one can integrate Ada into mainstream development projects and
provide serious interoperability opportunities for Ada.   The new
product from ACT,  GPS, promises to open up new frontiers for
Ada as a language for new kinds of development.   The George
libraries, along with other resuable component libaries can
make Ada attractive for a larger range of applications.

Is it too late?   I often ask myself this question.   With the decision
to abandon Ada for JSF (a wrong decision in my opinion),  along
with the increasing use of Java instead of C, C++, or Ada for
educational venues it will be a mighty struggle for Ada to make
a comeback.   The decision to abandon support for JGNAT
demonstrates one of the serious problems with Ada.   This
decision is reminsicent of the "bodice ripper" phrase, "seduced
and abandoned."   Just as many of us in the educational community
were becoming excited by the opportunities for JGNAT, began
projects using it, got thesis students enthused about it, had
other professors asking about it, it vanished.

If Ada is to succeed, we must stop promising what we cannot
deliver, and deliver what we do promise.   Products that are
under-funded, under-supported, and potentially doomed do
not inspire confidence.   No one wants to commit to a language
or development environment with a short lifespan.   For Ada
to succeed, those of us who produce products and services
must be ready to support those products and services for as
long as our customers need them.    Those companies who are
telling their clients that they are abandoning Ada are not doing
it any good.  At the recent Embedded Systems Conference,
Green Hills made it clear that Ada was being good for them and
they unashamedly sang its praises to anyone who wanted to know
about it.   Certain other companies, one whose fortunes were
built on Ada, seemed intent on hiding any knowledge about its
Ada products or history with Ada.   I found myself directing
people to visit the Green Hills booth which I saw as Ada friendly.

It's Sunday afternoon, Mother's Day, and I should be doing other
things with my day.  Instead, I got caught up in this rant.
My apologies.

Richard Riehle

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Hyman Rosen]

Richard Riehle wrote:
> It was not the language that was un-usable, but the
> implementations often fell short of what was necessary
> for a given platform.

Over in the C++ newsgroups people like to kid Andrei Alexandrescu
for being the only person in the world who can make a living writing
C++ libraries that no compiler in existence can compile.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

John R. Strohm wrote:

 > It only takes one such error in safety-critical code to kill someone.
 >  (To the best of my knowledge, the actual code error behind the
 > Therac-25 fatalities has never been explained.  I would not be at all
 >  surprised to learn that it was a buffer indexing problem that could
 > have been caught automatically by a type-safe language used
 > properly.)

I can't let that comment about Therac-25 pass unchallenged.  Nancy
Leveson has a very complete write-up on the Therac-25 problems.
The link http://sunnyday.mit.edu/therac-25.html will let you choose 
between PDF and Postscript versions.  The paper is 49 pages long, and I 
quail at trying to describe all the safety problems found in much less 
text. However, at least two specific software errors that could--and 
did--kill patients were found and connected with specific Therac-25 
overdose incidents.  Other cases could be from one or the other of these 
bugs, or several dozen other problems, but there is insufficient data to 
be certain.

The two bugs identified with particular patient deaths were one where, 
if the operator to edited the settings and hit P (for procede) within 8 
seconds after an error message, some key settings were not rechecked. 
In the other, a semaphore was incremented instead of being set to a 
specific value.  The semaphore was one byte long, and the code involved 
periodically checked settings.  If you hit the right key (I think it was 
B this time) just after the semaphore rolled over, some checks were in 
effect bypassed.

However, the particular software bugs that were actually determined to
have killed patients were a minor part of the entire Therac-25 debacle.
The real problem was that the system as a whole--hardware and 
software--was so buggy, and documentation and manufacturer support were 
so poor, that operators were used to ignoring software error codes and 
hardware "glitches."  I'd have to re-read the entire report to be sure, 
but I think that in all but one case of a patient overdose, the operator 
continued operation after some error message appeared.

As far as I am concerned, once I read that there was an error message,
that indicated the dosage was too high or too low, and that if it was
too high the displayed dosage was too low, I sort of gave up.  I don't
even want to think about Pointy-Haired Bosses and safety-critical
software beyond that.  I might be tempted to go on a shooting rampage.

Nancy's report is practically a catalog of every type of design,
management and process error you can make in building a safety-critical
system.  Using Ada might have helped, at least with those two bugs, but 
the real necessity was a safety-critical development process.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Sun, 11 May 2003 16:15:20 -0500 (CDT)
NNTP-Posting-Host: ![-nV1k-WWi2kke (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3EBE9BD4.1050008@attbi.com...
> Wesley Groleau wrote:
> >
> >> I don't know where this notion arose that a "super-strong"
> >> type system is just for preventing bugs. I know that in C++
> >
> >
> > I didn't say that it was only for preventing bugs.
> > I said it's a crock that it requires programmers
> > to do a lot of allegedly unnecessary workarounds.
> >
> > For me, preventing bugs is the second biggest benefit
> > of Ada's type system.  The bigger one is that it
> > allows you to define things in terms of your
> > abstraction instead of your implementation.
>
> I think my first deep insight into the implications of Ada programming
> came in 1983, just after Ada 83 became an ANSI standard.  I told someone
> working on our (Ada) compiler: "No, in Ada you model the problem space,
> not the solution space."  I then excused myself for a minute to write it
> on my office whiteboard.
>
> The reasons this works so well are twofold.  First it makes code much
> more understandable to the reader--and therefore logic bugs are much
> more obvious.  But the second and more powerful reason is that
> requirements change.  If your abstraction model is close to the "real"
> world problem space, then changing requirements have no effect on most
> of the code.
>
> My favorite example is a program I wrote in a few hours to demonstrate
> the "right" way to generate random permutations in Ada.  The main loop
> of the program looks like:
>
> for I in 0..Number_of_Hands - 1 loop

There is ABSOLUTELY NO EXCUSE in Ada for the above.  Human beings learn to
count starting at "one", not "zero".

  for I in 1..Number_of_Hands loop


>          Text_IO.New_Page;
> -- Print header
>      --  Put_Line calls to output Board number, Dealer and
>      --  Vulnerability omitted.
>      Shuffle(Deck, Gen);
>      Deal;
>
> -- Print hands.
>     --  More Put_Line calls with arguments like Cards(North, Spades)
>     --  omitted.
>    end loop;
>
> The type declarations are also very closely bound to the problem space,
> a deck of cards:
>
>    type Suits is (Spades, Hearts, Diamonds, Clubs);
>    type Ranks is (Ace, King, Queen, Jack, Ten, Nine, Eight, Seven,
>                  Six, Five, Four, Three, Deuce);
>    ...
>    type Card is record
>      Suit: Suits;
>      Rank: Ranks;
>    end record;
>
>    type Card_Array is array (Natural range <>) of Card;
>
>    Deck: Card_Array(0..51);

Same comment.

   Deck: Card_Array(1..52);

> It is really, really hard to have bugs in code that is as unsubtle as
> that.  And even if the universe changes, the changes are pretty
> localized.  For example, it would take just a few minutes to change the
> code to deal Pinochle hands, or even to switch to a Tarot deck.

Actually, with a Tarot deck, it would be a bit harder.  You have the four
different suits, and the various numbered cards, but you also have the
various special cards (e.g., the Fool, the Tower, Death...) that have to be
handled separately.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Sun, 11 May 2003 16:15:21 -0500 (CDT)
NNTP-Posting-Host: ![-nV1k-WWi2kke (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:T7yva.16129$rV2.4345@nwrdny01.gnilink.net...
> Robert I. Eachus wrote:
> >     Shuffle(Deck, Gen);
> >
> > It is really, really hard to have bugs in code that is as unsubtle as
> > that.  And even if the universe changes, the changes are pretty
> > localized.  For example, it would take just a few minutes to change the
> > code to deal Pinochle hands, or even to switch to a Tarot deck.
>
> I think this is a perfect example of the blind spot of Ada programmers.
> You are so enamored of enumerations and perfectly indexed arrays and
> lack of buffer overflows that you will probably miss the most likely
> and subtle bug of this kind of code, which is that the Shuffle routine
> fails to produce each possible permutation with uniform probability!

Let's see, are you saying we shouldn't eliminate the simple problems because
we can't eliminate the hard problems at the same time?

The obvious end consequent of that argument is that we should all be
programming in absolute binary.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

Robert I. Eachus wrote:

 > My favorite example is a program I wrote in a few hours to 
demonstrate > the "right" way to generate random permutations in Ada.

Hyman Rosen wrote:
> I think this is a perfect example of the blind spot of Ada programmers.
> You are so enamored of enumerations and perfectly indexed arrays and
> lack of buffer overflows that you will probably miss the most likely
> and subtle bug of this kind of code, which is that the Shuffle routine
> fails to produce each possible permutation with uniform probability!

Did you read what I wrote, really?  Should I have included the notes in 
the Shufflling routine which showed why this particular method of 
generation permutations was unbiased?  Okay done:

    procedure Shuffling (List : in out List_Type;
                         Gen  : in     Generator) is
-- a routine for producing permutations of a list of elements.  Note
-- that this method is unbiased for any independent sequence.  (For
-- any two cards the possibility that they will be in a particular
-- order is exactly 1/2, this can be extended by iteration to show
-- that each sequence has a probablity of 1/N!   Note that for large
-- lists of elements not all permutations will be generated.  There
-- are N! permutations of a list of N values, and this may be much
-- greater than the number of generator states.  Note also that the
-- actual number of different possible permutations generated from
-- one starting seed is k/GCD(N,k) for a generator with k states.

       List_Copy : constant List_Type := List;

       type Rec is
          record
             Index : Index_Type;
             Rand  : Float;
          end record;

       type Rec_Array is array (Index_Type range <>) of Rec;

       Temp : Rec_Array(List'Range);

       function "<" (L, R: Rec) return Boolean is
       begin return L.Rand < R.Rand; end "<";

       procedure Sort is new Sorting(Rec, Index_Type, Rec_Array, "<");

     begin
        for I in Temp'Range loop
           Temp(I) := (I, NFR.Random(Gen));
        end loop;

        Sort(Temp);  --  Sort based on value of random number

        --  Now rearrange List based on the order of indices in Temp
        for I in List'Range loop
           List(I) := List_Copy(Temp(I).Index);
        end loop;
     end Shuffling;

Again, no subtlety present or wanted.

Note that for Ada, the generator you get from Ada.Numerics.Float_Random 
will usually have more that 2^32 states.  If it is the one I wrote that 
is in Gnat, the GCD mentioned will be one, unless N has a factor that is 
one of two five digit primes. Oh, and this is the body of a generic 
where Element_Type, List_Type, and Index_Type are generic parameters. 
Okay? No?

Well if you really need a longer period generator, write me.  The other 
alternative is to combine two generators with independent seeds and 
periods.  Adding typical [0..1) generators and if >1, subtracting 1 
works just fine unless one of the generators is biased.  In fact, for 
most tests of randomness, you get more random behavior than either 
generator alone.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

soft-eng wrote:

> Y2K impact was overestimated!

I normally don't respond to trolls, but this was too much.  Go get a 
list of the banks in business in 1995.  Doesn't have to be complete, for 
example it could be a list of all banks with federal charters.  Now look 
at the same list for the year 2000.  Over 90% of the banks from your 
first list will have disappeared, and not due to name changes.

The Y2K crisis was underestimated for over a decade, then it started 
getting the attention it deserved.  The result was a lot of bank mergers 
to reduce the cost of the software work required.  In the area where I 
live, one bank, St. Mary's Bank and a couple of credit unions survived. 
  All the rest eventually merged into other banks.  (In case you care, 
Bank of New Hampshire was one of those that moved into the area by 
buying other banks.  I had one checking account which went through five 
banks and another that went through four during this period, as banks 
were swallowed by bigger banks, then merged again and again.)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Shayne Wissler]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3EBEB9AE.2060704@attbi.com...

> Nancy's report is practically a catalog of every type of design,
> management and process error you can make in building a safety-critical
> system.  Using Ada might have helped, at least with those two bugs, but
> the real necessity was a safety-critical development process.

Clearly the way this machine was developed was very poor. But what should
have prevented these accidents was the judgement of the people buying the
machines. It was very clear from the report that these Therac-25's were
extremely buggy, that part of the operator's standard procedure was hacks to
work around the glitches. I mean, the thing was worse than Windows 3.1.

The machine did not function as designed, nor as any reasonable person would
expect. Yet the hospital staff still purchased and used the machines. Now if
this machine were something used for a relatively safe procedure, like
writing a document, and all that you were going to lose was your work since
your last save, that would be one thing. But these hospitals were putting
their patient's lives on the line. Any hint of a flawed machine should have
resulted in taking them out of service. But they had much more than a hint.


Shayne Wissler

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

> I think this is a perfect example of the blind spot of Ada programmers.
> You are so enamored of enumerations and perfectly indexed arrays and
> lack of buffer overflows that you will probably miss the most likely
> and subtle bug of this kind of code, which is that the Shuffle routine
> fails to produce each possible permutation with uniform probability!

Hyman, your posts are generally rational,
even when we disagree.  But you must have
had a brain fart on this one.  Robert's
post contained not even a hint of the
implementation of the Shuffloe routine,
so there is NO WAY you could have either
tested it or analyzed it to justify your
claim that it is not random.

On top of that, a shuffle by human hands
probably does not produce each possible
permutation with uniform probability!

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Hyman Rosen]

John R. Strohm wrote:
> Let's see, are you saying we shouldn't eliminate the simple problems because
> we can't eliminate the hard problems at the same time?

No. But there very often seems to be a lack of acknowledgement of the
hard problems. The impression I get from the Ada folks very often is
that Ada will give you error-free code, or at the very least, errors
will be detected and reported.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Bill Findlay]

On 11/5/03 21:11, in article T7yva.16129$rV2.4345@nwrdny01.gnilink.net,
"Hyman Rosen" <hyrosen@mail.com> wrote:

> Robert I. Eachus wrote:
>>     Shuffle(Deck, Gen);
>> 
>> It is really, really hard to have bugs in code that is as unsubtle as
>> that.  And even if the universe changes, the changes are pretty
>> localized.  For example, it would take just a few minutes to change the
>> code to deal Pinochle hands, or even to switch to a Tarot deck.
> 
> I think this is a perfect example of the blind spot of Ada programmers.
> You are so enamored of enumerations and perfectly indexed arrays and
> lack of buffer overflows that you will probably miss the most likely
> and subtle bug of this kind of code, which is that the Shuffle routine
> fails to produce each possible permutation with uniform probability!
> 

Hyman, this really is not up to your usual standard.

Are you suggesting that programmers who carry the additional burdens of
having to simulate enumerations by themselves, ensure perfect indexing by
themselves, and check by themselves for buffer overflows, are somehow *more*
likely to get the algorithm correct?

Come off it!

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Hyman Rosen]

Wesley Groleau wrote:
> so there is NO WAY you could have either
> tested it or analyzed it to justify your
> claim that it is not random.

I was speaking to the general Ada programmer, not to Robert specifically.
And it's well known that subtle errors can lurk in dealing with random
numbers, and those are the kinds of errors that have nothing to do with
the automatic checks that Ada and type safety gives you, so I found it
pertinent that that part of the code was left out.

> On top of that, a shuffle by human hands
> probably does not produce each possible
> permutation with uniform probability!

And there are people who believe they can take advantage of that.
On the other hand, a shuffle by human hands takes place far less
often than a shuffle by computer, and a shuffle by human hands is
not algorithmic, so there are compensatory effects.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Bill Findlay]

On 12/5/03 00:43, in article ReBva.27$hX1.18@nwrdny01.gnilink.net, "Hyman
Rosen" <hyrosen@mail.com> wrote:

> John R. Strohm wrote:
>> Let's see, are you saying we shouldn't eliminate the simple problems because
>> we can't eliminate the hard problems at the same time?
> 
> No. But there very often seems to be a lack of acknowledgement of the
> hard problems. The impression I get from the Ada folks very often is
> that Ada will give you error-free code, or at the very least, errors
> will be detected and reported.

Hyman, this a straw man; and you know it.

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Hyman Rosen]

Robert I. Eachus wrote:
> Did you read what I wrote, really?

Sure.

> Should I have included the notes in the Shufflling routine which
 > showed why this particular method of generation permutations was
 > unbiased?  Okay done:

Okay, thanks. Since not all Ada programmers are the author of random
number generators for Ada compilers, you should agree that this is an
issue that can be overlooked, and could produce incorrect results that
would not be caught by Ada language facilities. An impression I often
get from Ada proponents is that the errors that Ada catches are the
(only) ones that matter.

And by the way...
 > type Suits is (...);
 > type Ranks is (...);
 > Deck: Card_Array(0..51);

What's up with that 51? Shouldn't that be a calculation based on the
Suits'Last'Pos and Ranks'Last'Pos?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dave Thompson]

On 9 May 2003 11:52:31 -0700, jimmaureenrogers@worldnet.att.net (Jim
Rogers) wrote:
[snip]
> The most convenient feature when dealing with arrays is
> Ada's ability to efficiently deal with array bounds 
> checking. 
> 
> For example, if I define an Ada string with a length
> of 10 characters:
> 
>    Name : String(1..10);
> 
> I can then perform I/O using that string object and
> never need to worry about array bounds violations.
> 
> Ada.Text_Io.Get_Line(Item => Name, Last => Count);
[snip]
> In C I would need to do something like the following:
>    char name[11];
> 
>    scanf("%.10s", name);
> 
Not quite.  Ada Get_Line is much closer to C fgets, 
although it does store the newline character (if it fits) 
and you must often deal with removing it, and it does 
not return the length explicitly (you must strlen for it).

> The point here is that I must hardcode the size limit
> into the scanf format string. If I change the size of
> the array then I must also change the scanf format 
> string.
> 
For fgets the length is a separate argument and so can 
and almost always should be computed as sizeof(buf) 
without hardcoding *if* buf is local or global, but not if 
passed as a parameter/dummy/formal because C 
doesn't have true array parameters only pointers 
that don't carry size information.

*scanf %s reads only up to whitespace, not a whole line, 
making it more like a nonstandard Get_Token.  Even if 
you make it %limit[^\n] (any characters except newline) 
it doesn't 'eat' the newline, and just adding a %*c in 
the same call won't work if the %[ read nothing (failed).
You can in simple cases hack in a #define'd length using 
preprocessor stringize (and string literal concatenation) 
or in general compute the format string at runtime, but 
neither is as convenient as even passing the bound explicitly 
to fgets,  much less automatically as in Ada.

> Unfortunately, array bounds violations are still a common
> failure mode in C programs. The techniques for avoiding 
> array bounds violations are well known. Unfortunately
> they are not used as frequently as one would like.
> 
Concur, and with the rest [snipped].

- David.Thompson1 at worldnet.att.net

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

John R. Strohm wrote:

 >>for I in 0..Number_of_Hands - 1 loop
 >
> There is ABSOLUTELY NO EXCUSE in Ada for the above.  Human beings learn to
> count starting at "one", not "zero".

>>   Deck: Card_Array(0..51); 
> Same comment.

Well, excuse me!  I did not write that because I am a closet C 
programmer.  I wrote that in both cases because those values are used in 
  mod operations, the deck when initializing cards, the Number_of_Hands 
in determining vulnerability and dealer.  In both cases, I could either 
have expressions like  (I-1) mod 13 + 1, or I mod 13.  Guess which I chose.

>  Actually, with a Tarot deck, it would be a bit harder.  You have the four
> different suits, and the various numbered cards, but you also have the
> various special cards (e.g., the Fool, the Tower, Death...) that have to be
> handled separately.

Not that much, at least with the Tarot decks I have used.  They have 22 
Major Arcana and four suits of 14 cards in the Minor Arcana for a total 
of 78 cards.  It would be pretty easy to have six suits of thirteen 
cards and special names for the cards in two of them (including the four 
Pages from the Minor Arcana).  Or you could just generate the names in 
the Minor Arcana, and fill in the Major Arcana last.  Since the names 
are assigned to the cards once, and from then on printed/displayed, it 
would take very little additional code.  A little more difficult would 
be adding a bit for reversed, and flipping it randomly during shuffling. 
  Hardest part would be remembering the names of the Major Arcana, but 
what else is Google for: http://www.byzant.com/tarot/structuremajor.asp ;-)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

Hyman Rosen wrote:

> Okay, thanks. Since not all Ada programmers are the author of random
> number generators for Ada compilers, you should agree that this is an
> issue that can be overlooked, and could produce incorrect results that
> would not be caught by Ada language facilities.

It was just that I had stated that the only reason for writing this 
program was to use it to explain the rationale for generating 
permutations this way.

> And by the way...
>  > type Suits is (...);
>  > type Ranks is (...);
>  > Deck: Card_Array(0..51);
> 
> What's up with that 51? Shouldn't that be a calculation based on the
> Suits'Last'Pos and Ranks'Last'Pos?

Good, question, I think the answer is a judgement call.  I could have 
written:

    Deck: Card_Array(0..(Suits'Last'Pos+1)*(Ranks'Last'Pos+1)-1);

But I think the way I chose was more obviously correct, and easier to 
maintain, even if someone wanted to change the code to play Pinochle.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

> would not be caught by Ada language facilities. An impression I often
> get from Ada proponents is that the errors that Ada catches are the
> (only) ones that matter.

Oh, bull.  Numerous people in c.l.a. have often said
that one can write bad code in any language.  Our
irritation with a certain large subset of C programmers
is their insistence that "any decent programmer" can
avoid the errors Ada prevents--while they continue
to fail to avoid those errors.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Wesley Groleau]

Dennis Lee Bieber wrote:
> Wesley Groleau fed this fish to the penguins on Sunday 11 May 2003 
>>On top of that, a shuffle by human hands
>>probably does not produce each possible
>>permutation with uniform probability!
>
>         In truth -- performing 8 perfect riffle shuffles on a standard deck 
> actually returns it to the original ordering.

What percent of people are capable of doing even
two "perfect" shuffles in a row?

Nevertheless, even the imperfect ones are unlikely
to "produce each possible permutation with perfect probability!

comp.lang.alliteration ?

Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Anders Wirzenius]

"Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message news:dstanbro-DDA263.20492210052003@mec2.bigpond.net.au...
> soft-eng wrote:
>
> > But for how long can you keep on making the same type
> > of mistakes?
>
> Forever, if we examine software faults. What's your point?
> That people -shouldn't-? I would agree with that. That people
> can learn to be 100% accurate in everything they do? I don't
> think i'll agree on that.
>
> dale

Exactly.
Isn't a good quality system a system which catches possible human mistakes?

The more a process is dependent on human beings to be perfect, the more vulnerable the process is. A quality system is as much a
support for the performing staff as it is a support for the management.

The weaker the quality system is the more it demands a management to be involved in the daily working details meaning less time to
work with long term organizational issues.

Error catching as early as possible is a good co-worker to both the programmer and his superior.

Anders

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

soft-eng wrote:
> Hyman Rosen <hyrosen@mail.com> wrote in message news:<1052495061.43545@master.nyc.kbcfp.com>...
>> soft-eng wrote:
>> > That should be "in tribute to CLU".
>> 
>> Well, *I* write it in tribute to Ada, regardless of whether
>> it has its origins in a different language.
> 
> Oh!  That's all right then -- I misread that as you not having
> any clu about the source of generics in Ada!!

I'm starting to see that you don't have a clue about Ada.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

soft-eng wrote:
> Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbbpe3n.3o1.randhol+abuse@kiuk0152.chembio.ntnu.no>...

> Imagine his surprise when he slowly progresses to serious
> programming, and starts to discover that all of his logic
> errors will continue to stay logic errors, Ada or no Ada.
> And the ultimate solution for those logic errors will
> come from -- horrors, fallible humans.

How stupid is it possible to be? I have not at all said one cannot make
logical errors in Ada or any other language nor that Ada prevents them.
But perhaps a self-proclaimed "expert" [*] like yourself do not grasp
the advantage of having a language which helps reduces the number of
non-logical errors (syntactic, range errors etc...) to a minimum in
stead of expecting that the programmer discover all those themself. Just
take a look at the state of software security and you will find most
problems lies in buffer overflows for instance.

> Of course, for freshmen programmers whose biggest problem is
> getting the types right, Ada is clearly useful.  No doubts
> about that.  Also for those who are never going to
> progress to any programming that requires something more
> complex than getting the types right.

Oh and how is C better than Ada when it comes limiting logical errors or
maintaining large complex systems?

*Plonk*

[*] The mere fact that you don't even use your real name, screams
teenager.
-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

Hyman Rosen wrote:
> I think this is a perfect example of the blind spot of Ada programmers.
> You are so enamored of enumerations and perfectly indexed arrays and
> lack of buffer overflows that you will probably miss the most likely
> and subtle bug of this kind of code, which is that the Shuffle routine
> fails to produce each possible permutation with uniform probability!

Well while you are busy finding the former bugs in your software we have
time to work on the latter.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

Hyman Rosen wrote:
> 
> I was speaking to the general Ada programmer, not to Robert specifically.

Well you can just as well address your speech to the general C/C++
programmer that he should not only look for the simple bugs, but also
work out the hard ones.

I think it is only C/C++ programmer who think that when Ada programmer
say Ada removes bugs they mean all bugs. On the other hand saying that
Ada programmer are incapable of seeing the bugs in their software, can
also only be just cheap shots at getting ahead in the debate? At any
rate there is a logical bug in the reasoning.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Leif Roar Moldskred]

Tim Ottinger <TOttinge@indy.rr.com> writes:

> But if you try to intimidate Ada guys, they'll let you know that
> their data types and generics can beat up your data types and
> templates.

And, of course, chances are good that their customers are quite
capable of beating up your customers.

-- 
Leif Roar Moldskred

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbbof6r.6ep.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...

> Here is one key example.  VMS didn't have a shell where actual
> ordinary users could write programs which functioned like the built in
> ones.  It was "RUN MY_USER_PROGRAM" versus the huge hairball of "SHOW
> THIS/THAT" or "SET THIS TO THAT".
> 
> If you wanted to have your own software work like that it was a huge
> rigamarole poring through one of the 20 or 30 orange covered
> notebooks.
> 
> Unix had argc and argv, and a simple library that you didn't even
> need to use if you didn't want to.
> 
> It was like Alexander cutting the Gordian knot. 
> 
> DCL was completely cognitively opaque.  What exactly was it doing, what
> programs is it running when?
> 
> Unix was dumb, and smart at the same time.
> 
> Simply: 
> 
>       Unix *felt* like freedom.  
>       VMS didn't.
> 

A lot of people felt the same way about C vs Pascal/Ada style languages!

Of course, today's C, C++, Java etc don't have type-checking
problems like early C, which may have led to my perception that 
type-checking simply is NOT a problem in modern software development.
But come to think of it, at one point it was.  Even so,
C *felt* like freedom.

Because the strong type-checking of today's C-family languages
has evolved rather than been dictated, it has had to retain
that freedom.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbbulf5.mi7.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> soft-eng wrote:
> > Hyman Rosen <hyrosen@mail.com> wrote in message news:<1052495061.43545@master.nyc.kbcfp.com>...
> >> soft-eng wrote:
> >> > That should be "in tribute to CLU".
> >> 
> >> Well, *I* write it in tribute to Ada, regardless of whether
> >> it has its origins in a different language.
> > 
> > Oh!  That's all right then -- I misread that as you not having
> > any clu about the source of generics in Ada!!
> 
> I'm starting to see that you don't have a clue about Ada.

Are you disagreeing that the source of generics
in Ada was CLU?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3EBECAF3.4010509@attbi.com>...
> soft-eng wrote:
> 
> > Y2K impact was overestimated!
> 
> I normally don't respond to trolls, but this was too much.  Go get a 
> list of the banks in business in 1995.  Doesn't have to be complete, for 
> example it could be a list of all banks with federal charters.  Now look 
> at the same list for the year 2000.  Over 90% of the banks from your 
> first list will have disappeared, and not due to name changes.
> 
> The Y2K crisis was underestimated for over a decade, then it started 
> getting the attention it deserved.  The result was a lot of bank mergers 
> to reduce the cost of the software work required.  In the area where I 
> live, one bank, St. Mary's Bank and a couple of credit unions survived. 
>   All the rest eventually merged into other banks.  (In case you care, 
> Bank of New Hampshire was one of those that moved into the area by 
> buying other banks.  I had one checking account which went through five 
> banks and another that went through four during this period, as banks 
> were swallowed by bigger banks, then merged again and again.)

I thought banks merged due to economic issues -- if any
single merger was related to Y2K, it sure wasn't publicized.

OT: Card Shuffling

[Frank J. Lhota]

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:5tOdnfV8pvrVtiKjXTWcpQ@gbronline.com...
> What percent of people are capable of doing even
> two "perfect" shuffles in a row?

The percentage of general public who can do one perfect shuffle, much less
several in a row, is very small. There are, however, many experts who have
mastered the art of doing perfect shuffles. Among these experts are
magicians who use this ability for card tricks. Card sharks have also
mastered this art, and therefore you should be suspicious of anyone who
makes a habit of shuffling a deck exactly eight times.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

soft-eng wrote:
> Are you disagreeing that the source of generics
> in Ada was CLU?

Nope

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<ReBva.27$hX1.18@nwrdny01.gnilink.net>...
> John R. Strohm wrote:
> > Let's see, are you saying we shouldn't eliminate the simple problems because
> > we can't eliminate the hard problems at the same time?
> 
> No. But there very often seems to be a lack of acknowledgement of the
> hard problems. The impression I get from the Ada folks very often is
> that Ada will give you error-free code, or at the very least, errors
> will be detected and reported.

OK, let's just all get ourselves on record.  I'll start:

I, an Ada programmer of sound mind and body, acknowledge that there
are hard problems that Ada does not catch.  I further acknowledge that
Ada will not catch each and every error which I am capable of
committing.  Lastly, I acknowledge that there are many problem types
which Ada is much more competent than I am to catch, and that by using
Ada I subject myself to shorter hours at work and more domestic
tranquility at home, and further that I rarely get to have the best
debugging war stories in the company lunchroom.

Mike

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Stephen Leake]

snarflemike@yahoo.com (Mike Silva) writes:

> OK, let's just all get ourselves on record.  I'll start:
> 
> I, an Ada programmer of sound mind and body, acknowledge that there
> are hard problems that Ada does not catch.  I further acknowledge that
> Ada will not catch each and every error which I am capable of
> committing.  Lastly, I acknowledge that there are many problem types
> which Ada is much more competent than I am to catch, and that by using
> Ada I subject myself to shorter hours at work and more domestic
> tranquility at home, and further that I rarely get to have the best
> debugging war stories in the company lunchroom.

Me too :).

-- 
-- Stephe

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Stephen Leake]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> John R. Strohm wrote:
> 
>  >>for I in 0..Number_of_Hands - 1 loop
>  >
> > There is ABSOLUTELY NO EXCUSE in Ada for the above.  Human beings learn to
> > count starting at "one", not "zero".
> 
> >>   Deck: Card_Array(0..51);
> > Same comment.
> 
> Well, excuse me!  I did not write that because I am a closet C
> programmer.  I wrote that in both cases because those values are used
> in mod operations, the deck when initializing cards, the
> Number_of_Hands in determining vulnerability and dealer.  In both
> cases, I could either have expressions like  (I-1) mod 13 + 1, or I
> mod 13.  Guess which I chose.

Ok. But now you are in the solution space, not the problem space :).

Even professors get to be a little inconsistent :).

Perhaps you should write:

function Mod (I : in Card_Index_Type) return Card_Index_Type;

which does what you want.

-- 
-- Stephe

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Larry Kilgallen]

In article <ubry881tb.fsf@nasa.gov>, Stephen Leake <Stephe.Leake@nasa.gov> writes:
> snarflemike@yahoo.com (Mike Silva) writes:
> 
>> OK, let's just all get ourselves on record.  I'll start:
>> 
>> I, an Ada programmer of sound mind and body, acknowledge that there
>> are hard problems that Ada does not catch.  I further acknowledge that
>> Ada will not catch each and every error which I am capable of
>> committing.  Lastly, I acknowledge that there are many problem types
>> which Ada is much more competent than I am to catch, and that by using
>> Ada I subject myself to shorter hours at work and more domestic
>> tranquility at home, and further that I rarely get to have the best
>> debugging war stories in the company lunchroom.
> 
> Me too :).

Me three.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Willard Thompson]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<ZpGva.13$1Q1.6@read3.inet.fi>...
> "Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message news:dstanbro-DDA263.20492210052003@mec2.bigpond.net.au...
> > soft-eng wrote:
> >
> > > But for how long can you keep on making the same type
> > > of mistakes?
> >
> > Forever, if we examine software faults. What's your point?
> > That people -shouldn't-? I would agree with that. That people
> > can learn to be 100% accurate in everything they do? I don't
> > think i'll agree on that.
> >
> > dale
> 
> Exactly.
> Isn't a good quality system a system which catches possible human mistakes?
> 
> The more a process is dependent on human beings to be perfect, the more vulnerable the process is. A quality system is as much a
> support for the performing staff as it is a support for the management.
> 
> The weaker the quality system is the more it demands a management to be involved in the daily working details meaning less time to
> work with long term organizational issues.
> 
> Error catching as early as possible is a good co-worker to both the programmer and his superior.
> 
> Anders

A good quality system or process is managing defects at every stage of
the software development process.  Requirement defects, design
defects, etc.  I would have to agree that many defects that are caught
early and subsequently fixed early would be less costly overall and
can lead to higher quality software systems.  However, what happens
when a big defect pops up after release?  ...so much for quality.

One big question that no one knows the exact answer to is how exactly
does the software process quality lead to software product quality? 
We most certainly know that process quality affects product quality,
that is obvious.  To attempt to answer such a question, I think would
require mountains of formal and rigorous process documentation over
the life time of many projects for tracking/comparing purposes, which
is only half the battle.  I think the other half is maintenance, to be
able to trace a newly discovered bug back via the documented
development process to properly identify not only the exact location
in code but abstraction and reasoning as well.

WILLARD_|_|_|_|_|_|_|_|_|_|_
|_|_|_|AT_|_|_|_|_|_|_|_|_|_
|_|_|_|_|BLETCHLEYPARK|_|_|_
|_|_|_|_|_|_|_|_|_|_|_DOT_|_
|_|_|_|_|_|_|_|_|_|_|_|_|NET

Re: Using Ada for device drivers? (Was: the Ada mandate, and whyit collapsed and died)

[Richard Riehle]

Hyman Rosen wrote:

> Over in the C++ newsgroups people like to kid Andrei Alexandrescu
> for being the only person in the world who can make a living writing
> C++ libraries that no compiler in existence can compile.

Which is too bad because Alexandrescu's work could almost persuade
me to be a little less cynical about C++.   His book is really
excellent.

Richard Riehle

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Mon, 12 May 2003 21:28:16 -0500 (CDT)
NNTP-Posting-Host: !Zm:G1k-VJhXs^b (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Willard Thompson" <need_more_spam@yahoo.com> wrote in message
news:7507f79d.0305121629.5b8b7369@posting.google.com...
> "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
news:<ZpGva.13$1Q1.6@read3.inet.fi>...
> > "Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message
news:dstanbro-DDA263.20492210052003@mec2.bigpond.net.au...
> > > soft-eng wrote:
> > >
> > > > But for how long can you keep on making the same type
> > > > of mistakes?
> > >
> > > Forever, if we examine software faults. What's your point?
> > > That people -shouldn't-? I would agree with that. That people
> > > can learn to be 100% accurate in everything they do? I don't
> > > think i'll agree on that.
> > >
> > > dale
> >
> > Exactly.
> > Isn't a good quality system a system which catches possible human
mistakes?
> >
> > The more a process is dependent on human beings to be perfect, the more
vulnerable the process is. A quality system is as much a
> > support for the performing staff as it is a support for the management.
> >
> > The weaker the quality system is the more it demands a management to be
involved in the daily working details meaning less time to
> > work with long term organizational issues.
> >
> > Error catching as early as possible is a good co-worker to both the
programmer and his superior.
> >
> > Anders
>
> A good quality system or process is managing defects at every stage of
> the software development process.  Requirement defects, design
> defects, etc.  I would have to agree that many defects that are caught
> early and subsequently fixed early would be less costly overall and
> can lead to higher quality software systems.  However, what happens
> when a big defect pops up after release?  ...so much for quality.
>
> One big question that no one knows the exact answer to is how exactly
> does the software process quality lead to software product quality?
> We most certainly know that process quality affects product quality,
> that is obvious.  To attempt to answer such a question, I think would
> require mountains of formal and rigorous process documentation over
> the life time of many projects for tracking/comparing purposes, which
> is only half the battle.  I think the other half is maintenance, to be
> able to trace a newly discovered bug back via the documented
> development process to properly identify not only the exact location
> in code but abstraction and reasoning as well.

That is PRECISELY what the higher levels of the Capability Maturity Model
are all about.  Part of what you are doing at the higher levels is tracking
defect causes, and adapting the ongoing software process to kill the process
errors that allowed the defects to happen and escape immediate detection.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Mon, 12 May 2003 21:28:17 -0500 (CDT)
NNTP-Posting-Host: !Zm:G1k-VJhXs^b (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106


"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3EBEEFA0.8060008@attbi.com...
> John R. Strohm wrote:
>
>  >>for I in 0..Number_of_Hands - 1 loop
>  >
> > There is ABSOLUTELY NO EXCUSE in Ada for the above.  Human beings learn
to
> > count starting at "one", not "zero".
>
> >>   Deck: Card_Array(0..51);
> > Same comment.
>
> Well, excuse me!  I did not write that because I am a closet C
> programmer.  I wrote that in both cases because those values are used in
>   mod operations, the deck when initializing cards, the Number_of_Hands
> in determining vulnerability and dealer.  In both cases, I could either
> have expressions like  (I-1) mod 13 + 1, or I mod 13.  Guess which I
chose.

Actually, this one is a bit worse than it appears.  You are assuming that
#(suits)*#(cards in suit) = #(Card_Array).  Change the definition of suits
or cards, to e.g. add a new suit, or maybe add a new denomination, and you
have to remember to change the magic number that represents the number of
elements in the Cartesian product of the two sets.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On Fri, 9 May 2003 21:44:29 -0500, John R. Strohm <strohm@airmail.net> wrote:
> It only takes one such error in commercial code to create a buffer overrun
> vulnerability.  Haven't we seen enough of those?  (Was it Edsger Dijkstra
> who compared testing with subscript checking enabled and running production
> with it disabled to sailing in the harbor with a life jacket and then taking
> the jacket off when you ventured out onto the open ocean?  Maybe it was Tony
> Hoare.  I've sailed on the Pacific, in 10-foot seas as I recall; I have a
> LOT of respect for open ocean.)

But in practical reality bounds checking is usually not a life vest on
the open ocean.  It's an automatic box that sqwacks, "Danger Will
Robinson, Drowning Alert!!!" when the hull is 3/4ths submerged.


Not that I have a problem with it---I hate programming without it

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On Sun, 11 May 2003 18:52:05 GMT, Robert I. Eachus <rieachus@attbi.com> wrote:
> Wesley Groleau wrote:
>> 
>>> I don't know where this notion arose that a "super-strong"
>>> type system is just for preventing bugs. I know that in C++
>> 
>> 
>> I didn't say that it was only for preventing bugs.
>> I said it's a crock that it requires programmers
>> to do a lot of allegedly unnecessary workarounds.
>> 
>> For me, preventing bugs is the second biggest benefit
>> of Ada's type system.  The bigger one is that it
>> allows you to define things in terms of your
>> abstraction instead of your implementation.
> 
> I think my first deep insight into the implications of Ada programming 
> came in 1983, just after Ada 83 became an ANSI standard.  I told someone 
> working on our (Ada) compiler: "No, in Ada you model the problem space, 
> not the solution space."  I then excused myself for a minute to write it 
> on my office whiteboard.

That's nice, but I can model an eigenvalue problem space just fine.

Doesn't do squat to finding a numerically stable algorithmic solver. 

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On 12 May 2003 06:43:34 -0700, soft-eng <softeng3456@netscape.net> wrote:
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbbof6r.6ep.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> 
>> Here is one key example.  VMS didn't have a shell where actual
>> ordinary users could write programs which functioned like the built in
>> ones.  It was "RUN MY_USER_PROGRAM" versus the huge hairball of "SHOW
>> THIS/THAT" or "SET THIS TO THAT".
>> 
>> If you wanted to have your own software work like that it was a huge
>> rigamarole poring through one of the 20 or 30 orange covered
>> notebooks.
>> 
>> Unix had argc and argv, and a simple library that you didn't even
>> need to use if you didn't want to.
>> 
>> It was like Alexander cutting the Gordian knot. 
>> 
>> DCL was completely cognitively opaque.  What exactly was it doing, what
>> programs is it running when?
>> 
>> Unix was dumb, and smart at the same time.
>> 
>> Simply: 
>> 
>>       Unix *felt* like freedom.  
>>       VMS didn't.
>> 
> 
> A lot of people felt the same way about C vs Pascal/Ada style languages!

With Pascal they were right: it is too constraining.

With Ada they were wrong.

>Even so,
> C *felt* like freedom.

Compared to Pascal--which was only intended as a pedagogical language---it was.

Pascal was not the only other language ever invented. 

> Because the strong type-checking of today's C-family languages
> has evolved rather than been dictated, it has had to retain
> that freedom.

that's a nice way of saying it's full of cruft. 

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Anders Wirzenius]

"Willard Thompson" <need_more_spam@yahoo.com> wrote in message news:7507f79d.0305121629.5b8b7369@posting.google.com...
> A good quality system or process is managing defects at every stage of
> the software development process.  Requirement defects, design
> defects, etc.  I would have to agree that many defects that are caught
> early and subsequently fixed early would be less costly overall and
> can lead to higher quality software systems.  However, what happens
> when a big defect pops up after release?  ...so much for quality.
>
> One big question that no one knows the exact answer to is how exactly
> does the software process quality lead to software product quality?

The exact answer is hardly found in any production environment: software, hardware, serviceware, educationware, you name it. A
quality system certificate is nothing more than a paper stating that the production process includes some overhead routines that can
be said affecting the product quality, like you write:

> We most certainly know that process quality affects product quality,
> that is obvious.  To attempt to answer such a question, I think would
> require mountains of formal and rigorous process documentation over

Not mountains, a few pages will do. The key issue is that, to avoid the "details hell", the process documentation should be made by
the foremen, not the workers. What is then between the overall process documentation and the details? That is called profession
skill (=individuals, but still human beings that may any time have a bad day and code an array bounds overflow ;-).

> the life time of many projects for tracking/comparing purposes, which
> is only half the battle.  I think the other half is maintenance, to be
> able to trace a newly discovered bug back via the documented
> development process to properly identify not only the exact location
> in code but abstraction and reasoning as well.
>

One should always remember that the maintenance is pure maintenance only if you don't reuse code or algorithms in new deliveries.
Otherwise you always have a connection between the delivered bugs and new software on its way. The new software may not have been
coded yet, it may still be in "abstraction and reasoning" phase.

A former employer to me had in their quality system a routine where the R&D was required to make a resume of corrective actions made
for previous versions of the product. To make the resume was a piece of cake since all service actions in the service department
were recorded in a database. This resume requirement was a part of the R&D actions prior to the "abstraction and reasoning" phase.

Anders

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Larry Kilgallen]

In article <slrnbc0pdt.1o8.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>, Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes:
> On 12 May 2003 06:43:34 -0700, soft-eng <softeng3456@netscape.net> wrote:
>> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbbof6r.6ep.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
>> 
>>> Here is one key example.  VMS didn't have a shell where actual
>>> ordinary users could write programs which functioned like the built in
>>> ones.  It was "RUN MY_USER_PROGRAM" versus the huge hairball of "SHOW
>>> THIS/THAT" or "SET THIS TO THAT".

It is too bad you missed the SET COMMAND documentation, but that is not
really our fault, is it.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Marin David Condic]

I agree and would add this personal observation: In one job incarnation I
programmed in Ada for 10 years and NOT ONCE did I ever have to turn on the
debugger.(O.K. Maybe an occasional Put_Line statement, but NO DEBUGGER!) I
left to join another company that had its main product in MSVC++. The
debugger instantly became a WAY OF LIFE.

Granted, this is anecdotal and may have a lot to do with issues of style,
etc., but I doubt I am the only one with such a story. I also wouldn't
suggest that Ada compilers should not provide debuggers or that they are
never necessary. I would only claim that I have seen far less need for
debuggers with Ada than with C or C++

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Mike Silva <snarflemike@yahoo.com> wrote in message
news:20619edc.0305120923.1ccfa3be@posting.google.com...
>
> OK, let's just all get ourselves on record.  I'll start:
>
> I, an Ada programmer of sound mind and body, acknowledge that there
> are hard problems that Ada does not catch.  I further acknowledge that
> Ada will not catch each and every error which I am capable of
> committing.  Lastly, I acknowledge that there are many problem types
> which Ada is much more competent than I am to catch, and that by using
> Ada I subject myself to shorter hours at work and more domestic
> tranquility at home, and further that I rarely get to have the best
> debugging war stories in the company lunchroom.
>
> Mike

Re: Using Ada for device drivers?

[Georg Bauhaus]

In comp.lang.ada soft-eng <softeng3456@netscape.net> wrote:
 
: I thought banks merged due to economic issues -- if any
: single merger was related to Y2K, it sure wasn't publicized.

What else than a technically caused economic issue shoud Y2K be?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<ln0wa.54$a03.44@read3.inet.fi>...
> "Willard Thompson" <need_more_spam@yahoo.com> wrote in message news:7507f79d.0305121629.5b8b7369@posting.google.com...
> > A good quality system or process is managing defects at every stage of
> > the software development process.  Requirement defects, design
> > defects, etc.  I would have to agree that many defects that are caught
> > early and subsequently fixed early would be less costly overall and
> > can lead to higher quality software systems.  However, what happens
> > when a big defect pops up after release?  ...so much for quality.
> >
> > One big question that no one knows the exact answer to is how exactly
> > does the software process quality lead to software product quality?
> 
> The exact answer is hardly found in any production environment: software, hardware, serviceware, educationware, you name it. A
> quality system certificate is nothing more than a paper stating that the production process includes some overhead routines that can
> be said affecting the product quality, like you write:
> 
> > We most certainly know that process quality affects product quality,
> > that is obvious.  To attempt to answer such a question, I think would
> > require mountains of formal and rigorous process documentation over
> 
> Not mountains, a few pages will do. The key issue is that, to avoid the "details hell", the process documentation should be made by
> the foremen, not the workers. What is then between the overall process documentation and the details? That is called profession
> skill (=individuals, but still human beings that may any time have a bad day and code an array bounds overflow ;-).
> 
> > the life time of many projects for tracking/comparing purposes, which
> > is only half the battle.  I think the other half is maintenance, to be
> > able to trace a newly discovered bug back via the documented
> > development process to properly identify not only the exact location
> > in code but abstraction and reasoning as well.
> >
> 
> One should always remember that the maintenance is pure maintenance only if you don't reuse code or algorithms in new deliveries.
> Otherwise you always have a connection between the delivered bugs and new software on its way. The new software may not have been
> coded yet, it may still be in "abstraction and reasoning" phase.
> 
> A former employer to me had in their quality system a routine where the R&D was required to make a resume of corrective actions made
> for previous versions of the product. To make the resume was a piece of cake since all service actions in the service department
> were recorded in a database. This resume requirement was a part of the R&D actions prior to the "abstraction and reasoning" phase.
> 
> Anders


Believe it or not, many people have thought very hard
about this issue!

There are generally two major approaches people
come up with.

1)  Hire good people, and give them the tools they
need.  Many companies follow this approach, e.g. Microsoft.
(See http://www.joelonsoftware.com/articles/fog0000000072.html )

2)  Since you are very smart, use your brains to
think up a quality solution.  The staff you have,
of course, doesn't matter.  You just need to
give them a quality solution, and quality will
follow.  Just tell them what to do and make
sure they do it.  (In the above URL, see the behavior
at Juno.)  For instance, a militaristic language that
will catch all their errors and solve the problem
of human fallibility.  Or a methodology that
will make quality flow out their ears.  Typical
command-and-conquer stuff is "now everybody will
write a spec in this here format before starting
a new module.  This will make our product quality
improve amazingly."

You can usually tell the people who took approach (2),
because they are always bemoaning how things don't
work right, and why it is somebody's fault.  E.g.
complaining about their vendor, or complaing about
how everybody is so stupid to use languages like C,
C++ or Java when it is obvious that better solutions
would have easily solved all world's problems.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

soft-eng wrote:

> 1)  Hire good people, and give them the tools they
> need.  Many companies follow this approach, e.g. Microsoft.
> (See http://www.joelonsoftware.com/articles/fog0000000072.html )

LOL! Good quality?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Kent Paul Dolan]

"John R. Strohm" <strohm@airmail.net> wrote:
> "Willard Thompson" <need_more_spam@yahoo.com> wrote:

>> One big question that no one knows the exact answer to is
>> how exactly does the software process quality lead to
>> software product quality?  We most certainly know that
>> process quality affects product quality, that is obvious.
>> To attempt to answer such a question, I think would
>> require mountains of formal and rigorous process
>> documentation over the life time of many projects for
>> tracking/comparing purposes, which is only half the
>> battle.  I think the other half is maintenance, to be
>> able to trace a newly discovered bug back via the
>> documented development process to properly identify not
>> only the exact location in code but abstraction and
>> reasoning as well.

> That is PRECISELY what the higher levels of the Capability
> Maturity Model are all about.  Part of what you are doing
> at the higher levels is tracking defect causes, and
> adapting the ongoing software process to kill the process
> errors that allowed the defects to happen and escape
> immediate detection.

Nuts, I sat up all night, and you _still_ beat me to that
answer! <grin>

Let me just add that the Software Engineering Institute's
Capability Maturity Model text (the formal title is longer
than that), and the subsequent white papers and refereed
journal articles showing the results of following it, and
giving more in-detail "how it works in the shop" data,
should be a part of any serious programmer's knowledge base,
just to understand what is _possible_ with continuous
process improvement programs in the software development
field, and with luck to start practicing it.

xanthian, who lent his copy to a friend, then got canned and
never saw it again: next time, for sure, I chain it to my
desk at the same time I nail my shoes to the floor.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert Spooner]

Preben Randhol wrote:
> soft-eng wrote:
> 
> 
>>1)  Hire good people, and give them the tools they
>>need.  Many companies follow this approach, e.g. Microsoft.
>>(See http://www.joelonsoftware.com/articles/fog0000000072.html )
> 
> 
> LOL! Good quality?
> 


Of course! Microsoft defines robust software as software with lots of
features.
Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert Spooner]

Dr Chaos wrote:
> On Fri, 9 May 2003 21:44:29 -0500, John R. Strohm <strohm@airmail.net> wrote:
> 
> 
> But in practical reality bounds checking is usually not a life vest on
> the open ocean.  It's an automatic box that sqwacks, "Danger Will
> Robinson, Drowning Alert!!!" when the hull is 3/4ths submerged.
> 
> 
> Not that I have a problem with it---I hate programming without it

Actually, bounds checking tells you to fix the leak before you leave the 
harbor.
Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

PS:  Another interesting link on how to get quality products
done:

http://www.joelonsoftware.com/articles/TwoStories.html

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[James S. Rogers]

"Robert Spooner" <rls19@psu.edu> wrote in message
news:3EC10141.7070000@psu.edu...
>
>
> Dr Chaos wrote:
> > On Fri, 9 May 2003 21:44:29 -0500, John R. Strohm <strohm@airmail.net>
wrote:
> >
> >
> > But in practical reality bounds checking is usually not a life vest on
> > the open ocean.  It's an automatic box that sqwacks, "Danger Will
> > Robinson, Drowning Alert!!!" when the hull is 3/4ths submerged.
> >
> >
> > Not that I have a problem with it---I hate programming without it
>
> Actually, bounds checking tells you to fix the leak before you leave the
> harbor.

In theory only.

In practice, the only way to detect bounds checking errors in C is to
either carefully inspect the code for all such errors, or test test test
test.
Of those two choices code inspection is the most efficient solution.
In either case there is a strong likelyhood that you will miss one or two
subtle conditions that cause array bounds violations.

Using a language with array bounds checking built in means that
detection is automatic at run time. Using the Ada approach, where
you must clearly define the array index range to the compiler, most
bounds violations are caught at compile time.

With Ada you fix the leak before leaving the ship yard.

Jim Rogers

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Willard Thompson]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<ln0wa.54$a03.44@read3.inet.fi>...
> "Willard Thompson" <need_more_spam@yahoo.com> wrote in message news:7507f79d.0305121629.5b8b7369@posting.google.com...
> > A good quality system or process is managing defects at every stage of
> > the software development process.  Requirement defects, design
> > defects, etc.  I would have to agree that many defects that are caught
> > early and subsequently fixed early would be less costly overall and
> > can lead to higher quality software systems.  However, what happens
> > when a big defect pops up after release?  ...so much for quality.
> >
> > One big question that no one knows the exact answer to is how exactly
> > does the software process quality lead to software product quality?
> 
> The exact answer is hardly found in any production environment: software, hardware, serviceware, educationware, you name it. A
> quality system certificate is nothing more than a paper stating that the production process includes some overhead routines that can
> be said affecting the product quality, like you write:
> 
> > We most certainly know that process quality affects product quality,
> > that is obvious.  To attempt to answer such a question, I think would
> > require mountains of formal and rigorous process documentation over
> 
> Not mountains, a few pages will do. The key issue is that, to avoid the "details hell", the process documentation should be made by
> the foremen, not the workers. What is then between the overall process documentation and the details? That is called profession
> skill (=individuals, but still human beings that may any time have a bad day and code an array bounds overflow ;-).

Perhaps.  However, to avoid the "details hell" regardless of who makes
the documents, layers of abstraction need to be properly managed. 
You're right, it is a key issue.  A few pages - actually the correct
pages - from the mountain of information regarding a software system
is key.  By separating concerns, having distinct and easily
identifiable boundaries and targeting what is relevant towards a
problem, will reduce time complexity.  Someone, made a post a few
weeks ago, regarding how to define/identify these layers within
specific contexts, environments, etc. and the more thought I give it,
the more I think that individual is on to something.

WILLARD_|_|_|_|_|_|_|_|_|_|_
|_|_|_|AT_|_|_|_|_|_|_|_|_|_
|_|_|_|_|BLETCHLEYPARK|_|_|_
|_|_|_|_|_|_|_|_|_|_|_DOT_|_
|_|_|_|_|_|_|_|_|_|_|_|_|NET

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Kaz Kylheku]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<ZpGva.13$1Q1.6@read3.inet.fi>...
> "Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message news:dstanbro-DDA263.20492210052003@mec2.bigpond.net.au...
> > soft-eng wrote:
> >
> > > But for how long can you keep on making the same type
> > > of mistakes?
> >
> > Forever, if we examine software faults. What's your point?
> > That people -shouldn't-? I would agree with that. That people
> > can learn to be 100% accurate in everything they do? I don't
> > think i'll agree on that.
> >
> > dale
> 
> Exactly.
> Isn't a good quality system a system which catches possible human mistakes?
>
> The more a process is dependent on human beings to be perfect, the more vulnerable the process is. A quality system is as much a
> support for the performing staff as it is a support for the management.
> 
> The weaker the quality system is the more it demands a management to be involved in the daily working details meaning less time to
> work with long term organizational issues.
> 
> Error catching as early as possible is a good co-worker to both the 
> programmer and his superior.

This is true only if everything else remains constant. The only way it
can remain constant is if you keep the intelligent, productive,
high-level language exactly the way it is, but make the implementation
very smart, so that it can perform a deep analysis and catch mistakes
by inference.

Once you start dumbing down the language with requirements for static
declarations, then what you are doing is throwing away an entire class
of programs, leaving a remainder that is much easier to check for
errors. You are basically changing the rules: ``Gee, I can't win at
chess, so why don't we reinterpret the configuration of the board as
checkers, a dumber and easier game''.

Now this would be acceptable if you could write all your software in
the dumbed-down language---if none of the rejected programs were
useful in your domain. But the problem is that this is rarely true. In
fact, the programmer will work around the language to reclaim that
discarded space.

When the rules are changed to prevent mistakes, the advantage is not
obvious. Closing all the roads would prevent car accidents and
therefore save lives. Except that the economy would be destroyed,
which would wreck lives---oh, but that's too deep of an intuition.
Safety first!

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Robert Spooner <rls19@psu.edu> wrote:

>Of course! Microsoft defines robust software as software with lots of
>features.

Great definition. Especially if you start counting each bug as
distinct feature.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbc0pdt.1o8.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...

> > Because the strong type-checking of today's C-family languages
> > has evolved rather than been dictated, it has had to retain
> > that freedom.
> 
> that's a nice way of saying it's full of cruft.

So should we assume what you said earlier about Unix,
was a nice way of saying it's full of cruft?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Simon Wright]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <slrnbc0pdt.1o8.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>, Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes:
> > On 12 May 2003 06:43:34 -0700, soft-eng <softeng3456@netscape.net> wrote:
> >> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbbof6r.6ep.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> >> 
> >>> Here is one key example.  VMS didn't have a shell where actual
> >>> ordinary users could write programs which functioned like the built in
> >>> ones.  It was "RUN MY_USER_PROGRAM" versus the huge hairball of "SHOW
> >>> THIS/THAT" or "SET THIS TO THAT".
> 
> It is too bad you missed the SET COMMAND documentation, but that is not
> really our fault, is it.

Most of my work used the "foreign command" feature (and continues to
do so, last updated in 1985 I think! That was a mix of Fortran,
Pascal, Macro & DCL ...)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Wesley Groleau]

soft-eng wrote:
> PS:  Another interesting link on how to get quality products
> done:
> 
> http://www.joelonsoftware.com/articles/TwoStories.html

I'm impressed.  If that's truly typical of Microsoft management.

OTOH, somehow it hasn't stopped them from churning out garbage
year after year.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dr Chaos]

On 13 May 2003 10:30:08 -0700, soft-eng <softeng3456@netscape.net> wrote:
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbc0pdt.1o8.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> 
>> > Because the strong type-checking of today's C-family languages
>> > has evolved rather than been dictated, it has had to retain
>> > that freedom.
>> 
>> that's a nice way of saying it's full of cruft.
> 
> So should we assume what you said earlier about Unix,
> was a nice way of saying it's full of cruft?

well it is, but I think it's aged and evolved somewhat
better than C, except for the fact that you can STILL only
really call system facilities except by parsing and calling
literal C-language files. 

Those things about Unix which were intentionally designed
in as a major important concept (inodes!) are still great.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

Dave Thompson wrote:

> Not quite.  Ada Get_Line is much closer to C fgets, 
> although it does store the newline character (if it fits) 
> and you must often deal with removing it, and it does 
> not return the length explicitly (you must strlen for it).

There are three errors here.  The first is a category error.  The 
description of Ada.Text_IO.Get was just to show that in Ada, you can 
never have a buffer overflow error.  (Unless of course you go very far 
out of your way to specifically program one.  It can be done, but many 
Ada programmer don't know how, and most Ada programmers would consider 
going out of your way to construct an Ada program that had a potential 
buffer overflow not as a challenge, but as a kind of pornography.

The second error is technical. If an Ada program copies a newline 
character as part of a Get, that is an error.  If the type of the text 
file was incorrectly specified, for example as one where LF (linefeed) 
is the representation of end of line, instead of CR LF, then you will 
read a CR character.  This occasionally used to happen when people 
ported files between Windows and Unix.  I think now thought that all Ada 
compilers accept any combination of CR and LF as end of line, while 
using the appropriate end of line marker for that system when writing 
text files.

Finally, in Ada the only cases where you need to call strlen is when 
converting a C or C++ string to an Ada String.  In Ada the name of the 
length of the string named Foo is Foo'Length.  But it is an explict 
property of the string, just like Foo'First and Foo'Last.  (Most Ada 
compilers only store two of the three attributes as part of the 
representation of a dynamic string. (A string whose length is not known 
at compile time.)  But that is an implementation detail.

The whole point here is that an Ada programmer never worries about the 
length of a string or the any of the implicit checking that needs to be 
explicit in C.  In fact in Ada 95 there are several library packages 
defined to make it easier to create string objects with different 
properties.  The objects of the standard String type have their 
attributes determined when the object is created.  The values of the 
String type can be of any size or bounds.  (Well subject to 
X'Last-X'First+1 = X'Length.)  However there is an explicit type 
Ada.Strings.Unbounded.Unbounded_String, which can store different length 
strings. (Yes, you can rename it if you want to use it. ;-) This is 
handy if you want to create "ragged" arrays of strings, or to  have a 
library level string object whose length changes.

There is also a Bounded_String type which corresponds to the PL/I char * 
varying, or what most C programmers thing that buffers are like.  (But 
assigning to long a string to a Bounded_String will cause an error. If 
you don't know what the limit should be, or can't figure out how to 
handle the exception, use Unbounded_String instead.)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

Stephen Leake wrote:

> Ok. But now you are in the solution space, not the problem space :).
> Even professors get to be a little inconsistent :). 
> Perhaps you should write: 
> function Mod (I : in Card_Index_Type) return Card_Index_Type;
> which does what you want.

First of all I would have to define:

    function "Mod" (I : Card_Index_Type) return Card_Index_Type;

But I found the existing "mod" operator to be perfectly fine.  However, 
what you are missing is the deeper truth that for enties that have this 
sort of behavior are best represented as modular types.  If I had been 
able to write the program in Ada 95--this was written while working on 
the Ada 9X standard--I could have written:

type Card_Index_Type is mod 52;

Deck: array (Card_Index_Type) of Card;

Would that make you happier?

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

Robert I. Eachus wrote:
> There are three errors here.  The first is a category error.  The 
> description of Ada.Text_IO.Get was just to show that in Ada, you can 
> never have a buffer overflow error.  (Unless of course you go very far 
> out of your way to specifically program one.  It can be done, but many 
> Ada programmer don't know how, and most Ada programmers would consider 
> going out of your way to construct an Ada program that had a potential 
> buffer overflow not as a challenge, but as a kind of pornography.

Excellent quote :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Anders Wirzenius]

This is about people management, but since a process quality system is nothing but how to manage people and their work, I did not
change the subject line.


"soft-eng" <softeng3456@netscape.net> wrote in message news:9fa75d42.0305130543.60381450@posting.google.com...
>
> Believe it or not, many people have thought very hard
> about this issue!

I believe it ;-)

>
> There are generally two major approaches people
> come up with.
>
> 1)  Hire good people, and give them the tools they
> need.  Many companies follow this approach, e.g. Microsoft.
> (See http://www.joelonsoftware.com/articles/fog0000000072.html )
>
> 2)  Since you are very smart, use your brains to
> think up a quality solution.  The staff you have,
> of course, doesn't matter.  You just need to
> give them a quality solution, and quality will
> follow.  Just tell them what to do and make
> sure they do it.  (In the above URL, see the behavior
> at Juno.)  For instance, a militaristic language that
> will catch all their errors and solve the problem
> of human fallibility.  Or a methodology that
> will make quality flow out their ears.  Typical
> command-and-conquer stuff is "now everybody will
> write a spec in this here format before starting
> a new module.  This will make our product quality
> improve amazingly."
>
> You can usually tell the people who took approach (2),
> because they are always bemoaning how things don't
> work right, and why it is somebody's fault.  E.g.
> complaining about their vendor, or complaing about
> how everybody is so stupid to use languages like C,
> C++ or Java when it is obvious that better solutions
> would have easily solved all world's problems.

In a follow-up soft-eng gave another link:

> PS:  Another interesting link on how to get quality products
> done:
>
> http://www.joelonsoftware.com/articles/TwoStories.html

Good stories, thanks for the addresses.

In the latter story Joel Spolsky writes:
"The programmers were bugging me every day to get them more pages so that they could write more code"

He had a lucky time since the programers were loyal to him. I wonder how Mr Spolsky had reacted if the programmers had ignored his
pages and programmed the macro handling based on their own knowledge of macro language strategy? Had he intervened in their work or
just trusted them and let them do their job?

If you stretch the Microsoft story to its extreme, you may perhaps ask what the benefits of having levels in an organization are?
Why not just come together, set up a company, and have all persons owning their area with no possibility for the co-workers to have
an influence? If you get bad quality, just fire the person and hire another expert (and hope for the best:-). But who has then the
mandate to fire?

The Juno part was a good story of the opposite approach. Some people claim that the army gives a good education to leadership. To me
the army is more of the Juno type while most companies nowadays belong to the Microsoft type where you have to convince and motivate
people if you want to have an impact on their work (read: get them to do what you are in charge of). You cannot just rely on your
position in the organizational hierarchy.

The real world lies of course somewhere between these. You need "management" to some degree and therefore I stick to what I wrote in
a previous post: "Error catching as early as possible is a good co-worker to both the programmer and his superior".
Compilers that reveal programming errors or issue warnings are a good thing to both me and my superior.

I have worked in both types of companies; I could write a similar two-story. Sad to say it, but my present employer is of the Juno
type but that is another off-topic story.

Anders

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Preben Randhol <randhol+abuse@pvv.org> wrote in message
news:slrnbc1tum.62g.randhol+abuse@kiuk0152.chembio.ntnu.no...
> soft-eng wrote:
>
> > 1)  Hire good people, and give them the tools they
> > need.  Many companies follow this approach, e.g. Microsoft.
> > (See http://www.joelonsoftware.com/articles/fog0000000072.html )
>
> LOL! Good quality?
>

Microsoft? The inventer of the "Rebootive Multitasking Operating System"? An
example of "Quality"??? I share your amusement, Preben.

My jet engine control has *never* failed in flight operational use. It
can't. Someone would die if it did. It's programmed in Ada. Coincidence? Or
is it possible that Ada contributed to its quality? But then I suppose we
just hire stupid people and try to control their every action through
militaristic command and control sorts of "Quality Systems" that ultimately
don't work so we are left to complain about our vendors or how lousy
languages like C are. :-)

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<nNmdnZ46ROWIwFyjXTWcqg@gbronline.com>...
> soft-eng wrote:
> > PS:  Another interesting link on how to get quality products
> > done:
> > 
> > http://www.joelonsoftware.com/articles/TwoStories.html
> 
> I'm impressed.  If that's truly typical of Microsoft management.
> 
> OTOH, somehow it hasn't stopped them from churning out garbage
> year after year.

It's fashionable to say that.

But it is one thing to achieve quality control in a 50-100K
LOC program for a limited userbase.  But if you have actually
done that, you should be able to extrapolate to several
million LOC programs that work in multiple languages and
are literally used by millions of people in all sorts of
un-anticipated ways.  Given the magnitude of the task,
MS has indeed achieved great results.

Most problem domains don't have such challenging QA requirements.
Macintosh is another one (with only a fraction of
the user-base) -- but any honest Macintosh user
will admit to familiarity with the "bomb" icon.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[soft-eng]

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbc2rr1.djv.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> On 13 May 2003 10:30:08 -0700, soft-eng <softeng3456@netscape.net> wrote:
> > Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message news:<slrnbc0pdt.1o8.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>...
> > 
> >> > Because the strong type-checking of today's C-family languages
> >> > has evolved rather than been dictated, it has had to retain
> >> > that freedom.
> >> 
> >> that's a nice way of saying it's full of cruft.
> > 
> > So should we assume what you said earlier about Unix,
> > was a nice way of saying it's full of cruft?
> 
> well it is, but I think it's aged and evolved somewhat
> better than C, except for the fact that you can STILL only
> really call system facilities except by parsing and calling
> literal C-language files. 
> 
> Those things about Unix which were intentionally designed
> in as a major important concept (inodes!) are still great.

I liked both Unix and C, but I see it very differently.

Unix, once the forefront of operating system thought,
is now obsolete.  It has not evolved at all.
It is merely being kept alive as a zombie
by Linux and GNU.

C is the one that's evolved into C++, C#, Java.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marc A. Criley]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305130543.60381450@posting.google.com>...
> 
> There are generally two major approaches people
> come up with.
> 
> 1)  Hire good people, and give them the tools they
> need.  Many companies follow this approach, e.g. Microsoft.
> (See http://www.joelonsoftware.com/articles/fog0000000072.html )
> 
> 2)  Since you are very smart, use your brains to
> think up a quality solution.  The staff you have,
> of course, doesn't matter.  You just need to
> give them a quality solution, and quality will
> follow.  Just tell them what to do and make
> sure they do it.  (In the above URL, see the behavior
> at Juno.)  For instance, a militaristic language that
> will catch all their errors and solve the problem
> of human fallibility.  Or a methodology that
> will make quality flow out their ears.  Typical
> command-and-conquer stuff is "now everybody will
> write a spec in this here format before starting
> a new module.  This will make our product quality
> improve amazingly."

But where in the above dichotomy does the following situation fit?  A
project where:

1) Good people were hired and given the tools they needed.
2) One of those tools was a "militaristic" Ada compiler that caught
oversights at both compilation and run-time.
3) A quality software architecture was devised that a) rigorously
adhered to an object oriented methodology (OMT), and conformance to
that architecture was enforced, and b) intentionally exploited the
capabilities of the Ada programming language (such as concurrency and
heavy use of typing and subtyping).
4) An SEI CMM Level 3 conformant defect tracking/rework/build/recheck
process was utilized that was tight and optimized as hell.  Defect
identification, analysis, resolution, checkout in a developmental
build, and incorporation into the baseline had gotten to the point of
same-day turnaround for the overwhelming majority of defects.  (Of
course the fact that defects were getting more and more sporadic aided
that turnaround time.)

The end result of the project was a serious weapon command and control
system that came in on schedule, on budget, with no late nights or
weekends required of either the development or test staff, and the
lowest number of unresolved defects in any production release of the
system--1 of severity 4 (out of 5, where 1 is critical, and 5 is
considered a nice-to-have).

In addition, this system was a clean sheet redesign of an existing
system, so while it did have the advantage of lessons learned from the
previous systems, it was still a "Release 1.0" for all intents and
purposes.

How could such a thing be?

Marc A. Criley

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert Spooner]

Anders Wirzenius wrote:
> 
> The Juno part was a good story of the opposite approach. Some people claim that the army gives a good education to leadership. To me
> the army is more of the Juno type while most companies nowadays belong to the Microsoft type where you have to convince and motivate
> people if you want to have an impact on their work (read: get them to do what you are in charge of). You cannot just rely on your
> position in the organizational hierarchy.
> 

I think history shows that our armed forces are a combination. The 
"Juno" approach may be used to train and instill discipline, but once 
that is done, it can be seen that one of the profound influences on the 
outcome of battles has been the individual initiative that has been 
encouraged and flourishes during operations. In addition, it is a 
tribute to the military system that many of the leaders of W.W.II and 
the following cold war went through the service academies during the 
height of anti-military fervor during the 1930's.

Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[The Ghost In The Machine]

In comp.lang.java.advocacy, Robert Spooner
<rls19@psu.edu>
 wrote
on Tue, 13 May 2003 10:28:41 -0400
<3EC10119.9050607@psu.edu>:
> Preben Randhol wrote:
>> soft-eng wrote:
>> 
>> 
>>>1)  Hire good people, and give them the tools they
>>>need.  Many companies follow this approach, e.g. Microsoft.
>>>(See http://www.joelonsoftware.com/articles/fog0000000072.html )
>> 
>> 
>> LOL! Good quality?
>> 
> 
> 
> Of course! Microsoft defines robust software as software with lots of
> features.
> Bob

Evidently confusing "robust" with "bistro". :-)

-- 
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Preben Randhol]

soft-eng wrote:
> Unix, once the forefront of operating system thought,
> is now obsolete. 

I bet your real name is Steve Ballmer.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Marin David Condic wrote:
> My jet engine control has *never* failed in flight operational use. It
> can't. Someone would die if it did. It's programmed in Ada. Coincidence? Or
> is it possible that Ada contributed to its quality? But then I suppose we
> just hire stupid people and try to control their every action through
> militaristic command and control sorts of "Quality Systems" that ultimately
> don't work so we are left to complain about our vendors or how lousy
> languages like C are. :-)

What I am wondering is why do C or C++ programmers need so many tools to
check their code if they are so good infallible programmers and the
language is so excellent? Shouldn't correct code just pour out of their
fingertips guided by the excellence of the language? And of course if
you find a bug it is because there was *one* bad programmer on the team
and it has nothing to do with the language. 

If there was a debugger-free day I guess C programmers would take the day
off ;-)

Preben
-- 
"When Roman engineers built a bridge, they had to stand under it while
 the first legion  marched across.  If programmers today  worked under
 similar  ground rules,  they might well find  themselves getting much
 more interested in Ada!"                              -- Robert Dewar

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Preben Randhol wrote:
> What I am wondering is why do C or C++ programmers need so many tools to
> check their code

The tool that checks my C++ code is my compiler. I do have to work
with third-party libraries, so occasionally I use Purify when a
mystery erupts.

> If there was a debugger-free day

Debuggers are useful to stop a program in mid-execution and then
prowl around in its innards to get a snapshot of current state.
When the program in question is responding to external events
and messages, and also does not seem to be behaving as expected,
the debugger can give you insight as to what's going on. This
doesn't mean that I'm using the debugger to track down buffer
overruns or those other Ada-checked things.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Wesley Groleau]

Anders Wirzenius wrote:
> The Juno part was a good story of the opposite approach.
 > Some people claim that the army gives a good education
 > to leadership. To me the army is more of the Juno type
> while most companies nowadays belong to the Microsoft
> type where you have to convince and motivate

No, ideally and in general, the military works like
Joel described Microsoft.  Of course, due to it's mission,
the military has to have the potential for intervention
from on high IF NECESSARY.  There are indeed officers
who abuse this potential to act like the alleged Juno CEO,
but in peace time, they tend to get drummed out eventually,
and in war time, they tend to get killed.  (Unfortunately,
too often they take a lot of others with them either way.)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Hyman Rosen <hyrosen@mail.com> wrote:

>the debugger can give you insight as to what's going on. This
>doesn't mean that I'm using the debugger to track down buffer
>overruns or those other Ada-checked things.

Well, I had to use it two days before[0]. Two parameters to a function
call that took a lot of ints were accidentally swapped. Yeah, of
course I could have taken a more deeper look into the function
specification but I was still sleeping and missed my morning coffee.

With some distinct types for the parameters an Ada compiler *could*
have catched this. Of course, one has to make *use* of the strong type
system, then.

For me I have to say, I use(d) the debugger quite often in C, I still
use it for some stuff in Pascal but with now about a year experience
in doing more and more serious Ada-stuff I never had to use it there.


Vinzent.

[0] Probably I should upgrade it sooner or later. IIRC it said 1992 at
startup... ;)

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Thant Tessman]

Preben Randhol wrote:
> soft-eng wrote:
> 
>>Unix, once the forefront of operating system thought,
>>is now obsolete. 
> 
> 
> I bet your real name is Steve Ballmer.
> 

He he! It's the only explanation for such an absurd statement. Unix was 
never the forefront, and the only popular alternative is worse!

-thant

Re: Using Ada for device drivers?

[soft-eng]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote in message news:<b9qnfq$him$2@a1-hrz.uni-duisburg.de>...
> In comp.lang.ada soft-eng <softeng3456@netscape.net> wrote:
>  
> : I thought banks merged due to economic issues -- if any
> : single merger was related to Y2K, it sure wasn't publicized.
> 
> What else than a technically caused economic issue shoud Y2K be?

You think the economy tanked due to Y2K?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

mcq95@earthlink.net (Marc A. Criley) wrote in message news:<254c16a.0305140549.3a87281b@posting.google.com>...
> But where in the above dichotomy does the following situation fit?  A
> project where:
> 
> 1) Good people were hired and given the tools they needed.
> 2) One of those tools was a "militaristic" Ada compiler that caught
> oversights at both compilation and run-time.
> 3) A quality software architecture was devised that a) rigorously
> adhered to an object oriented methodology (OMT), and conformance to
> that architecture was enforced, and b) intentionally exploited the
> capabilities of the Ada programming language (such as concurrency and
> heavy use of typing and subtyping).
> 4) An SEI CMM Level 3 conformant defect tracking/rework/build/recheck
> process was utilized that was tight and optimized as hell.  Defect
> identification, analysis, resolution, checkout in a developmental
> build, and incorporation into the baseline had gotten to the point of
> same-day turnaround for the overwhelming majority of defects.  (Of
> course the fact that defects were getting more and more sporadic aided
> that turnaround time.)
> 
> The end result of the project was a serious weapon command and control
> system that came in on schedule, on budget, with no late nights or
> weekends required of either the development or test staff, and the
> lowest number of unresolved defects in any production release of the
> system--1 of severity 4 (out of 5, where 1 is critical, and 5 is
> considered a nice-to-have).
> 
> In addition, this system was a clean sheet redesign of an existing
> system, so while it did have the advantage of lessons learned from the
> previous systems, it was still a "Release 1.0" for all intents and
> purposes.
> 
> How could such a thing be?
> 
> Marc A. Criley

I don't agree that Ada is likely to be particularly useful
for catching errors in a professional environment -- say 2-3%
of the actual errors at best.  If it's catching more than
that, I don't see how you can have good people.

But good people can certainly make projects succeed using
many kinds of tools, including Ada.

The only thing is they might privately grumble more, and may
often have to get C/C++ libraries written by outside vendors
or themselves.  (Usually there are excuses - We could
have done it all in Ada, except for this and that...
But excuses or not, if you need a graphics library for
a new device, you would typically not write it in Ada.  You
will wait until someone writes it in C++, they you will wait
until that someone gives you an Ada API.  This is ok in
the government industries.  But private enterprises
quickly lost their enthusiasm for Ada due to such
reasons -- while they are waiting for the Ada API
to come through, their competitor using C++ would be
eating their lunch!  In the early days of PCs, people
had to often write many things from scratch, and address
CGA and VGA and whatnot cards, and draw pixels, and interface
to telephony cards...  All that would have been practically
impossible in Ada.  If such pressures are not involved, of
course, you can get many things done with Ada given enough
time, libraries and APIs.  Specially if you have
a good bunch of people.)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[tmoran]

> In the early days of PCs, people
> had to often write many things from scratch, and address
> CGA and VGA and whatnot cards, and draw pixels, and interface
> to telephony cards...  All that would have been practically
> impossible in Ada.
  Having done each of those things with both Ada and C, I'm curious why
you could possibly think they were any harder in Ada, much less
"practically impossible".  I have an especially pleasant memory of moving
a largish, graphics intensive DOS program, written in Ada, to the
Macintosh, in two days.  You may recall DOS graphics and Macintosh
graphics were somewhat dissimliar at the OS level.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

soft-eng wrote:
> I don't agree that Ada is likely to be particularly useful
> for catching errors in a professional environment -- say 2-3%
> of the actual errors at best.  If it's catching more than
> that, I don't see how you can have good people.

If it only catches 2-3% of the errors then there must be a huge amount
of bugs in professional environment software. If you look at all the
buffer overflow errors then these programs will be riddled with bugs as
buffer overflow lands in your 2-3% category.

Another advantage of Ada is the readability of the source code. In order
to catch your errors you have to read through the source not simply test
it to see if it runs. I believe IBM once published some data of how
many percent was discovered by reading the code versus just testing it.
I think the numbers where something like 60%-70% and 20-30%
respectively. Miscrosoft used only the latter method earlier IIRC, what
they do now, I don't know.

On quality: http://www.fastcompany.com/online/06/writestuff.html

> But good people can certainly make projects succeed using
> many kinds of tools, including Ada.

A great many things are possible, yet not practical. (Isaac Asimov)
Or in other words you can probably make a huge complex system in
assembly code, but it will take you a couple of decades to get the job
done.

> The only thing is they might privately grumble more, and may
> often have to get C/C++ libraries written by outside vendors
> or themselves.  

If you are interfacing with an OS written in C you would have to
make bindings to the C part even if you use C++.

> (Usually there are excuses - We could
> have done it all in Ada, except for this and that...
> But excuses or not, if you need a graphics library for
> a new device, you would typically not write it in Ada.  You

Why not?


-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Graham Perkins]

> > I'm impressed.  If that's truly typical of Microsoft management.
> >
> > OTOH, somehow it hasn't stopped them from churning out garbage
> > year after year.
>
> It's fashionable to say that.
>
> But it is one thing to achieve quality control in a 50-100K
> LOC program for a limited userbase.  But if you have actually
> done that, you should be able to extrapolate to several
> million LOC programs that work in multiple languages and
> are literally used by millions of people in all sorts of
> un-anticipated ways.  Given the magnitude of the task,
> MS has indeed achieved great results.

My other principal usage experience is with Unix and
VAX-VMS.  I suggest that both of those systems are
considerably better than MS-Windows, qualitatively.
Moreover, they were of extremely high quality from very
early on in their life.  And you never had to double your
processor speed and memory size every two years to
keep up with the code bloat :-(

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<5mmwa.65$dp4.60@read3.inet.fi>...

> He had a lucky time since the programers were loyal to him. I wonder how Mr Spolsky had reacted if the programmers had ignored his
> pages and programmed the macro handling based on their own knowledge of macro language strategy? Had he intervened in their work or
> just trusted them and let them do their job?

Well, that's where the trust comes from.

The basic idea is that you assume your
programmers are smart, conscientious workers.

If you go with that idea, then the only reason programmers
would ignore his pages is if he was a very dumb person, hired
accidentally, and had no clue what he was designing.

In which case, perhaps ignoring his pages would have
been the right thing to do.

"Consensus building" does require support from hierarchy.
But the primary motivation is "does this makes sense",
rather than "what is the opinion of the highest person
in the hierarchy who is involved".

> If you stretch the Microsoft story to its extreme, you may perhaps ask what the benefits of having levels in an organization are?
> Why not just come together, set up a company, and have all persons owning their area with no possibility for the co-workers to have
> an influence? If you get bad quality, just fire the person and hire another expert (and hope for the best:-). But who has then the
> mandate to fire?
> 

I guess in the Microsoft story, the job of the mgmt hierarchy is
to make sure good programmers are hired, are happy, have
their jobs well-defined, and can do it without interference.

In the the Juno story, the job of the mgmt is the same as
the job of the programmers, but the lower a person
is in the hierarchy, the more "low level" stuff he/she
does.  In earlier incarnations of Juno-style thinking,
the lowest level is supposed to just code
stuff from pseudo-code.  The next higher level writes
pseudo-code.  The next higher level is deemed adequate
to understand algorithms... 

> The real world lies of course somewhere between these. You need "management" to some degree and therefore I stick to what I wrote in
> a previous post: "Error catching as early as possible is a good co-worker to both the programmer and his superior".
> Compilers that reveal programming errors or issue warnings are a good thing to both me and my superior.

But if you are managing, this should be an issue
for your programmers to decide by consensus
and not for you.  (Of course, it is a management issue
if you are subcontracting to some DoD or Boeing thing
and getting the contract depends upon Ada.  In that
case, you have to explain nicely to your programmers
"I know Ada is slow and frustrating to work with, but
it's not really our choice, and you all are good folks,
so I know you will get things done anyway.")

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Roy Smith]

Graham Perkins <gperkins@gperkins.co.uk> wrote:
> My other principal usage experience is with Unix and
> VAX-VMS.  I suggest that both of those systems are
> considerably better than MS-Windows, qualitatively.
> Moreover, they were of extremely high quality from very
> early on in their life.  And you never had to double your
> processor speed and memory size every two years to
> keep up with the code bloat :-(

Unix first escaped from Bell Labs in roughly 1977 (26 years ago).  At
the time it was running on pdp-11's with 64 kbytes of memory.

If you double 64k every 2 years for 26 years, you end up with 512
Meg, which isn't too far off from what you need to run Unix today.  My
newest Unix box is a Macintosh running OS-X, for which Apple
recommends a minimum of 128 Meg.  Of course, that 128 Meg is for a
personal workstation; that 64k pdp-11 used to support a dozen users.

The reason, of course, is code bloat.  We've added networking,
graphics, virtual memory, better file systems, threading, etc.  These
are good things and I wouldn't want to give them up.

I'm also not sure I'd call the early Unix system "extremely high
quality".  Back in the pdp-11 days, we'd be happy if the system stayed
up for a week before it crashed or needed to be rebooted.  Kernel
panics because the file system ran out of inodes?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[achrist]

tmoran@acm.org wrote:
> 
> > In the early days of PCs, people
> > had to often write many things from scratch, and address
> > CGA and VGA and whatnot cards, and draw pixels, and interface
> > to telephony cards...  All that would have been practically
> > impossible in Ada.
>   Having done each of those things with both Ada and C, I'm curious why
> you could possibly think they were any harder in Ada, much less
> "practically impossible".  

IIRC the early days of the PC were also the early days of Ada.  The
only Ada I could find that ran on a PC was the Alsys(?) version,
requiring a custom hardware upgrade because the compiler required
4 MB or so to run, and many PC's had far less than the 640 kb of
ram that the 8088's and 8086's could address. 

There was not only a 640 kb limit, there were some 64 kb limits
on the size of memory segments in most of the PC software prior to
1987.  I don't recall ever seeing an Ada product or tool that would
run on an 8086 or 8088 without special hardware added.  Were there
any? 


Al

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[David Lightstone]

<achrist@easystreet.com> wrote in message
news:3EC3A45B.4A34A487@easystreet.com...
> tmoran@acm.org wrote:
> >
> > > In the early days of PCs, people
> > > had to often write many things from scratch, and address
> > > CGA and VGA and whatnot cards, and draw pixels, and interface
> > > to telephony cards...  All that would have been practically
> > > impossible in Ada.
> >   Having done each of those things with both Ada and C, I'm curious why
> > you could possibly think they were any harder in Ada, much less
> > "practically impossible".
>
> IIRC the early days of the PC were also the early days of Ada.  The
> only Ada I could find that ran on a PC was the Alsys(?) version,
> requiring a custom hardware upgrade because the compiler required
> 4 MB or so to run, and many PC's had far less than the 640 kb of
> ram that the 8088's and 8086's could address.
>
> There was not only a 640 kb limit, there were some 64 kb limits
> on the size of memory segments in most of the PC software prior to
> 1987.  I don't recall ever seeing an Ada product or tool that would
> run on an 8086 or 8088 without special hardware added.  Were there
> any?

If I am to believe the documentation for the Meridian compilier version 4.1
it should work on a 8086
with MS-DOS version 2.1 or later

I have never tested it in that environment, so I can not confirm the claim

>
>
> Al

Re: Quality systems (Was: Using Ada for device drivers? (Was: theAda mandate, and why it collapsed and died))

[David C. Hoos]

<achrist@easystreet.com> wrote in message
news:3EC3A45B.4A34A487@easystreet.com...
> tmoran@acm.org wrote:
> >
> > > In the early days of PCs, people
> > > had to often write many things from scratch, and address
> > > CGA and VGA and whatnot cards, and draw pixels, and interface
> > > to telephony cards...  All that would have been practically
> > > impossible in Ada.
> >   Having done each of those things with both Ada and C, I'm curious why
> > you could possibly think they were any harder in Ada, much less
> > "practically impossible".
>
> IIRC the early days of the PC were also the early days of Ada.  The
> only Ada I could find that ran on a PC was the Alsys(?) version,
> requiring a custom hardware upgrade because the compiler required
> 4 MB or so to run, and many PC's had far less than the 640 kb of
> ram that the 8088's and 8086's could address.
>
> There was not only a 640 kb limit, there were some 64 kb limits
> on the size of memory segments in most of the PC software prior to
> 1987.  I don't recall ever seeing an Ada product or tool that would
> run on an 8086 or 8088 without special hardware added.  Were there
> any?
I had the Janus Ada compiler running on a 386SX in the late 80s, and
taught my then-15-year-old son to write Ada, while I was using DEC Ada
at work.

Later, there was the Meridian compiler than ran on standard PC hardware
(still late 80s or before 1992, I don't remember exactly)..
>
>
> Al
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Wesley Groleau]

>>to telephony cards...  All that would have been practically
>>impossible in Ada.
> 
>   Having done each of those things with both Ada and C, I'm curious why
> you could possibly think they were any harder in Ada, much less
> "practically impossible".  I have an especially pleasant memory of moving

This is not the first time that "soft-eng"
has made it obvious he/she knows very little
about Ada, and not enough about software in
general to make credible his/her claim of
professorship.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

achrist@easystreet.com wrote:

>There was not only a 640 kb limit, there were some 64 kb limits
>on the size of memory segments in most of the PC software prior to
>1987.

So what?

>  I don't recall ever seeing an Ada product or tool that would
>run on an 8086 or 8088 without special hardware added.

Seems you don't have a clue.

>Were there any? 

The Meridian Ada83 compiler.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote:

>If I am to believe the documentation for the Meridian compilier version 4.1
>it should work on a 8086 with MS-DOS version 2.1 or later

Be sure it does. I got mine from eBay. :)


Vinzent.

Re: Quality systems (Was: Using Ada for device drivers? (Was: theAda mandate, and why it collapsed and died))

[Vinzent Hoefler]

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

>Later, there was the Meridian compiler than ran on standard PC hardware
>(still late 80s or before 1992, I don't remember exactly)..

The ACE 4.1.1 copyright statement says 1990-91. Probably there were
some earlier versions.


Vinzent.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Stephen Leake]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Two parameters to a function
> call that took a lot of ints were accidentally swapped. Yeah, of
> course I could have taken a more deeper look into the function
> specification but I was still sleeping and missed my morning coffee.
> 
> With some distinct types for the parameters an Ada compiler *could*
> have catched this. Of course, one has to make *use* of the strong type
> system, then.

You could also use named association at the call site. That's my style
policy; if there are two parameters to a function with the same type,
use named association.

-- 
-- Stephe

Re: Quality systems (Was: Using Ada for device drivers? (Was: theAda mandate, and why it collapsed and died))

[tmoran]

>> There was not only a 640 kb limit, there were some 64 kb limits
>> on the size of memory segments in most of the PC software prior to
>> 1987.  I don't recall ever seeing an Ada product or tool that would
>> run on an 8086 or 8088 without special hardware added.  Were there
>> any?
>
>I had the Janus Ada compiler running on a 386SX in the late 80s, and
>taught my then-15-year-old son to write Ada, while I was using DEC Ada
>at work.
  I still have a copy on my old Toshiba 3100 portable (286, 640K).
No special hardware.  It would produce either .com (64K, "small memory
model") or .exe ("large memory model") executables.
>
>Later, there was the Meridian compiler than ran on standard PC hardware
>(still late 80s or before 1992, I don't remember exactly)..
  Compuserve at one point had an Ada study group.  I got my Macintosh
Meridian Ada compiler at that time and ported the DOS Janus Ada program
that I mentioned earlier.

Re: Quality systems

[Dave Aronson]

(NOTE: F'UPS TRIMMED TO WHAT I READ!)

In comp.software-eng Roy Smith <roy@panix.com> wrote:

 RS> If you double 64k every 2 years for 26 years, you end up with 512
 RS> Meg, which isn't too far off from what you need to run Unix today.

Ha.  A couple years ago, I was happily running Linux on a 486/33 with a
mere 32 megs of RAM, and using only about 1/4 of my 1.3 gig hard drive.
Even as of then, Windows would not survive in such an environment.

-- 
David J. Aronson, Software Engineer for hire in Washington DC area.
See http://destined.to/program/ for online resume, references, etc.

Re: Quality systems

[Vinzent Hoefler]

Stephen Leake <Stephe.Leake@nasa.gov> wrote:

[parameter "swap" in function call]
>You could also use named association at the call site. That's my style
>policy; if there are two parameters to a function with the same type,
>use named association.

Yes, of course. Another very nice feature helping both error
prevention and readability.
I used that a lot in earlier VHDL code I wrote, so how could I forget
this...? Well, probably I'm getting old. ;)


Vinzent.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Jim Rogers]

Vinzent Hoefler <ada.rocks@jlfencey.com> wrote in message news:<b9u2te$n7g67$1@ID-175126.news.dfncis.de>...
> Hyman Rosen <hyrosen@mail.com> wrote:
> 
> >the debugger can give you insight as to what's going on. This
> >doesn't mean that I'm using the debugger to track down buffer
> >overruns or those other Ada-checked things.
> 
> Well, I had to use it two days before[0]. Two parameters to a function
> call that took a lot of ints were accidentally swapped. Yeah, of
> course I could have taken a more deeper look into the function
> specification but I was still sleeping and missed my morning coffee.
> 
> With some distinct types for the parameters an Ada compiler *could*
> have catched this. Of course, one has to make *use* of the strong type
> system, then.

You could also have avoided this problem in Ada using named 
notation on your function call. With named notation the actual
parameters are explicitly associated with the formal parameters,
regardless of the ordering of the parameters.

Jim Rogers

Re: Using Ada for device drivers?

[Georg Bauhaus]

In comp.lang.ada soft-eng <softeng3456@netscape.net> wrote:
: Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote in message news:<b9qnfq$him$2@a1-hrz.uni-duisburg.de>...
:> In comp.lang.ada soft-eng <softeng3456@netscape.net> wrote:
:>  
:> : I thought banks merged due to economic issues -- if any
:> : single merger was related to Y2K, it sure wasn't publicized.
:> 
:> What else than a technically caused economic issue shoud Y2K be?
: 
: You think the economy tanked due to Y2K?

No. Why do you ask? Rhetorics?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert I. Eachus]

Preben Randhol wrote:

> A great many things are possible, yet not practical. (Isaac Asimov)
> Or in other words you can probably make a huge complex system in
> assembly code, but it will take you a couple of decades to get the job
> done.

Or it may be impossible.  There have been several times I have thought 
of creating a bug tracking system that tracks how many bugs are caused 
by a previous "bug-fix."  The number of such bugs for each earlier bug 
is a major determinant of when existing software has become too 
"brittle" and has to be replaced.  But it also allows you to determine 
when, and in fact if, a new development project is ever going to be 
complete.

Obviously, if each bug fix (on average) creates one new bug, you can 
never win.  The problem is that a bug tracking system only contains bugs 
that have been found, whether or not they have been fixed.  So from 
experience when the observed ratio reaches 0.3 on a new development 
project you are probably already slipping schedule, hit 0.4 and you are 
in deep kimchee.  For fielded software that is being actively 
maintained, at about 0.6 it is time to start working on the complete 
rewrite.  Of course, the reality is that if you are smart you rewrite 
individual modules where the rate of secondary bugs is high and keep the 
overall system working until it is replaced or retired.

I've never written the tool, because my role at MITRE meant that I 
usually only had access to the contractors bug database, and if I was 
lucky, the source code.  But going through the database and classifying 
bugs as original or secondary was usually sufficient to tell me how bad 
off the project was.  The largest amount of documentation associated 
with a single bug is probably a good proxy.  Above 10 pages or so, you 
are entering the twilight zone.  I remember one bug report that included 
134 separate code changes in the fix.  Is it any wonder that that 
project never had working software and was eventually cancelled?)

I don't think I have ever worked on an Ada project where this ratio ever 
got high enough to be statistically greater than zero.  (Yes, if you 
have one such incident you know the ratio is greater than zero.  But the 
standard error, as calculated, included zero.)  At Verdix (now part of 
Rational, now part of IBM ;-) they tracked this type of information for 
their Ada compiler, originally written in C.  When the number of bugs 
associated with a given module was too high, they rewrote the module in 
Ada.  Even with the fact that this meant that only the more complex 
parts of their compiler were eventually written in Ada, the bug rate for 
the Ada sections was much lower.  (You could argue that this biased 
their data because the Ada modules were second attempts, but there were 
also some parts of the compiler that were never written in C.)

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Robert I. Eachus]

Marin David Condic wrote:
> I agree and would add this personal observation: In one job incarnation I
> programmed in Ada for 10 years and NOT ONCE did I ever have to turn on the
> debugger.(O.K. Maybe an occasional Put_Line statement, but NO DEBUGGER!) I
> left to join another company that had its main product in MSVC++. The
> debugger instantly became a WAY OF LIFE.
> 
> Granted, this is anecdotal and may have a lot to do with issues of style,
> etc., but I doubt I am the only one with such a story. I also wouldn't
> suggest that Ada compilers should not provide debuggers or that they are
> never necessary. I would only claim that I have seen far less need for
> debuggers with Ada than with C or C++

I certainly agree.  I was thinking that I could probably count the 
number of times I have used a debugger with Ada on the fingers of one 
hand, and that included development work on several Ada compilers during 
the past 20+ years.  Sticking in Put_Lines, at least in my case probably 
doesn't count.  Because I do a lot of simulation and random number 
generation work, the Put_Line statements are often part of the original 
code for validation purposes, then turned off via pragma Debug for 
normal use.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Shayne Wissler]

Robert I. Eachus wrote:

> Preben Randhol wrote:
> 
>> A great many things are possible, yet not practical. (Isaac Asimov)
>> Or in other words you can probably make a huge complex system in
>> assembly code, but it will take you a couple of decades to get the job
>> done.
> 
> Or it may be impossible.  There have been several times I have thought
> of creating a bug tracking system that tracks how many bugs are caused
> by a previous "bug-fix."  The number of such bugs for each earlier bug
> is a major determinant of when existing software has become too
> "brittle" and has to be replaced. 

I think what it indicates is that the development methods used are 
brittle--which leads to the brittle code. If you see the secondary bug to 
primary bug ratio consistently rising, the first thing to do is ask 
questions about who is managing the project, not about the software itself. 
Even the best software will have bad ratios if the people working on it are 
sloppy.

Although it's not easy, I don't think it's rocket science to be able to make 
consistent progress. If, for every bug you hit, you always investigate why 
the bug happened, and then modify your approach accordingly, I don't think 
you can get into the spiral you're referring to. I think it only happens 
when people stop introspecting, and just blindly pull a bug off the top of 
the list and proceed with "fixing" it.

A methodical approach can appear to be less efficient, and I'm sure it's the 
pressure to deliver that leads to many breaches in integrity to a proper 
engineering methodology. Of course, in the long run, such breaches always 
end up costing you more.

A lot of software does deserve to be completely rewritten. But that should 
be apparent by how slow you have to go when adding features, not by 
ever-cascading bugs. On the contrary, if you see bugs spiraling out of 
control, that's evidence that you don't want that particular team and/or 
its management to undertake rewriting the system.


Shayne Wissler

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Preben Randhol wrote:
> Or in other words you can probably make a huge complex system in
> assembly code, but it will take you a couple of decades to get the job
> done.

I don't see why you say that. Huge complex systems have been written
in assembly code in considerably less than decades. Writing in assembly
isn't an especially difficult proposition.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert Spooner]

Robert I. Eachus wrote:
> ...
> Or it may be impossible.  There have been several times I have thought 
> of creating a bug tracking system that tracks how many bugs are caused 
> by a previous "bug-fix."  The number of such bugs for each earlier bug 
> is a major determinant of when existing software has become too 
> "brittle" and has to be replaced.  But it also allows you to determine 
> when, and in fact if, a new development project is ever going to be 
> complete.
> 
> Obviously, if each bug fix (on average) creates one new bug, you can 
> never win.  The problem is that a bug tracking system only contains bugs 
> that have been found, whether or not they have been fixed.  So from 
> experience when the observed ratio reaches 0.3 on a new development 
> project you are probably already slipping schedule, hit 0.4 and you are 
> in deep kimchee.  For fielded software that is being actively 
> maintained, at about 0.6 it is time to start working on the complete 
> rewrite.  Of course, the reality is that if you are smart you rewrite 
> individual modules where the rate of secondary bugs is high and keep the 
> overall system working until it is replaced or retired.
> 

I saw a hardware situation analogous to this when I worked in industry. 
The digital circuitry was on ten inch square wire wrap boards in rack 
cabinets. The circuitry was designed, then sent out to a wire wrap house 
to be semi automatically wrapped. Fully automatic wrapping was not 
feasible because the Manhattan pattern of the wires would make the 
circuitry too slow. Once a board returned and was populated, it would be 
tested. There were some design errors and some wire wrap errors because 
of chains being broken or tied together, etc. In looking at the defects 
over time, I saw an exponential decay curve. A technician would take one 
of these 10,000 pin boards, and have to add and remove wires. In the 
process, some mistakes would be made, perhaps miscounting pins, perhaps 
having to remove and then forgetting to replace some wires to get to a 
lower level error. Occasionally there were other design errors uncovered 
as well. After testing more changes would have to be done giving rise to 
a percentage of errors again. Assuming that the defect decay rate was a 
function of board size, it was easy to see that we would have been in 
real trouble if the boards had been 12 inches square instead of 10!

The experience drove home to me the truth that you can't just scale up 
what works on a small project and expect it to work just as well on a 
large one. That's why Ada is so useful for programming in the large - it 
gives you the architectural tools you need so that you don't have to 
contend with the software version of a wire wrap board with 14,400 pins. 
The nuclear industry found out that scaling up a 50 megawatt submarine 
propulsion reactor to 500 or 1000 megawatts for power generation didn't 
work so well either.

Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[achrist]

Vinzent Hoefler wrote:
> 
> >  I don't recall ever seeing an Ada product or tool that would
> >run on an 8086 or 8088 without special hardware added.
> 
> Seems you don't have a clue.
> 
> >Were there any?
> 
> The Meridian Ada83 compiler.
> 
> Vinzent.
> 

OK.  The post to which I replied read "In the early days pf PCs".
The early days of PC's (to me) were the period 1981-1985, when the 
first-generation 8088 was the typical machine.  Was Meridian running
on 8088 PC's at that time?  Could it both raise and handle interrupts?
Load registers?  Call the BIOS?  Address the DOS low memory?  Compile
to object code that other languages could use without a large run-time
library (remember it took about 35kb to talk to the mouse under DOS,
so many programs didn't bother to include any mouse support).  TSR?

I surely remember looking pretty hard for an Ada compiler for my PC in
1986 and not finding anything affordable.  Maybe Ada on the PC was hard
to find because Intel had developed the 432 as their chip to run Ada,
but for whatever reason, Ada on the PC was not out there leading the
way.


Al



Al

Re: Quality systems

[Willard Thompson]

postmaster@airnsun.dcfido.org.invalid (Dave Aronson) wrote in message news:<mdqcndrpQf5MXl6jXTWcqw@speakeasy.net>...
> (NOTE: F'UPS TRIMMED TO WHAT I READ!)
> 
> In comp.software-eng Roy Smith <roy@panix.com> wrote:
> 
>  RS> If you double 64k every 2 years for 26 years, you end up with 512
>  RS> Meg, which isn't too far off from what you need to run Unix today.
> 
> Ha.  A couple years ago, I was happily running Linux on a 486/33 with a
> mere 32 megs of RAM, and using only about 1/4 of my 1.3 gig hard drive.
> Even as of then, Windows would not survive in such an environment.

By the way, there's an article on cnn.com:
http://www.cnn.com/2003/TECH/biztech/05/15/microsoft.linux.reut/index.html,
regarding MS offering discounts to maintain OS supremcy.


WILLARD_|_|_|_|_|_|_|_|_|_|_
|_|_|_|AT_|_|_|_|_|_|_|_|_|_
|_|_|_|_|BLETCHLEYPARK|_|_|_
|_|_|_|_|_|_|_|_|_|_|_DOT_|_
|_|_|_|_|_|_|_|_|_|_|_|_|NET

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Thu, 15 May 2003 22:01:06 -0500 (CDT)
NNTP-Posting-Host: !Zf<,1k-W@h7L(; (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Robert Spooner" <rls19@psu.edu> wrote in message
news:3EC3EEFF.4030601@psu.edu...
> The experience drove home to me the truth that you can't just scale up
> what works on a small project and expect it to work just as well on a
> large one. That's why Ada is so useful for programming in the large - it
> gives you the architectural tools you need so that you don't have to
> contend with the software version of a wire wrap board with 14,400 pins.
> The nuclear industry found out that scaling up a 50 megawatt submarine
> propulsion reactor to 500 or 1000 megawatts for power generation didn't
> work so well either.

Examples to back up that statement?

Re: Ada for tiny machines ?

[Wesley Groleau]

> OK.  The post to which I replied read "In the early days pf PCs".
> The early days of PC's (to me) were the period 1981-1985, when the 
> first-generation 8088 was the typical machine.  Was Meridian running
> on 8088 PC's at that time?  Could it both raise and handle interrupts?
> Load registers?  Call the BIOS?  Address the DOS low memory?  Compile
> to object code that other languages could use without a large run-time
> library (remember it took about 35kb to talk to the mouse under DOS,
> so many programs didn't bother to include any mouse support).  TSR?

I can not remember the exact year, but there was a
subset of Ada available for my Z80 machine (64 K RAM)
at one time.  Don't know how big a subset or what they
left out.  Seems like it was Janus or RR but I'm not sure.
Had adverts in Byte magazine.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dr Chaos]

On Thu, 15 May 2003 21:47:00 -0500, John R. Strohm <strohm@airmail.net> wrote:
> X-A-Notice: References line has been trimed due to 512 byte limitation
> Abuse-Reports-To: abuse at airmail.net to report improper postings
> NNTP-Proxy-Relay: library2.airnews.net
> NNTP-Posting-Time: Thu, 15 May 2003 22:01:06 -0500 (CDT)
> NNTP-Posting-Host: !Zf<,1k-W@h7L(; (Encoded at Airnews!)
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> 
> "Robert Spooner" <rls19@psu.edu> wrote in message
> news:3EC3EEFF.4030601@psu.edu...
>> The experience drove home to me the truth that you can't just scale up
>> what works on a small project and expect it to work just as well on a
>> large one. That's why Ada is so useful for programming in the large - it
>> gives you the architectural tools you need so that you don't have to
>> contend with the software version of a wire wrap board with 14,400 pins.
>> The nuclear industry found out that scaling up a 50 megawatt submarine
>> propulsion reactor to 500 or 1000 megawatts for power generation didn't
>> work so well either.
> 
> Examples to back up that statement?

Submarine reactors use quite highly enriched (closer to bomb-grade)
uranium.  (It would be very very bad if terrorists could steal their
core, but generally they are considered pretty damn secure and hard
to break into, and unless it is virgin fuel, it will be very radioactive.) 

Fission reactors rely on the rather remarkable and very fortuitous
property of fissioning uranium that two neutrons come out of the
nucleus within microseconds, whereas on average a third one comes out
of the products over the span of hours.  A reactor is designed to be
stable to prompt neutrons, in that there is a net exponential decrease
of fissions from these on the microsecond timescale, but unstable
(when ramping up) or critical (at steady state) when you count the
slow neutrons.

Neutron loss is a function of absorption by moderators and physical
geometry, where free neutrons escape the boundary of the fuel and do
not fission any more.

As a result a design that is satisfactory in a smaller geometry
(submarine) can be very unsatisfactory if you scale everything up,
because a large assembly of highly enriched Uranium will
go unstable to prompt neutrons.  

That is definitely Bad. 

The reactor at Chernobyl went unstable to prompt neutrons.




I can see an analogy to programming here.  If you use less 'safe'
tools, then in a small project you can still be stable where the
fixing of one bug or addition of a feature does not cause it to go
exponentially unstable.  But if you had a big system, the 'free
neutron' from a bug fix is more likely to intersect some other part of
the system.

If it's too big, you are more likely to get an exponentially
growing cascade of crap: it went unstable.  

the point being that differences in "safety" among programming
langugaes and systems may be irrelevant and minor in small scale
programming---and in people's experience the safety technology is
constraining and annoying.  But even that small difference may turn
out to be the difference between a safe and stable large system and
prompt criticality.



dogbert says:

hey engineers, next time you hear that cliche "getting a critical
mass" in a business buzzword setting, drolly mention "oh yes, you must
mean prompt criticality".  Think "Chernobyl". 

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada

[tmoran]

>... Load registers?  Call the BIOS?  Address the DOS low memory?  Compile
>to object code that other languages could use without a large run-time
>library (remember it took about 35kb to talk to the mouse under DOS,
>so many programs didn't bother to include any mouse support).  TSR?
  Looking at an old mouse binding in Ada I see in the comments:
    -- uses int33 functions
    ...
    -- In 1987 this interface was standard and supported by all PC mice.
which suggests the code dates from 1987.  I also found an old (Ada) .com
program, 36K in size, which displays atomic orbitals with the perspective
changing as you move the mouse.  I doubt the mouse takes up "35kb" of
that. (To my surprise, it still runs under W2k!)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Richard Riehle]

David Lightstone wrote:

> If I am to believe the documentation for the Meridian compilier version 4.1
> it should work on a 8086
> with MS-DOS version 2.1 or later

Correct.  Beyond that, Meridian had a compiler that worked
on the MacIntosh.   It also  worked on later versions of MS-DOS
with x386.   It included a nice set of packages in its DOS Library
for doing screen formatting, etc.   There were two drawbacks to
the Meridian compiler that would have been fixed if it Rational had
allowed it to survive the transition to Ada.  One was the definition
for System.Address which was a signed integer and made it
impossible to access the high-order memory beyond 640K. The
other was the absence of a Mouse library.

Aside from that, the Meridian compiler was fun.   There was also
the Janus compiler.  It didn't have as many libraries, but accessing
low-level aspects of the environment was a little easier so one
could build one's own libraries.

The Alsys compiler was  quite good but priced too high.  They
could have priced it more competitively and made a real
difference.  Of particular usefulness was the ability to access
any part of memory with the Alsys compiler and the availability
of an Unsigned_Number package.

Richard Riehle

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Anders Wirzenius]

"soft-eng" <softeng3456@netscape.net> wrote in message news:9fa75d42.0305150600.72feef7f@posting.google.com...
> "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<5mmwa.65$dp4.60@read3.inet.fi>...
>
> > He had a lucky time since the programers were loyal to him. I wonder how Mr Spolsky had reacted if the programmers had ignored
his
> > pages and programmed the macro handling based on their own knowledge of macro language strategy? Had he intervened in their work
or
> > just trusted them and let them do their job?
>
> Well, that's where the trust comes from.
>
> The basic idea is that you assume your
> programmers are smart, conscientious workers.
>
> If you go with that idea, then the only reason programmers
> would ignore his pages is if he was a very dumb person, hired
> accidentally, and had no clue what he was designing.
>
> In which case, perhaps ignoring his pages would have
> been the right thing to do.
>
> "Consensus building" does require support from hierarchy.
> But the primary motivation is "does this makes sense",
> rather than "what is the opinion of the highest person
> in the hierarchy who is involved".

It is easy to be a manager in any management culture when things are going nice and smoothly. The real quality of the management
style is tested when problems arise (hired wrong person...different way of thinking...two persons just cannot sit in the same
room...alcoholism...using working hours for private business ...).
"Assume your subordinates are smart", "make sure", "trust", "hire right people" are all round words. The interesting thing is to
analyse in detail the difference between the acting of MS managers and Juno managers when they encounter problems.

> > The real world lies of course somewhere between these. You need "management" to some degree and therefore I stick to what I
wrote in
> > a previous post: "Error catching as early as possible is a good co-worker to both the programmer and his superior".
> > Compilers that reveal programming errors or issue warnings are a good thing to both me and my superior.
>
> But if you are managing, this should be an issue
> for your programmers to decide by consensus
> and not for you.  (Of course, it is a management issue
> if you are subcontracting to some DoD or Boeing thing
> and getting the contract depends upon Ada.  In that
> case, you have to explain nicely to your programmers
> "I know Ada is slow and frustrating to work with, but
> it's not really our choice, and you all are good folks,
> so I know you will get things done anyway.")

At least this troll is an attempt to get the thread back towards the original discussion :)


Anders

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Hyman Rosen wrote:
> Preben Randhol wrote:
>> Or in other words you can probably make a huge complex system in
>> assembly code, but it will take you a couple of decades to get the job
>> done.
> 
> I don't see why you say that. Huge complex systems have been written
> in assembly code in considerably less than decades. Writing in assembly
> isn't an especially difficult proposition.

OK, so why don't they still make large complex systems in pure assembly
then? It is not because it takes a lot longer than any other high level
language? That it is much harder to maintain?

By the way do you have any examples?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

"soft-eng" wrote:
> I don't agree that Ada is likely to be particularly useful
> for catching errors in a professional environment -- say 2-3%
> of the actual errors at best.  If it's catching more than
> that, I don't see how you can have good people.

Are you sure that you know what you spend your time on?

Or are you one of those who whips up 100 lines of code in a few hours. Brags
about it and forget about the two days you spent getting it to work as it
should?

greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

"Preben Randhol wrote:
> OK, so why don't they still make large complex systems in pure assembly
> then? It is not because it takes a lot longer than any other high level
> language? That it is much harder to maintain?

Because the doctrine says that it should be faster with a more high level
language. And you have a half decent chance to move your software to a
different architecture.

Assembly language programmers know they are living dangerous. C programmers
think the program is safe. That is why it is not particularly difficult to
develop lage assembly language programs compared to C.


greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marc A. Criley]

"soft-eng" <softeng3456@netscape.net> wrote in message news:9fa75d42.0305141747.5680c577@posting.google.com...
> I don't agree that Ada is likely to be particularly useful
> for catching errors in a professional environment -- say 2-3%
> of the actual errors at best.  If it's catching more than
> that, I don't see how you can have good people.
> 
> But good people can certainly make projects succeed using
> many kinds of tools, including Ada.

Now waitaminnit.
 
First we read a recommendation for software development success that
consists of "1)  Hire good people, and give them the tools they need."
Since that was the extent of the advice, presumably that's the
foundation for success. And given the nature of this debate, it is
being argued that the Ada programming language is not to be considered
an inherently good tool that aids success (from a purely technical
perspective).
 
And that, in contrast, one would be hard-pressed to achieve success if
one believes that "2) [...] You just need to give them a quality
solution, and quality will follow.  Just tell them what to do and make
sure they do it.  [...] For instance, a militaristic language that
will catch all their errors and solve the problem of human
fallibility.  Or a methodology that will make quality flow out their
ears.  Typical command-and-conquer stuff is "now everybody will write
a spec in this here format before starting a new module." [Excisions
done with care.]
 
But, but, we did achieve success! We had a quality architecture and
design that took advantage of Ada's technical strengths, the staff was
a set of good, journeyman programmers--no gurus, except for one
exceptional young woman--with anywhere from a few month's to 10 years
experience with Ada, the design was in keeping with a quality
methodology (OMT), and development followed a rigorous
"command-and-conquer" process for all defect
identification/analysis/resolution/rework/retest/rebaselining. And
yes, it was made certain that everyone rigorously followed it.
 
Reread what the outcome was:
 
>>mcq95:
>> The end result of the project was a serious weapon command and
control
>> system that came in on schedule, on budget, with no late nights or
>> weekends required of either the development or test staff, and the
>> lowest number of unresolved defects in any production release of
the
>> system--1 of severity 4 (out of 5, where 1 is critical, and 5 is
>> considered a nice-to-have).

We did all that stuff that you claim is supposed to work against
project success, yet the project succeeded nonetheless, and rather
painlessly at that.

> The only thing is they might privately grumble more, and may
> often have to get C/C++ libraries written by outside vendors
> or themselves.  (Usually there are excuses - We could
> have done it all in Ada, except for this and that...
 
Now where does that come from? "Grumbling?" "Excuses?" About going
home and having dinner with the family each night, and having one's
weekend to themselves?
 
Excuses for what? For the system having the lowest defect rate of any
production release and it steadily improving with each passing day?
Okay--it was Ada's fault!
 
There still seems to be this complete ignorance of the benefits of Ada
and strong typing: Strong typing doesn't just "catch errors" (but for
the sake of argument I'll allow the low figure of 2-3% that you
propose). Some such errors you don't even really notice as errors. For
instance, if I accidentally swap Latitude and Longitude in a procedure
call, the compiler barfs, I fix it, and move on. Well, that one
compilation error just saved a lot of time, since that error probably
wouldn't get noticed until an executable gets into some sort of
testing, whether unit or system testing.
 
But again, the real benefit of error prevention comes not from those
errors that are caught, but from those that _never_ occur!
 
Iterating over an array:
 
   for Eng in Engagements'Range loop
      ...
   end loop;
 
There will _never_ be an array indexing error.
 
Every reference to Some_Type'Last or Some_Array'Length will _always_
be valid, they will never, ever exceed the valid range.
 
When strong typing is properly employed,  a variable will never take
on an invalid value--and if an attempt is made to do that, such as by
assigning to a subtype with a more constrained range, an exception is
immediately raised (one of those 2-3% of errors).
 
It's not that Ada prevents all errors from occurring (that's an absurd
claim that anti-Ada zealots repeatedly and disingenuously try to
attribute to Ada advocates), but it a priori does in fact prevent
certain classes of errors from occurring, and immediately catches
other classes of errors when they occur. And these errors continue to
be put into code every day by programmers throughout the ability
continuum: idiot, competent, and guru.
 
It's no harder to code taking advantage of strong typing than not, and
thereby avoid whole classes of errors--and I'd argue it takes more
effort to fight it, or to manually code the equivalent capability in
more weakly typed languages.
 
Given the effort it saves, why not code in Ada?
 
Marc A. Criley

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<QeqdnYjhssf6MV6jXTWcoA@gbronline.com>...

> general to make credible his/her claim of
> professorship.

Huh?  I did say "evening class", didn't I?  If I didn't,
that must have been an ommission (sorry, don't have
an Ada compiler to check my posts!)

You don't need to be a tenured or tenure-track professor
for teaching evening classes.  Since regular professors don't
want to teach those, many universities used to be willing to
hire somebody from the industry who they thought will
be able to teach at their prestige level.  (And they
would even lower their quality levels often, though
I like to think this was not so in my case!)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

"Graham Perkins" <gperkins@gperkins.co.uk> wrote in message news:<ba067m$iph$1@south.jnrs.ja.net>...
> My other principal usage experience is with Unix and
> VAX-VMS.  I suggest that both of those systems are
> considerably better than MS-Windows, qualitatively.
> Moreover, they were of extremely high quality from very
> early on in their life.  And you never had to double your

Early on?  You are either kidding, or you must not have
used Unix at least until 10-15 years after its inception,
or you have totally forgotten the numerous
reboots and "PANIC" halts followed by "fsck"
run manually.

Btw, the architect of Win-32 is the same individual
who architected VAX-VMS.  (Bill Gates doesn't sit down
and design Windows himself, he hires good people.)
That might be one of the reasons why Win-32 has always
been relatively stable, and with almost a decade of
use behind it, has achieved very decent quality levels.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:<b9tcov$u6q$1@slb3.atl.mindspring.net>...
> Preben Randhol <randhol+abuse@pvv.org> wrote in message
> news:slrnbc1tum.62g.randhol+abuse@kiuk0152.chembio.ntnu.no...
> > soft-eng wrote:
> >
> > > 1)  Hire good people, and give them the tools they
> > > need.  Many companies follow this approach, e.g. Microsoft.
> > > (See http://www.joelonsoftware.com/articles/fog0000000072.html )
> >
> > LOL! Good quality?
> >
> 
> Microsoft? The inventer of the "Rebootive Multitasking Operating System"? An
> example of "Quality"??? I share your amusement, Preben.
> 
> My jet engine control has *never* failed in flight operational use. It
> can't. Someone would die if it did. It's programmed in Ada. Coincidence? Or
> is it possible that Ada contributed to its quality? But then I suppose we
> just hire stupid people and try to control their every action through
> militaristic command and control sorts of "Quality Systems" that ultimately
> don't work so we are left to complain about our vendors or how lousy
> languages like C are. :-)
> 

It's been done with assembly language before.

The point I have been trying to make is that Ada catches
a small extra subset of errors (and compared to modern C, C++
or Java, the "extra" might be non-existent).  Ada or not,
you should have a mechanism that catches those errors
before you ship out the jet engine.

With professional programmers, the "type errors" are
very few anyway (I estimated 2-3% of all errors,
so if a bug-list has 100 items on it, and if more than
2-3 are type-safety issues, I would worry about
programmer quality.)

So the tradeoff is, possibly a bug or two caught
at compile time rather than during testing, versus
using a very large language that was created by fiat.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Marc A. Criley wrote:
> Given the effort it saves, why not code in Ada?

Yep. C++ also gives you some of the same advantages.
For example, iteration over containers looks like
     for (i = c.begin(); i != c.end(); ++i)
so you get the same lack of overruns. But Ada has a
lot more of this type of stuff.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Steve O'Neill]

soft-eng wrote:
> So the tradeoff is, possibly a bug or two caught
> at compile time rather than during testing, 

But one should remember that the farther down the process 
that those errors are caught the amount of time and effort
(read $$$) required to diagnose and correct them.  Not to
mention the ramifications if, God forbid, the error is 
found through someone's injury or death.

> versus using a very large language 

And C++ is small?? Also, you don't need to use it all - just
the parts that you need.

> that was created by fiat.

First, I take exception to your characterization of how Ada
came to be but even if I accepted it how a tool came into being 
should not be a factor in whether you use it or not.  Unless,
of course, the tool was developed ins a sweat shop somewhere.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

soft-eng wrote:
> The point I have been trying to make is that Ada catches
> a small extra subset of errors (and compared to modern C, C++
> or Java, the "extra" might be non-existent).  Ada or not,
> you should have a mechanism that catches those errors
> before you ship out the jet engine.

Please go an reeducate yourself, your pointless reitterations over what
you percieve to be the case is getting boring.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

soft-eng wrote:
> 
> Huh?  I did say "evening class", didn't I?  If I didn't,
> that must have been an ommission (sorry, don't have
> an Ada compiler to check my posts!)

But if you had been a *professional* poster you would of course never
do that mistake, right? 

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

tmoran@acm.org wrote in message news:<7GGwa.849701$F1.107635@sccrnsc04>...
> > In the early days of PCs, people
> > had to often write many things from scratch, and address
> > CGA and VGA and whatnot cards, and draw pixels, and interface
> > to telephony cards...  All that would have been practically
> > impossible in Ada.
>   Having done each of those things with both Ada and C, I'm curious why
> you could possibly think they were any harder in Ada, much less
> "practically impossible".  I have an especially pleasant memory of moving

Mostly from obervations of goings-on.  I don't doubt that
anything can be done in Ada for academic purposes or
to prove a point.  But for serious stakes, Ada groups
actually tend to wait for Ada APIs from C++ vendors, rather
than roll their own if things look bad -- as C++
groups are apt to do.

Of course, I don't claim extensive involvement with
Ada groups.  If what I observed is the exception
rather than the norm, I would be happy to hear
from Ada people who have had little qualms about
rolling their own stuff when the vendors were
not up to snuff.

But what I hear from this group is people who
claim Ada is perfect for everything from writing
device drivers to artificial intelligence.  But
if it becomes clear that the Ada "device driver authors"
have a hard time dealing with null-terminated strings, then
one tends to wonder if the all-encompassing claims are
perhaps a tiny bit exaggerated.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<ej%wa.58$f4.31@read3.inet.fi>...
> "soft-eng" <softeng3456@netscape.net> wrote in message news:9fa75d42.0305150600.72feef7f@posting.google.com...
> > "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<5mmwa.65$dp4.60@read3.inet.fi>...
> >
> > > He had a lucky time since the programers were loyal to him. I wonder how Mr Spolsky had reacted if the programmers had ignored
>  his
> > > pages and programmed the macro handling based on their own knowledge of macro language strategy? Had he intervened in their work
>  or
> > > just trusted them and let them do their job?
> >
> > Well, that's where the trust comes from.
> >
> > The basic idea is that you assume your
> > programmers are smart, conscientious workers.
> >
> > If you go with that idea, then the only reason programmers
> > would ignore his pages is if he was a very dumb person, hired
> > accidentally, and had no clue what he was designing.
> >
> > In which case, perhaps ignoring his pages would have
> > been the right thing to do.
> >
> > "Consensus building" does require support from hierarchy.
> > But the primary motivation is "does this makes sense",
> > rather than "what is the opinion of the highest person
> > in the hierarchy who is involved".
> 
> It is easy to be a manager in any management culture when things are going nice and smoothly. The real quality of the management
> style is tested when problems arise (hired wrong person...different way of thinking...two persons just cannot sit in the same
> room...alcoholism...using working hours for private business ...).
> "Assume your subordinates are smart", "make sure", "trust", "hire right people" are all round words. The interesting thing is to
> analyse in detail the difference between the acting of MS managers and Juno managers when they encounter problems.
> 

There is indeed some of that in Joel's URLs.  He said Microsoft
managers tried to remove themselves out of the situations,
and let the involved people fight it out (on the grounds
that the manager has the least information on the details.)
Though once, when a bunch of Ph.D.s were trying to make things
happen contrary to the corporate culture by using hierarchical
leverage, the group was very quickly disbanded and placed in
separate positions (presumably so they could do less harm.)

As opposed to Juno management where the CEO was brought in
and weighed in with a strong opinion to resolve a very
minor dispute between Joel and his manager.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada

[achrist]

tmoran@acm.org wrote:
> 
> which suggests the code dates from 1987.  I also found an old (Ada) .com
> program, 36K in size, which displays atomic orbitals with the perspective
> changing as you move the mouse.  I doubt the mouse takes up "35kb" of
> that. (To my surprise, it still runs under W2k!)

You didn't count the size of the mouse driver. In DOS everything 
had to come out of the addressable 1 MB of memory.  

Al

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tom Welsh]

In article <9fa75d42.0305160440.7846d18c@posting.google.com>, soft-eng
<softeng3456@netscape.net> writes
>
>Btw, the architect of Win-32 is the same individual
>who architected VAX-VMS.  (Bill Gates doesn't sit down
>and design Windows himself, he hires good people.)
>That might be one of the reasons why Win-32 has always
>been relatively stable, and with almost a decade of
>use behind it, has achieved very decent quality levels.

That turns out not to be the case.

1. Dave Cutler didn't architect VAX/VMS all by himself. He was a member
of a team, and not necessarily the dominant member (except perhaps in
terms of personality).

2. Cutler didn't design Win32 either. He joined Microsoft in 1988 to
write a new operating system, which turned out to be Windows NT.
Cutler's team wrote the operating system kernel and services. Win32 was
a load that NT had to carry, not a source of strength. 

3. According to G Pascal Zachary's book "Showstopper!", "...Cutler
didn't disguise his scorn for Microsoft and its products. He thought the
company's code was poorly written, and that DOS, its crown jewel, was a
'toy'".

Actually, it was the requirement to support the Windows graphics
subsystem that came closest to wrecking the whole NT project. Zachary
again: "Cutler saw the worst in graphics. 'He worried about that group
all the time,' an intimate said. 'He saw them as loose cannons'".

It is true that Cutler's work laid the foundation for a series of
"relatively stable" Microsoft operating systems. But there was (and
still is) a fundamental tension between the things that make VMS and
Windows NT stable, and the user interface glitz that have made Windows
the popular success it is.
-- 
Tom Welsh

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert I. Eachus]

Shayne Wissler wrote (I'm quoting it in full because it deserves to be 
reread):

> I think what it indicates is that the development methods used are 
> brittle--which leads to the brittle code. If you see the secondary bug to 
> primary bug ratio consistently rising, the first thing to do is ask 
> questions about who is managing the project, not about the software itself. 
> Even the best software will have bad ratios if the people working on it are 
> sloppy.
> 
> Although it's not easy, I don't think it's rocket science to be able to make 
> consistent progress. If, for every bug you hit, you always investigate why 
> the bug happened, and then modify your approach accordingly, I don't think 
> you can get into the spiral you're referring to. I think it only happens 
> when people stop introspecting, and just blindly pull a bug off the top of 
> the list and proceed with "fixing" it.
> 
> A methodical approach can appear to be less efficient, and I'm sure it's the 
> pressure to deliver that leads to many breaches in integrity to a proper 
> engineering methodology. Of course, in the long run, such breaches always 
> end up costing you more.
> 
> A lot of software does deserve to be completely rewritten. But that should 
> be apparent by how slow you have to go when adding features, not by 
> ever-cascading bugs. On the contrary, if you see bugs spiraling out of 
> control, that's evidence that you don't want that particular team and/or 
> its management to undertake rewriting the system.

Everything you say is true, and good advice.  But you need to know where 
I am coming from.  At MITRE software engineers are often used by the 
government as firemen to go into an out-of-control project and determine 
what can be done to fix things.  Sometimes the advice has to be that the 
project is hopeless and can't be saved.  If the software is too brittle, 
it doesn't matter how it got that way, all that matters is that the only 
way to ever deliver a product is to fund a new project with a new team, 
and bury the original code so that it can't possibly be reused. 
Expensive?  Not really.  It is like a fireman deciding that they can 
save all the buildings around the one that is burning, or try to save 
that building and lose everything.  It is not a decision you take lightly.

Let me give two examples.  The first is one where MITRE was involved, 
called Cheyanne Mountain Upgrade.  At the time it was started, the 
Soviet Union was still a threat, and NORAD being off the air for even 
part of a day was considered unacceptable.  The overall project was a 
success, even though the reasons for that success involved spending 
extra money to put firewalls between each component of the upgrade. 
Some of the components were late and involved lots of nasty problems 
like changes in requirements.  (It doesn't matter if the system can deal 
with the original threat assessment.  If the threat changes, the real 
requirements must change.  Also one of the biggest requirements changes 
was caused by the Goldwater-Nichols reorganization of the DoD command 
structure.)  But because of the firewalling each component was of 
managable size and could be installed without depending on other parts 
of CMU.

The other example is a program where MITRE was not the FFRDC invovled. 
The A-12 attack aircraft program for the Navy did not have this type of 
firewalling.  By the time that budget overruns and schedule delays 
brought the program to the attention of Congress, the whole project was 
unsalvageable.  (And, yes, some of the people who let it get out of 
control were fired. See http://www.fas.org/man/dod-101/sys/ac/a-12.htm 
for a write up of the disaster.)

In any case, my reasons for wanting to develop a defect management tool 
was not for the people actually involved in the project.  It was so that 
the government and FFRDC people involved in managing the project for the 
government could detect the problem before it was too late.  The most 
important thing to take away from this discussion is that it is possible 
to get to the point where it really is too late to save the project.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

soft-eng wrote:
> 
> Btw, the architect of Win-32 is the same individual
> who architected VAX-VMS.  (Bill Gates doesn't sit down
> and design Windows himself, he hires good people.)
> That might be one of the reasons why Win-32 has always
> been relatively stable, and with almost a decade of
> use behind it, has achieved very decent quality levels.

What is you definition of stable? Win-32 has not had a good record of
stability at all.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

Shayne Wissler <thales000@yahoo.com> wrote in message news:<fZQwa.855043$F1.107665@sccrnsc04>...
> Robert I. Eachus wrote:
> 
> > Or it may be impossible.  There have been several times I have thought
> > of creating a bug tracking system that tracks how many bugs are caused
> > by a previous "bug-fix."  The number of such bugs for each earlier bug
> > is a major determinant of when existing software has become too
> > "brittle" and has to be replaced. 
> 
> I think what it indicates is that the development methods used are 
> brittle--which leads to the brittle code. If you see the secondary bug to 
> primary bug ratio consistently rising, the first thing to do is ask 
> questions about who is managing the project, not about the software itself. 
> Even the best software will have bad ratios if the people working on it are 
> sloppy.
> 
> Although it's not easy, I don't think it's rocket science to be able to make 
> consistent progress. If, for every bug you hit, you always investigate why 
> the bug happened, and then modify your approach accordingly, I don't think 
> you can get into the spiral you're referring to. I think it only happens 
> when people stop introspecting, and just blindly pull a bug off the top of 
> the list and proceed with "fixing" it.

Precisely.

When you have a bug, you need to understand what is causing
it.  That should be obvious.  What is not obvious to many
except those involved, is that often it is possible
to fix a bug without having fully figured out what's causing it.

Now sometimes it is ok.  E.g. if you haven't figured out
exactly what's causing it, but you know the module it's
happening in, and you figure you can just rewrite the
module and make it bug-proof.  In that case, you don't
have to know the path in the old module that caused
the bug to surface.

Other times are when the bug is very intermittent
and cannot be duplicated and you have to proceed
blindly, based on theories that are sometimes half-baked.

And then there are cases where you are working
with a crucial part of the system, without fully
understanding its full impact on the rest of the
system.  So you fix a bug, and the rest of the
system comes crashing down on you...

But the truth is the choice of language has little to
do with situations like these.  You just need professionalism
and discipline.  Don't fix until you are sure you
have found the bug, or at least the module where
the bug is.  If you have to shoot-in-the-dark,
use a source code control system so you can back
out of any theories that didn't work out, without
leaving new bugs.  If you are working with critical parts
of the system, read the code until you know what every
if statement does, and don't touch it until
you know EXACTLY what you are doing.  Don't
be afraid of re-writing large chunks of
the code, but only if you have done the
homework of understanding the old code cold.
None of which has to do with the language choice.

Sorry, there is NO magic bullet for such things.
I strongly doubt stories where the choice
of a new language turned all coders into
highly disciplined professionals, just like
I doubt array-bounds-checking is the most
useful invention in programming languages ever,
before which everybody was just sloppily writing
outside their arrays all the time as a matter of habit.

Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Marc A. Criley]

"soft-eng" <softeng3456@netscape.net> wrote in message news:9fa75d42.0305160453.29c0c4af@posting.google.com...
> The point I have been trying to make is that Ada catches
> a small extra subset of errors (and compared to modern C, C++
> or Java, the "extra" might be non-existent).  Ada or not,
> you should have a mechanism that catches those errors
> before you ship out the jet engine.

And it's that point you're trying to make that reflects a startling
tunnel vision on your part.

> With professional programmers, the "type errors" are
> very few anyway (I estimated 2-3% of all errors,
> so if a bug-list has 100 items on it, and if more than
> 2-3 are type-safety issues, I would worry about
> programmer quality.)

Assuming an Ada-coded system where proper usage has been made of
strong typing...

I'm not positive what you mean by "type errors"--I see two potential
interpretations that are relevant to Ada:

1) Type conflicts
2) Range errors

The first, type conflicts, are fixed almost without thought by an Ada
programmer, since the program won't compile until they're are. If I
swap Lat and Lon in a procedure call, or mis-assign a "Plan_Number"
value to an "Engagement_Number" variable, it's immediately caught and
I fix it--I don't even bother to count that as a defect--so it never
makes it onto a bug list--that's just a momentary "oops" on my part.

What happens when you swap nLat and nLong in a function call? You get
an object file, I get a compile error.

When does it get noticed? When you run a test, when I look at the
compiler's output.

These little type conflicts are always caught and fixed, without  the
Ada programmer even thinking about it--these errors just never make it
into the test regime, because they've been long since dealt with.

Range errors get automatically detected at run-time in an Ada-coded
system, where they can be as simple as an off-by-1 error, and who
hasn't dealt with that one?

What happens when your indexing is off by one? The program may crash,
or it may not. It may corrupt neighboring data, or it may not. It may
often exhibit erratic behavior, or it may do so intermittently.

When my indexing is off by one an exception is raised and I
immediately know there's a problem that I need to identify and fix.

------------------------------

But granting this low estimation of "type error" occurrence, that
means many of the remaining errors would be designated as "logic
errors", and it's been suggested that this is the type of the majority
of errors (which I believe is true), and that neither Ada nor any
other language is inherently capable of preventing logic errors--also
true.

So your assertion appears to be that 1) most software errors are logic
errors, and 2) Ada's strong typing only helps prevent an uncommon type
of error (type errors), therefore the effort required to work with or
around Ada's strong typing adds no value to the detection and
correction of the predominant type of error (logic).

Okay then, so how _does_ one know they've got a logic error in their
code?

The error is going to manifest itself in one of three ways:
1) The program runs but the functionality isn't as desired. This may
be obvious (it immediately exits), or not (a cumulative microsecond
drift that becomes noticeable only after a couple days caused by a
counter not getting reset).
2) The program crashes at some point.
3) The program runs but behaves erratically, and this behavior may be
intermittent.

In the third case, clearly Ada and strong typing would likely be of
benefit here, since such erratic behavior may arise from "type errant"
run-time behavior that was initiated by executing the wrong logic.
Pretty much every time an unexpected exception occurs in an Ada-coded
program, the cause is a logic error that causes the execution of code
that is an inconsistent internal state (because that code wasn't
supposed to be executed!). Stale data values may be referenced,
garbage values may be in variables, and as soon as Ada does a range
check on them, everything halts--and you can go track down the
problem.

In the second case, one has to determine what led to the crash: Was it
an immediate crash at the point of error? E.g., trying to write
through a null pointer? Or was the program getting messed up
internally, but gave no indication and continued to run for awhile
before the cascade of errors got so bad that it crashed? If the
former, Ada's no better or worse than any other language in which that
occurs, but if the latter, you've just got case #3 again, but where it
does eventually terminate.

In the first case, things like peer reviews and formal inspections
have proven to be of measurable assistance.

> So the tradeoff is, possibly a bug or two caught
> at compile time rather than during testing, versus
> using a very large language that was created by fiat.

Again, you're not counting the errors that _never_ occur _because_ of
strong typing. (And you've also been ignoring all mention of how the
type information embedded within Ada software due to its strong type
model also aids correctness and maintainability.) Because C/C++
doesn't flag type conflicts among values having the same base type
(int or float) and also does implicit type coercion, you never see
such conflicts when you're compiling your software, and by the time
they manifest themselves--in test--they've become logic errors: "I
meant to use Latitude rather than Longitude here."

Marc A. Criley

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Steve O'Neill]

soft-eng wrote:
[snip]

> Of course, I don't claim extensive involvement with
> Ada groups.  

Yeah, you gotta get out more... :)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Chad R. Meiners]

"Tarjei T. Jensen" <tarjei.jensen@akerkvaerner.com> wrote in message
news:3ec4b5c5$1@news.wineasy.se...
> Assembly language programmers know they are living dangerous. C
programmers
> think the program is safe. That is why it is not particularly difficult to
> develop lage assembly language programs compared to C.

That is a great observation!  It also explains why I prefer assembly
programming to C programming ;)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Wesley Groleau]

> propose). Some such errors you don't even really notice as errors. For
> instance, if I accidentally swap Latitude and Longitude in a procedure
> call, the compiler barfs, I fix it, and move on. Well, that one

An example of such an error: A lot of math libraries
contain a "two-arg Arctan" where the _first_ argument
must be 'Y' and the _second_ 'X'  It's VERRY easy to
invoke Atan (X, Y);

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Wesley Groleau]

>>general to make credible his/her claim of
>>professorship.
> 
> Huh?  I did say "evening class", didn't I?  If I didn't,
> that must have been an ommission (sorry, don't have
> an Ada compiler to check my posts!)

Perhaps you did.  My memory slipped?
Happens often.  That's why I prefer
using Ada AND a good process.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Linnea]

soft-eng wrote:
> 
> But the truth is the choice of language has little to
> do with situations like these.  You just need professionalism
> and discipline.  Don't fix until you are sure you
> have found the bug, or at least the module where
> the bug is.  If you have to shoot-in-the-dark,
> use a source code control system so you can back
> out of any theories that didn't work out, without
> leaving new bugs.

This far I can agree,

> If you are working with critical parts
> of the system, read the code until you know what every
> if statement does,

and even this far,

> and don't touch it until
> you know EXACTLY what you are doing.  Don't
> be afraid of re-writing large chunks of
> the code, but only if you have done the
> homework of understanding the old code cold.

but here you are saying something I cannot agree with.

I have learnt my first lessons on refactoring in early 80's, long before
I knew anything about version control and the other aids to support it,
and almost two decades before I found Martin Fowler's book on
refactoring. Ever since those first lessons, I've always considered
refactoring - even when I didn't have a name for it - as the only way to
ensure that I know exactly what I am doing, and to find out what exactly
the code is doing.

You HAVE to touch the code IN ORDER TO understand it. You have to
continuously edit, compile, debug, edit, compile, debug, in order to
find whatever you are looking for. Even when you don't understand which
change eventually fixed a bug, refactoring is a way to ensure your fix
doesn't break anything.

There is no better method to read the code than refactoring, especially
when dealing with the various sediments of history, but so many
generations of programmers have been educated to just WRITE programs.
Each new generation believes they write better programs than the
previous, and therefore are privileged to discard what others wrote.
When shall we see the first generation that was taught from the
beginning to read the code and respect the experience?

The only way to learn to read the code is my touching it, by refactoring
it. If that's what you mean by "homework of understanding the old code
cold", then we agree. However, I see no indication of you meaning it
that way.

> None of which has to do with the language choice.

From here on I can agree again.

Linnea

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dr Chaos]

On Fri, 16 May 2003 09:21:46 -0400, Hyman Rosen <hyrosen@mail.com> wrote:
> Marc A. Criley wrote:
>> Given the effort it saves, why not code in Ada?
> 
> Yep. C++ also gives you some of the same advantages.
> For example, iteration over containers looks like
>      for (i = c.begin(); i != c.end(); ++i)
> so you get the same lack of overruns. But Ada has a
> lot more of this type of stuff.

Does the C++ language prevent 'i' from being modified 
abnormally in the loop and the container being
dereferenced abnormally thereby? 

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert I. Eachus]

soft-eng wrote:

> Other times are when the bug is very intermittent
> and cannot be duplicated and you have to proceed
> blindly, based on theories that are sometimes half-baked.

We call those Heisenbugs.  Converting a Heisenbug to a Bohrbug that you 
can reproduce is often the first part of fixing the problem.

> And then there are cases where you are working
> with a crucial part of the system, without fully
> understanding its full impact on the rest of the
> system.  So you fix a bug, and the rest of the
> system comes crashing down on you...
> 
> But the truth is the choice of language has little to
> do with situations like these.

No, no, NO!  Sorry. There are two nice software engineering terms 
coupling and cohesion. Low coupling means that program modules have a 
low degree of interaction with other modules. Cohesion means that code 
in one module all deals with the same data construct or constructs.  Low 
coupling and high cohesion are good, and the combination of good 
software design and Ada allows you to achieve very low coupling and good 
cohesion.  You can't manage this without good software engineering, and 
you can do bad software engineering in just about any progamming 
language, including Ada.  What Ada allows you to do is accomplish 
extremely low coupling.

For example, assume your design requires several different list 
structures, including single and double ended queues.  In Ada you can 
have a dozen different queue types in your program library.  At each 
point where a list or queue is needed you instantiate a generic.  The 
generic instantiation is the only coupling between the program and the 
queue module.  There is no coupling between the queue module and the 
program.

This combination of data hiding, data abstraction, and modularization is 
what makes Ada so wonderful for programming in the large.  In a good Ada 
design, it is normal for program modifications, whether they are bug 
fixes or adapting the system to new requirements to only affect one 
module.  I can't begin to count the number of times when something which 
would be a month's work if we hadn't used Ada turned out to be a 
"trivial fix" in Ada.

I remember one time when during the system acceptance testing for a 
150,000 LOC project, the users noticed a problem with the user interface 
(which worked as specified).  At the end of the first day, the program 
manager was tasked to find out the cost of making the change, which 
would require a change to several major data structures.  (Basically it 
provided a common mechanism for the users to back out of any data entry 
transaction with no updates occuring, rather than knowing how often to 
hit the escape key.)

By lunch the next day, he had a cost estimate, and a (one page) diff 
from re-running all the test scripts.  Turned out that the change 
belonged in a component which was part of all the data types, and the 
implementation was private to one package.  Total LOC changes?  Nine, 
including three comment lines. ;-)

> Sorry, there is NO magic bullet for such things.
> I strongly doubt stories where the choice
> of a new language turned all coders into
> highly disciplined professionals, just like
> I doubt array-bounds-checking is the most
> useful invention in programming languages ever,
> before which everybody was just sloppily writing
> outside their arrays all the time as a matter of habit.

Ada is not a magic bullet.  What it does allow is that if you have a 
good process for creating a workable overall software design structure, 
then Ada modularization rules match the project structure.  As long as 
the implementor of a module stays within the lines, he can't add 
coupling to the system during development.  To go back to the original 
discussion, once the software design is finished, any change which would 
increase coupling comes with very serious warning flags attached.

Since there is almost never a reason to make one of those changes, a 
project manager can keep a hammer in his office to use on anyone who 
proposes such a change.  (A foam rubber hammer, of course, unless you 
have some programmers who are incapable of learning. Actaully, this is a 
matter of personal preference.  At Stratus I kept a plastic Whiffleball 
bat in my umbrella stand, and it came out and was on my desk or in my 
hand whenever someone wanted to change a global data structure, in a way 
that was visible to other modules. ;-)  Sometimes finding a way to make 
the change without adding coupling is tough.  But in the long run it was 
worth it to take several hours of time to find a better way.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Larry Hazel]

Robert I. Eachus wrote:
> 
> Since there is almost never a reason to make one of those changes, a 
> project manager can keep a hammer in his office to use on anyone who 
> proposes such a change.  (A foam rubber hammer, of course, 

Ah yes, must have the proper SOFTware tools :)

Re: Quality systems

[Georg Bauhaus]

In comp.lang.ada soft-eng <softeng3456@netscape.net> wrote:
: [in response to what the let-go management does when confronted
: with "problematic programmers"]
: Though once, when a bunch of Ph.D.s were trying to make things
: happen contrary to the corporate culture by using hierarchical
: leverage, the group was very quickly disbanded and placed in
: separate positions (presumably so they could do less harm.)

I might have misread the article, but I was under the impression
that higher ranking management intervened to remove influence
of some "architecture people" to let the programmer go on inventing
macro support for an MS product. He seems not to have been a
problem in the eyes of this part of management, so this part
of managment intervened and "removed" a lower ranking part of
"non-programmers". The question was about how they manage
"problematic" programmers.
According to a TV documentation about former long time MS employees,
if you become a problem for management,
management will issue one warning, and give you the freedom
of correcting the problem yourself... And that is not exactly
managing problematic situations in my view, it is removing the
situations together with the peple involved. There is a saying,
in German, about a bath and a child, and emptying the bath tub.
Is that known in English?
Consider that, seemingly, you are allowed to
work as long as you like in MS buildings; one might point out that
the smart management has no problem at all leading the way to
burn-out. A Bill Gates publication about his view of computing
business future adds further corroborations. Good old
Benjamin Franklin. Are Gates and Balmer protestants, BTW?

So there might be a premise for complete programming freedom:
total engagement, with dismissal pending otherwise (that is, showing 
only non-total engagement, which is the usual healthy case in
general, or isn't it?)  They said, the avery age of programmers
within MS is around 23 or 24 years. Usually, alcoholism starts
later, family "duties" start later, "settlement" comes later. I'd
like to know how they deal with that.

My OT view, georg

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[AG]

> "soft-eng" wrote:
> > I don't agree that Ada is likely to be particularly useful
> > for catching errors in a professional environment -- say 2-3%
> > of the actual errors at best.  If it's catching more than
> > that, I don't see how you can have good people.

Remember, those 2-3% just may account for, say,
50% of the effort. Let me give an example:

I had once to track down a bug which manifested
itself in a pop-up error screen telling the end-user
that "Default coercion is not available" [imagine
the amount of more or less sarcastic comments
caused by that]

Turned out that, way down in the call chain,
one thing expected a number. The other was
providing a string [That's the bug]. However,
the run-time system insisted by default on doing
the best it can converting from one to the other.
So that worked. Until some set of inputs
produced a string that could *not* be converted
to a number and the thing keeled over and died.

In fact, the authors of the string-producing
module were quite good at what they did
since that error happened very rarely under
some very special and unforeseen circumstances.
Can't blame them for missing it - everyone
makes mistakes or fails to catch them.
However, a strict (or even not-so-strict)
type system would have prevented
that problem from even making it past
compile-time. Not to mention the actual
field-release.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Alexander Kopilovitch]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3EC539FA.1040500@attbi.com>...
> soft-eng wrote:
> 
> > Other times are when the bug is very intermittent
> > and cannot be duplicated and you have to proceed
> > blindly, based on theories that are sometimes half-baked.
> 
> We call those Heisenbugs.  Converting a Heisenbug to a Bohrbug that you 
> can reproduce is often the first part of fixing the problem.
 
Perhaps it would be more accurate to use slightly softer name Schrodbugs,
reserving the name Heisenbugs to those particularly wicked ones, which
disappear at any attempt to investigate/localize them either using debugger
or inserting printouts.


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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

Linnea <dunno@none.yet> wrote in message news:<3EC532A8.A13C0342@none.yet>...
> > and don't touch it until
> > you know EXACTLY what you are doing.  Don't
> > be afraid of re-writing large chunks of
> > the code, but only if you have done the
> > homework of understanding the old code cold.
> 
> but here you are saying something I cannot agree with.
> 
> I have learnt my first lessons on refactoring in early 80's, long before
> I knew anything about version control and the other aids to support it,
> and almost two decades before I found Martin Fowler's book on
> refactoring. Ever since those first lessons, I've always considered
> refactoring - even when I didn't have a name for it - as the only way to
> ensure that I know exactly what I am doing, and to find out what exactly
> the code is doing.
> 
> You HAVE to touch the code IN ORDER TO understand it. You have to

I agree with that totally!

But while I am playing around with the old code making changes
to it to see what it's doing and breaking it in strange ways,
the original code is safe in version control.  When I have
a good handle on what's going on, I will dump my experimentation,
check out the code, and then touch the code with the intent
of a real modification.

> The only way to learn to read the code is my touching it, by refactoring
> it. If that's what you mean by "homework of understanding the old code
> cold", then we agree. However, I see no indication of you meaning it
> that way.

I do mean it that way!  The "homework" can hardly ever be done
by simple reading, if the code is complex.

I guess I didn't clarify that "touching the old code" meant
touching with the intent of making permanent changes!

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3EC539FA.1040500@attbi.com>...

> > But the truth is the choice of language has little to
> > do with situations like these.
> 
> No, no, NO!  Sorry. There are two nice software engineering terms 
> coupling and cohesion. Low coupling means that program modules have a 
> low degree of interaction with other modules. Cohesion means that code 

Well, ok, I will agree the choice of language does have something to
do with getting the design into implementation.  In which case,
unless you have been using the latest Ada versions, you
might want to check out these "OOP" thingies that C has evolved into!

Even prior to OOP, you could translate a good design into
C, but it did require more planning.  Ada, like other
languages before it, did provide ADTs, and taking
advantage of that is certainly a good idea if
you are working in Ada.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

"AG" <ang@xtra.co.nz> wrote in message news:<AFdxa.3805$3t6.46222@news.xtra.co.nz>...
> > "soft-eng" wrote:
> > > I don't agree that Ada is likely to be particularly useful
> > > for catching errors in a professional environment -- say 2-3%
> > > of the actual errors at best.  If it's catching more than
> > > that, I don't see how you can have good people.
> 
> Remember, those 2-3% just may account for, say,
> 50% of the effort. Let me give an example:
> 
> I had once to track down a bug which manifested
> itself in a pop-up error screen telling the end-user
> that "Default coercion is not available" [imagine
> the amount of more or less sarcastic comments
> caused by that]
> 
> Turned out that, way down in the call chain,
> one thing expected a number. The other was
> providing a string [That's the bug]. However,
> the run-time system insisted by default on doing
> the best it can converting from one to the other.
> So that worked. Until some set of inputs
> produced a string that could *not* be converted
> to a number and the thing keeled over and died.
> 
> In fact, the authors of the string-producing
> module were quite good at what they did
> since that error happened very rarely under
> some very special and unforeseen circumstances.
> Can't blame them for missing it - everyone
> makes mistakes or fails to catch them.
> However, a strict (or even not-so-strict)
> type system would have prevented
> that problem from even making it past
> compile-time. Not to mention the actual
> field-release.

C would catch that in a vanilla situation (assigning
an integer to a string pointer), so I
assume the situation was far from vanilla, in
which case it is possible for things like
that to happen in Ada.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[soft-eng]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3EC539FA.1040500@attbi.com>...
> soft-eng wrote:
> 
> > Other times are when the bug is very intermittent
> > and cannot be duplicated and you have to proceed
> > blindly, based on theories that are sometimes half-baked.
> 
> We call those Heisenbugs.  Converting a Heisenbug to a Bohrbug that you 
> can reproduce is often the first part of fixing the problem.

GC has made a class of these "Heisenbugs" go away that used to
result from dynamic memory management issues.  But it can add some
very mysterious bugs of its own -- e.g. if you use weak references,
and if a bug results from a logical error in there, it can be
extremely hard to reproduce.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[AG]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305161748.1735fc32@posting.google.com...

> C would catch that in a vanilla situation (assigning
> an integer to a string pointer),

Ah, a "pointer". That speaks volumes :-)

On top of that, did you really mean integer
to a [string] pointer or a pointer to a pointer?

> so I
> assume the situation was far from vanilla, in
> which case it is possible for things like
> that to happen in Ada.

No, that was a plain vanilla case like:
[not Ada of course]

F(x in number)
Y return string
z := F(Y);

Now, the critical problem is not the syntax
(or lack thereof) but the meaning.

Unfortunately, both the compile and the
run-time systems thought they could outguess
the programmer(s) who made that mistake.

It wouldn't be at all bad if it guessed wrong
but smelled fire and let someone do
the checking - but hey, that would be
strong typing, right?

Instead, it just went ahead and did some
conversions that it *thought* is ok to do.
Which happened to be ok except in
some special cases which programmers
had no control over.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[James S. Rogers]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305161748.1735fc32@posting.google.com...
> C would catch that in a vanilla situation (assigning
> an integer to a string pointer), so I
> assume the situation was far from vanilla, in
> which case it is possible for things like
> that to happen in Ada.

This is an interesting statement. You say that with no technical
detail.

One of the big differences between the Ada type system and the
C/C++/Java type systems regarding numeric types is the complete
lack of implicit conversion between numeric types in Ada.

My experience is that implicit language conversions make coding
very convenient. They also make coding somewhat unpredictable.
The worst example of that, in my experience, is PL1.

Another insidious problem with C style numerics is value overflows.
C, C++, and Java do not detect or flag numeric overflows or
underflows. For instance, a Java byte has a range of values of
-128 to 127. Calculations that overflow those ranges produce a
value wrapping. This behavior is appropriate for modular or
unsigned types. It is not appropriate for signed types.

The smaller integer types are provided to allow the programmer to
conserve memory. This conservation comes at a price; the need to
guard against value overflows. The result is that int and long are
generally used because it is easier to excuse a little extra memory
usage than to explain erroneous calculations.

I am sure you would agree that a good programmer will carefully
analyze the problem domain before using a short or a byte type.
The problem arises during program maintenance, when the
requirements change and a value needs to handle values beyond
the range of a short or a byte. The program will still compile and
run without flagging errors. The results of calculations will, however
reveal serious errors.

Ada's strong typing allows you to define small types with limited
value ranges. On the surface this may seem to be just what you
get from the C family of languages. Strong typing does make a
difference here. Ada signed numeric types do not exhibit value
roll over. Instead, a run-time exception will be raised if an out of
range value is calculated. To fix the maintenance problem described
above in Ada you simply replace the original numeric type definition
with one that fits the new requirements. This typically means changing
one line in one file.

Fixing the problem in C requires a much longer search through the
source. You must change all the variable declarations in the file
containing the function(s) that need to use the larger type in a
calculation. You then need to change all the parameters passed
to those functions, particularly if they are passed by reference.
All those changes require a very carefully crafted and executed
test suite to confirm that the job was done properly.  Even the
testing is simplified due to the Ada strong type model.

Jim Rogers

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada

[tmoran]

> You didn't count the size of the mouse driver. In DOS everything
> had to come out of the addressable 1 MB of memory.
  With a little coaxing, the old T3100 turned on.  MSMOUSE.SYS,
dated 10-10-85, is 7003 bytes, not 35K.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Martin Dowie]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305160453.29c0c4af@posting.google.com...
> The point I have been trying to make is that Ada catches
> a small extra subset of errors (and compared to modern C, C++
> or Java, the "extra" might be non-existent).  Ada or not,

Nope - a while back we did a comparison using a rather well known
study into the root causes of programming errors in 'C' (I'll reply with
the exact reference when I get to work on Monday, if you want) Roughly
50% of the errors either could not occur in Ada or would be caught by the
compiler. C++ also (almost by definition) contains the same root causes
as 'C'.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Larry Kilgallen]

In article <ba4s5p$q92$1@hercules.btinternet.com>, "Martin Dowie" <martin.dowie@no_spam.btopenworld.com> writes:
> "soft-eng" <softeng3456@netscape.net> wrote in message
> news:9fa75d42.0305160453.29c0c4af@posting.google.com...
>> The point I have been trying to make is that Ada catches
>> a small extra subset of errors (and compared to modern C, C++
>> or Java, the "extra" might be non-existent).  Ada or not,
> 
> Nope - a while back we did a comparison using a rather well known
> study into the root causes of programming errors in 'C' (I'll reply with
> the exact reference when I get to work on Monday, if you want) Roughly
> 50% of the errors either could not occur in Ada or would be caught by the
> compiler. C++ also (almost by definition) contains the same root causes
> as 'C'.

In particular because of the ability to readily "drop into C" from
a C++ compiler.

Raise your hand if an instance of dropping into C would cause
those in a code review to prevent a project from being put into
production at your shop.

Hmmm, my terminal emulator shows no hands :-)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

Preben Randhol wrote:
> What is you definition of stable? Win-32 has not had a good record of
> stability at all.

That is pre-nt4. In general windows from nt4 onwards has been good enough
for office use.

Windows 2000 has been quite solid. Windows XP is better.


greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Well, I'm not going to argue the point. You believe based on some personal
experience that it is only 2% to 3% of the errors that would be caught/fixed
by Ada. My metrics collected over 10 years indicate that we got a factor of
four decrease in defects by switching to Ada. There may be some domain
differences or perhaps you believe that our team of programmers were all
incompetent, but whatever the case, my scientific evidence fails to convince
you. I can't possibly overcome that with more science or more argument.
Believe what you like and I hope you work for my competitors. :-)

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

soft-eng <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305160453.29c0c4af@posting.google.com...
>
> With professional programmers, the "type errors" are
> very few anyway (I estimated 2-3% of all errors,
> so if a bug-list has 100 items on it, and if more than
> 2-3 are type-safety issues, I would worry about
> programmer quality.)
>
> So the tradeoff is, possibly a bug or two caught
> at compile time rather than during testing, versus
> using a very large language that was created by fiat.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Bjorn Reese]

Shayne Wissler wrote:

> I think what it indicates is that the development methods used are
> brittle--which leads to the brittle code. If you see the secondary bug to
> primary bug ratio consistently rising, the first thing to do is ask
> questions about who is managing the project, not about the software itself.
> Even the best software will have bad ratios if the people working on it are
> sloppy.
[...]
> A lot of software does deserve to be completely rewritten. But that should 
> be apparent by how slow you have to go when adding features, not by 
> ever-cascading bugs. On the contrary, if you see bugs spiraling out of 
> control, that's evidence that you don't want that particular team and/or 
> its management to undertake rewriting the system.

While sloppiness, or similar human traits, may be a contributing factor,
I think that it is too simplistic to attribute cascading defects to this
single factor. Nor do I believe that the situation will improve in general
by replacing the people.

The major factor, in my experience, to cascading defects is increasing
cognitive complexity of the system, usually combined with insufficient
staffing. The problem is that no matter how clever your staff is, they
will eventually reach a break-even point where the cognitive complexity
of the system exceeds their mental capabilies. Blaming or replacing the
staff will not decrease cognitive complexity.

If you replace the staff, you also risk that the new people will simply
make the same mistakes that the old staff did. Assuming that at least
some from the old staff is capable of learning from their errors, they
may be in a better position to rewrite the system. They also have a
broader understanding of the required domain knowledge.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Wesley Groleau]

>>The point I have been trying to make is that Ada catches
>>a small extra subset of errors (and compared to modern C, C++
>>or Java, the "extra" might be non-existent).  Ada or not,
> 
> Nope - a while back we did a comparison using a rather well known
> study into the root causes of programming errors in 'C' (I'll reply with
> the exact reference when I get to work on Monday, if you want) Roughly
> 50% of the errors either could not occur in Ada or would be caught by the
> compiler. C++ also (almost by definition) contains the same root causes
> as 'C'.

Or (at the risk of irritating those who've
seen me post this before) read: "C Traps and
Pitfalls"  NONE of the Traps and Pitfalls
in the first one-third of the book would
ever happen in Ada.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Tarjei T. Jensen wrote:
> That is pre-nt4. In general windows from nt4 onwards has been good enough
> for office use.

pre-nt4? There has been several win-32 releases post-nt that are not
stable. Not even for Office use.

But for server use win-32 is not stable.

> Windows 2000 has been quite solid. Windows XP is better.

Well, Windows XP has given me BSOD 5-6 times.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert I. Eachus]

Bjorn Reese wrote:

> The major factor, in my experience, to cascading defects is increasing
> cognitive complexity of the system, usually combined with insufficient
> staffing. The problem is that no matter how clever your staff is, they
> will eventually reach a break-even point where the cognitive complexity
> of the system exceeds their mental capabilies. Blaming or replacing the
> staff will not decrease cognitive complexity.

Right, once the code gets too complex, all you can do is either freeze 
it totally, if that is acceptable, or start with a fresh sheet of paper.

If the system as a whole has low coupling, it is often possible to use 
that fresh sheet of paper to rewrite a small part of the system where 
the bugs and complexity are concentrated.  However, often the "bad" 
modules do have high coupling, and the only choice is to can the whole 
system.

By the way, if you find that one of your programmers is creating an 
undue share of follow-on bugs, get that guy's hands off the code 
immediately.  If you can put the hot-shot in charge of some stand alone 
utilities great, otherwise you may have to fire him or her.  (Although 
hot-shot programmers are almost alway male.)  I have never had to fire 
anyone in this situation.  Assign them to documenting what their 
existing code, or to write test scripts, and they are gone so fast that 
your head will spin.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[WinGuru]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbccqiq.rve.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Tarjei T. Jensen wrote:

> > Windows 2000 has been quite solid. Windows XP is better.
>
> Well, Windows XP has given me BSOD 5-6 times.
>

In how much time under what conditions with what type or quality of hardware
and with what type of drivers?  Have you made any particular analysis of why
there was the crash or did you just blame MS without any real clue as to
what went wrong?  Seriously, do you have the post-mortem analysis?   Are you
absolutely positive that you can ascribe the error to Windows and MS and not
some flaky hardware or device driver?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

WinGuru wrote:
> In how much time under what conditions with what type or quality of hardware
> and with what type of drivers?  Have you made any particular analysis of why
> there was the crash or did you just blame MS without any real clue as to
> what went wrong?  Seriously, do you have the post-mortem analysis?   Are you
> absolutely positive that you can ascribe the error to Windows and MS and not
> some flaky hardware or device driver?

No, no flaky hardware and all M$ device drivers signed and all. Linux
has not crashed or complained once so it is a M$ Windows problem.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada

[achrist]

tmoran@acm.org wrote:
> 
> > You didn't count the size of the mouse driver. In DOS everything
> > had to come out of the addressable 1 MB of memory.
>   With a little coaxing, the old T3100 turned on.  MSMOUSE.SYS,
> dated 10-10-85, is 7003 bytes, not 35K.

OK.  You can believe that size on disk = amount of memory used, and
I'll believe that I did the experiment of building and running the
same program with and without mouse support and saved about 35kb.


Al

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[AG]

"WinGuru" <anonymous> wrote in message news:3ec67910$1@nntp0.pdx.net...

It wasn't me you replied to but let me chip-in with an example:

> In how much time under what conditions with what type or quality of
hardware
> and with what type of drivers?  Have you made any particular analysis of
why
> there was the crash or did you just blame MS without any real clue as to
> what went wrong?  Seriously, do you have the post-mortem analysis?   Are
you
> absolutely positive that you can ascribe the error to Windows and MS and
not
> some flaky hardware or device driver?

I happen to run a multi-boot setup on a reasonably new, reasonably
modern machine (all the latest patches and drivers installed).
It has a regular plain-vanilla dial-up modem. Now, one of the systems
installed (W98) has absolutely no trouble using it. Works fine. Another
(W2K) has all sorts of problems even connecting. When it does, it
connects at a lower speed and tends to drop the connection depending
(apparently) on the current weather in Antarctica.

Now - we have exactly the same hardware, exactly the same locality,
phone line etc etc. One system works just fine, thank you. The other
is a total flop handling a simple connection. Who would *you* blame?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[tmoran]

>Windows 2000 has been quite solid. Windows XP is better.
  Having now spent the better part of two days trying to resuscitate
a W2k system that died for no apparent reason, I beg to differ.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada

[tmoran]

> >   With a little coaxing, the old T3100 turned on.  MSMOUSE.SYS,
> > dated 10-10-85, is 7003 bytes, not 35K.
>
> OK.  You can believe that size on disk = amount of memory used, and
> I'll believe that I did the experiment of building and running the
> same program with and without mouse support and saved about 35kb.
  With no mouse driver in config.sys (or autoexec.bat), MEM says
580,672 bytes available, and an old program that reports on its
available data area says 271K.  A program that requires a mouse
quits with a message that no mouse is installed.
  With "device=msmouse.sys" added to config.sys, MEM says
575,264 bytes available, and the old program says it has 265K for data.
The program that wants a mouse runs fine.
  Perhaps you had a fancier mouse driver?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

Preben Randhol wrote:
> Tarjei T. Jensen wrote:
> > That is pre-nt4. In general windows from nt4 onwards has been good
enough
> > for office use.
>
> pre-nt4? There has been several win-32 releases post-nt that are not
> stable. Not even for Office use.
>
> But for server use win-32 is not stable.

It is. We have several database, file and print servers. All running windows
2000. As far as reliability is concerned, they work good enough.

But then we don't install every piece of software on the internet on these
machines.

> > Windows 2000 has been quite solid. Windows XP is better.
>
> Well, Windows XP has given me BSOD 5-6 times.

Then we ask: what software have you installed on this machine?


greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

"tmoran@acm.org" wrote:
 >Windows 2000 has been quite solid. Windows XP is better.
>   Having now spent the better part of two days trying to resuscitate
> a W2k system that died for no apparent reason, I beg to differ.

We have several thousand win2k PCs and around two hundred servers with
win2k. They all work within expectations.

The rule is: be careful about what you install on your PC.

Lets face it: the only reason Unix is more stable than windows, is because
Unixes does less.

greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

AG wrote:

> I happen to run a multi-boot setup on a reasonably new, reasonably
> modern machine (all the latest patches and drivers installed).
> It has a regular plain-vanilla dial-up modem. Now, one of the systems
> installed (W98) has absolutely no trouble using it. Works fine. Another
> (W2K) has all sorts of problems even connecting. When it does, it
> connects at a lower speed and tends to drop the connection depending
> (apparently) on the current weather in Antarctica.
> 
> Now - we have exactly the same hardware, exactly the same locality,
> phone line etc etc. One system works just fine, thank you. The other
> is a total flop handling a simple connection. Who would *you* blame?

I remember it was said that Windows (3.1) makes i386 out of any i486. And 
that was just about 3 Windows. Now, 2000 Windows in one box, it is much too 
much! (:-)) 

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Tarjei T. Jensen wrote:
> Lets face it: the only reason Unix is more stable than windows, is because
> Unixes does less.

By what do you mean: does less?

A stable OS should not be crashed by the applications it runs.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Tarjei T. Jensen wrote:
> 
> It is. We have several database, file and print servers. All running windows
> 2000. As far as reliability is concerned, they work good enough.

Good enough?

>> Well, Windows XP has given me BSOD 5-6 times.
> 
> Then we ask: what software have you installed on this machine?

First time I got a BSOD was doing a Window Update. But it doesn't matter
what software you run. The OS should not crash because of the software
you run on it. But at any rate I don't run anything fancy now a whole
lot as I use the XP only for about 20% of my work.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Preben Randhol wrote:
> what software you run. The OS should not crash because of the software
> you run on it. But at any rate I don't run anything fancy now a whole
                                                            ^^^
                                                            nor

> lot as I use the XP only for about 20% of my work.


-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

"Preben Randhol"  wrote:
> By what do you mean: does less?

Windows does a LOT more than any Unix does.

> A stable OS should not be crashed by the applications it runs.

Then we don't have any stable operating systems.


greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

"Preben Randhol"
> Good enough?

Excellent concept.

> First time I got a BSOD was doing a Window Update. But it doesn't matter
> what software you run. The OS should not crash because of the software
> you run on it. But at any rate I don't run anything fancy now a whole
> lot as I use the XP only for about 20% of my work.

And there should be no war, everybody should have enough food, clean water,
healtcare and a home.


greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Tarjei T. Jensen wrote:
> "Preben Randhol"  wrote:
>> By what do you mean: does less?
> 
> Windows does a LOT more than any Unix does.

What does it do that Unix doesn't?


-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Tarjei T. Jensen wrote:
> 
> "Preben Randhol"
>> Good enough?
> 
> Excellent concept.

I was only wondering as you said in one post it was stable and in the
next you say good enough. So what is the definition of stable?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dale Stanbrough]

Tarjei T. Jensen wrote:

> "Preben Randhol"  wrote:
> > By what do you mean: does less?
> 
> Windows does a LOT more than any Unix does.


I presume you mean "Windows as an operating system" rather
than "Windows as a platform with lots of applications".

I don't know that much about Windows; what does it do more
than Unix?

Dale

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Pascal Obry]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Tarjei T. Jensen wrote:
> > "Preben Randhol"  wrote:
> >> By what do you mean: does less?
> > 
> > Windows does a LOT more than any Unix does.
> 
> What does it do that Unix doesn't?

I thought it was clear from this thread. It crashes :)

Could not resit, even if this thread is OT, and BTW I found Windows XP an
excellent system (far better than 2000). Bashing Windows just for fun is not
a good thing.

Now this thread should certainly be moved to another NG.

Pascal.

-- 

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

"Dale Stanbrough"  wrote:
> I presume you mean "Windows as an operating system" rather
> than "Windows as a platform with lots of applications".

That is correct.

Something to ponder: Until we deployed NT4, the users were constantly
complaining about the operating system and wanting something better. After
NT4, there have been no complaints.

> I don't know that much about Windows; what does it do more than Unix?

Its simply too much to list everything.

Some things: DDE, DCOM, printing, HTML applications (HTA), jet, various APIs
(mapi, odbc, etc). Once you start digging, you find a lot of interesting
things. The object stuff is wonderful compared to what we have in Unix.

.Net is an extension of DCOM. People ar excited about .Net because it is an
excellent idea.

BTW. Until Gnome came along, I've spent 10 years trying to get Unix people
to understand that support for printing does not equal lpd support. With
Gnome comes the first real understanding of user needs into the Unix
universe.

The main problem with microsoft is they start with something and then just
stop without finishing properly or the project continues in a completely
haphazard manner oblivious to user needs.

BTW: You should read Alan Cooper's "The Inmates Are Running The Asylum". He
will change how you look at software development. He will help you focus. On
the other hand; he is quite annoying and not always right.

greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

Tarjei T. Jensen wrote:
> Some things: DDE, DCOM, printing, HTML applications (HTA), jet, various
APIs
> (mapi, odbc, etc). Once you start digging, you find a lot of interesting
> things. The object stuff is wonderful compared to what we have in Unix.

I forgot the user authentication and access control stuff. You get the PC
into a NT domain and windows takes care of everything. It works better on
Netware of course.

greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dale Stanbrough]

Tarjei T. Jensen wrote:

> I forgot the user authentication and access control stuff. You get the PC
> into a NT domain and windows takes care of everything. It works better on
> Netware of course.


I was always disappointed when Apple dropped OpenDoc - apparently it 
was an excellent object model. I don't think anything has taken its
place :-(

BTW the unix I run on my mac has excellent support for printing, 
and lots of interesting other stuff. Perhaps you are comparing 
windows with the wrong Unix...

(i'm not in love with unix - it seems very old in many ways,
and it seems clear that the windows people must have learnt something
- perhaps this is optimistic though).

dale

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dale Stanbrough]

Tarjei T. Jensen wrote:

> I forgot the user authentication and access control stuff. You get the PC
> into a NT domain and windows takes care of everything. It works better on
> Netware of course.


I was always disappointed when Apple dropped OpenDoc - apparently it 
was an excellent object model. I don't think anything has taken its
place :-(

BTW the unix I run on my mac has excellent support for printing, 
and lots of interesting other stuff. Perhaps you are comparing 
windows with the wrong Unix...

(i'm not in love with unix - it seems very old in many ways,
and it seems clear that the windows people must have learnt something
- perhaps this is optimistic though).

dale

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

True, but with an OS this is achievable. It is possible to build an OS that
won't crash because of the particular application being run on it. (Or at
least crash so infrequently as to be practically the same thing).

MDC

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

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

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Tarjei T. Jensen <tarjei@online.no> wrote in message
news:TmIxa.13310$8g5.206471@news2.e.nsc.no...
>
> And there should be no war, everybody should have enough food, clean
water,
> healtcare and a home.
>

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[soft-eng]

mcq95@earthlink.net (Marc A. Criley) wrote in message news:<254c16a.0305160930.40bb42f9@posting.google.com>...

> Assuming an Ada-coded system where proper usage has been made of
> strong typing...
> 
> I'm not positive what you mean by "type errors"--I see two potential
> interpretations that are relevant to Ada:
> 
> 1) Type conflicts
> 2) Range errors
> 
> The first, type conflicts, are fixed almost without thought by an Ada
> programmer, since the program won't compile until they're are. If I
> swap Lat and Lon in a procedure call, or mis-assign a "Plan_Number"
> value to an "Engagement_Number" variable, it's immediately caught and
> I fix it--I don't even bother to count that as a defect--so it never
> makes it onto a bug list--that's just a momentary "oops" on my part.
> 
> What happens when you swap nLat and nLong in a function call? You get
> an object file, I get a compile error.
> 
> When does it get noticed? When you run a test, when I look at the
> compiler's output.
> 
> These little type conflicts are always caught and fixed, without  the
> Ada programmer even thinking about it--these errors just never make it
> into the test regime, because they've been long since dealt with.
> 
> Range errors get automatically detected at run-time in an Ada-coded
> system, where they can be as simple as an off-by-1 error, and who
> hasn't dealt with that one?
> 
> What happens when your indexing is off by one? The program may crash,
> or it may not. It may corrupt neighboring data, or it may not. It may
> often exhibit erratic behavior, or it may do so intermittently.
> 
> When my indexing is off by one an exception is raised and I
> immediately know there's a problem that I need to identify and fix.
> 
> ------------------------------
> 
> But granting this low estimation of "type error" occurrence, that
> means many of the remaining errors would be designated as "logic
> errors", and it's been suggested that this is the type of the majority
> of errors (which I believe is true), and that neither Ada nor any
> other language is inherently capable of preventing logic errors--also
> true.
> 
> So your assertion appears to be that 1) most software errors are logic
> errors, and 2) Ada's strong typing only helps prevent an uncommon type
> of error (type errors), therefore the effort required to work with or
> around Ada's strong typing adds no value to the detection and
> correction of the predominant type of error (logic).
> 
> Okay then, so how _does_ one know they've got a logic error in their
> code?
> 
> The error is going to manifest itself in one of three ways:
> 1) The program runs but the functionality isn't as desired. This may
> be obvious (it immediately exits), or not (a cumulative microsecond
> drift that becomes noticeable only after a couple days caused by a
> counter not getting reset).
> 2) The program crashes at some point.
> 3) The program runs but behaves erratically, and this behavior may be
> intermittent.
> 
> In the third case, clearly Ada and strong typing would likely be of
> benefit here, since such erratic behavior may arise from "type errant"
> run-time behavior that was initiated by executing the wrong logic.
> Pretty much every time an unexpected exception occurs in an Ada-coded
> program, the cause is a logic error that causes the execution of code
> that is an inconsistent internal state (because that code wasn't
> supposed to be executed!). Stale data values may be referenced,
> garbage values may be in variables, and as soon as Ada does a range
> check on them, everything halts--and you can go track down the
> problem.
> 
> In the second case, one has to determine what led to the crash: Was it
> an immediate crash at the point of error? E.g., trying to write
> through a null pointer? Or was the program getting messed up
> internally, but gave no indication and continued to run for awhile
> before the cascade of errors got so bad that it crashed? If the
> former, Ada's no better or worse than any other language in which that
> occurs, but if the latter, you've just got case #3 again, but where it
> does eventually terminate.
> 
> In the first case, things like peer reviews and formal inspections
> have proven to be of measurable assistance.
> 
> > So the tradeoff is, possibly a bug or two caught
> > at compile time rather than during testing, versus
> > using a very large language that was created by fiat.
> 
> Again, you're not counting the errors that _never_ occur _because_ of
> strong typing. (And you've also been ignoring all mention of how the
> type information embedded within Ada software due to its strong type
> model also aids correctness and maintainability.) Because C/C++
> doesn't flag type conflicts among values having the same base type
> (int or float) and also does implicit type coercion, you never see
> such conflicts when you're compiling your software, and by the time
> they manifest themselves--in test--they've become logic errors: "I
> meant to use Latitude rather than Longitude here."

That sounds to me an unrealistic level of discipline: subtyping
to the extent that all lattitudes and longitudes (and things
along that line) are separate types.  More common usage is that both
will be just real numbers (floats), whatever the language chosen.  So
academically this is an advantage, in practice it won't be there.
(Similarly, as other messages point out, in practice, any usage of
subranges you will see in Ada is just what you have in C++,
int8, int16, int32.  Though in a classroom setting it may sound like
a great advantage to be able to have my own subranges of integers
from 1 to 9102 each and every time I need it...)

But in any case, you sure can create Lattitude and Longitude classes
in C++ as well if you are so disciplined, so the advantage you are
pointing out is not very clear.

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[James S. Rogers]

"soft-eng" <softeng3456@netscape.net> wrote in message
news:9fa75d42.0305181502.53703035@posting.google.com...
> That sounds to me an unrealistic level of discipline: subtyping
> to the extent that all lattitudes and longitudes (and things
> along that line) are separate types.  More common usage is that both

This is the common level of discipline in Ada programming. The reason
it has become common is that the benefits provided by these distinct
types far exceed the effort required to create them.

> will be just real numbers (floats), whatever the language chosen.  So
> academically this is an advantage, in practice it won't be there.
> (Similarly, as other messages point out, in practice, any usage of
> subranges you will see in Ada is just what you have in C++,
> int8, int16, int32.  Though in a classroom setting it may sound like
> a great advantage to be able to have my own subranges of integers
> from 1 to 9102 each and every time I need it...)

Ada user defined numeric types are more than simply the different
sized ints and floating point types in C and C++. C and C++ give you
no easy way to define a type that truly fits the problem. For instance,
if you are monitoring voltages that must always be between -5.0 and
+5.0 volts, you can define the following type:

type Voltages is digits 15 range -5.0..5.0;

This defines a floating point type with a 15 decimal digits of
precision and a valid range of values from -5.0 through 5.0.
Any attempt to evaluate a value outside that range will result in
a Constraint_Error exception being raised.

Note that the C and C++ numeric types like int8, int16, uint32,
provide much less help in matching your needs in this case.
Similarly, float and double do not help in ensuring that the data
is correctly within range. Neither to they ensure 15 decimal digits of
precision.

>
> But in any case, you sure can create Lattitude and Longitude classes
> in C++ as well if you are so disciplined, so the advantage you are
> pointing out is not very clear.

Yes, C++ does allow you to create such classes. Upon creating those
classes you also need to define all the appropriate numeric operators
for the class, as well as the logic for restricting the valid values to a
domaine-valid range. This takes a LOT more discipline and time
than achieving the same thing in Ada. The Voltages type defined above
gets all the floating point operators defined for it automatically by the
compiler. It also gets all the range checking defined automatically by the
compiler.

The Ada solution does take a bit more discipline than simply using the
predefined float or long_float types. The difference in the source code
is minimal. The real discipline comes in designing data types to satisfy
the requirements of your problem domaine. It takes some work and some
thought. This is the same level of work and thought that is needed in any
language to produce a reliable, safe, efficient design.

Ada also makes safe I/O for user defined numeric types safe and easy.
The standard generic package Ada.Text_IO.Float_IO may be instantiated
for any floating point type.

  package Voltage_IO is new Ada.Text_IO.Float_IO(Voltages);

The I/O routines in that instantiation will validate data entry over the
allowed range of values for type Voltages. Any attempt to enter an
out-of-range value will result in the Constraint_Error exception being
raised. All you need to do is write the appropriate exception handlers
for your application.

Not only is this kind of discipline common in most Ada programming
teams, many teams set up coding guidelines prohibiting the use of the
pre-defined data types.

For junior Ada programmers this approach causes problems. They find
the compiler keeps complaining about improper mixing of types. Even
the junior Ada programmers find, however, that once the program
compiles it has far fewer logic errors caused by inappropriate mixing
of variables in a calculation. This saves much more time in debugging
than was consumed in compilation. Senior Ada programmers seldom
encounter such a difficulty during compilation. They are used to the
discipline needed to avoid most compilation diagnostic messages.

Jim Rogers

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

James S. Rogers wrote:
> Another insidious problem with C style numerics is value overflows.
> C, C++, and Java do not detect or flag numeric overflows or
> underflows.

C and C++ have undefined behavior on overflows. It is perfectly
legal for an implementation to detect these and report an error.
I don't know of any which do, however. It is to be noted that by
default, GNAT has overflow checking disabled as well.

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Robert I. Eachus]

soft-eng wrote:

> That sounds to me an unrealistic level of discipline: subtyping
> to the extent that all lattitudes and longitudes (and things
> along that line) are separate types.  More common usage is that both
> will be just real numbers (floats), whatever the language chosen.  So
> academically this is an advantage, in practice it won't be there.

You still refuse to "get it."  If I want to declare Latitude as its own 
floating-point type in Ada I would say:

type Latitude is digits 7 range -90.0..90.0;

In actual practice I would be more likely to declare it to be a 
fixed-point type with a declaration like:

type Latitude is digits 8 delta 0.000001 range -90.0..90.0;

or if I wanted to represent hundreths of a second exactly:

type Latitude is delta 1.0/360000 range -90.0..90.0;
for Latitude'Small use 1.0/360000;

However, if I wanted to make it a subtype of Float for some reason, I 
would say:

subtype Latitude is new Float range -90.0..90.0;

For longitude you need a larger range:

type Longitude is digits 7 range -180.0..180.0;
-- or
type Longitude is digits 9 delta 0.000001 range -180.0..180.0;
-- or
type Longitude is delta 1.0/360000 range -180.0..180.0;
for Longitude'Small use 1.0/360000;
-- or
subtype Longitude is new Float range -180.0..180.0;

Now the smallest of these in number of characters is defining a new 
floating point type.  So if you laboriously type using hunt and peck, 
that might influence you to use the new floating point type.  I assure 
you that the fact that it takes 15 more characters than using a floating 
point type has nothing to do with my preference for the decimal version. 
  I would use whatever approach is most appropriate for the problem. 
But it wouldn't occur to me to make Latitude and Longitude subtypes of 
Float.

> (Similarly, as other messages point out, in practice, any usage of
> subranges you will see in Ada is just what you have in C++,
> int8, int16, int32.  Though in a classroom setting it may sound like
> a great advantage to be able to have my own subranges of integers
> from 1 to 9102 each and every time I need it...)

I will say it one last time.  NO YOU WON'T.  You are much more likely to 
see programmers new to Ada using predefined types all over the place 
before they finally "get it." And start using programmer defined types 
because they are easier and better. There is zero benefit to using 
predefined types in Ada for much other than indexes of strings, SOME 
loop counters, and some other arrays.  It would defeat the whole purpose 
of having all these safety features if they were too costly to use, in 
either programmer's time or in program execution time.  Using the safety 
features in Ada saves both, even if you never actually need that safety 
for some particular type.

If in Ada I am iterating over some array Foo, I could go look up the 
type declaration for Foo, find what its range was, and the type of that 
range, and then write some code that will be error prone if the 
declaration of Foo is ever changed.  Or I can write:

for I in Foo'Range loop ... end loop;

or if for some reason I need to go backwards:

for I in reverse Foo'Range loop ... end loop;

I don't have to think about what that range is, whether it is static or 
dynamic, or whether it is an 8-bit integer, a 32-bit integer, a 
character type, or the colors of the rainbow.  As long as I use Foo(I) 
to reference elements of Foo, not only do I know they are safe, but the 
compiler does too.  So no range checking is needed at run-time and I 
still get that safety.

> But in any case, you sure can create Lattitude and Longitude classes
> in C++ as well if you are so disciplined, so the advantage you are
> pointing out is not very clear.

There are no such programmers.  All programmers are human, at least so 
far, and they have a limited capacity to juggle things in their head. 
Adding Lattitude and Longitude classes in C++ will increase the number 
of things that a programmer has to work with, so they reduce the 
complexity of problem that the programmer can easily handle.  In Ada, 
once I declare Latitude and Longitude, I can forget all the details.

All I have to remember is that there are two types with those names, and 
the compiler will let me know if I ever make a mistake trying to assign 
a Latitude value to a Longitude object, or vice-versa.  You will notice 
that I could make a mistake if I assigned the aggregate: (23.347,45.103) 
to an object with Lattitude and Longitude fields. The right thing to do 
is write: (Lattitude'(23.347), Longitude'(45.103)) but I will admit that 
there are programmers who will be that lazy.  Of course the system 
designers can fight back by making the Lattitude and Longitude types 
private so that they don't have literals visible to users of the type. 
But that is a different discussion.

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Wesley Groleau]

> Not only is this kind of discipline common in most Ada programming
> teams, many teams set up coding guidelines prohibiting the use of the
> pre-defined data types.

That is one place where I _have_ seen an "unrealistic
level of discipline."  Since Positive was a prohibited
predefined data type, and since String is indexed by
Positive, String was prohibited, too (guilt by association!)

Sad the gyrations I saw code go through in order
to do String things with arrays of Characters
indexed by a "portable" type.

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Anders Wirzenius]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:wzWxa.88930$cO3.6074665@bgtnsc04-news.ops.worldnet.att.net...

> Ada user defined numeric types are more than simply the different
> sized ints and floating point types in C and C++. C and C++ give you
> no easy way to define a type that truly fits the problem. For instance,
> if you are monitoring voltages that must always be between -5.0 and
> +5.0 volts, you can define the following type:
>
> type Voltages is digits 15 range -5.0..5.0;
>
> This defines a floating point type with a 15 decimal digits of
> precision and a valid range of values from -5.0 through 5.0.
> Any attempt to evaluate a value outside that range will result in
> a Constraint_Error exception being raised.

Marc A. Criley <mcq95@earthlink.net> showed in message
news:254c16a.0305091127.42ec7b21@posting.google.com

an even better way to do that, viz.:

   Extreme_Voltage : constant := 5.0;
   type Voltages is digits 15 range -Extreme_Voltage..+Extreme_Voltage;

Anders

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Hyman Rosen wrote:

>C and C++ have undefined behavior on overflows.

AFAIK only for signed types.

>It is perfectly
>legal for an implementation to detect these and report an error.

And it will do only if the machine is "limited" this way.


Vinzent.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Ole-Hjalmar Kristensen]

Hyman Rosen <hyrosen@mail.com> writes:

> Marc A. Criley wrote:
> > Given the effort it saves, why not code in Ada?
> 
> Yep. C++ also gives you some of the same advantages.
> For example, iteration over containers looks like
>      for (i = c.begin(); i != c.end(); ++i)
> so you get the same lack of overruns. But Ada has a
> lot more of this type of stuff.
> 

Yes, provided you get your termination condition of the loop right.
The C for loop is much more like the Ada
loop ... exit when ... end loop construct.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Ole-Hjalmar Kristensen wrote:
> Hyman Rosen <hyrosen@mail.com> writes:
>>     for (i = c.begin(); i != c.end(); ++i)
> 
> Yes, provided you get your termination condition of the loop right.

Huh? That's the termination condition, right there in the middle.
When you loop over a container, you start at begin(), and quit at end().

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Vinzent Hoefler wrote:
> Hyman Rosen wrote:
>>C and C++ have undefined behavior on overflows.
> 
> AFAIK only for signed types.

Yes, so? The unsigned types are like Ada's modular types,
with explicitly defined wraparound semantics. I dare say
that if C had not had unsigned types, Ada would never have
gotten modular types.

>>It is perfectly
>>legal for an implementation to detect these and report an error.
> 
> And it will do only if the machine is "limited" this way.

I'm sorry but I don't understand what that sentence means.
What machine? What does limited mean, and why is it in scare quotes?
As far as I know, Ada and C can run on the same machines, so if Ada
can have overflow checks, C can too.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Tarjei T. Jensen wrote:
> Its simply too much to list everything.
> 
> Some things: DDE, DCOM, printing, HTML applications (HTA), jet, various APIs
> (mapi, odbc, etc). Once you start digging, you find a lot of interesting
> things. The object stuff is wonderful compared to what we have in Unix.

So you don't have printing on a Unix? In another post you said user
authentication and access. You mean unix doesn't have that either? I
don't know what you mean by HTML applications when you talk about the
Windows OS.

> .Net is an extension of DCOM. People ar excited about .Net because it is an
> excellent idea.

And this is related to NT4 how?

> BTW. Until Gnome came along, I've spent 10 years trying to get Unix people
> to understand that support for printing does not equal lpd support. With
> Gnome comes the first real understanding of user needs into the Unix
> universe.

Now you are not talking about the OS, but about the applications. Either
you have to compare Windows as a desktop versus Linux or some other Unix
desktop or as server to server. You cannot compare apples, bananas and
pinapples.

Here, at the universe the Windows network servers are run on Unix
machines (using Samba).

> The main problem with microsoft is they start with something and then just
> stop without finishing properly or the project continues in a completely
> haphazard manner oblivious to user needs.

That I agree on :-)

> BTW: You should read Alan Cooper's "The Inmates Are Running The Asylum". He
> will change how you look at software development. He will help you focus. On
> the other hand; he is quite annoying and not always right.

Will do :-)

But this is Ada group, so I'll stop this discussion for my part here.
Have been down this road so many times before :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Dale Stanbrough wrote:
> (i'm not in love with unix - it seems very old in many ways,
> and it seems clear that the windows people must have learnt something
> - perhaps this is optimistic though).

Well the internet is also old, so your point is? I agree that there are
a lot of things that could be done differently, but it all boils down
to who is the user?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Pascal Obry wrote:
> Bashing Windows just for fun is not
> a good thing.

Implying that I do?

> Now this thread should certainly be moved to another NG.

Agree.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Preben Randhol]

Hyman Rosen wrote:
> C and C++ have undefined behavior on overflows. It is perfectly
> legal for an implementation to detect these and report an error.
> I don't know of any which do, however. It is to be noted that by
> default, GNAT has overflow checking disabled as well.

Just to make it clear, when you say overflows you mean numeric
overflows. Besides GNAT has division by zero checking is on by
default.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Hyman Rosen wrote:

>Yes, so? The unsigned types are like Ada's modular types,
>with explicitly defined wraparound semantics.

Yes, but that ain't Ada. In Ada you have to exeplicitely tell the
compiler that you really want to do it and leave the burden to
implement it to the compiler (and that sometimes might be not that
easy as it looks at the first glance).

>I dare say
>that if C had not had unsigned types, Ada would never have
>gotten modular types.

I doubt that. C just got modular types because it was convinient and
natively supported by the machine.

Disclaimer: I'm not old enough to know the PDP-7 by heart. ;)

>>>It is perfectly
>>>legal for an implementation to detect these and report an error.
>> 
>> And it will do only if the machine is "limited" this way.
>
>I'm sorry but I don't understand what that sentence means.
>What machine?

The underlying machine the code is compiled for.

>What does limited mean, and why is it in scare quotes?

"Limited" in the sense that it is not able to wrap around signed
integers without signalling some overflow exception or similar. That's
the one and only reason this "check" is permitted in C.

Another reason is that there might be some machines that don't use the
two's-complement, so the whole operation is simply undefined behaviour
in that case. Or at least not that what you've expected.

So in C the answer is simple: Don't overflow signed types, the result
may not be defined. Nice try, but I wouldn't call that overflow
*check*. Even if it *would* occur on some particular machine, you
wouldn't be able to catch it at runtime (well, not with standard
language features).

>As far as I know, Ada and C can run on the same machines, so if Ada
>can have overflow checks, C can too.

No. In C you only get the overflow checks (for signed types) if the
machine itself supports it.
Otherwise you get a wonderful implementation defined (or whatever this
is called) wraparound. And I know a lot of programmers who rely on
this for the particular machine their code is running on ("Signed?
Unsigned? Don't bother me, it's all the same bit pattern anyway.").


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dale Stanbrough]

In article <slrnbch36b.410.randhol+abuse@kiuk0152.chembio.ntnu.no>,
 Preben Randhol <randhol+abuse@pvv.org> wrote:

> Well the internet is also old, so your point is? I agree that there are
> a lot of things that could be done differently, but it all boils down
> to who is the user?

Ok, I should have said it seems "old and creaky", i.e. that there
are (or should be) better ways of doing things.

Do you want to give access to a file to someone? You can get a
patch for Access Control Lists for linux, which doesn't quite
put it into the term "unix" yet.

Signals are a bit of a mess (setjmp anyone?), and I find the
posix interface rather ugly, due in most part to its C heritage
and lack of namespaces.

And I only know a little bit about Unix...

Dale

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Ole-Hjalmar Kristensen]

Hyman Rosen <hyrosen@mail.com> writes:

> Ole-Hjalmar Kristensen wrote:
> > Hyman Rosen <hyrosen@mail.com> writes:
> >>     for (i = c.begin(); i != c.end(); ++i)
> > Yes, provided you get your termination condition of the loop right.
> 
> Huh? That's the termination condition, right there in the middle.
> When you loop over a container, you start at begin(), and quit at end().
> 

A small typo, and the loop will probably not do what you want. Yes, I
know the probability is very low.
What stops someone from modifying i inside the loop?

Also, begin() and end() only applies to STL type containers, not to
plain arrays. 

The only thing I'm saying is that C/C++ has no equivalent of the Ada for loop.
The plain loop .... end loop is the equivalent of the C for loop.
 
-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Martin Dowie]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305181502.53703035@posting.google.com>...
> 
> That sounds to me an unrealistic level of discipline: subtyping
> to the extent that all lattitudes and longitudes (and things
> along that line) are separate types.  More common usage is that both
> will be just real numbers (floats), whatever the language chosen.  So

NO! That's just plain wrong - I've spent the last 15 years working in
aerospace and this is EXACTLY the level of typing that is used
EVERYDAY.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Ole-Hjalmar Kristensen wrote:
> A small typo, and the loop will probably not do what you want.

I imagine that this is true of every programming language
ever invented.

> What stops someone from modifying i inside the loop?

Nothing.

> Also, begin() and end() only applies to STL type containers, not to
> plain arrays.

Godd C++ programmers don't use plain arrays. Remember, C++ isn't
Ada, where arrays are convenient to use :-) And if you insist,

     template <typename T, size_t N>
     T *begin(T (&array)[N]) { return array; }
     template <typename T, size_t N>
     T *end(T (&array)[N]) { return array + N; }
     template <typename T, size_t N>
     char (&sizer(T (&)[N]))[N];

Now if you have an array A, begin(A) and end(A) will give you
pointers to the beginning and end suitable for use as STL
iterators. And sizeof(sizer(A)) will give you its number of
elements as a compile-time static expression. You will get
compile-time errors if you try to apply them to pointers
instead of arrays, eliminating a common source of C errors.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Vinzent Hoefler wrote:
 > (and that sometimes might be not that easy as it looks at the first glance).

That's because the Ada folks got clever and decided that the
modulus didn't need to be a poer of two. Doesn't Dewar rant
on this subject occasionally?

> I doubt that. C just got modular types because it was convinient and
> natively supported by the machine.

That doesn't mean that Ada didn't copy the notion from C.

> No. In C you only get the overflow checks (for signed types) if the
> machine itself supports it.

That's silly. You get whatever the compiler gives you. If someone
wanted to implement overflow checking, that would be perfectly
legitimate, regardless of hardware.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
> > (and that sometimes might be not that easy as it looks at the first glance).
>
>That's because the Ada folks got clever and decided that the
>modulus didn't need to be a poer of two.

You don't seem to see the real problem.

Try that with binary values on a machine with one's complement. Try
that on a machine that throws an overflow error if the sign changes...

There is much more work involved to make it work correct than to
simply leave it implementation defined like in C.

>Doesn't Dewar rant on this subject occasionally?

So what? You don't have to use it (BTW, SPARK explicitely forbids
that), but the problem would remain the same for some machines.

>> I doubt that. C just got modular types because it was convinient and
>> natively supported by the machine.
>
>That doesn't mean that Ada didn't copy the notion from C.

I still doubt that. And unless someone from the language designers can
definitely confirm that, I will keep doing so.

The use(fulness) of modular types is older than C.

>> No. In C you only get the overflow checks (for signed types) if the
>> machine itself supports it.
>
>That's silly.

Yes. Don't bother, so is the whole language. ;->

>You get whatever the compiler gives you. If someone
>wanted to implement overflow checking, that would be perfectly
>legitimate, regardless of hardware.

Why should someone do such worthless stuff? According to the standard,
it's implementation defined (IIRC) either way. So why should someone
do the work to implement an meaningless overflow "check" that leads to
a program crash rather than just go on calculating with fancy values
like all the others expect it to do? Just to break some existing
C-programs?


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the

[Larry Kilgallen]

In article <1053352870.115958@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Ole-Hjalmar Kristensen wrote:
>> A small typo, and the loop will probably not do what you want.
> 
> I imagine that this is true of every programming language
> ever invented.

I presume the implicit meaning was:

  "A small typo, and the loop will probably not do what you want,
   but the compiler will still accept it."

Attempts were made to make the compiler fail on many small typos
by the designers of Ada (and other languages).

>> What stops someone from modifying i inside the loop?
> 
> Nothing.

And again, that is the point.

> Godd C++ programmers don't use plain arrays.

Do good C++ compilers guard against programmers dropping into C ?
(I don't have much C++ compiler experience.)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Vinzent Hoefler wrote:
> You don't seem to see the real problem.
> Try that with binary values on a machine with one's complement. Try
> that on a machine that throws an overflow error if the sign changes...
> There is much more work involved to make it work correct than to
> simply leave it implementation defined like in C.

C and C++ define arithmetic on an unsigned types to be
the conventional rules of modulo arithmetic, regardless
of the underlying machine representation, so the compiler
has to get it correct, regardless of what the hardware does.

Testing for overflow is no big deal. If the machine doesn't
give you a hardware check, you just check the inputs first.
You can look up an old 68000 assembly language manual, for
example, which described in detail how the V, C, O, and S
flags were set for each arithmetic operation.

> I still doubt that. And unless someone from the language designers can
> definitely confirm that, I will keep doing so.

Here's a quote from the Ada95 Rationale,
<http://www.ocsystems.com/user_guide/powerada/html/9x_rationale/rat95-p2-3.html#3-2>
      The modular types are unsigned integer types which exhibit
      cyclic arithmetic. (They thus correspond to the unsigned
      types of some other languages such as C.)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the

[Hyman Rosen]

Larry Kilgallen wrote:
> Do good C++ compilers guard against programmers dropping into C ?

Nope.

Re: [off-topic] fruit inspection

[Wesley Groleau]

> Now you are not talking about the OS, but about the applications. Either
> you have to compare Windows as a desktop versus Linux or some other Unix
> desktop or as server to server. You cannot compare apples, bananas and
> pinapples.

Pinapples!  That's Windows--an oversized prickly fruit
with something missing.  :-)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Wesley Groleau]

>>(i'm not in love with unix - it seems very old in many ways,
>>and it seems clear that the windows people must have learnt something
>>- perhaps this is optimistic though).

Yeah--they learned how to copy stuff and screw it up.
Then they spend years fixing their mistakes.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>
>C and C++ define arithmetic on an unsigned types to be
>the conventional rules of modulo arithmetic, regardless
>of the underlying machine representation, so the compiler
>has to get it correct, regardless of what the hardware does.

ACK. But you do not seem to recognize the fact that C was simply
designed around a specific hardware. Most computers to modulo
arithmetic and the only reason C permits an overflow exception on
signed types is that some hardware exists that might raise such an
exception in such a case.
There was *never* the idea to have some kind of overflow check in
C-programs, the standard was simply dictated by the fact that some
machines do it and they wanted to have C-support on them. The same
applies to the shift operator. The only reason it is not perfectly
defined for signed types is that some machine just know a logical and
no arithmetic shift or vice versa.

>Testing for overflow is no big deal.

Sure, I know my condition codes, thank you. The fact remains, there
are no overflow checks in C. The one that *might* occur for signed
types is just a hardware dictated incident.

>> I still doubt that. And unless someone from the language designers can
>> definitely confirm that, I will keep doing so.
>
>Here's a quote from the Ada95 Rationale,
><http://www.ocsystems.com/user_guide/powerada/html/9x_rationale/rat95-p2-3.html#3-2>
>      The modular types are unsigned integer types which exhibit
>      cyclic arithmetic. (They thus correspond to the unsigned
>      types of some other languages such as C.)

Well, "they ... correspond". Quite a difference, and especially when
you read on, it is quite clear that C just comes out as an example for
a broader concept. Most CPU's simply use modular arithmetic internally
and that is the only reason this is the (only) default in C. And some
other languages.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Marc A. Criley]

softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305181502.53703035@posting.google.com>...
> That sounds to me an unrealistic level of discipline: subtyping
> to the extent that all lattitudes and longitudes (and things
> along that line) are separate types.  More common usage is that both
> will be just real numbers (floats), whatever the language chosen.  So

As noted elsewhere, this "unrealistic" level of discipline is the norm
in an Ada software shop.  You don't see this, and you see the common
usage as being just using floats in such situations, because you don't
work with Ada programmers.  You've indicated you work primarily with
C++ and Java, neither of which provide the simple, direct support for
the strong typing of scalars, so of course you won't--and simply
can't--see this sort of usage.

> academically this is an advantage, in practice it won't be there.
> (Similarly, as other messages point out, in practice, any usage of
> subranges you will see in Ada is just what you have in C++,
> int8, int16, int32.  Though in a classroom setting it may sound like
> a great advantage to be able to have my own subranges of integers
> from 1 to 9102 each and every time I need it...)

I'm not sure which other messages you're referring to (though I may
have just overlooked some--this has been a BIG thread :-), but the
only references to such definitions that I recall have been to
denigrate that practice (outside of the realm of external
interfacing), since it nullifies the benefit of strong typing and is
typically done by those unfamiliar with Ada and strong typing.

> But in any case, you sure can create Lattitude and Longitude classes
> in C++ as well if you are so disciplined, so the advantage you are
> pointing out is not very clear.

Of course one could create such classes--but _No_One_Does_ as a matter
of course--it's more work!  You said yourself that the more common
usage is to just use real numbers(floats).  Again, in Ada it's just as
easy to create distinct types for quantities like this and gain all
the benefits of strong typing and the services (attributes) that the
language automatically provides, as it is to declare a Latitude member
as plain vanilla float.

Doing the latter, though, requires that all the supporting constraint,
limit, and verification code be explicitly written by the
programmer--which is the case with C/C++ and Java.  Regardless of
whether you encapsulate it in a class or do it inline with reference
to consts and #define's.

How does one justify doing and debugging all this extra work to
duplicate what Ada gives you out of the box?

Marc A. Criley

Re: [off-topic] fruit inspection

[Preben Randhol]

Wesley Groleau wrote:
> Pinapples!  That's Windows--an oversized prickly fruit
> with something missing.  :-)

Which get stuck between your teeth after eating one ;-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Overflow checking in GNAT (Was: Quality systems)

[Jacob Sparre Andersen]

Hyman Rosen wrote:

 > It is to be noted that by
> default, GNAT has overflow checking disabled as well.

[ GNAT is the GNU Ada compiler ]

Yes.  And that is a most annoying choice, which I really do not 
understand.  Luckily this is something which can be fixed in a good 
command interpreter, but it is still a problem, when one has to help 
beginners getting started using GNAT.

Jacob
-- 
"If you think Tuck has said something that is completely
  wrong, you are almost certainly missing something :-)"

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Simon Wright]

martin.dowie@btopenworld.com (Martin Dowie) writes:

> softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305181502.53703035@posting.google.com>...
> > 
> > That sounds to me an unrealistic level of discipline: subtyping
> > to the extent that all lattitudes and longitudes (and things
> > along that line) are separate types.  More common usage is that both
> > will be just real numbers (floats), whatever the language chosen.  So
> 
> NO! That's just plain wrong - I've spent the last 15 years working in
> aerospace and this is EXACTLY the level of typing that is used
> EVERYDAY.

My project is using 'subtype Radians is Long_Float' or equivalent,
with constraints occasionally (though personally I don't now think
that Radians can sensibly be constrained without a lot of work). Of
course Latitude could be. The trouble is that the constraints won't
catch that may errors (in UK waters, anyway).

I've always thought that the pain of introducing full dimensional
handling (without language support) is unjustifiable, and that if
necessary one should rather go for records in this context:

  type Position is record
     Lat  : Latitude;
     Long : Longitude;
  end record;

and inspect the low-level support subprograms.

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Dr Chaos]

On 19 May 2003 20:42:42 +0100, Simon Wright <simon@pushface.org> wrote:
>   type Position is record
>      Lat  : Latitude;
>      Long : Longitude;
>   end record;
> 
> and inspect the low-level support subprograms.

What is the right way to do spherical geometry with separate
latitude and longitude types?     

The problem mathematically that I see is that SO(3) 
transformations will yield arithmetic combinations of these,
which would require lots of I would guess conversions to
some kind of default float.

On the other hand, if Latitude and Longitude were variables
whose values would be displayed to humans or perhaps stored
in some database, then the separate typing may work. 

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dr Chaos]

On Mon, 19 May 2003 10:01:10 -0400, Hyman Rosen <hyrosen@mail.com> wrote:
> Ole-Hjalmar Kristensen wrote:
>> A small typo, and the loop will probably not do what you want.
> 
> I imagine that this is true of every programming language
> ever invented.
> 
>> What stops someone from modifying i inside the loop?
> 
> Nothing.
> 
>> Also, begin() and end() only applies to STL type containers, not to
>> plain arrays.
> 
> Godd C++ programmers don't use plain arrays. Remember, C++ isn't
> Ada, where arrays are convenient to use :-) And if you insist,
> 
>      template <typename T, size_t N>
>      T *begin(T (&array)[N]) { return array; }
>      template <typename T, size_t N>
>      T *end(T (&array)[N]) { return array + N; }
>      template <typename T, size_t N>
>      char (&sizer(T (&)[N]))[N];

> Now if you have an array A, begin(A) and end(A) will give you
> pointers to the beginning and end suitable for use as STL
> iterators. 

This looks like some deep-guru C++ programming.  I see
templates instantiated by two parameters, T and N. 

How does "begin(A)" instantiate it with two parameters
instead of one? 

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Gautier Write-only]

soft-eng wrote:

> That sounds to me an unrealistic level of discipline: subtyping
> to the extent that all lattitudes and longitudes (and things
> along that line) are separate types.  More common usage is that both
> will be just real numbers (floats), whatever the language chosen.  So
> academically this is an advantage, in practice it won't be there.
> (Similarly, as other messages point out, in practice, any usage of
> subranges you will see in Ada is just what you have in C++,
> int8, int16, int32.

You are spoilt with these vary high-level programming languages.
Why not speaking with ah or al, ax, eax, like everybody in the real
software engineering world ?

Well, seriously: an Ada compiler precisely won't do the blunder of
mapping blindly subtypes to their smallest container. This is a very
unefficient choice.

You seem obsessed by the idea that strong-typing means just making
subranges. It's is a bit more than that.
It means there is no misunderstanding between you (the programmer)
and the compiler, about what pointers are pointing to, dimensions
and sizes of arrays, not uselessly mixing enumerated types and so
on. Really more a compile-time advantage. The underlying base types,
this is another story. You can either let the compiler find the
best match or specify the precise representation - necessary for bit
fiddling.

Your other obsession is that Ada is just strong-typing.
The better you have is to switch off Internet and peacefully #include
punched cards into your preferred machine...
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Preben Randhol]

Dr Chaos wrote:
> On 19 May 2003 20:42:42 +0100, Simon Wright <simon@pushface.org> wrote:
>>   type Position is record
>>      Lat  : Latitude;
>>      Long : Longitude;
>>   end record;
>> 
>> and inspect the low-level support subprograms.
> 
> What is the right way to do spherical geometry with separate
> latitude and longitude types?
> 
> The problem mathematically that I see is that SO(3) 
> transformations will yield arithmetic combinations of these,
> which would require lots of I would guess conversions to
> some kind of default float.

Maybe so (I don't know), but would it not be a bigger chance of catch
lunatic calculations when you try to do a conversion back to Latitude
and Longitude? I mean if the values are outside the bounds of the
Latitude and Longitude types?

> On the other hand, if Latitude and Longitude were variables
> whose values would be displayed to humans or perhaps stored
> in some database, then the separate typing may work. 

Huh?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[James S. Rogers]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
news:Za_xa.22$lF1.17@read3.inet.fi...
> "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> news:wzWxa.88930$cO3.6074665@bgtnsc04-news.ops.worldnet.att.net...
>
> > Ada user defined numeric types are more than simply the different
> > sized ints and floating point types in C and C++. C and C++ give you
> > no easy way to define a type that truly fits the problem. For instance,
> > if you are monitoring voltages that must always be between -5.0 and
> > +5.0 volts, you can define the following type:
> >
> > type Voltages is digits 15 range -5.0..5.0;
> >
> > This defines a floating point type with a 15 decimal digits of
> > precision and a valid range of values from -5.0 through 5.0.
> > Any attempt to evaluate a value outside that range will result in
> > a Constraint_Error exception being raised.
>
> Marc A. Criley <mcq95@earthlink.net> showed in message
> news:254c16a.0305091127.42ec7b21@posting.google.com
>
> an even better way to do that, viz.:
>
>    Extreme_Voltage : constant := 5.0;
>    type Voltages is digits 15 range -Extreme_Voltage..+Extreme_Voltage;

I guess it is a matter of taste. The definition of Extreme_Voltage adds
nothing
to the information known to the compiler. It also forces a symmetric set of
values.

To use that pattern for assymmetric values I would need to define two
constants:

Low_Voltage : constant := -5.0;
High_Voltage : constant := 7.0;
type Voltages is digits 15 range Low_Voltage..High_Voltage;

Now, I cannot see the definition of the range boundaries without finding
the definitions of Low_Voltage and High_Voltage.

The only place I can see how such an approach would make good sense
is if the range is defined by data read from a configuration file or
database:

function Low_Voltage return Long_Float;
function High_Voltage return Long_Float;

Jim Rogers

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert I. Eachus]

Hyman Rosen wrote:
> Vinzent Hoefler wrote:
>  > (and that sometimes might be not that easy as it looks at the first 
> glance).
> 
> That's because the Ada folks got clever and decided that the
> modulus didn't need to be a power of two. Doesn't Dewar rant
> on this subject occasionally?

As the sort of guilty party in this, let me explain why Ada allows 
modular types with bases other than powers of two, and what you can and 
can't do with the feature.

There is an operation in almost all hardware that allows quickly 
calculating (X * Y) mod N for any N smaller than the machine's natural 
word size:
           X * Y --> r1,r2 (or some register pair)
           (r1,r2) mod N --> r2

All other arithmetic operations on modular types are fast.  Well 
actually sometimes weird people like me want the non-arithmetic integer 
divide.  (If X, Y are all relatively prime, that is their pairwise GCDs 
are all 1, then there exists a unique Z such that Y * Z = X.)  But if we 
want it, it can be written in Ada and the "normal" divide for that type 
can be overridden.  The problem is that the Ada semantics make it very 
difficult to specify the modular multiplication for moduli that are 
non-powers of two, although all hardware has the two instructions above 
available, if you want to write an efficient version in Ada you have to 
use embedded assembler or the like.  If the feature of non-power of two 
moduli is supported in the language, the code generation is easy.

Why are these types needed?  The actual need is very small, but 
important.  Pulse doppler radar for example use a technique called the 
Chinese remainder theorem to disambiguate target ranges.  If you use 
pulse repetition frequencies A and B with a rational ratio A/B, then you 
can disambiguate the ranges to targets which are futher away than half 
the distance the radar signal can travel between pulses.  The two (or 
more) pulse rates are usually chosen so that the range ambiguity is a 
few kilometers.  For a simple example let's choose a ratio of 11 and 13.

If you get a return that could be at 7, 18, 29, 40, 51, 62, 73,... 
kilometers and from the other rep rate, a return at 2, 15, 38, 51,... 
kilometers, you conclude that the target is 51 kilometers away.  In 
practice target disambiguation and range disambiguation is much more 
complex.  But all you really need to know is that all the work is done 
with numbers in two different non-power of two modular types.

Other cases where non-power of two moduli crop up are in pseudo-random 
number generation, cryptography, and discrete Fast Fourier Transforms. 
So non-power of two moduli are very useful in a number of embedded 
applications where the cost of having the operations supported is 
trivial compared to the benefits.  And cryptography and random number 
generation make the types more generally useful.

So why does Robert Dewar rant occasionally about the types?  In a highly 
portable compiler like GNAT, the code generator has to support 
instructions that are not needed for any other language.  So this 
feature is a code-generation issue for GNAT that needed to be added to 
the gcc backend.  Technically, GNAT could have chosen the largest 
permitted non-power-of-two modulus to be 2^16-1.  But GNAT went to the 
effort to support non-power-of-two moduli up to Integer'LAST, and 
integrated the support into the code generator instead of doing the 
multiplies by using a two instruction code insert.  Which means that in 
discrete FFTs and Chinese Remainder Theorem implementations you get very 
high-quality code.  So he is in my book entitled to rant, and every time 
I use the feature I try to think of something nice to do for GNAT. ;-)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[The Ghost In The Machine]

In comp.lang.java.advocacy, Ole-Hjalmar Kristensen
<oleh@vlinux.voxelvision.no>
 wrote
on Mon, 19 May 2003 08:46:06 GMT
<7v65o78gtv.fsf@vlinux.voxelvision.no>:
> Hyman Rosen <hyrosen@mail.com> writes:
> 
>> Ole-Hjalmar Kristensen wrote:
>> > Hyman Rosen <hyrosen@mail.com> writes:
>> >>     for (i = c.begin(); i != c.end(); ++i)
>> > Yes, provided you get your termination condition of the loop right.
>> 
>> Huh? That's the termination condition, right there in the middle.
>> When you loop over a container, you start at begin(), and quit at end().
>> 
> 
> A small typo, and the loop will probably not do what you want. Yes, I
> know the probability is very low.

Not that low.

enum State { idle, started, running, waiting, done};
State state = idle;

for(i=0;state=idle;i++)
{
   /* ... */
}

Spot The Bug.

I don't know if Ada went the Pascal route or not ( ':=' for assignments,
'=' for testing), but that's one way of mitigating this bug.

(A for_each() construct in C++/STL is highly preferable anyway.
for_each(c.begin(), c.end(), f) does the trick.  It's a pity
there's no equivalent to Java's declaration though:

new AbstractClass() { public void concreteMethod() {...} }

:-) )

> What stops someone from modifying i inside the loop?

Nothing.  It's either a bug or a feature depending on how
one looks at it.  (Usually, it's a bug.)

> 
> Also, begin() and end() only applies to STL type containers,
> not to plain arrays. 

for_each() can take plain arrays, although the coding style is
different:

int a[10];

for_each(a,a+sizeof(a)/sizeof(a[0]),f);

where f is a _Function; the only requirement here is that
f(p) make sense, where p is an int; this means f can either
be an actual function with a single int argument, or a class
overloading () with a single int argument.

f(int&) would work as well, within certain limitations.
If one's worried about it one can declare

for_each((const int *) a, (const int *) a+sizeof(a)/sizeof(a[0]), f);

which isn't the pretties of constructs. :-)

> 
> The only thing I'm saying is that C/C++ has no equivalent
> of the Ada for loop.  The plain loop .... end loop is the
> equivalent of the C for loop.
>  

This is more or less correct, although for_each() comes
somewhat close.  However, for_each() has not been around
that long -- maybe since the late 1990's.  (C++ has been
around since 1990, if not even earlier; I still remember
cfront and this= assignments.)

-- 
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Martin Dowie]

Simon Wright <simon@pushface.org> wrote in message news:<x7v4r3q67v1.fsf@smaug.pushface.org>...
> My project is using 'subtype Radians is Long_Float' or equivalent,
> with constraints occasionally (though personally I don't now think
> that Radians can sensibly be constrained without a lot of work). Of
> course Latitude could be. The trouble is that the constraints won't
> catch that may errors (in UK waters, anyway).

True - but we tend to have whole-world-coverage type requirements.

It wouldn't be unusual to find something like:

   type A_Degree is digits 15;

   type A_Latitude is private;

   type A_Longitude is private;

   function To_Latitude (D : A_Degree)
      return A_Latitude;

   function To_Longitude (D : A_Degree)
      return A_Longitude;

private

   type A_Latitude is 
      new A_Degree range -90.0 .. 90.0;

   type A_Longitude is
      new A_Degree range -180.0 .. A_Degree'Pred (180.0);

in our code. Given that the algorithms are as old as the sun (e.g.
great circle) the number of times you actually need to do calculations
with both lat and long are fairly rare, so the type conversion just
are much of a hassle.


> I've always thought that the pain of introducing full dimensional
> handling (without language support) is unjustifiable, and that if

We only define what we need. As I mentioned at AdaUK, I've tried
greating *all* combinations before and the text editor just exploded!
:-)

> necessary one should rather go for records in this context:
> 
>   type Position is record
>      Lat  : Latitude;
>      Long : Longitude;
>   end record;
> 
> and inspect the low-level support subprograms.

...and a surprisingly similar...

   type A_Coordinate is record
      Lat  : A_Latitude;
      Long : A_Longitude;
   end record;

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Ole-Hjalmar Kristensen]

Hyman Rosen <hyrosen@mail.com> writes:

> Ole-Hjalmar Kristensen wrote:
> > A small typo, and the loop will probably not do what you want.
> 
> I imagine that this is true of every programming language
> ever invented.
> 

Sure, but the probability that the compiler will complain about typos
in the control part of an Ada for loop is higher than in the C for
loop.

> > What stops someone from modifying i inside the loop?
> 
> Nothing.
> 

But the Ada compiler will stop you if you try to change the loop
parameter inside the loop.

> > Also, begin() and end() only applies to STL type containers, not to
> > plain arrays.
> 
> Godd C++ programmers don't use plain arrays. Remember, C++ isn't
> Ada, where arrays are convenient to use :-) And if you insist,
> 

Yes, I know. But when you've got a few hundred thousand lines of legacy C++ code to maintain, like me, you are bound to see some plain arrays.

>      template <typename T, size_t N>
>      T *begin(T (&array)[N]) { return array; }
>      template <typename T, size_t N>
>      T *end(T (&array)[N]) { return array + N; }
>      template <typename T, size_t N>
>      char (&sizer(T (&)[N]))[N];
> 
> Now if you have an array A, begin(A) and end(A) will give you
> pointers to the beginning and end suitable for use as STL
> iterators. And sizeof(sizer(A)) will give you its number of
> elements as a compile-time static expression. You will get
> compile-time errors if you try to apply them to pointers
> instead of arrays, eliminating a common source of C errors.
> 

Neat trick. Templates are fun.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Logic Errors and Ada

[Peter Hermann]

In comp.lang.ada Robert I. Eachus <rieachus@attbi.com> wrote:
> In actual practice I would be more likely to declare it to be a 
> fixed-point type with a declaration like:

> type Latitude is digits 8 delta 0.000001 range -90.0..90.0;

> or if I wanted to represent hundreths of a second exactly:

> type Latitude is delta 1.0/360000 range -90.0..90.0;
> for Latitude'Small use 1.0/360000;

thank you, Robert, for your excellent contribution:
you should have sent it a couple of years sooner   ;-)
OTOH, thanks to Ada it is quite easy to update my code 
http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/coords.ads
for enhanced precision.
For storage reasons I could?should offer different types of precision.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Hyman Rosen]

Martin Dowie wrote:
>>I've always thought that the pain of introducing full dimensional
>>handling (without language support) is unjustifiable, and that if
> 
> We only define what we need. As I mentioned at AdaUK, I've tried
> greating *all* combinations before and the text editor just exploded!

Language support is very helpful here. In C++ you just define
the templates for what you need, and the compiler takes care
of instantiating just the ones that are used.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

The Ghost In The Machine wrote:
> A for_each() construct in C++/STL is highly preferable anyway.

Only if you include some third-party stuff, like Boost's
Lambda Library. The problem with for_each and its ilk is
that you must supply a functor, and without this library
or something similar, that functor has to be defined out
of line, distant from the point where it is used. Using
LL, it's much simpler, and then for_each is OK.

> for_each(a,a+sizeof(a)/sizeof(a[0]),f);

As I said in the other post, it's much better to define
begin and end function templates for arrays. Then do
     for_each(begin(a), end(a), f);
You could also define begin and end for the other
container types and use uniform syntax:
     template <typename T> typename T::iterator
     begin(std::vector<T> &v) { return v.begin(); }
     template <typename T> typename T::const_iterator
     begin(std::vector<T> const &v) { return v.begin(); }

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Stephen Leake]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Dr Chaos wrote:
> > On 19 May 2003 20:42:42 +0100, Simon Wright <simon@pushface.org> wrote:
> >>   type Position is record
> >>      Lat  : Latitude;
> >>      Long : Longitude;
> >>   end record;
> >> 
> >> and inspect the low-level support subprograms.
> > 
> > What is the right way to do spherical geometry with separate
> > latitude and longitude types?
> > 
> > The problem mathematically that I see is that SO(3) 
> > transformations will yield arithmetic combinations of these,
> > which would require lots of I would guess conversions to
> > some kind of default float.
> 
> Maybe so (I don't know), but would it not be a bigger chance of catch
> lunatic calculations when you try to do a conversion back to Latitude
> and Longitude? I mean if the values are outside the bounds of the
> Latitude and Longitude types?
> 
> > On the other hand, if Latitude and Longitude were variables
> > whose values would be displayed to humans or perhaps stored
> > in some database, then the separate typing may work. 
> 
> Huh?

I think he agrees with my policy; do all internal calculations in a
data structure that supports full rotations (SO(3) is group theory
notation for the rotation group); that means orthornormal matrices or
unit quaternions. Only convert to lat/long for user input/output. That
avoids singularities and unit confusion in the core code.

-- 
-- Stephe

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert A Duff]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Hyman Rosen wrote:
> 
> >Vinzent Hoefler wrote:
> > > (and that sometimes might be not that easy as it looks at the first glance).
> >
> >That's because the Ada folks got clever and decided that the
> >modulus didn't need to be a poer of two.
> 
> You don't seem to see the real problem.
> 
> Try that with binary values on a machine with one's complement. Try
> that on a machine that throws an overflow error if the sign changes...
> 
> There is much more work involved to make it work correct than to
> simply leave it implementation defined like in C.

But it is not implementation defined in C.  C requires unsigned
arithmetic to wrap around.  Ada requires modular arithmetic to wrap
around (but allows an out for ones' complement machines).

Signed arithmetic is unpredictable in C (in overflow cases).
In Ada, you get an exception.

> >Doesn't Dewar rant on this subject occasionally?

Yes, he does.  I agree with him -- non-binary modulii are an unnecessary
frill, and should have been left out of Ada.  Consider the weird
semantics of "not" for non-binary modulii.

> So what? You don't have to use it (BTW, SPARK explicitely forbids
> that), but the problem would remain the same for some machines.
> 
> >> I doubt that. C just got modular types because it was convinient and
> >> natively supported by the machine.
> >
> >That doesn't mean that Ada didn't copy the notion from C.
> 
> I still doubt that. And unless someone from the language designers can
> definitely confirm that, I will keep doing so.

OK, I was on Ada 9X design team.  The fact that other languages support
modular arithmetic was certainly one factor in the decision.  C is the
prime example, but there are others.  And the fact that these types wrap
around in Ada (rather than raising an exception on overflow) is partly
because that's what other languages do, and partly because that's what
much hardware does.

> The use(fulness) of modular types is older than C.

True.

By the way, modular types is one of my least favorite features of Ada.
It's an odd mixture of high level and low level.  For high-level
purposes, I'd rather have multi-word arithmetic, and do the "mod"s
explicitly when desired, and I don't want bit-wise "and" and the like.
For low-level purposes, I want bit-wise "and", but I don't want
non-binary modulii.

Note that even for binary modulii, Ada gives you more than C.  C
supports certain-sized unsigned types (short, long, etc) -- presumably
the ones supported by the hardware.  But in Ada, you can have a modulus
of 2**13, for example.  I believe most implementations do that with an
"and" instruction on every arithmetic operation.  Another way to do it
would be "lazy" -- do the "and" only on output and conversion and the
like.

The design team actually went back and forth several times between two
solutions: a kludgy "magic" package that supports unsigned types of
certain sizes, pretty much like C, and a first-class type with syntax
and relatively general semantics (including non-binary modulii).
I think perhaps the magic package was the better solution.

- Bob

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[soft-eng]

Gautier Write-only <gautier@somewhere.nil> wrote in message news:<3EC95355.A6B66F5C@somewhere.nil>...

> The better you have is to switch off Internet and peacefully #include
> punched cards into your preferred machine...

This from supporters of a 20-year language on life-support?
(In human years I guess that's like a 250 years old or
something, fighting with the remaining tooth and nail
for the good-old-days.)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Robert A Duff wrote:

>Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
>
>> Hyman Rosen wrote:
>> 
[modular arithmetic]
>But it is not implementation defined in C.  C requires unsigned
>arithmetic to wrap around.  Ada requires modular arithmetic to wrap
>around (but allows an out for ones' complement machines).
>
>Signed arithmetic is unpredictable in C (in overflow cases).

Yes, of course. I was referring to signed types only here. Sorry, if
that didn't come out clear enough.

And H.2.2 of the current C99-Standard says:

|An implementation that defines signed integer types as also being
|modulo need not detect integer overflow, in which case, only integer
|divide-by-zero need be detected.

Additionaly, J.3.5 definitely confirms that this is an implementation
defined feature in C.

>> >Doesn't Dewar rant on this subject occasionally?
>
>Yes, he does.  I agree with him -- non-binary modulii are an unnecessary
>frill, and should have been left out of Ada.

Well, although myself I've never used them thus far, I'm sure there is
something useful you can do with them. And if it's just to make the
compiler writers crazy about that they have to support it... ;)

>  Consider the weird
>semantics of "not" for non-binary modulii.

Well, you get what you've asked for. :-)

>> >> I doubt that. C just got modular types because it was convinient and
>> >> natively supported by the machine.
>> >
>> >That doesn't mean that Ada didn't copy the notion from C.
>> 
>> I still doubt that. And unless someone from the language designers can
>> definitely confirm that, I will keep doing so.
>
>OK, I was on Ada 9X design team.  The fact that other languages support
>modular arithmetic was certainly one factor in the decision.

Yes, of course. I didn't want to say that the Ada design team invented
the wheel in that particular case. I just doubt that especially C was
the main reason to have such type.

>By the way, modular types is one of my least favorite features of Ada.
>It's an odd mixture of high level and low level.  For high-level
>purposes, I'd rather have multi-word arithmetic, and do the "mod"s
>explicitly when desired, and I don't want bit-wise "and" and the like.
>For low-level purposes, I want bit-wise "and", but I don't want
>non-binary modulii.

Well, let's get an example out of my praxis. I got a kind of random
lookup table with 15 entries (yes, I know, this is silly, especially
because speed should have been a main concern when this was written
first) and I just want to go through that array in circles. So using a
modular type in that case would be what? Low level? High level?

Currently this thing is written in assembly language, but if I'd ever
reengineer that in Ada I'd definitely use a (non-binary) modular type
for the index then (and an array with 16 entries instead). Of course,
as you pointed out, I could do the modulo arithmetic by hand, but why
if I can let the compiler handle it?

>The design team actually went back and forth several times between two
>solutions: a kludgy "magic" package that supports unsigned types of
>certain sizes, pretty much like C,

Well, I guess Interfaces.C comes quite close...

>and a first-class type with syntax
>and relatively general semantics (including non-binary modulii).
>I think perhaps the magic package was the better solution.

Well, I am no compiler writer, but I wouldn't consider that a use for
another package [well, I *hate* using Interfaces.C, too ;-)]. After
all, it's still some kind of Integer. YMMV.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert A Duff]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Robert A Duff wrote:
> >  Consider the weird
> >semantics of "not" for non-binary modulii.
> 
> Well, you get what you've asked for. :-)

;-)

> Well, let's get an example out of my praxis. I got a kind of random
> lookup table with 15 entries (yes, I know, this is silly, especially
> because speed should have been a main concern when this was written
> first) and I just want to go through that array in circles. So using a
> modular type in that case would be what? Low level? High level?

High level.

> Currently this thing is written in assembly language, but if I'd ever
> reengineer that in Ada I'd definitely use a (non-binary) modular type
> for the index then (and an array with 16 entries instead). Of course,
> as you pointed out, I could do the modulo arithmetic by hand, but why
> if I can let the compiler handle it?

Because it makes the code easier to understand if the "mod" is explicit.

- Bob

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Gautier Write-only]

> > The better you have is to switch off Internet and peacefully #include
> > punched cards into your preferred machine...
> 
> This from supporters of a 20-year language on life-support?
> (In human years I guess that's like a 250 years old or
> something, fighting with the remaining tooth and nail
> for the good-old-days.)

Interesting extrapolation. Let's see, if I apply it to your vision of
programming... WOW - 425 years! My respects 8-).
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Tom Welsh]

In article <9fa75d42.0305200821.46ac73bf@posting.google.com>, soft-eng
<softeng3456@netscape.net> writes
>
>This from supporters of a 20-year language on life-support?
>(In human years I guess that's like a 250 years old or
>something, fighting with the remaining tooth and nail
>for the good-old-days.)

Are you implying that older languages are necessarily worse? That is not
always true by any means...

"Algol 60 was not only an improvement on its predecessors, but also on
nearly all its successors" - C. A. R. Hoare

Don't forget that C is nearly twice as old as Ada (Ada-83, that is, the
older version). And Bjarne Stroustrup invented "C with classes",
which later became known as C++, in 1979 - four years before the first
Ada compilers appeared.

If a 20-year-old language is like a 250-year-old person, I guess C must
be more like a 400-year-old. As for that Methuselah of languages, COBOL,
which dates back to 1959-61, that would correspond to over 500 years.
Which is probably why there are some 200 billion lines of COBOL code in
active service, accounting for 70-85 percent of the world's business
systems. (And before you say it's all old, another 5 billion lines of
COBOL is written every year according to Gartner).

New is not always better. 
-- 
Tom Welsh

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[tmoran]

> -- non-binary modulii are an unnecessary
> frill, and should have been left out of Ada.
  But handy for instance as indexes for card decks or tables with 'length
a power of ten rather than a power of two.

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Martin Dowie]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1053435857.635685@master.nyc.kbcfp.com...
> Language support is very helpful here. In C++ you just define
> the templates for what you need, and the compiler takes care
> of instantiating just the ones that are used.

If you check the AIs, you will see that there is one to introduce
such a built-in feature into Ada0Y (maybe!).

Re: Logic Errors and Ada

[Robert I. Eachus]

Peter Hermann wrote:

> thank you, Robert, for your excellent contribution:
> you should have sent it a couple of years sooner   ;-)
> OTOH, thanks to Ada it is quite easy to update my code 
> http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/coords.ads
> for enhanced precision.

It probably would not have worked.  In Ada83 there was an unintentional 
glitch in the definition of the multiply operator for fixed point types 
that made it a pain for compilers to accept "arbitrary" specifications 
of 'Small.  This was all the more painful because a programmer might 
never create the horrible case, but compilers had to reject the type 
declaration if they couldn't handle all possible cases where types with 
different 'Smalls were used in one multiplication.  I won't go into the 
gory details, but there were a few cases which required triple precision 
integer arithmetic at run time.  No one really wanted to use those 
operations, but the easiest thing for implementors to do was to reject 
many specifications of 'Small.

In Ada95 the rules were change slightly.  But IMHO, the bigger change 
was that all implementors were reassured that if a weird case not 
covered by the rules showed up, the intent was to fix the rules, not 
punish implementors.  Add to that the new decimal types which require 
some support for non-powers-of-two 'Small, and AFIAK all Ada compilers 
now support the most important case: 1.0/X where X is a (32-bit) integer.

Oh, and I really do mean integer there.  Division of 1.0 by a universal 
integer is legal in Ada.  I don't know if any compilers are not smart 
enough to figure out that 1.0/360000.0 should mean the same thing. It is 
so easy to ask for what I want (X * My_Type'Small = 1.0 exactly).  So I 
do that instead of asking for something else and hoping the compiler 
will figure it out.

> For storage reasons I could?should offer different types of precision.

I can't see why.  Most likely unless you really want to try to force the 
compiler to use 16-bit representations, you will get a 32-bit object. 
Hundreths of a second gets you, what, about one foot accuracy? 
(Technically, a compiler should be able to support 1/2000 of a degree in 
latitude and  1/1000 in longitude, but I have never tried it.)

Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[Martin Dowie]

"Martin Dowie" <martin.dowie@no.spam.btopenworld.com> wrote in message news:<bae65q$4tn$1@sparta.btinternet.com>...
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1053435857.635685@master.nyc.kbcfp.com...
> > Language support is very helpful here. In C++ you just define
> > the templates for what you need, and the compiler takes care
> > of instantiating just the ones that are used.
> 
> If you check the AIs, you will see that there is one to introduce
> such a built-in feature into Ada0Y (maybe!).

...possibly quite a big maybe, by the way - it's not a particularly
easy thing to achieve :-)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Robert A Duff wrote:

> The design team actually went back and forth several times between two
> solutions: a kludgy "magic" package that supports unsigned types of
> certain sizes, pretty much like C, and a first-class type with syntax
> and relatively general semantics (including non-binary modulii).
> I think perhaps the magic package was the better solution.

What about:

1. arbitrary modulii without add, or, xor, not.

2. predefined boolean array types with bit-wise and arithmetic operations, 
packed, allowed for discriminants etc.

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[The Ghost In The Machine]

In comp.lang.java.advocacy, Hyman Rosen
<hyrosen@mail.com>
 wrote
on Tue, 20 May 2003 09:18:05 -0400
<1053436685.260636@master.nyc.kbcfp.com>:
> The Ghost In The Machine wrote:
>> A for_each() construct in C++/STL is highly preferable anyway.
> 
> Only if you include some third-party stuff, like Boost's
> Lambda Library. The problem with for_each and its ilk is
> that you must supply a functor, and without this library
> or something similar, that functor has to be defined out
> of line, distant from the point where it is used. Using
> LL, it's much simpler, and then for_each is OK.

Not familiar with that particular library, or for that
matter lambda expressions (although I've heard of them),
but you're probably right, and certainly Java's construct
helps a lot there.  (It's the closest thing to a lambda
expression -- which AIUI can be construed as an unnamed
function -- that Java has.)

> 
>> for_each(a,a+sizeof(a)/sizeof(a[0]),f);
> 
> As I said in the other post, it's much better to define
> begin and end function templates for arrays. Then do
>      for_each(begin(a), end(a), f);

I must have missed that, but yes, that would be much cleaner.

> You could also define begin and end for the other
> container types and use uniform syntax:
>      template <typename T> typename T::iterator
>      begin(std::vector<T> &v) { return v.begin(); }
>      template <typename T> typename T::const_iterator
>      begin(std::vector<T> const &v) { return v.begin(); }
> 

The problem is that if one defines

#define begin(a) (a)
#define end(a) ((a) + sizeof(a)/sizeof((a)[0]))

one now cannot use templates.  The C++ preprocessor is muy stupido. :-)

One could try

template <type A> A * begin(A * start, int s) { return start; }
template <type A> A * end(A * start, int s) { return start + n / sizeof(A); }

which would require constructs such as

for_each(begin(a,sizeof(a)), end(a,sizeof(a)), f)

Your other templates would of course require a second argument,
which would simply be discarded, for the sake of consistency.
It's not the prettiest of solutions, but C++ is not the
prettiest of languages with respect to array handling.

If one can afford the multinode copy, one might use a vector<> instead.
(Note that sizeof(vector<>) is a constant.  My brain hurts.)

-- 
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

The Ghost In The Machine wrote:
> The problem is that if one defines
> #define begin(a) (a)
> #define end(a) ((a) + sizeof(a)/sizeof((a)[0]))

You really did miss my other post, didn't you? :-)
     template <typename T, size_t N> T *begin(T (&a)[N]) { return a;     }
     template <typename T, size_t N> T *end  (T (&a)[N]) { return a + N; }
Using array references prevents the decay to pointer and
allows both the array size and type to be deduced.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert A Duff]

tmoran@acm.org writes:

> > -- non-binary modulii are an unnecessary
> > frill, and should have been left out of Ada.
>   But handy for instance as indexes for card decks or tables with 'length
> a power of ten rather than a power of two.

I don't agree.  I think for *those* kinds of uses, one should use a
signed type, and write the "mod" operations explicitly where they
occur.  Having a type that magically does a mod operation every time
you do arithmetic is not an aid to readability.

- Bob

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Robert A Duff wrote:
> 
> > The design team actually went back and forth several times between two
> > solutions: a kludgy "magic" package that supports unsigned types of
> > certain sizes, pretty much like C, and a first-class type with syntax
> > and relatively general semantics (including non-binary modulii).
> > I think perhaps the magic package was the better solution.
> 
> What about:
> 
> 1. arbitrary modulii without add, or, xor, not.

By "add", you mean "and"?

Shrug.  I don't like the whole concept of modular; I think it's more
readable to do the "mod" explicitly.  Except perhaps for low-level cases
where you're mimicing hardware and the like.

And I don't like the fact that in order to get one extra bit (e.g. a
range of 0..2**32-1 or 0..2**64-1) I have to use modular semantics,
in cases where I'm just counting things, so modular semantics is just
wrong.

> 2. predefined boolean array types with bit-wise and arithmetic operations, 
> packed, allowed for discriminants etc.

I would love to have discriminants whose type is array or record.
It's annoying to have to introduce pointers (and then make things
aliased) in order to pass an array as a parameter to a type.

- Bob

Re: Quality systems

[Peter Hermann]

Robert A Duff <bobduff@shell01.theworld.com> wrote:
> tmoran@acm.org writes:
>> > -- non-binary modulii are an unnecessary
>> > frill, and should have been left out of Ada.
>>   But handy for instance as indexes for card decks or tables with 'length
>> a power of ten rather than a power of two.
> I don't agree.  I think for *those* kinds of uses, one should use a
> signed type, and write the "mod" operations explicitly where they
> occur.  Having a type that magically does a mod operation every time
> you do arithmetic is not an aid to readability.
> - Bob

I very much appreciate the practical comfort given with the 
"extended" mod type feature and wont miss it.
There are many examples where Ada makes live easier i.e.
where the compiler makes the job instead of the programer,
e.g. the fixed real types when floating point cpu missing,
e.g. the numeric type conversion towards the nearest neighbor
(model number, think of e.g. float2pixel),
and several dozen other new benefits.
This one is a benefit.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[tmoran]

> Having a type that magically does a mod operation every time
> you do arithmetic is not an aid to readability.
   Target := Indices'succ(Target) [ mod Ring_Buffer_Size];  ?
Even "Target := (Target+1) mod Ring_Buffer_Size;" vs "Target := Target+1;"
is a step downward in abstraction.  It also allows more easily the error
Target := Target+1 mod Ring_Buffer_Size;

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[John R. Strohm]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Wed, 21 May 2003 13:40:42 -0500 (CDT)
NNTP-Posting-Host: !]3Oq1k-XgoE]rX (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:bafoi4$rerai$2@ID-77047.news.dfncis.de...
> Robert A Duff wrote:
>
> > The design team actually went back and forth several times between two
> > solutions: a kludgy "magic" package that supports unsigned types of
> > certain sizes, pretty much like C, and a first-class type with syntax
> > and relatively general semantics (including non-binary modulii).
> > I think perhaps the magic package was the better solution.
>
> What about:
>
> 1. arbitrary modulii without add, or, xor, not.

Without addition, you by definition don't have a modular type.  The whole
point of a modular type is that it is characterized by wraparound (modular)
addition.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Brian Gaffney]

"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message news:<xzNwa.145$nE3.93@newssvr16.news.prodigy.com>...
> <achrist@easystreet.com> wrote in message
> > There was not only a 640 kb limit, there were some 64 kb limits
> > on the size of memory segments in most of the PC software prior to
> > 1987.  I don't recall ever seeing an Ada product or tool that would
> > run on an 8086 or 8088 without special hardware added.  Were there
> > any?
> 
> If I am to believe the documentation for the Meridian compilier version 4.1
> it should work on a 8086
> with MS-DOS version 2.1 or later
> 
> I have never tested it in that environment, so I can not confirm the claim
> 

I just happen to have a copy of Meridian Open Ada 4.1 for _PC_ DOS
sitting on my desk.  And yes it does just that - I've used in on a NEC
Ultralight laptop (~8086) with 640k RAM and a 2Mb RAM 'hard disk'. 
Not that I use the compiler currently, 640k limit, 5 1/4 floppies, and
all that.

Anyone know who 'owns' this product now (if anyone)?  I had tracked it
thru 3 or 4 company changes, but never found anything recent.

                                                --Brian

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[David Lightstone]

"Brian Gaffney" <Brian.Gaffney@myrealbox.com> wrote in message
news:5e9b8c34.0305211211.75bdfc5d@posting.google.com...
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:<xzNwa.145$nE3.93@newssvr16.news.prodigy.com>...
> > <achrist@easystreet.com> wrote in message
> > > There was not only a 640 kb limit, there were some 64 kb limits
> > > on the size of memory segments in most of the PC software prior to
> > > 1987.  I don't recall ever seeing an Ada product or tool that would
> > > run on an 8086 or 8088 without special hardware added.  Were there
> > > any?
> >
> > If I am to believe the documentation for the Meridian compilier version
4.1
> > it should work on a 8086
> > with MS-DOS version 2.1 or later
> >
> > I have never tested it in that environment, so I can not confirm the
claim
> >
>
> I just happen to have a copy of Meridian Open Ada 4.1 for _PC_ DOS
> sitting on my desk.  And yes it does just that - I've used in on a NEC
> Ultralight laptop (~8086) with 640k RAM and a 2Mb RAM 'hard disk'.
> Not that I use the compiler currently, 640k limit, 5 1/4 floppies, and
> all that.
>
> Anyone know who 'owns' this product now (if anyone)?  I had tracked it
> thru 3 or 4 company changes, but never found anything recent.

Who was the last owner?
It will be easier for someone to track it with a reference point
If you know the state of incorporation that may make the task easier (state
govt keeps records)

>
>                                                 --Brian

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[achrist]

> 
> I just happen to have a copy of Meridian Open Ada 4.1 for _PC_ DOS
> sitting on my desk.  And yes it does just that - I've used in on a NEC
> Ultralight laptop (~8086) with 640k RAM and a 2Mb RAM 'hard disk'.
> Not that I use the compiler currently, 640k limit, 5 1/4 floppies, and
> all that.
> 

What's the date on this product?  Is it really from the early days 
of PC's (e.g. 1985 o earlier)?


Al

Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)

[Dave Thompson]

On Wed, 14 May 2003 03:25:03 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

> Dave Thompson wrote:
> 
> > Not quite.  Ada Get_Line is much closer to C fgets, 
> > although it does store the newline character (if it fits) 
> > and you must often deal with removing it, and it does 
> > not return the length explicitly (you must strlen for it).
> 
Apparently my antecedent wasn't clear, sorry.

> There are three errors here.  The first is a category error.  The 
> description of Ada.Text_IO.Get was just to show that in Ada, you can 
> never have a buffer overflow error.  (Unless of course you go very far 
> out of your way to specifically program one.  It can be done, but many 
> Ada programmer don't know how, and most Ada programmers would consider 
> going out of your way to construct an Ada program that had a potential 
> buffer overflow not as a challenge, but as a kind of pornography.
> 
Yes, Ada protects against overrun unless deliberately and
inconveniently overridden, as I agreed in a part you didn't quote.
And I did and do agree that was the important point.

> The second error is technical. If an Ada program copies a newline 
> character as part of a Get, that is an error.  If the type of the text 
> file was incorrectly specified, for example as one where LF (linefeed) 
> is the representation of end of line, instead of CR LF, then you will 
> read a CR character.  This occasionally used to happen when people 
> ported files between Windows and Unix.  I think now thought that all Ada 
> compilers accept any combination of CR and LF as end of line, while 
> using the appropriate end of line marker for that system when writing 
> text files.
> 
Other way.  Ada Get_Line does not store anything for end-of-line, 
assuming it is recognized correctly as you allude to.  If it matters 
whether you got a complete line, and it usually does, you must 
determine by whether the count hit the limit.  C fgets *does* 
store the (single, but otherwise implementation-defined) character
'\n' for a recognized (perhaps implementation-dependent) end-of-line.
In the fairly common case you don't want the \n in your string, 
you have to explicitly delete it, or exclude from a copy operation.

> Finally, in Ada the only cases where you need to call strlen is when 
> converting a C or C++ string to an Ada String.  In Ada the name of the 
> length of the string named Foo is Foo'Length.  But it is an explict 
> property of the string, just like Foo'First and Foo'Last.  (Most Ada 
> compilers only store two of the three attributes as part of the 
> representation of a dynamic string. (A string whose length is not known 
> at compile time.)  But that is an implementation detail.
> 
Again I meant C:  fgets does not return the length of the read data 
explicitly (nor is it an attribute of the buffer variable) so *if* you
need the length, which is not always, you must call strlen (or equal).
Agree that in Ada you don't need to do that except for C  interfacing
in which case the canonical way is Interfaces.C.Strings.Value which
actually does strlen but type-safely; or some weird I/O.

> The whole point here is that an Ada programmer never worries about the 
> length of a string or the any of the implicit checking that needs to be 
> explicit in C.  In fact in Ada 95 [Bounded_String and Unbounded_String]

Agreed.  I was only correcting and somewhat expanding your example.

- David.Thompson1 at worldnet.att.net

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

John R. Strohm wrote:

> X-A-Notice: References line has been trimed due to 512 byte limitation
> Abuse-Reports-To: abuse at airmail.net to report improper postings
> NNTP-Proxy-Relay: library1-aux.airnews.net
> NNTP-Posting-Time: Wed, 21 May 2003 13:40:42 -0500 (CDT)
> NNTP-Posting-Host: !]3Oq1k-XgoE]rX (Encoded at Airnews!)
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> 
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:bafoi4$rerai$2@ID-77047.news.dfncis.de...
>> Robert A Duff wrote:
>>
>> > The design team actually went back and forth several times between two
>> > solutions: a kludgy "magic" package that supports unsigned types of
>> > certain sizes, pretty much like C, and a first-class type with syntax
>> > and relatively general semantics (including non-binary modulii).
>> > I think perhaps the magic package was the better solution.
>>
>> What about:
>>
>> 1. arbitrary modulii without add, or, xor, not.
> 
> Without addition, you by definition don't have a modular type.  The whole
> point of a modular type is that it is characterized by wraparound
> (modular) addition.

Sorry, it was typo error, I meant *and*.

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Robert A Duff wrote:
>> 
>> > The design team actually went back and forth several times between two
>> > solutions: a kludgy "magic" package that supports unsigned types of
>> > certain sizes, pretty much like C, and a first-class type with syntax
>> > and relatively general semantics (including non-binary modulii).
>> > I think perhaps the magic package was the better solution.
>> 
>> What about:
>> 
>> 1. arbitrary modulii without add, or, xor, not.
> 
> By "add", you mean "and"?

Yes of course.

> Shrug.  I don't like the whole concept of modular; I think it's more
> readable to do the "mod" explicitly.  Except perhaps for low-level cases
> where you're mimicing hardware and the like.

Modular types are still useful for cyclic buffers etc. BTW, it is strange 
that modular types are associated with unsigned numbers. In my view it 
would be more consistent to have:

type X is mod range -2..4;

> And I don't like the fact that in order to get one extra bit (e.g. a
> range of 0..2**32-1 or 0..2**64-1) I have to use modular semantics,
> in cases where I'm just counting things, so modular semantics is just
> wrong.

Yes, it should be a normal number, and also declared so:

type X is range 0..2**(32-1);
pragma Unsigned (X);

or 

type X is unsigned range 0..2**(32-1);

>> 2. predefined boolean array types with bit-wise and arithmetic
>> operations, packed, allowed for discriminants etc.
> 
> I would love to have discriminants whose type is array or record.
> It's annoying to have to introduce pointers (and then make things
> aliased) in order to pass an array as a parameter to a type.

That's for sure. Discriminants of any type and for any type!

type Dimensioned (SI : Unit) is ...;
type Vector (SI : Unit) is array (...) of Dimensioned (SI);

or even class-wide discriminated arrays:

type X is tagged ...;
type Class_Array (T : Tag) is array (...) of X (T);

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

Marin David Condic wrote:
> True, but with an OS this is achievable. It is possible to build an OS
that
> won't crash because of the particular application being run on it. (Or at
> least crash so infrequently as to be practically the same thing).

I know of no operating system which does not crash because of application
behaviour. Some does so more seldom than others, but they still do.


greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Larry Kilgallen]

In article <3ecca391$1@news.wineasy.se>, "Tarjei T. Jensen" <tarjei.jensen@akerkvaerner.com> writes:
> Marin David Condic wrote:
>> True, but with an OS this is achievable. It is possible to build an OS
> that
>> won't crash because of the particular application being run on it. (Or at
>> least crash so infrequently as to be practically the same thing).
> 
> I know of no operating system which does not crash because of application
> behaviour. Some does so more seldom than others, but they still do.

Are you saying that operating systems survive longer if you don't use them ?

Or are you saying there is generally _specific_ application behavior that
can trigger a crash ?

24 years ago there was a magic sequence I could type on the console to
provoke (unintended) crashes.  Seven versions later, that is now gone,
and most of the crashes I read about (but do not experience myself) are
exotic race conditions that might not be encountered with zero load,
but certainly are not a direct response to any particular application
activity.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Well, as a matter of logic, one can't prove a negative assumption. I
can't *prove* that any given operating system *won't* crash. The best
one can do is demonstrate that an operating system *does* crash.

That
said, I could point to VMS and observe that with later versions of it, I
drove it around quite extensively and had ill-behaved programs that
crashed, but they never killed the OS. Nor was it ever necessary to
reboot it periodically to clear problems. It may have been possible to
kill it, but if it could stay up and running for months on end and not
crash under a large variety of uses, this ought to be good enough for a
large variety of users.

Safety critical applications might require a much more
rigorous standard, but I'd be satisfied with a stability standard for
PC/Workstation OS's that demonstrated that you really had to work hard
to make the OS crash and that it could be up and running indefinitely
without observable problems.

MDC
 >
 >
 > I know of no operating system which does not crash because of
 > application behaviour. Some does so more seldom than others, but they
 >  still do.
 >
 >
 > greetings,
 >
 >
 >

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Marin David Condic wrote:

> It may have been possible to
>kill it, but if it could stay up and running for months on end and not
>crash under a large variety of uses, this ought to be good enough for a
>large variety of users.

Well, I can exactly tell you when we had a power outage the last time:

|1:46pm  up 209 days,  4:22,  1 user,  load average: 2.00, 2.00, 2.03

Is that "good enough" already?


SCNR,

Vinzent.

Re: Quality systems

[Peter Hermann]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> that modular types are associated with unsigned numbers. In my view it 
> would be more consistent to have:
> type X is mod range -2..4;

oh noo! please dont open that can of worms with all its intricacies.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Larry Kilgallen]

In article <baidl0$267i$1@ID-175126.news.dfncis.de>, Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
> Marin David Condic wrote:
> 
>> It may have been possible to
>>kill it, but if it could stay up and running for months on end and not
>>crash under a large variety of uses, this ought to be good enough for a
>>large variety of users.
> 
> Well, I can exactly tell you when we had a power outage the last time:
> 
> |1:46pm  up 209 days,  4:22,  1 user,  load average: 2.00, 2.00, 2.03
> 
> Is that "good enough" already?

Certainly not, even though that uptime and failure reason match my own.
I always figure my failure to provide a UPS is my own problem, but
there are some whose needs are more critical.

The record I know of without a reboot is about 16 years, for the Irish
Railway.  When they finally brought the machine down, it was running a
_very_ old version of the operating system.

But that machine did not have a wide variety of usages, and the OS was
old enough that some of those user-provoked crashes we know from history
were likely still present.

But we are concerned about the defects that have _not_ yet been fixed
in contemporary releases of the operating system.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Tarjei T. Jensen]

"Larry Kilgallen" wrote:
> Seven versions later, that is now gone,
> and most of the crashes I read about (but do not experience myself) are
> exotic race conditions that might not be encountered with zero load,
> but certainly are not a direct response to any particular application
> activity.

Does it matter as long as the system crashes?

greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Larry Kilgallen]

In article <3ecca391$1@news.wineasy.se>, "Tarjei T. Jensen" <tarjei.jensen@ake
h rkvaerner.com> writes:
> Marin David Condic wrote:
>> True, but with an OS this is achievable. It is possible to build an OS
> that
>> won't crash because of the particular application being run on it. (Or at
>> least crash so infrequently as to be practically the same thing).
> 
> I know of no operating system which does not crash because of application
> behaviour. Some does so more seldom than others, but they still do.

Seeming to indicate reproducible conditions that are relatively easy
for a trustworthy OS vendor to replicate in order to determine the defect
and eliminate it.

In article <3eccccc3$1@news.wineasy.se>, "Tarjei T. Jensen" <tarjei.jensen@akerkvaerner.com> writes:
> 
> "Larry Kilgallen" wrote:
>> Seven versions later, that is now gone,
>> and most of the crashes I read about (but do not experience myself) are
>> exotic race conditions that might not be encountered with zero load,
>> but certainly are not a direct response to any particular application
>> activity.
> 
> Does it matter as long as the system crashes?

If you don't care about the system crashing, it does not matter.

Otherwise it is useful to know the relative ease with which the OS
vendor could have eliminated the problem.  Non-reproducible problems
may require entirely different software design techniques and dumping
previous code.  Many operating system vendors are unwilling to do that.

Reproducible problems typically require simple debugging and fixing up.
Operating system vendors who cannot accomplish that do not seem to me
worthy of trust.

Of course this all depends on the application.  My ReplayTV has an
OS race condition leading to occasional hangs.  I deal with it by
cooling the unit and not pressing buttons too quickly.

Re: Quality systems

[Dmitry A. Kazakov]

Peter Hermann wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> that modular types are associated with unsigned numbers. In my view it
>> would be more consistent to have:
>> type X is mod range -2..4;
> 
> oh noo! please dont open that can of worms with all its intricacies.

Why? Bit-wise operations should be disallowed anyway, I think it is a common 
feeling.

The rest is well-defined:

For any @ = {+, -, *, /} the corresponding operation of a type T can be 
defined as

((a @ b) mod (T'Last - T'First + 1)) + T'First

BTW, I think that ranges should have other semantic for modular types than 
now:

for I in T'(4)..T'(0) loop -- should go through 4, -2, -1, 0

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Randy Brukardt]

Brian Gaffney wrote in message
<5e9b8c34.0305211211.75bdfc5d@posting.google.com>...
>"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in
message news:<xzNwa.145$nE3.93@newssvr16.news.prodigy.com>...
>> <achrist@easystreet.com> wrote in message
>> > There was not only a 640 kb limit, there were some 64 kb limits
>> > on the size of memory segments in most of the PC software prior to
>> > 1987.  I don't recall ever seeing an Ada product or tool that would
>> > run on an 8086 or 8088 without special hardware added.  Were there
>> > any?
>>
>> If I am to believe the documentation for the Meridian compilier
version 4.1
>> it should work on a 8086
>> with MS-DOS version 2.1 or later
>>
>> I have never tested it in that environment, so I can not confirm the
claim
>>
>
>I just happen to have a copy of Meridian Open Ada 4.1 for _PC_ DOS
>sitting on my desk.  And yes it does just that - I've used in on a NEC
>Ultralight laptop (~8086) with 640k RAM and a 2Mb RAM 'hard disk'.
>Not that I use the compiler currently, 640k limit, 5 1/4 floppies, and
>all that.
>
>Anyone know who 'owns' this product now (if anyone)?  I had tracked it
>thru 3 or 4 company changes, but never found anything recent.


For what it's worth, the basic Janus/Ada 83 compiler works fine in a
640K MS-DOS environment. And it's still available (at least until the
manuals run out, and we have several hundred left).  We also have a
number of the DOS-Extender version of that compiler left (that allows
the compilation of larger programs targetting a 640K DOS environment).
If you're doing anything serious, you'd prefer that version.

The quality of the Meridian product was suspect. We had lots of bug
reports from people trying to port code to Janus/Ada from some other
compiler. Usually, if the compiler was Alsys or Telesoft or Verdix, the
bug was in Janus/Ada (and we fixed it promptly). But if the compiler was
Meridian, the code was always illegal Ada that somehow was accepted by
that compiler; the Janus/Ada compiler was right. I don't think there
ever was a single instance of such a report where the Meridian compiler
was correct.

In any case, Meridian was sold to Verdix, who was sold to Rational, who
was sold to IBM. I'm pretty sure no one can find that anymore. RRS is
still here; we'll still support Janus/Ada 83.

                   Randy Brukardt
                   R.R. Software, Inc.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Randy Brukardt]

achrist@easystreet.com wrote in message
<3ECC37F8.29CD9152@easystreet.com>...
>>
>> I just happen to have a copy of Meridian Open Ada 4.1 for _PC_ DOS
>> sitting on my desk.  And yes it does just that - I've used in on a
NEC
>> Ultralight laptop (~8086) with 640k RAM and a 2Mb RAM 'hard disk'.
>> Not that I use the compiler currently, 640k limit, 5 1/4 floppies,
and
>> all that.
>>
>
>What's the date on this product?  Is it really from the early days
>of PC's (e.g. 1985 o earlier)?


Meridian I believe came out in 1986 or so. Janus/Ada was available on
PCs from early 1983 onwards, although the full Ada version wasn't
released until 1987. But before Meridian there was Artek and before them
there was Supersoft. And both Supersoft and early Janus/Ada ran on
CP/M-80 on a Z-80 (these obviously were subsets). Janus/Ada always had
versions available for less than $300, and usually had a $99 version.
(The basic MS-DOS version now is $129.)

                  Randy Brukardt.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Randy Brukardt]

Robert A Duff wrote in message ...
>Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
>> Currently this thing is written in assembly language, but if I'd ever
>> reengineer that in Ada I'd definitely use a (non-binary) modular type
>> for the index then (and an array with 16 entries instead). Of course,
>> as you pointed out, I could do the modulo arithmetic by hand, but why
>> if I can let the compiler handle it?
>
>Because it makes the code easier to understand if the "mod" is
explicit.


I agree, especially because the generated code for modular types is
ugly.

My personal opinion is that wrap-around semantics for unsigned types is
a mistake. Ada is about safety, and there is no safety in 2+2=1. I
thought and still think that we should have added unsigned integer types
with overflow, and then had a special package with wrap-around types of
the full sizes for those rare cases where you need such functionality.

Virtually every time I use a modular type, I end up tracking down some
bug at runtime that would have been caught had there been an overflow
check. (Typically in the creation of an array index or the like.) Most
of the these types are 'indexes' (handles) that have to fit in a
particular size, and I often write checks like:
    if Index-1 > 0 then
        Index := Index - 1;
    end if;
which is wrong for a modular type. (Consider Index=0).

                         Randy.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Randy Brukardt wrote:
> Virtually every time I use a modular type, I end up tracking down some
> bug at runtime that would have been caught had there been an overflow
> check.

Why are you using a modular type if you don't want the wraparound
semantics? Just use regular types and do the mod yourself. It seems
unAdalike to use the wrong tool for the job.

> I often write checks like:
>     if Index-1 > 0 then

Many of us would write
     if Index > 1
and then not have any problems. Why do it the unnatural way?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[The Ghost In The Machine]

In comp.lang.java.advocacy, Hyman Rosen
<hyrosen@mail.com>
 wrote
on Wed, 21 May 2003 10:22:10 -0400
<1053526931.61358@master.nyc.kbcfp.com>:
> The Ghost In The Machine wrote:
>> The problem is that if one defines
>> #define begin(a) (a)
>> #define end(a) ((a) + sizeof(a)/sizeof((a)[0]))
> 
> You really did miss my other post, didn't you? :-)
>      template <typename T, size_t N> T *begin(T (&a)[N]) { return a;     }
>      template <typename T, size_t N> T *end  (T (&a)[N]) { return a + N; }
> Using array references prevents the decay to pointer and
> allows both the array size and type to be deduced.
> 

Oops.  You're absolutely right!  I'll admit, though, that
I'm not entirely sure what the function calls (as opposed
to the function defs above) would look like.

Probably

begin<int, 10>(a)
end<int, 10>(a)

which isn't very pretty looking either.

However, it turns out, strangely enough, that

int a[10];

begin(a)
end(a)

actually does in fact work on g++, so hopefully you'll forgive me. :-)
It's certainly an interesting capability.

(What do these look like in C#?)

-- 
#191, ewill3@earthlink.net
It's still legal to go .sigless.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Richard Riehle]

Randy Brukardt wrote:

> In any case, Meridian was sold to Verdix, who was sold to Rational, who
> was sold to IBM. I'm pretty sure no one can find that anymore. RRS is
> still here; we'll still support Janus/Ada 83.

And no one is supporting Meridian anymore.  Rational, after acquiring
ownership of Meridian promptly sold it to another publisher.  If I recall
correctly, that was Harcourt-Brace.  No one has any idea what Harcourt
intended to do with it but they seem to have allowed it to vanish.

Any current copy of Meridian is probably out of copyright and can
probably be used freely.  However, as Randy points out, Janus is
still supported and can be purchased at a pretty reasonable price.

Richard Riehle

Re: Quality systems (Was: Using Ada for device drivers? (Was: theAda mandate, and why it collapsed and died))

[Richard Riehle]

Hyman Rosen wrote:

> That doesn't mean that Ada didn't copy the notion from C.

It did not copy the notion from C.  Modular types are an old
form of  type.  Some of the early Ada 83 compilers did support
an Unsigned Type (Alsys).

I recall some projects where there was no direct unsigned
type support and it caused all sorts of complicated problems.
This was not added because C had it but because it was
clearly necessary for a large range of software solutions.

Richard Riehle

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Randy Brukardt wrote:

> Virtually every time I use a modular type, I end up tracking down some
> bug at runtime that would have been caught had there been an overflow
> check. (Typically in the creation of an array index or the like.) Most
> of the these types are 'indexes' (handles) that have to fit in a
> particular size, and I often write checks like:
>     if Index-1 > 0 then
>         Index := Index - 1;
>     end if;
> which is wrong for a modular type. (Consider Index=0).

But a modular type should have no "<" defined! A transitive "<" is 
incompatible with modular "+" and "-".

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dale Stanbrough]

Richard Riehle <richard@adaworks.com> wrote:

> Randy Brukardt wrote:
> 
> > In any case, Meridian was sold to Verdix, who was sold to Rational, who
> > was sold to IBM. I'm pretty sure no one can find that anymore. RRS is
> > still here; we'll still support Janus/Ada 83.
> 
> And no one is supporting Meridian anymore.  Rational, after acquiring
> ownership of Meridian promptly sold it to another publisher.  If I recall
> correctly, that was Harcourt-Brace.  No one has any idea what Harcourt
> intended to do with it but they seem to have allowed it to vanish.

I recall that they intended to issue an Ada book with the compiler in the
back. 

> Any current copy of Meridian is probably out of copyright and can
> probably be used freely.  However, as Randy points out, Janus is
> still supported and can be purchased at a pretty reasonable price.

Threw my copy in the bin quite some time ago.

Dale

RE: Quality systems (Was: Using Ada for device drivers? (Was: theAda mandate, and why it collapsed and died))

[Robert C. Leif]

I agree. When one models instrument data, the possibility of undetected
overflows has to be dealt with. Most of my data are unsigned 16 (0 to 2**16)
and 32 (0 to 2**32) bit numbers. 

An example of the need for the use of Ada software for this type of data in
scientific software follows. Presently, my company, Newport Instruments,
develops ultrasensitive tags for cell and clinical analysis. We have a
special ultrasensitive camera to image cells stained with these tags. Our
final images are the summation of 1,000 to 10,000 individual images produced
by flashlamp excitation. The individual images have a resolution of 12 bits.
The C++ programmer, who wrote the imaging software for the company that
provided the camera, summed them as 16 bit integers. Therefore, the camera
often produces nonrepresentational art instead of scientific data. This
summer's project is to create Ada packages that directly interface with the
existing DCOM objects and use XForms as the GUI to store and display the
images.

Bob Leif

-----Original Message-----
From: Randy Brukardt [mailto:randy@rrsoftware.com] 
Sent: Thursday, May 22, 2003 2:15 PM
To: comp.lang.ada@ada.eu.org

Robert A Duff wrote in message ...
>Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
>> Currently this thing is written in assembly language, but if I'd ever
>> reengineer that in Ada I'd definitely use a (non-binary) modular type
>> for the index then (and an array with 16 entries instead). Of course,
>> as you pointed out, I could do the modulo arithmetic by hand, but why
>> if I can let the compiler handle it?
>
>Because it makes the code easier to understand if the "mod" is
explicit.


I agree, especially because the generated code for modular types is
ugly.

My personal opinion is that wrap-around semantics for unsigned types is
a mistake. Ada is about safety, and there is no safety in 2+2=1. I
thought and still think that we should have added unsigned integer types
with overflow, and then had a special package with wrap-around types of
the full sizes for those rare cases where you need such functionality.

Virtually every time I use a modular type, I end up tracking down some
bug at runtime that would have been caught had there been an overflow
check. (Typically in the creation of an array index or the like.) Most
of the these types are 'indexes' (handles) that have to fit in a
particular size, and I often write checks like:
    if Index-1 > 0 then
        Index := Index - 1;
    end if;
which is wrong for a modular type. (Consider Index=0).

                         Randy.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Randy Brukardt]

Hyman Rosen wrote in message ...
>Randy Brukardt wrote:
>> Virtually every time I use a modular type, I end up tracking down
some
>> bug at runtime that would have been caught had there been an overflow
>> check.
>
>Why are you using a modular type if you don't want the wraparound
>semantics? Just use regular types and do the mod yourself. It seems
>unAdalike to use the wrong tool for the job.


Your basic point is right, of course, but Ada doesn't quite completely
cover the possibilities. Sometimes, the only choice is a modular type.

Ada doesn't have unsigned but checked integer types. You can define an
unsigned subtype of a signed type, but not all compilers support the
unsigned representation, and most do math with the next larger size of
signed math. Depending on the processor, that can be more expensive (for
instance, if the compiler supports 64-bit math on a 32-bit machine).
Moreover, if you want the largest possible unsigned type (say 0 ..
2**32-1 or 0 .. 2**64-1), it has to be modular; you can't declare the
needed signed type to make a subtype.

>> I often write checks like:
>>     if Index-1 > 0 then
>
>Many of us would write
>     if Index > 1
>and then not have any problems. Why do it the unnatural way?


Because the expression is usually more complex than that, and in any
case, the problem makes it more natural to write it this. Of course, you
can refactor it -- that's how I usually fix such bugs -- but that
usually makes the code harder to understand.

In any case, this is a relatively minor issue. It's annoying that Ada is
less safe than it can be, but you can live with it.

               Randy.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Randy Brukardt wrote:
> 
> > Virtually every time I use a modular type, I end up tracking down some
> > bug at runtime that would have been caught had there been an overflow
> > check. (Typically in the creation of an array index or the like.) Most
> > of the these types are 'indexes' (handles) that have to fit in a
> > particular size, and I often write checks like:
> >     if Index-1 > 0 then
> >         Index := Index - 1;
> >     end if;
> > which is wrong for a modular type. (Consider Index=0).
> 
> But a modular type should have no "<" defined! A transitive "<" is 
> incompatible with modular "+" and "-".

But I think Randy and I are saying that a type with transitive "<"
should not have modular semantics.

- Bob

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Randy Brukardt wrote:
>> 
>> > Virtually every time I use a modular type, I end up tracking down some
>> > bug at runtime that would have been caught had there been an overflow
>> > check. (Typically in the creation of an array index or the like.) Most
>> > of the these types are 'indexes' (handles) that have to fit in a
>> > particular size, and I often write checks like:
>> >     if Index-1 > 0 then
>> >         Index := Index - 1;
>> >     end if;
>> > which is wrong for a modular type. (Consider Index=0).
>> 
>> But a modular type should have no "<" defined! A transitive "<" is
>> incompatible with modular "+" and "-".
> 
> But I think Randy and I are saying that a type with transitive "<"
> should not have modular semantics.

This or that way (:-))

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert I. Eachus]

Randy Brukardt wrote:

> Ada doesn't have unsigned but checked integer types. You can define an
> unsigned subtype of a signed type, but not all compilers support the
> unsigned representation, and most do math with the next larger size of
> signed math. Depending on the processor, that can be more expensive (for
> instance, if the compiler supports 64-bit math on a 32-bit machine).
> Moreover, if you want the largest possible unsigned type (say 0 ..
> 2**32-1 or 0 .. 2**64-1), it has to be modular; you can't declare the
> needed signed type to make a subtype.

> In any case, this is a relatively minor issue. It's annoying that Ada is
> less safe than it can be, but you can live with it.

It also seems like a problem that is easy to fix in Ada0Y, if not just 
by getting compilers to do the right thing.

You want to be able to say:

type Unsigned is range 0..2**32-1;
for Unsigned'Size use 32;

There are three potential solutions for Ada0Y:

1) All vendors agree to support such a declaration.  (What about you Randy?)

2) Such a type is declared in Standard, probably saying:
for Unsigned'Size use Integer'Size;
This type should be a non-standard integer type in the sense of 
3.5.4(25).  It could also be declared in a package other than Standard, 
possibly System.  After all it is very likely that System.Address will 
be such a type.

3) Add a pragma Unsigned which has to be used immediately after a type 
declaration, and has the semantic effect that negative values of the 
type can raise Constraint_Error even on intermediate calculations.  In 
other words A-B+C could raise an exception if B < A, even if B < A+C.

I think that solution two is probably the right choice.  After all what 
Randy is saying is that it is the particular case which the current 
language doesn't guarantee to work and that he needs.  Those of us who 
want real modular types can ignore the silly inequality operators that 
are there but we would never use.  (Well, not really.  There are some 
cases where A < B is useful shorthand for:

A, B: Modular;
...
if Some_Integer_Type(A) < Some_Integer_Type(B) then...

Of course, those implicit conversions to an integer type prevent 
refactoring.)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> But a modular type should have no "<" defined! A transitive "<" is 
> incompatible with modular "+" and "-".

I will try this argument next time I come in to work at 10am
and am accused of being late!

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

The Ghost In The Machine wrote:
> (What do these look like in C#?)

They don't, since all of the languages that "improve" upon C++
have chosen to discard templates as the second step in the process.
(The first is to discard multiple inheritance.) I don't mean to
include Ada in this category, by the way.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dale Stanbrough]

 Hyman Rosen <hyrosen@mail.com> wrote:

> hey don't, since all of the languages that "improve" upon C++
> have chosen to discard templates as the second step in the process.
> (The first is to discard multiple inheritance.) I don't mean to
> include Ada in this category, by the way.

Coming soon to a Java near you - templates.

Whether they count as templates I don't know, but Java 1.5 will have
generics, with a definately C++ like syntax.

Dale

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Dale Stanbrough wrote:
> Whether they count as templates I don't know, but Java 1.5 will have
> generics, with a definately C++ like syntax.

But with nothing like the C++ semantics, as far as I know.
For example, I believe you will not be able to have two
overloaded methods of the form
     void foo(Box<Nails> b)
     void foo(Box<Snails> b)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> But a modular type should have no "<" defined! A transitive "<" is
>> incompatible with modular "+" and "-".
> 
> I will try this argument next time I come in to work at 10am
> and am accused of being late!

Your manager would point you out that in Ada the type Time is not modular! 
(:-))

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Matthew Woodcraft]

In article <3ECFF541.1010705@attbi.com>,
Robert I. Eachus <rieachus@attbi.com> wrote:
>It also seems like a problem that is easy to fix in Ada0Y, if not just 
>by getting compilers to do the right thing.
>
>You want to be able to say:
>
>type Unsigned is range 0..2**32-1;
>for Unsigned'Size use 32;

I would certainly like to see something of the sort.

At the moment, we have:

[3.5.4]
| 9   A signed_integer_type_definition defines an integer type whose
| base range includes at least the values of the simple_expressions and
| is symmetric about zero, excepting possibly an extra negative value. 
| A signed_integer_type_definition also defines a constrained first
| subtype of the type, with a range whose bounds are given by the
| values of the simple_expressions, converted to the type being
| defined.

It seems to me that something like your solution three would be needed:

>3) Add a pragma Unsigned which has to be used immediately after a type 
>declaration, and has the semantic effect that negative values of the 
>type can raise Constraint_Error even on intermediate calculations.  In 
>other words A-B+C could raise an exception if B < A, even if B < A+C.

3.5.4.9 would presumably need to change so that for unsigned types the
base range didn't include negative integers?

-M-

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

While you guys are at the business of creating new numeric types for 
Ada0y, how about one of my favorite types - some form of a saturated 
math type? It would be nice to have support for the basic math types 
that would saturate instead of wrap-around or overflow/exception. How 
difficult or inefficient would that be to implement?

MDC


> 
> 
> It also seems like a problem that is easy to fix in Ada0Y, if not just 
> by getting compilers to do the right thing.
> 
> You want to be able to say:
> 
> type Unsigned is range 0..2**32-1;
> for Unsigned'Size use 32;
> 

Re: Quality systems (Was: Using Ada for device drivers? (Was: theAdamandate, and why it collapsed and died))

[Tarjei T. Jensen]

Randy Brukardt wrote:
>My personal opinion is that wrap-around semantics for unsigned types is
>a mistake. Ada is about safety, and there is no safety in 2+2=1. I
>thought and still think that we should have added unsigned integer types
>with overflow, and then had a special package with wrap-around types of
>the full sizes for those rare cases where you need such functionality.

The problem is that there seemed to have been an misunderstanding in parts
of the Ada community with regards to certain _t types (e.g. size_t) in
Unix/C.  They seem to have been unaware that these types were unsigned in
order to get a larger range and not because unsigned types wraps.

greetings,

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

Marin David Condic wrote:
> How difficult or inefficient would that be to implement?

Certainly no more so than the code you write to do it yourself,
and then everyone would have it once and for all. What effect
do you want when you subtract from a saturated value, though?
Do you want semantics of infinity, or can the result go below
the maximum value? Both?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert I. Eachus]

Hyman Rosen wrote:
> Dmitry A. Kazakov wrote:
> 
>> But a modular type should have no "<" defined! A transitive "<" is 
>> incompatible with modular "+" and "-".
> 
> 
> I will try this argument next time I come in to work at 10am
> and am accused of being late!
> 

Reminds me of an occasion when the main machine we were using for Ada 
compiler validatation crashed about a week before the validation team 
was scheduled to show up--during back-up.  Worse the idiot manager for 
the machine room had "simplified" the explicit backup rules which used 
three disk volumes so that he only needed two.  You guessed it the crash 
was in the operational pack, and the backup was half-erased and 
half-written.

I found out about this when I checked the machine room on my way out the 
door.   Computer room 1 was near the main entrance. And our server was 
near the computer room door.  So my coat and briefcase went in a chair, 
and I told the operator to "touch nothing!"  I put a bootable disk in a 
third drive and started putting the pieces together to see what should 
be recovered.  (And then called my wife to tell her not to wait dinner.)

It turned out that the damage was to the VTOC (volume table of contents) 
on the original drive.  The files were all there, they just had to be 
recovered with a disk repair utility.

Around 10 AM I finished validating that I had recreated a valid bootable 
disk with all the files and started making a copy to a third pack.  I 
went up to my office, carrying my briefcase and coat.

My boss ambushed me, literally frothing at the mouth.  "The server is 
down, the machine room supervisor says you ordered him not to touch the 
machine, and I left word at the guard station to have you call me the 
moment you came in."

"I didn't come in, but the server is up now."
"Huh."
"The guard didn't have me call you since I didn't come in.  I was here 
all night..."

We were back on schedule by that afternoon after a bit of schedule 
shifting to get the large server off the critical path.  But the 
supervisor was gone.  It turned out HE had called Dick and Alan (my 
boss's boss) to complain about being ordered not touch one of "his" 
machines.  But he hadn't explained that I was in the machine room at the 
time--and what he had done to get to the top of my shit list.

Earlier he had stopped one machine in the middle of a B-test series run: 
"It was printing out all these error messages, so I shut it down."  In 
spite of a large "Do not touch" sign.  Then he shut down a machine 
because it just sat there with 100% utilization, and no output. 
(Looking for a subtle memory leak.  It turned out to be a case where the 
OS on a 32-bit machine was rounding an allocation from the stack up to a 
multiple of four, then rounding to a multiple of two when freeing the 
space.)

This was the third time the machine room supervisor had disobeyed 
explicit instructions in the log in less than three weeks.  Bye, bye.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert I. Eachus]

Matthew Woodcraft wrote:

> 3.5.4.9 would presumably need to change so that for unsigned types the
> base range didn't include negative integers?

No, what is wanted/needed is a non-standard integer type as defined in 
3.5.4(26): "An implementation may provide nonstandard integer types, 
descendants of root_integer that are declared outside of the 
specification of package Standard, which need not have all the standard 
characteristics of a type defined by an integer_type_definition. For 
example, a nonstandard integer type might have an asymmetric base range 
or it might not be allowed as an array or loop index (a very long 
integer). Any type descended from a nonstandard integer type is also 
nonstandard. An implementation may place arbitrary restrictions on the 
use of such types; it is implementation defined whether operators that 
are predefined for ``any integer type'' are defined for a particular 
nonstandard integer type. In any case, such types are not permitted as 
explicit_generic_actual_parameters for formal scalar types -- see 12.5.2."

This is under implementation permissions.  In effect what I was doing 
was tweaking a few noses.  This permission has always been "in there." 
Some compilers did provide explicit non-standard unsigned integer types 
in Ada 83, and in many Ada 83 compilers, System.Address was exactly such 
a type.

But now in GNAT: type Address is mod Memory_Size;  which is precisely 
correct on most hardware.  Adding indexes wraps, and even when the index 
size is less than the address size, there is no sign extension.

Are unsigned types required?  I don't know.  I know I have never had a 
use for them, but I have had and continue to have a need for modular 
types.  I just don't see a conflict.

The same thing goes for saturating arithmetic.  There are cases where it 
is needed.  But as far as I am concerned for integer, float, and fixed 
point types it is possible to create these by overriding the arithmetic 
operators.  If they really are needed, I would expect to see users 
complaining about the inconveniences of the overriding approach, but I 
haven't seen that.  I've seen wouldn't it be nice...

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Well, the usefullness of saturated math can be seen in something as
simple as plotting a line on a screen. If the center of the screen is
(0,0) and you start moving your line off towards any edge of the screen,
when you hit the edge, you'd like for it to stop. So if you have a + & -
boundary on it, you want it to saturate at either end. You'd probably
want the bounds to be asymetric because often the real-world bounds are
just that.

This is a very useful characteristic in control systems where an
actuator has some "safe" limit of motion. Any accidental motion beyond
the limits might slam an actuator arm into a mechanical stop, for
example. Hence, you never want to command a position outside the bounds,
but the behavior of all Ada math types is - well - inadequate without
"Field Improvements". Wraparound semantics would only command the
actuator 100% in the opposite direction. (That's called "A Bad Thing" in
the technical jargon. :-) Exceptions help, but that can send you into
some sort of "Reset" conditon wherein your control is now out of
control. (Also called "A Bad Thing") Whereas, if you had some
misbehaving control loop that accidentally commanded 110% of the range
limit, it would get clipped to 100% and you'd be safe.

I'm pretty sure it would have usefulness in a variety of areas -
especially things like graphics. However, the usual "homegrown"
solutions can suffer from performance problems - or at least be
difficult to get done efficiently. Ideally, you'd like it to be
supported in the hardware. Getting it done (efficiently) as a matter of
course for the compiler, is the next best answer. Homebrew solutions can
(and have) been done, but why not ask for it from the compiler?

I didn't used to have modular types in Ada83 and one could say "Well
brew up a batch for yourself and quit whining" :-) so why did they make
it into Ada95 as a standard type? It probably started with "convenience"
and moved into "type safety" issues and eventually found all sorts of
new and interesting uses because it modeled the problem space nicely. I
think saturated math would do the same.

MDC

Hyman Rosen wrote:
 > Marin David Condic wrote:
 >
 >> How difficult or inefficient would that be to implement?
 >
 >
 > Certainly no more so than the code you write to do it yourself, and
 > then everyone would have it once and for all. What effect do you want
 > when you subtract from a saturated value, though? Do you want
 > semantics of infinity, or can the result go below the maximum value?
 > Both?
 >


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Hyman Rosen]

What semantics do you want for the arithmetic? For example,
IEEE floats have saturation (using infinity), but once you
get there you stay there. It sounds like what you want is
different, in that subtraction from the high limit gets you
back down. That has various effects, such as making addition
no longer be associative, so you could very easily write
erroneous programs which would trigger saturation effects
on some platforms but not others.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Pretty simple stuff. Suppose you had a type like:

type Saturated_Integer is range -10..10 ;

and an object of that type such as:

X : Saturated_Integer := 9 ;

and then:

X := X + 4 ;

would mean:

(X = 10)

and later you might do:

X := X - 25 ;

and you get

(X = -10)

I don't know of any hardware that would do this for either floating 
point or integer numbers, so I'd suspect it would not be practical to do 
anything but implement it in software. You'd probably want to do 
whatever it is you do to check for an overflow on a subtype, but instead 
of raising an exception, you plug it with the max value and continue to run.

The idea is that you're not exactly catching an error in the code - 
presumably you should be building the code such that it doesn't compute 
values outside of the valid range - but if there is such an error, it 
lets the code continue to run uninterrupted and do something that might 
be more sensible than halting with an exception or wrapping around to 
the opposite end of the range. I'm sure there would be issues about 
where the range checks would have to be performed, how efficient the 
checks would be, the consequences of turning off checks and what it does 
to your worst-case behavior if it takes the failure path. Still, it 
seems like a useful feature for some kinds of jobs.

MDC

Hyman Rosen wrote:
> What semantics do you want for the arithmetic? For example,
> IEEE floats have saturation (using infinity), but once you
> get there you stay there. It sounds like what you want is
> different, in that subtraction from the high limit gets you
> back down. That has various effects, such as making addition
> no longer be associative, so you could very easily write
> erroneous programs which would trigger saturation effects
> on some platforms but not others.
> 


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dale Stanbrough]

Marin David Condic <nobody@noplace.com> wrote:


> I don't know of any hardware that would do this for either floating 
> point or integer numbers, so I'd suspect it would not be practical to do 
> anything but implement it in software. You'd probably want to do 
> whatever it is you do to check for an overflow on a subtype, but instead 
> of raising an exception, you plug it with the max value and continue to run.


I'm pretty sure that the PowerPC chip's Altivec instruction has this.

yes, google says...

   http://e-www.motorola.com/brdata/PDFDB/docs/ALTIVECPIM.pdf

which indicates saturated maths is for integral types.

Dale

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Randy Brukardt]

Robert I. Eachus wrote in message <3ECFF541.1010705@attbi.com>...
>Randy Brukardt wrote:
>
>> Ada doesn't have unsigned but checked integer types. You can define
an
>> unsigned subtype of a signed type, but not all compilers support the
>> unsigned representation, and most do math with the next larger size
of
>> signed math. Depending on the processor, that can be more expensive
(for
>> instance, if the compiler supports 64-bit math on a 32-bit machine).
>> Moreover, if you want the largest possible unsigned type (say 0 ..
>> 2**32-1 or 0 .. 2**64-1), it has to be modular; you can't declare the
>> needed signed type to make a subtype.
>
>> In any case, this is a relatively minor issue. It's annoying that Ada
is
>> less safe than it can be, but you can live with it.
>
>It also seems like a problem that is easy to fix in Ada0Y, if not just
>by getting compilers to do the right thing.
>
>You want to be able to say:
>
>type Unsigned is range 0..2**32-1;
>for Unsigned'Size use 32;
>
>There are three potential solutions for Ada0Y:
>
>1) All vendors agree to support such a declaration.  (What about you
Randy?)

Our code generators always have supported unsigned and checked types. I
had to add a set of special operations to support the wrap-around
semantics of

But: this type is very nasty for code shared generics. It essentially
means that you cannot share generics with formal integer types, or you
have to have bizarre operations that decide at runtime whether they are
handling a signed or unsigned type. (Ada 95 has a little of this for
formal discrete types, but it never happens in practice.)

>2) Such a type is declared in Standard, probably saying:
>for Unsigned'Size use Integer'Size;
>This type should be a non-standard integer type in the sense of
>3.5.4(25).  It could also be declared in a package other than Standard,
>possibly System.  After all it is very likely that System.Address will
>be such a type.


Non-standard avoids the generic problem, but it makes one wonder why
this isn't a first class type.

>3) Add a pragma Unsigned which has to be used immediately after a type
>declaration, and has the semantic effect that negative values of the
>type can raise Constraint_Error even on intermediate calculations.  In
>other words A-B+C could raise an exception if B < A, even if B < A+C.


Yuck.

               Randy.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[AG]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3ED353BE.40605@noplace.com...
> Pretty simple stuff. Suppose you had a type like:
>
> type Saturated_Integer is range -10..10 ;
>
> and an object of that type such as:
>
> X : Saturated_Integer := 9 ;
>
> and then:
>
> X := X + 4 ;
>
> would mean:
>
> (X = 10)
>
> and later you might do:
>
> X := X - 25 ;
>
> and you get
>
> (X = -10)

But that means that something somewhere
must have an actual counter which keeps
the actual value of what you pretend is
a saturated integer. After all, you, as
the user of the saturated type, don't
(or shouldn't) know if one saturated
number is equal to another - they are
all equal in a sense. But whatever
implements them obviously must. So,
what about this (assuming X is already
saturated and Y is the largest unsaturated
number):

if Y = X - 1 then

Should that tell me I've got the smallest
saturated number? Can I then count them?
(I've got the smallest number and I have
"+", "-", "<", ">" etc) - looks like an ordinary
integer now. Almost.

Can I do something like

for I in X..Y  ? What would that do if
there are several saturated values in that
range?

It looks like what you describe is just
a simple matter of having a much wider
actual range but providing some sort
of a checked conversion/mapping
which just does the range checking
on the number and overrides it with
a limit if needed..

It's not hard to implement either
as a custom code or some utility
library. However, pushing it onto
the compiler seems to open all
kinds of semantic cans of worms.

Unless I misunderstood your
point of course.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Marin David Condic wrote:

> Pretty simple stuff. Suppose you had a type like:
> 
> type Saturated_Integer is range -10..10 ;
> 
> and an object of that type such as:
> 
> X : Saturated_Integer := 9 ;
> 
> and then:
> 
> X := X + 4 ;
> 
> would mean:
> 
> (X = 10)
> 
> and later you might do:
> 
> X := X - 25 ;
> 
> and you get
> 
> (X = -10)
> 
> I don't know of any hardware that would do this for either floating
> point or integer numbers, so I'd suspect it would not be practical to do
> anything but implement it in software. You'd probably want to do
> whatever it is you do to check for an overflow on a subtype, but instead
> of raising an exception, you plug it with the max value and continue to
> run.
> 
> The idea is that you're not exactly catching an error in the code -
> presumably you should be building the code such that it doesn't compute
> values outside of the valid range - but if there is such an error, it
> lets the code continue to run uninterrupted and do something that might
> be more sensible than halting with an exception or wrapping around to
> the opposite end of the range. I'm sure there would be issues about
> where the range checks would have to be performed, how efficient the
> checks would be, the consequences of turning off checks and what it does
> to your worst-case behavior if it takes the failure path. Still, it
> seems like a useful feature for some kinds of jobs.

Aha! There is a mathematical analogy of what you need. It is a finite set of 
numbers with two additional infinite elements ]-oo,T'First] and 
[T'Last,+oo[. Thus

   type Saturated_Integer is range -10..10;

could be something like {]-oo,-10], -9, ..., 9, [10,+oo[}

for all finite x, [10,+oo[ - x is defined as [10,+oo[. So

(5 + 5) - 5 = [10,+oo[

while

5 + (5 - 5) = 5

Which reminds me horrors of PL/1! (:-)) To avoid this you have to define 
some Universal_Saturated with an infine domain set. This would require 
unlimited precision arithmetics at run-time. Shudder.

Then [10,+oo[ - [10,+oo[ is of course undefined. Thus

X := 9 + 4;
X := X - X  -- Constraint_Error!

But

X := X - 25

is either Constraint_Error or [10,+oo[ (with Universal_Saturated 
arithmetics). Both differ from the semantics you gave.

Mixing saturated types will be full of surprizes:

type T1 is range -10..10;
type T2 is range -100..100;

X : T1 := -10;
Y : T2 := T2 (X); -- Results in -100!

Ergo, I think it would be better to leave that for the realm of user-defined 
type.

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Vinzent Hoefler]

Marin David Condic wrote:

>Pretty simple stuff. Suppose you had a type like:
>
>type Saturated_Integer is range -10..10 ;

Well, yes this could be a nice feature but personally I think, this
would cause too many problems.

>and an object of that type such as:
>
>X : Saturated_Integer := 9 ;
>
>and then:
>
>X := X + 4 ;
>
>would mean:
>
>(X = 10)

Suppose you have an expression like:

X := X + 4 - 4;

(Those fours might not be actual constants)

What would be the result then?

6 if the expression is evaluated left-to-right or 9 if "4 - 4" is
evaluated first and then applied to X?

>I don't know of any hardware that would do this for either floating 
>point or integer numbers,

Well, at least Intels MMX has something similar, but of course it only
saturates to 16#7FFF...# for signed and 16#FFFF...# for unsigned math.

>so I'd suspect it would not be practical to do 
>anything but implement it in software.

Yes. IMO is has too many bad implications like effects on dependcy
with expression evaluation order.

>You'd probably want to do 
>whatever it is you do to check for an overflow on a subtype, but instead 
>of raising an exception, you plug it with the max value and continue to run.

I think the easy(?) way would be a generic package supplying such sort
of types like this:

|generic
|   type Item is range <>;
|package Saturated_Integer is
|   function "+" (I : Item; Amount : Item) return Item;
|   function "-" (I : Item; Amount : Item) return Item;
|end Saturated_Integer;

Well, I have a problem in successfully overloading the standard
integer operations here...

How do I do that? My understanding of generics is still quite vague.

>Still, it seems like a useful feature for some kinds of jobs.

Well, yes. But it's not an Ada-like feature, is it?


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Saturated math on *any* bounds? How would you do that? It would mean 
having to somehow include the bounds on every math operation. ("add X, 
Y, LB, UB" or something similar) It would be cool if you could do that, 
but there would be obvious speed penalties and difficult instruction 
sets for compilers to target.

MDC

Dale Stanbrough wrote:
> Marin David Condic <nobody@noplace.com> wrote:
> 
> 
> I'm pretty sure that the PowerPC chip's Altivec instruction has this.
> 
> yes, google says...
> 
>    http://e-www.motorola.com/brdata/PDFDB/docs/ALTIVECPIM.pdf
> 
> which indicates saturated maths is for integral types.
> 
> Dale


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Now you're getting all theoretical on me and all I was doing was trying 
to solve a practical problem. :-) Look at it this way: What does an 
Integer do when you add one too many to it? It trips an exception that 
halts normal flow of operation. Sometimes this is the desired behavior. 
What happens when you add one too many to a Modular number? It wraps 
around and continues normal program flow. Sometimes that is the right 
accommodation. What I propose is a Saturated type that when you add one 
too many to it, it ceases to increment beyond its upper bound and normal 
program flow continues.

We're not talking about something that has to have some sort of 
mathematical, logical consistency to it. We're talking about a fault 
accommodation. Sure, whatever calculations you subsequently use the 
number in are going to be "wrong". But isn't that the case with a 
modular type that exceeded its upper bound and wrapped around? You say 
"Yes, but Modular types are useful when properly applied...." The same 
would be true for a Saturated type - properly apply it and any overflows 
that saturate will give you the desired behavior even if the answer is 
"inaccurate".

MDC


AG wrote:
> 
> 
> But that means that something somewhere
> must have an actual counter which keeps
> the actual value of what you pretend is
> a saturated integer. After all, you, as
> the user of the saturated type, don't
> (or shouldn't) know if one saturated
> number is equal to another - they are
> all equal in a sense. But whatever
> implements them obviously must. So,
> what about this (assuming X is already
> saturated and Y is the largest unsaturated
> number):
> 
> if Y = X - 1 then
> 
> Should that tell me I've got the smallest
> saturated number? Can I then count them?
> (I've got the smallest number and I have
> "+", "-", "<", ">" etc) - looks like an ordinary
> integer now. Almost.
> 
> Can I do something like
> 
> for I in X..Y  ? What would that do if
> there are several saturated values in that
> range?
> 
> It looks like what you describe is just
> a simple matter of having a much wider
> actual range but providing some sort
> of a checked conversion/mapping
> which just does the range checking
> on the number and overrides it with
> a limit if needed..
> 
> It's not hard to implement either
> as a custom code or some utility
> library. However, pushing it onto
> the compiler seems to open all
> kinds of semantic cans of worms.
> 
> Unless I misunderstood your
> point of course.
> 
> 


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Quality systems (Was: Using Ada for device drivers? (Was: the

[Larry Kilgallen]

In article <3ED49CA6.1020709@noplace.com>, Marin David Condic <nobody@noplace.com> writes:
> Saturated math on *any* bounds? How would you do that? It would mean 
> having to somehow include the bounds on every math operation. ("add X, 
> Y, LB, UB" or something similar) It would be cool if you could do that, 
> but there would be obvious speed penalties and difficult instruction 
> sets for compilers to target.
> 
> MDC
> 
> Dale Stanbrough wrote:
>> Marin David Condic <nobody@noplace.com> wrote:
>> 
>> 
>> I'm pretty sure that the PowerPC chip's Altivec instruction has this.
>> 
>> yes, google says...
>> 
>>    http://e-www.motorola.com/brdata/PDFDB/docs/ALTIVECPIM.pdf
>> 
>> which indicates saturated maths is for integral types.

Presuming the ability to add and subtract to a storage location
(I don't know the Altivec instructions) would it not suffice to
say that "fetch" is the only operation for which the bounds must
be provided ?

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

That's an interesting analysis, but I don't know that we'd need to get 
that complex. Your basic floating, fixed and integer types have all the 
syntax they need to get the job done. They just need a variant that 
defines a different accommodation in the event that you assign a value 
that exceeds one of the bounds - saturation instead of an exception.

MDC

Dmitry A. Kazakov wrote:
> 
> 
> Aha! There is a mathematical analogy of what you need. It is a finite set of 
> numbers with two additional infinite elements ]-oo,T'First] and 
> [T'Last,+oo[. Thus
> 
>    type Saturated_Integer is range -10..10;
> 
> could be something like {]-oo,-10], -9, ..., 9, [10,+oo[}
> 
> for all finite x, [10,+oo[ - x is defined as [10,+oo[. So
> 
> (5 + 5) - 5 = [10,+oo[
> 
> while
> 
> 5 + (5 - 5) = 5
> 
> Which reminds me horrors of PL/1! (:-)) To avoid this you have to define 
> some Universal_Saturated with an infine domain set. This would require 
> unlimited precision arithmetics at run-time. Shudder.
> 
> Then [10,+oo[ - [10,+oo[ is of course undefined. Thus
> 
> X := 9 + 4;
> X := X - X  -- Constraint_Error!
> 
> But
> 
> X := X - 25
> 
> is either Constraint_Error or [10,+oo[ (with Universal_Saturated 
> arithmetics). Both differ from the semantics you gave.
> 
> Mixing saturated types will be full of surprizes:
> 
> type T1 is range -10..10;
> type T2 is range -100..100;
> 
> X : T1 := -10;
> Y : T2 := T2 (X); -- Results in -100!
> 
> Ergo, I think it would be better to leave that for the realm of user-defined 
> type.
> 


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Saturated Math (was: Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Vinzent Hoefler wrote:

> 
> Suppose you have an expression like:
> 
> X := X + 4 - 4;
> 
> (Those fours might not be actual constants)
> 
> What would be the result then?
> 
Imagine it was a garden variety integer with the same range. What does 
the ARM say it would do? What if it were a modular type with wraparound 
semantics? What does the ARM say it would do?

My suggestion would be that we look for the pages that define behavior 
on numeric types, copy them, change the type names to something 
indicating "Saturated" and wherever the ARM says "raise an exception" 
insert "saturate in the direction of the limit exceedence."


> 
> 
> Yes. IMO is has too many bad implications like effects on dependcy
> with expression evaluation order.
> 
No more so than you already have for the type Integer or Float or any 
other type. You're merely expressing a different accommodation for 
bounds exceedence.


> 
> I think the easy(?) way would be a generic package supplying such sort
> of types like this:
> 
> |generic
> |   type Item is range <>;
> |package Saturated_Integer is
> |   function "+" (I : Item; Amount : Item) return Item;
> |   function "-" (I : Item; Amount : Item) return Item;
> |end Saturated_Integer;
> 
> Well, I have a problem in successfully overloading the standard
> integer operations here...
> 
> How do I do that? My understanding of generics is still quite vague.
> 

We've cobbled together solutions like this in the past. It isn't 
impossible to go invent your own home-grown type and come up with 
operations that do what you want. The real issue is that it would just 
work so much better and easier if it was a directly supported feature of 
the language and well integrated with all the rest of Ada.

> 
>>Still, it seems like a useful feature for some kinds of jobs.
> 
> 
> Well, yes. But it's not an Ada-like feature, is it?
> 
How is it any less Ada-like than any other numeric type? I think one of 
the big advantages to Ada is that it provides a *wealth* of type 
capabilities so you can pick whatever type best fits the needs of the 
problem space. This would be adding a set of types that provide 
different behavior that is desirable in some situations. (Compare it to 
C where they say "here's your int and float and if you can't do it with 
that, go pound sand..." This would be very Ada-esque)

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Quality systems (Was: Using Ada for device drivers? (Was: the

[Marin David Condic]

Gee. I don't know. Its too early in the morning and I have not yet had 
my fill of coffe and would need to think about it more. I'd suspect that 
it wouldn't be the perfect answer because you want the chip to be able 
to do high-speed register-to-register instructions and such. You 
wouldn't want to limit these optimizations to only non-saturated types.

Are there any chips that support bounds checking on other types? Given 
that Ada has bounds other than machine bounds on floats, integers, etc., 
are there chips that will do the checking for you in some manner or do 
all compilers have to generate their own checks? If a chip can support 
range checking with exception-raising semantics, then it ought to be 
relatively straightforward to substitute saturation instead of 
interruption as the accommodation. I just don't know if any chip sets do 
this.

MDC


Larry Kilgallen wrote:

> 
> Presuming the ability to add and subtract to a storage location
> (I don't know the Altivec instructions) would it not suffice to
> say that "fetch" is the only operation for which the bounds must
> be provided ?


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Saturated Math

[Vinzent Hoefler]

Marin David Condic wrote:

>Vinzent Hoefler wrote:
>
>> Suppose you have an expression like:
>> 
>> X := X + 4 - 4;
>> 
>> (Those fours might not be actual constants)
>> 
>> What would be the result then?
>> 
>Imagine it was a garden variety integer with the same range. What does 
>the ARM say it would do?

IIRC such constructs *may* raise an exception if the [intermediate]
result cannot be represented (in the base type, I think). So the
result is either the correct one or you get an exception.

Well, let's read the ARM... mmh, yes, I would interprete 3.5.4(20) and
3.5.4(24) in that way.

>What if it were a modular type with wraparound 
>semantics?

No difference, the result is defined and the same in both cases. It
doesn't matter when you apply the modulus-operation:

"((a mod c) + (b mod c)) mod c" is always the same as "(a + b) mod c".

So the order of evaluation is of no concern here.

Let's suppose there would be a similar operator call sat for
saturation, this wouldn't hold true no longer:

"((a sat c) + (b sat c)) sat c" is *not* the same as "(a + b) sat c".

So the result depends on where and when you saturate the
subexpressions.

>My suggestion would be that we look for the pages that define behavior 
>on numeric types, copy them, change the type names to something 
>indicating "Saturated" and wherever the ARM says "raise an exception"
>insert "saturate in the direction of the limit exceedence."

Mmh:

(20)
|For a saturated integer type, the result is saturated in the direction
|of the limit exceedence by the execution of an operation that cannot
|deliver the correct result because it is outside of the base range for
|that type.

Hmm. *Might* be ok.

Now a changed (24):

|For the execution of a predefined operation of a saturated integer
|type, the implementation need not saturate in the direction of the
|limit exceedence if the result is outside the base range of the type,
|so long as the correct result is produced.

;)

Well, I think the problem here is:

On "normal" Integers it may
    a) raise an exception
    b) gives the proper result

So there's no real ambiguity (although I must admit, different
implementation might slightly differ in their behaviour).

With modular types there is no problem at all, with the example above
it would wrap around twice, still delivering the same result.

But with saturated integers it is possible to have more than a single
result. So which result is supposed to be the correct one?

IMO this would introduce a *very* ambiguous ambiguity.

How would you resolve that without forcing the order of expression
evaluation, supposed you also want to have the usual integer
operations on that type?

Perhaps by saying that the result of expressions involving saturated
integer types is always evaluated within type root_integer and that
the saturation then only applies on assignment? Note that this then
should also raise an exception if the intermediate result cannot be
represented anymore in root_integer or so (depending on how good the
machine is with integer math).
But raising an exception on saturated integer types is kind of weird,
this is the last I would expect from it.

>> Yes. IMO is has too many bad implications like effects on dependcy
>> with expression evaluation order.
>> 
>No more so than you already have for the type Integer or Float or any 
>other type.

Well, as long as you only allow simple expression like A + B this is
ok. The problem arises when you say A + B + C.

>You're merely expressing a different accommodation for 
>bounds exceedence.

Yes, the intention is very clear.

>>>Still, it seems like a useful feature for some kinds of jobs.
>> 
>> Well, yes. But it's not an Ada-like feature, is it?
>> 
>How is it any less Ada-like than any other numeric type?

It introduces an ambiguity that clearly would need to be solved first.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Saturated Math

[Randy Brukardt]

>Vinzent Hoefler wrote:


>>How is it any less Ada-like than any other numeric type?

>It introduces an ambiguity that clearly would need to be solved first.

I agree with everything Vinzent said. Any type that would be added to
Ada would have to have a clear mathematical underpinning. Otherwise,
code would not be portable because compiler implementations would vary
(in say the order of operations).

An example is what this would mean in a code shared generic. In such a
case, we'd have to pass in the bounds and include them in every math
operation. That would be SLOW.

But probably the best reason that something like this will not be added
to Ada is that it doesn't add anything. There is nothing here that
cannot be done with code you write yourself. Since there is no hardware
support for these types, everything is a batch of code anyway; it might
as well be done with an in-lined subprogram.

What would make sense in the standard would be some way to get numeric
literals for private types, so that a user-defined type could work just
like an integer type without any need for the compilers to get involved.

Something like:

        package Saturation is
            type Saturated_Integer is private;
            for Saturated_Integer'Literal use Convert;
            function Convert (Value : in Root_Integer) return
Saturated_Integer;

            function "+" (Left, Right : Saturated_Integer) return
Saturated_Integer;
            -- etc.
      end Saturation;

The idea being that when a literal occurs, the compiler wraps it into a
call to Convert. You can sort of do this with unary "+", but it's
annoying to always have to write "+" (and you also don't have a named
"Root_Integer" type to use, so you have to use some other Integer type
to get the proper range).

There hasn't been much interest in this idea (or the related
redefinition of array indexing), so don't hold your breath waiting for
it.

                        Randy.

Re: Saturated Math

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Something like:
> 
>         package Saturation is
>             type Saturated_Integer is private;
>             for Saturated_Integer'Literal use Convert;
>             function Convert (Value : in Root_Integer) return
> Saturated_Integer;
> 
>             function "+" (Left, Right : Saturated_Integer) return
> Saturated_Integer;
>             -- etc.
>       end Saturation;
> 
> The idea being that when a literal occurs, the compiler wraps it into a
> call to Convert. You can sort of do this with unary "+", but it's
> annoying to always have to write "+" (and you also don't have a named
> "Root_Integer" type to use, so you have to use some other Integer type
> to get the proper range).
> 
> There hasn't been much interest in this idea (or the related
> redefinition of array indexing), so don't hold your breath waiting for
> it.

I've always thought this sort of thing was a good idea.

But I think the 'Literal attribute should take a String.
That's what a literal is -- a string in the source code,
which the compiler converts into a value.  The goal is to give
the user a hook to control that conversion.

A good compiler could run Convert at compile time in most cases.

- Bob

Re: Saturated Math

[Dale Stanbrough]

Randy Brukardt wrote:

> Since there is no hardware
> support for these types, everything is a batch of code anyway; it might
> as well be done with an in-lined subprogram.

There is hardware support for saturated types with integral sizes.
I posted an example a couple of days ago - the PowerPC Altivec 
instructions.

I would guess that other SIMD instruction sets would have something
similar.

dale

RE: Saturated Math

[Robert C. Leif]

 
I agree on the saturated math. However, is there a way for a private integer
type to work directly with Universal_Integers? It is a pain to type convert
the 2.

My_Private_Integer_Y:= My_Private_Integer_X +2;

-----Original Message-----
From: Randy Brukardt [mailto:randy@rrsoftware.com] 
Sent: Wednesday, May 28, 2003 11:56 AM
To: comp.lang.ada@ada.eu.org

>Vinzent Hoefler wrote:


>>How is it any less Ada-like than any other numeric type?

>It introduces an ambiguity that clearly would need to be solved first.

I agree with everything Vinzent said. Any type that would be added to Ada
would have to have a clear mathematical underpinning. Otherwise, code would
not be portable because compiler implementations would vary (in say the
order of operations).

An example is what this would mean in a code shared generic. In such a case,
we'd have to pass in the bounds and include them in every math operation.
That would be SLOW.

But probably the best reason that something like this will not be added to
Ada is that it doesn't add anything. There is nothing here that cannot be
done with code you write yourself. Since there is no hardware support for
these types, everything is a batch of code anyway; it might as well be done
with an in-lined subprogram.

What would make sense in the standard would be some way to get numeric
literals for private types, so that a user-defined type could work just like
an integer type without any need for the compilers to get involved.

Something like:

        package Saturation is
            type Saturated_Integer is private;
            for Saturated_Integer'Literal use Convert;
            function Convert (Value : in Root_Integer) return
Saturated_Integer;

            function "+" (Left, Right : Saturated_Integer) return
Saturated_Integer;
            -- etc.
      end Saturation;

The idea being that when a literal occurs, the compiler wraps it into a call
to Convert. You can sort of do this with unary "+", but it's annoying to
always have to write "+" (and you also don't have a named "Root_Integer"
type to use, so you have to use some other Integer type to get the proper
range).

There hasn't been much interest in this idea (or the related redefinition of
array indexing), so don't hold your breath waiting for it.

                        Randy.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[David Lightstone]

<achrist@easystreet.com> wrote in message
news:3ECC37F8.29CD9152@easystreet.com...
> >
> > I just happen to have a copy of Meridian Open Ada 4.1 for _PC_ DOS
> > sitting on my desk.  And yes it does just that - I've used in on a NEC
> > Ultralight laptop (~8086) with 640k RAM and a 2Mb RAM 'hard disk'.
> > Not that I use the compiler currently, 640k limit, 5 1/4 floppies, and
> > all that.
> >
>
> What's the date on this product?  Is it really from the early days
> of PC's (e.g. 1985 o earlier)?


The distribution disks that I have are dated 5 Nov 1990
>
>
> Al

Re: Saturated Math

[Robert A Duff]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> IIRC such constructs *may* raise an exception if the [intermediate]
> result cannot be represented (in the base type, I think). So the
> result is either the correct one or you get an exception.

Right.

> On "normal" Integers it may
>     a) raise an exception
>     b) gives the proper result
> 
> So there's no real ambiguity (although I must admit, different
> implementation might slightly differ in their behaviour).

Slightly?!  Seems like a huge difference to me.  If I say:

    type T is range 1..100;
    X, Y: T := 100;

    Z := (X + Y) / 2;

on some implementations I will get the right answer, and on others, I
will get an exception (because it chose T'Base to be -128...127).
I think this is a flaw in Ada (although most competing languages
(i.e. languages that try to do efficient arithmetic) have even worse
rules).

> But with saturated integers it is possible to have more than a single
> result. So which result is supposed to be the correct one?
> 
> IMO this would introduce a *very* ambiguous ambiguity.

That's a good point.

However, note that X+Y+Z is parsed as (X+Y)+Z, and there's an extra
permission in 4.5(13) to evaluate this as X+(Y+Z), but only for
predefined operators.  If you write a saturating arithmetic package,
with overloaded "+", then X+Y+Z will always mean (X+Y)+Z.

So one could imagine a rule that said X+Y+Z will always mean (X+Y)+Z for
saturating operators, if saturating types were predefined.

One could also imagine that it doesn't matter: X+Y+Z might produce
"infinity" or might produce the right answer.

It seems to me that a saturating arithmetic ought to "stick" at
infinity.  If you say "X + 1000", and that returns the max, then
subtracting 1 from it should return the max, not max-1.  Others have
said otherwise, and I wonder why.

- Bob

Re: Saturated Math

[Robert I. Eachus]

Robert A Duff wrote:

> It seems to me that a saturating arithmetic ought to "stick" at
> infinity.  If you say "X + 1000", and that returns the max, then
> subtracting 1 from it should return the max, not max-1.  Others have
> said otherwise, and I wonder why.

All this discussion has convinced me is that any attempt to add 
saturating integer types to Ada is definitely a bad thing.  If a user 
implements the type of saturating arithmetic he needs, that is 
relatively safe.  At least he or she will know what happens and where. 
But adding a predefined saturating type to Ada would be like giving a 
loaded gun to a baby.  For every problem it solved, a dozen others would 
be papered over and hidden.

A case might be made for adding optional NaN values to fixed-point 
types, especially decimal types. As for floating point, I think GNAT 
allows users to "take advantage" of the saturating modes of IEEE 
floating point.  The idea makes my skin crawl slightly, but that is 
normal when I see floating point.

Seriously, there are many cases where error analysis for floating point 
code gives reasonable results. The creepy feeling comes when either the 
analysis obviously hasn't been done or the territory is full of land 
mines. So the real problem is that cases where the error analysis is 
tough get pushed into floating point, when using integer arithmetic or 
fixed point is probably impossible anyway.

The latitude and longitude discussion we just had was a good example. 
It takes about a minute to work out the worst case error for 32-bit 
fixed point.  The suitability of (24-bit) floating-point will depend on 
the accuracy you need and where you are.  (Degrees of longitude get 
smaller as you approach the poles, so the worst case is just above 32.0 
degrees of latitude or below -32.0 degrees. (Assuming decimal degrees.) 
  Degrees of latitude are the same size everywhere--modulo the Earth's 
deviation from spherical.  So the worst case in floating point, will be 
latitudes greater that 64.0 degrees or less than -64.0 degrees.

If I felt that people who used 32-bit floating point latitudes and 
longitudes had done that analysis, I'd sleep a lot more comfortably. 
Especially on overseas flights that might cross that magic 64 degree 
line. (Just below the Artic circle, or above the Antartic circle.)

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Marin David Condic wrote:

> That's an interesting analysis, but I don't know that we'd need to get
> that complex. Your basic floating, fixed and integer types have all the
> syntax they need to get the job done. They just need a variant that
> defines a different accommodation in the event that you assign a value
> that exceeds one of the bounds - saturation instead of an exception.

Numeric types are not just abstract ideas. They model real mathematical 
things. An exceptional state simply indicates when the model gets 
inadequate. So you cannot say: let us make something else instead of 
raising an exception. You *have* to change the subject of modelling, to be 
not a number, but an interval, a fuzzy number etc. Your saturated number is 
not a number!

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

Re: Saturated Math

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Something like:
>> 
>>         package Saturation is
>>             type Saturated_Integer is private;
>>             for Saturated_Integer'Literal use Convert;
>>             function Convert (Value : in Root_Integer) return
>> Saturated_Integer;
>> 
>>             function "+" (Left, Right : Saturated_Integer) return
>> Saturated_Integer;
>>             -- etc.
>>       end Saturation;
>> 
>> The idea being that when a literal occurs, the compiler wraps it into a
>> call to Convert. You can sort of do this with unary "+", but it's
>> annoying to always have to write "+" (and you also don't have a named
>> "Root_Integer" type to use, so you have to use some other Integer type
>> to get the proper range).
>> 
>> There hasn't been much interest in this idea (or the related
>> redefinition of array indexing), so don't hold your breath waiting for
>> it.
> 
> I've always thought this sort of thing was a good idea.
> 
> But I think the 'Literal attribute should take a String.
> That's what a literal is -- a string in the source code,
> which the compiler converts into a value.  The goal is to give
> the user a hook to control that conversion.
> 
> A good compiler could run Convert at compile time in most cases.

Isn't it better to povide user defined conversions (and constructors), which 
then will deal with literals as well?

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

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Perhaps you are right. However in the world I have to live in, we have 
found this behavior to be "A Good Thing". We have implemented packages 
that do this. It works nicely. Maybe we should have thought about 
needing a model and an interval and all that and decided it was 
impossible and abandoned the whole thing? :-)

My point is that in real world situations saturated math is useful, and 
people do come up with ways of doing it. Let the language lawyers and 
mathematicians stew over if for a while and figure out how to 
incorporate it into their model. It would be a good thing to have in Ada 
rather than something that has to be cobbled on to the side of it in an 
inefficient and/or ugly manner.

MDC

Dmitry A. Kazakov wrote:
> 
> Numeric types are not just abstract ideas. They model real mathematical 
> things. An exceptional state simply indicates when the model gets 
> inadequate. So you cannot say: let us make something else instead of 
> raising an exception. You *have* to change the subject of modelling, to be 
> not a number, but an interval, a fuzzy number etc. Your saturated number is 
> not a number!
> 


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Saturated Math

[Marin David Condic]

IMHO, that is the *worst* reason to exclude something from the language. 
;-) By that argument, there are scores of things in the annexes that 
should be gotten rid of. We should start with the basic log and trig 
functions.

Providing more facilities - especially if they are easy & cheap from the 
compiler writer's perspective - is something that will make Ada more 
generally useful and provide the developer with more leverage.

MDC

Randy Brukardt wrote:
> 
> But probably the best reason that something like this will not be added
> to Ada is that it doesn't add anything. There is nothing here that
> cannot be done with code you write yourself. Since there is no hardware
> support for these types, everything is a batch of code anyway; it might
> as well be done with an in-lined subprogram.
> 


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Saturated Math

[Marin David Condic]

Then it doesn't behave like the real world thing I wanted it to model. 
If you have an actuator that can move between -5.0 inches and +5.0 
inches and you try to command it to +5.5 inches, it "saturates" at +5.0. 
If I start commanding it to +4.0 inches, that's where it starts to go. 
One can find analogies in other problem domains as well.

MDC

Robert A Duff wrote:
> 
> It seems to me that a saturating arithmetic ought to "stick" at
> infinity.  If you say "X + 1000", and that returns the max, then
> subtracting 1 from it should return the max, not max-1.  Others have
> said otherwise, and I wonder why.
> 



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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Saturated Math

[tmoran]

>inches and you try to command it to +5.5 inches, it "saturates" at +5.0.
>If I start commanding it to +4.0 inches, that's where it starts to go.
>One can find analogies in other problem domains as well.
  I would imagine anywhwere actuators are involved.  eg, the brightness
of a pixel, the loudness of a sound.  The Pentium has had special
instructions for multimedia saturating arithmetic for some time now.
OTOH, they also do SIMD, which is not especially well expressed in
Ada and ought, for speed reasons, to be done in asm libraries.
------------
"Property is theft"  -- Proudhon

Re: Saturated Math

[Mike Silva]

Would've saved Ariane 501's hindquarters too!  (Not to mention all the
other bits)  Such a type (saturating, non-sticking) would definitely
be quite useful in the embedded world, and I would think it a Most
Excellent Addition -- might even help get some embedded programmers to
look at Ada.  I can't speak to the other problems it might create,
though.


Marin David Condic <nobody@noplace.com> wrote in message news:<3ED5EA28.2040703@noplace.com>...
> Then it doesn't behave like the real world thing I wanted it to model. 
> If you have an actuator that can move between -5.0 inches and +5.0 
> inches and you try to command it to +5.5 inches, it "saturates" at +5.0. 
> If I start commanding it to +4.0 inches, that's where it starts to go. 
> One can find analogies in other problem domains as well.
> 
> MDC
> 
> Robert A Duff wrote:
> > 
> > It seems to me that a saturating arithmetic ought to "stick" at
> > infinity.  If you say "X + 1000", and that returns the max, then
> > subtracting 1 from it should return the max, not max-1.  Others have
> > said otherwise, and I wonder why.
> > 
> 
> 
> 
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
> 
> Send Replies To: m c o n d i c @ a c m . o r g
> 
>      "In general the art of government consists in taking as
>      much money as possible from one class of citizens to give
>      to the other."
> 
>          --  Voltaire
> ======================================================================

RE: Saturated Math

[Robert C. Leif]

"SIMD, which is not especially well expressed in
Ada and ought, for speed reasons, to be done in asm libraries."

I would hope that the " not especially well expressed in
Ada" part would be addressed in Ada 200X. I should note that from both the
medical and military viewpoints, image processing is important. As for
efficiency, that is a problem for the compiler writers and microprocessor
architects.
Bob Leif

-----Original Message-----
From: tmoran@acm.org [mailto:tmoran@acm.org] 
Sent: Thursday, May 29, 2003 10:09 AM
To: comp.lang.ada@ada.eu.org

>inches and you try to command it to +5.5 inches, it "saturates" at +5.0.
>If I start commanding it to +4.0 inches, that's where it starts to go.
>One can find analogies in other problem domains as well.
  I would imagine anywhere actuators are involved.  eg, the brightness
of a pixel, the loudness of a sound.  The Pentium has had special
instructions for multimedia saturating arithmetic for some time now.
OTOH, they also do SIMD, which is not especially well expressed in
Ada and ought, for speed reasons, to be done in asm libraries.
------------
"Property is theft"  -- Proudhon

Re: Saturated Math

[Dale Stanbrough]

Marin David Condic wrote:


> Randy Brukardt wrote:
> > 
> > But probably the best reason that something like this will not be added
> > to Ada is that it doesn't add anything. There is nothing here that
> > cannot be done with code you write yourself. Since there is no hardware
> > support for these types, everything is a batch of code anyway; it might
> > as well be done with an in-lined subprogram.


I've just tried writing such a package (generic) and it doesn't seem
that it would be altogether seemless for the end user.

Given a declaration like this...

generic
   type Number is range <>;
package Saturate is

   function "+" (left, right : Number) return Number;
   function "-" (left, right : Number) return Number;
   function "*" (left, right : Number) return Number;
   function "/" (left, right : Number) return Number;
   function "**" (left, right : Number) return Number;


...

a calling procedure would look like this...

procedure main is
   type Number is new Integer range 1..5;
   
   package Saturated_Int is new Saturate (Number);
   use Saturated_Int;
   
   x : Number := 4;
begin
   x := Saturated_Int."+" (x, 2);
   x := Saturated_Int."-" (x, 6);
end;


The function "+" in the following

   x := x + 2;

is said to be ambiguous with Standard."+" (according
to gnat).

Am I missing something?

Dale

Re: Saturated Math

[AG]

"Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message
news:dstanbro-D4C3C0.18423630052003@mec2.bigpond.net.au...
> I've just tried writing such a package (generic) and it doesn't seem
> that it would be altogether seemless for the end user.
>
> Given a declaration like this...

How about the following:
[Just checked it on Gnat and it compiles fine]

Declars:

generic

type number is range <>;


package saturated is

type saturated_number is new number;

function "+"(left, right: saturated_number) return saturated_number;

end;

----------------------------

Usage:

----------------------------

with saturated;

procedure main is

package saturated_int is new saturated(integer);

use saturated_int;

x: saturated_number := 4;

begin

  x := x + 2;

end;

----------------------------


> a calling procedure would look like this...
>
> procedure main is
>    type Number is new Integer range 1..5;
>
>    package Saturated_Int is new Saturate (Number);
>    use Saturated_Int;
>
>    x : Number := 4;
> begin
>    x := Saturated_Int."+" (x, 2);
>    x := Saturated_Int."-" (x, 6);
> end;
>
>
> The function "+" in the following
>
>    x := x + 2;
>
> is said to be ambiguous with Standard."+" (according
> to gnat).

In this case, the problem seems to be that the compiler
(quite rightly) can't tell which "+" you mean since there
are, in fact, two implementations visible at that spot.

Regards
.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Larry Kilgallen]

In article <m3llwoodvt.fsf@niflheim.malonet>, Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

> The idea of a saturated math type is elegant, but don't you want a
> mechanism for checking if a variable has saturated (fx. for logging
> purposes)? Something like:
> 
> X := X + 5;
> 
> if X'Saturated then
>   -- report unexpected saturation
> end if;
> 
> Use_Value(X);
> 
> -- and so on
> 
> The attribute 'Saturated would apply to a variable X of a saturated
> type and return true if and only if the last value assignment to X had
> to be adjusted to fit the range of X.

What if the _penultimate_ assignment saturated, and the assignment after
that was:

	X := X + 0;

Re: Saturated Math

[Dale Stanbrough]

AG wrote:

> "Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message
> news:dstanbro-D4C3C0.18423630052003@mec2.bigpond.net.au...
> > I've just tried writing such a package (generic) and it doesn't seem
> > that it would be altogether seemless for the end user.
> >

> > procedure main is
> >    type Number is new Integer range 1..5;
> >
> >    package Saturated_Int is new Saturate (Number);
> >    use Saturated_Int;
> >
> >    x : Number := 4;
> > begin
> >    x := Saturated_Int."+" (x, 2);
> >    x := Saturated_Int."-" (x, 6);
> > end;
> >
> >
> > The function "+" in the following
> >
> >    x := x + 2;
> >
> > is said to be ambiguous with Standard."+" (according
> > to gnat).
> 
> In this case, the problem seems to be that the compiler
> (quite rightly) can't tell which "+" you mean since there
> are, in fact, two implementations visible at that spot.

yes, i agree. But i think that's the problem of user defined
saturation maths packages. (unless someone can come up with a
different solution).

It seems that the client has to use the package.operator notation
if you want to implement saturated maths this way. Is there any
way around this?

Dale

Re: Saturated Math

[AG]

"Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message
news:dstanbro-C01C2E.20545030052003@mec2.bigpond.net.au...
> AG wrote:

> > In this case, the problem seems to be that the compiler
> > (quite rightly) can't tell which "+" you mean since there
> > are, in fact, two implementations visible at that spot.
>
> yes, i agree. But i think that's the problem of user defined
> saturation maths packages. (unless someone can come up with a
> different solution).

Sorry, but have you missed the first part of my post
(which you snipped) where I provided an example
of that? The comment about ambiguous "+" was just
an after-thought to comment on just why yours
doesn't work.

>
> It seems that the client has to use the package.operator notation
> if you want to implement saturated maths this way. Is there any
> way around this?

See my example.

Re: Saturated Math

[Marin David Condic]

Yes. Exactly. In the real world, things have bounds that don't generate 
exceptions - they just create a limit beyond which one cannot go. In 
control logic, we *live* to rate and range limit things. :-) Examples of 
usage shouldn't be at all hard to imagine - anywhere in the world where 
there are walls that say "this far, but no farther" and you have a 
potential usage for a saturated number.

MDC

tmoran@acm.org wrote:
> 
>   I would imagine anywhwere actuators are involved.  eg, the brightness
> of a pixel, the loudness of a sound.  The Pentium has had special
> instructions for multimedia saturating arithmetic for some time now.
> OTOH, they also do SIMD, which is not especially well expressed in
> Ada and ought, for speed reasons, to be done in asm libraries.


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Saturated Math

[Marin David Condic]

Note that you'd also have some problems with assignment because Ada 
doesn't provide a means of overriding it. This is also the area where 
saturation would be the *most* useful.

Consider that I want to compute some position for an actuator. I don't 
really care if the computation itself is done with infinite precision. 
What I care about is the *result* being limited to within the bounds of 
the actuator. So what I need is saturation on assignment and it would 
also be handy to be able to easily mix it with constants and other 
compatible types. We've done it with home-brewed packages, but it just 
seems to be more clumsy than if it were just a feature of the language.

MDC

Dale Stanbrough wrote:

>    
>    x : Number := 4;



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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Mark Lorenzen]

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

> While you guys are at the business of creating new numeric types for
> Ada0y, how about one of my favorite types - some form of a saturated
> math type? It would be nice to have support for the basic math types
> that would saturate instead of wrap-around or overflow/exception. How
> difficult or inefficient would that be to implement?
> 
> MDC
> 

The idea of a saturated math type is elegant, but don't you want a
mechanism for checking if a variable has saturated (fx. for logging
purposes)? Something like:

X := X + 5;

if X'Saturated then
  -- report unexpected saturation
end if;

Use_Value(X);

-- and so on

The attribute 'Saturated would apply to a variable X of a saturated
type and return true if and only if the last value assignment to X had
to be adjusted to fit the range of X.

- Mark

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

No, I don't think so. I've got regular old integers and floats and fixed 
points that can generate an exception and let me stop and write out a 
report. The usage I would have for it is the case where I want to 
compute a position or rate and if it exceeds some limit, just chop it 
off and press onwards. (Often computation speed in this domain is 
critical) We usually do this manually with if-checks around the results 
of a computation. It just doesn't protect you in the event of an 
overflow that would generate an exception. The exception is "bad" 
because your typical response is to reboot the control and start over - 
and we all know what a bad thing that can be from the Ariane 5 disaster. :-)

MDC

Mark Lorenzen wrote:
> 
> The idea of a saturated math type is elegant, but don't you want a
> mechanism for checking if a variable has saturated (fx. for logging
> purposes)? Something like:
> 
> X := X + 5;
> 
> if X'Saturated then
>   -- report unexpected saturation
> end if;
> 
> Use_Value(X);
> 
> -- and so on
> 
> The attribute 'Saturated would apply to a variable X of a saturated
> type and return true if and only if the last value assignment to X had
> to be adjusted to fit the range of X.
> 
> - Mark


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Saturated Math

[Dale Stanbrough]

AG wrote:

> "Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message
> news:dstanbro-C01C2E.20545030052003@mec2.bigpond.net.au...
> > AG wrote:
> 
> > > In this case, the problem seems to be that the compiler
> > > (quite rightly) can't tell which "+" you mean since there
> > > are, in fact, two implementations visible at that spot.
> >
> > yes, i agree. But i think that's the problem of user defined
> > saturation maths packages. (unless someone can come up with a
> > different solution).
> 
> Sorry, but have you missed the first part of my post
> (which you snipped) where I provided an example
> of that? The comment about ambiguous "+" was just
> an after-thought to comment on just why yours
> doesn't work.

Ah, yes i did. Sorry, but I was in the middle of marking 
assignments, and was using c.l.a. as a welcome distraction...

I don't like the idea that you have to create a dummy type...

   type Pretend_Type is new Integer range 1..5;
   package Saturated_Int is new Saturate (Pretend_Type);
   ...

It seems a bit clunky just to get around the type system. I 
thought of passing in an upper and lower bound to the generic,
but what type should they be? You could make them integer, but
what if you wanted saturating integers with a larger range than
Standard.Integer?

Dale

Re: Saturated Math

[Vinzent Hoefler]

Robert A Duff wrote:

>Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
>
>> So there's no real ambiguity (although I must admit, different
>> implementation might slightly differ in their behaviour).
>
>Slightly?!  Seems like a huge difference to me.

ACK. I like understatements. ;)

>> But with saturated integers it is possible to have more than a single
>> result. So which result is supposed to be the correct one?
>> 
>> IMO this would introduce a *very* ambiguous ambiguity.
>
>That's a good point.
>
>However, note that X+Y+Z is parsed as (X+Y)+Z, and there's an extra
>permission in 4.5(13) to evaluate this as X+(Y+Z), but only for
>predefined operators.

Well, if saturated integer were a type in Ada it would have predefined
operators.

>So one could imagine a rule that said X+Y+Z will always mean (X+Y)+Z for
>saturating operators, if saturating types were predefined.

Ok, this would be a clear rule, yes. But I still think this could be
problematic, because the result of such operations perhaps weren't
very intuitive.

>One could also imagine that it doesn't matter: X+Y+Z might produce
>"infinity" or might produce the right answer.

*eek* No. We are talking about integers, so there is no infinity or
some sort of magic value for that. It's just a limit that shouldn't be
exceeded.

I would need that for the hardware we are driving. You cannot get
below or above a specific value (0 to 255 here, the DAC is just an
8-bit one). To compensate for the mechanical behaviour we sometimes
have to drive that thing with a higher or lower value than it really
should be (i.e. if we go from 127 to 160 we have to drive it to 163 so
that the mechanical part really gets to its position "160"). But as
someone can imagine I cannot drive it below 0 or above 255, so I have
to saturate the "overdrive" values at that point, but of course then I
still want to go into the other direction from there. So sticky or
even wraparound semantics would be absolutely wrong and a constraint
error isn't quite good neither.
So yes, I would like the idea of saturated math but OTOH I see that
this introduces too many problems if implemented as another integer
type.

>It seems to me that a saturating arithmetic ought to "stick" at
>infinity.  If you say "X + 1000", and that returns the max, then
>subtracting 1 from it should return the max, not max-1.

Now it's getting complex.

What about:

|type ... is saturated integer range ...;
|type ... is sticky saturated integer range ...;

Or perhaps the keywords should come before the range specification:

|type ... is integer saturated range ...;
|type ... is integer saturated sticky range ...;

;)

>  Others have said otherwise, and I wonder why.

Because its more intuitive for their problem domain. It would be in
mine. I have a lot of color value conversions that should stop at
black or white but I still need the grey values inbetween even after
some of these pixels have saturated.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Saturated Math

[Robert A Duff]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> Robert A Duff wrote:
> >Slightly?!  Seems like a huge difference to me.
> 
> ACK. I like understatements. ;)

;-)

> Because its more intuitive for their problem domain. It would be in
> mine. I have a lot of color value conversions that should stop at
> black or white but I still need the grey values inbetween even after
> some of these pixels have saturated.

I still don't get it.  By "sticky", I mean that arithmetic is sticky.
You can still set the thing to any value you like.  In your example of
0..255, if X = 200, and you say "X := X + 100;", then X = 255.
If you then subtract 100 from X, you go "too far" in the other
direction, it seems to me.  So if you want to, say, set it back to 200,
you should say "X := 200;", not "X := X - 100;".

- Bob

Re: Saturated Math

[Vinzent Hoefler]

Robert A Duff wrote:

>Vinzent Hoefler <ada.rocks@jlfencey.com> writes:
>
>> Because its more intuitive for their problem domain. It would be in
>> mine. I have a lot of color value conversions that should stop at
>> black or white but I still need the grey values inbetween even after
>> some of these pixels have saturated.
>
>I still don't get it.  By "sticky", I mean that arithmetic is sticky.

Yes, I think I know what you mean.

>You can still set the thing to any value you like.  In your example of
>0..255, if X = 200, and you say "X := X + 100;", then X = 255.

Yep, exactly.

>If you then subtract 100 from X, you go "too far" in the other
>direction, it seems to me.

Well, no. But this might be specific to the problem domain.

If I am going back that is because I compress the output color space,
so subtracting -100 from a black pixel that saturated before is
perfectly correct.

>  So if you want to, say, set it back to 200,
>you should say "X := 200;", not "X := X - 100;".

Yes, but this is what I don't want to do. I want to subtract 100 from
each pixel, either it was saturated before or not.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Saturated Math

[Robert A Duff]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

> >If you then subtract 100 from X, you go "too far" in the other
> >direction, it seems to me.
> 
> Well, no. But this might be specific to the problem domain.
> 
> If I am going back that is because I compress the output color space,
> so subtracting -100 from a black pixel that saturated before is
> perfectly correct.

OK, I guess that makes sense.  In my current project, I am using
saturating arithmetic that is sticky, but I now see that non-sticky
might also be useful.  (My package "sticks" at something like 2**1000 --
it uses multi-word arithmetic.)

- Bob

Re: Saturated Math

[Randy Brukardt]

Dale Stanbrough wrote in message ...
>...
>The function "+" in the following
>
>   x := x + 2;
>
>is said to be ambiguous with Standard."+" (according
>to gnat).
>
>Am I missing something?


Yes, by declaring the type separate from the operators, you get both
sets (the new ones and the predefined ones). That obviously doesn't
work. You have to declare the type and the operators in the same place.

         Randy.

Re: Saturated Math

[Randy Brukardt]

Dale Stanbrough wrote in message ...
>I don't like the idea that you have to create a dummy type...
>
>   type Pretend_Type is new Integer range 1..5;
>   package Saturated_Int is new Saturate (Pretend_Type);
>   ...
>
>It seems a bit clunky just to get around the type system. I
>thought of passing in an upper and lower bound to the generic,
>but what type should they be? You could make them integer, but
>what if you wanted saturating integers with a larger range than
>Standard.Integer?


It's mildly annoying that Ada doesn't have a standard name for the
largest range integer type supported by the implementation. (The
standard defines Root_Integer, but it is not a name that you can use in
a program.) But it is easy enough to declare:

    type Largest_Integer_Type is range System.Min_Int .. System.Max_Int;

The, the generic could look something like:

    generic
        Lower_Bound, Upper_Bound : Largest_Integer_Type;
    package Saturated_Math is
       type Saturated_Type is Lower_Bound .. Upper_Bound;
       function "+" (Left, Right : Saturated_Type) return
Saturated_Type;
       ...
    end Saturated_Math;

Using this would be virtually the same as using predefined integer
types. (We use something like this to emulate the target machine's math
in the Janus/Ada compiler. Why do that? We needed it for the Unisys 2200
compiler, as that is a one's complement, 36-bit machine.)

                  Randy.

Re: Saturated Math

[Randy Brukardt]

Marin David Condic wrote in message <3ED7437E.5060607@noplace.com>...
>Note that you'd also have some problems with assignment because Ada
>doesn't provide a means of overriding it. This is also the area where
>saturation would be the *most* useful.
>
>Consider that I want to compute some position for an actuator. I don't
>really care if the computation itself is done with infinite precision.
>What I care about is the *result* being limited to within the bounds of
>the actuator. So what I need is saturation on assignment and it would
>also be handy to be able to easily mix it with constants and other
>compatible types. We've done it with home-brewed packages, but it just
>seems to be more clumsy than if it were just a feature of the language.


I think that's rather different than what others have been talking
about. Saturation on operations is easy to implement cleanly, assignment
much less so. But Ada does have a way to override assignment, so that's
doable with a carefully crafted package. The question would be whether
the overhead was essessive. That of course would depend on the
implementation and on the number of objects of this type that was
declared.

     private with Ada.Finalization;
     generic
          type Literal_Type is range <>; -- Use for literals, defines
range of type.
     package Marins_Saturated_Math is
          type Saturated_Type is private;

          -- Operations:
          function "+" (Right : Saturated_Type) return Saturated_Type;
          function "-" (Right : Saturated_Type) return Saturated_Type;
          function "+" (Left, Right : Saturated_Type) return
Saturated_Type;
          ... -- Rest of the binary operations here.

          -- Operations to give literals:
          function "+" (Right : Literal_Type) return Saturated_Type;
          function "-" (Right : Literal_Type) return Saturated_Type;
          function "+" (Left : Saturated_Type; Right : Literal_Type)
return Saturated_Type;
          ... -- Rest of the binary operations here.

    private
          type Saturated_Type is new Ada.Finalization.Controlled with
record
                 Value : Literal_Type'Base; -- May exceed the range, but
is forced back on assignment.
          end record;
          procedure Adjust (Object : in out Saturated_Type);
          -- Initialize, Finalize not needed.
    end Marins_Saturated_Math;

And the implementation of Adjust would look like:

     procedure Adjust (Object : in out Saturated_Type) is
     begin
          if Object.Value > Literal_Type'Last then
                Object.Value := Literal_Type'Last;
         elsif Object.Value < Literal_Type'First then
                Object.Value := Literal_Type'First;
         end if;
     end Adjust;

Writing this package would be a pain, but it only has to be done once.

Also note that since this type doesn't override Finalize, a compiler
could eliminate all of the overhead of a controlled type. I don't think
that any compilers currently do that, but it is the sort of optimization
that compiler vendors do add for good customers. (The Adjust to call is
always known at compile-time, as long as 'Class is never used, which it
won't be for this type.)

                   Randy.

Re: Saturated Math

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Dale Stanbrough wrote in message ...
> >I don't like the idea that you have to create a dummy type...
> >
> >   type Pretend_Type is new Integer range 1..5;
> >   package Saturated_Int is new Saturate (Pretend_Type);
> >   ...
> >
> >It seems a bit clunky just to get around the type system. I
> >thought of passing in an upper and lower bound to the generic,
> >but what type should they be? You could make them integer, but
> >what if you wanted saturating integers with a larger range than
> >Standard.Integer?
> 
> 
> It's mildly annoying that Ada doesn't have a standard name for the
> largest range integer type supported by the implementation. (The
> standard defines Root_Integer, but it is not a name that you can use in
> a program.) But it is easy enough to declare:
> 
>     type Largest_Integer_Type is range System.Min_Int .. System.Max_Int;
> 
> The, the generic could look something like:
> 
>     generic
>         Lower_Bound, Upper_Bound : Largest_Integer_Type;
>     package Saturated_Math is
>        type Saturated_Type is Lower_Bound .. Upper_Bound;

But the bounds are not static expressions, as required, and you're
missing "range".  Or did you mean "subtype"?

>        function "+" (Left, Right : Saturated_Type) return
> Saturated_Type;
>        ...
>     end Saturated_Math;
> 
> Using this would be virtually the same as using predefined integer
> types. (We use something like this to emulate the target machine's math
> in the Janus/Ada compiler. Why do that? We needed it for the Unisys 2200
> compiler, as that is a one's complement, 36-bit machine.)
> 
>                   Randy.

Re: Saturated Math

[Vinzent Hoefler]

Randy Brukardt wrote:

>Yes, by declaring the type separate from the operators, you get both
>sets (the new ones and the predefined ones). That obviously doesn't
>work. You have to declare the type and the operators in the same place.

Aaah, the sky is clearing... I stumbled over the same problem. Now I
understand why this was the case. Thanks.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Saturated Math

[tmoran]

>I don't really care if the computation itself is done with infinite
>precision.  What I care about is the *result* being limited to within
>the bounds of the actuator.  So what I need is saturation on assignment
  In that case, a Limit function seems more straightforward:
    subtype Color_Brightness is integer range 0 .. 255;
    function Limit(V : Integer) return Color_Brightness is
    begin
      if V < Color_Brightness'first then return Color_Brightness'first;
      elsif V > Color_Brightness'last then return Color_Brightness'last;
      else return V;
      end if;
    end Limit;
    X,Y,Z : Color_Brightness;
    ...
    X := Limit(X+Y-Z);
Granted it's a little extra writing, but with inlining and a compiler
that doesn't generate an unnecessary range check, it should be nearly
costless at run time.  It gets around non-associative arithmetic
questions.  If you forget the function call, ie, X :=X+Y-Z; then
you raise an exception instead of saturating, so at least you know
there's a problem.
  In MMX the saturating arithmetic is tied up with SIMD vector operations,
so the hardware doesn't help for simple variables.

Re: Saturated Math

[John Griffiths]

Sorry to but in:

Question: don't fuzzy logic states saturate?

If so could be another reason to add to Ada2xxx.

Regards John

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3ED7437E.5060607@noplace.com...
> Note that you'd also have some problems with assignment because Ada
> doesn't provide a means of overriding it. This is also the area where
> saturation would be the *most* useful.
>
> Consider that I want to compute some position for an actuator. I don't
> really care if the computation itself is done with infinite precision.
> What I care about is the *result* being limited to within the bounds of
> the actuator. So what I need is saturation on assignment and it would
> also be handy to be able to easily mix it with constants and other
> compatible types. We've done it with home-brewed packages, but it just
> seems to be more clumsy than if it were just a feature of the language.
>
> MDC
>
> Dale Stanbrough wrote:
>
> >
> >    x : Number := 4;
>
>
>
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "In general the art of government consists in taking as
>      much money as possible from one class of citizens to give
>      to the other."
>
>          --  Voltaire
> ======================================================================
>

Re: Saturated Math

[Marin David Condic]

Except that what I *want* is for saturation to occur on any exception 
relating to the number. I *don't* want the exception. It halts the code. 
That probably causes a reset of the processor. Billion dollar rockets 
exploding in the sky and all that. Investigators unamused by anectdotes 
about how wonderful exceptions are in theory. Corporate types wanting to 
know why you used Ada instead of C "just like everyone else..." I don't 
like having my day ruined like that. :-)

The reason for wanting saturated math is because in an exceptional 
situation, the proper accommodation is NOT to raise an exception, but to 
saturate. We've done many analysese of these situations and determined 
that we'd prefer saturation instead of any other behavior because it is 
probably the least harmful thing to do.

We already know how to write packages to do saturated math. The point 
is, we don't want to. It would be much more convenient to have this as a 
standard feature of Ada. (For that matter, I could do the whole job in 
assembly language, so why do I need Ada at all? :-)

MDC

tmoran@acm.org wrote:

> questions.  If you forget the function call, ie, X :=X+Y-Z; then
> you raise an exception instead of saturating, so at least you know
> there's a problem.


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Saturated Math

[AG]

"Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message
news:dstanbro-7BB353.23461030052003@mec2.bigpond.net.au...

> Ah, yes i did. Sorry, but I was in the middle of marking
> assignments, and was using c.l.a. as a welcome distraction...
>
> I don't like the idea that you have to create a dummy type...

Well, I don't agree that the type was a dummy type.
It served as a tool to specify some important
properties of the values of that type (namely,
the "stickiness"). That's exactly what separates
the values of that type from other regular numbers.
So it's quite appropriate that they are given their
own type and related operations (that's what
disambiguates the operations).

As for the need to pass in explicit low/high
limits and problems with what type they are:
That's exactly why I did not try to pass the
limit numbers in but used a generic type instead.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Marin David Condic wrote:

> No, I don't think so. I've got regular old integers and floats and fixed
> points that can generate an exception and let me stop and write out a
> report. The usage I would have for it is the case where I want to
> compute a position or rate and if it exceeds some limit, just chop it
> off and press onwards. (Often computation speed in this domain is
> critical) We usually do this manually with if-checks around the results
> of a computation. It just doesn't protect you in the event of an
> overflow that would generate an exception. The exception is "bad"
> because your typical response is to reboot the control and start over -
> and we all know what a bad thing that can be from the Ariane 5 disaster.
> :-)

I think it is a bad desgin. You definitely do not need a staturated 
arithmetics if you control something. The type of the data sent to an actor 
is not (and should not be) same as the type used in computations. In my 
view it should be:

   type Controlled_Value is new Float ...;
   type Actor_Value is private;
   function Saturate (X : Controlled_Value) return Actor_Value;
private
   type Actor_Value is new Integer range 0..2048;

For example, you compute with corner moment (normal arithmetic!) and then 
convert it to an number for an DAC (saturated or more sophisticated 
translation, but no arithmetic at all) which results in some voltage. An 
extreme example is Fourier transformation. You definitely would not use 
*real* arithmetics in the space of images.

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

Re: Saturated Math

[Dmitry A. Kazakov]

Marin David Condic wrote:

> Note that you'd also have some problems with assignment because Ada
> doesn't provide a means of overriding it. This is also the area where
> saturation would be the *most* useful.
> 
> Consider that I want to compute some position for an actuator. I don't
> really care if the computation itself is done with infinite precision.
> What I care about is the *result* being limited to within the bounds of
> the actuator. So what I need is saturation on assignment and it would
> also be handy to be able to easily mix it with constants and other
> compatible types. We've done it with home-brewed packages, but it just
> seems to be more clumsy than if it were just a feature of the language.

What about a numeric attribute:

S'Saturate (X : T; L, R : <universal integer>)
   return <universal integer>;

for any subtype S of a floating point T gives X converted to universal 
integer type. The result is always within [L, R].

(What would you do with NaN?)

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

Re: Saturated Math

[Dmitry A. Kazakov]

John Griffiths wrote:

> Sorry to but in:
> 
> Question: don't fuzzy logic states saturate?
> 
> If so could be another reason to add to Ada2xxx.

What do you mean? Fuzzy logical values have no arithmetics. Logical 
operations are defined in terms of min and max, they cannot produce 
overflow. If you mean different t-/s-norms then, they are defined so that 
the result is always in [0,1], no overflow possible. If you mean fuzzy 
numbers then their arithmetics is a generalization of the conventional 
arithmetics. They do not saturate, but overflow. If you mean so-called 
"defuzzification" then yes, it can be viewed as sort of saturation, but it 
is usually more complex than a simple chopping.

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

Re: Saturated Math

[Dale Stanbrough]

AG wrote:

> Well, I don't agree that the type was a dummy type.

If your intention is to create a saturated type, 
then the preceeding non saturated (normal integer)
type with range will most likely not be used for
anything else.

That makes it a dummy type in my books.

Dale

Re: Saturated Math

[Marin David Condic]

I don't understand what this would do. Is it essentially a function that 
is going to range limit what you pass in to be between the lower and 
upper bound? That isn't much help. What I *want* (and I don't seem to be 
making this clear, do I?) is to have a type whos behavior on overflow is 
to saturate rather than raise an exception. The idea is that if there is 
some kind of mistake or error in the logic or some other exceptional 
condition, the numbers saturate rather than stop the execution of the 
program. That's the critical part - don't be raising exceptions on me - 
saturate and try to press on and hope we don't blow up this thing we're 
controlling.

Side benefits of the saturation might be that they have other uses - 
just like wraparound semantics on modular types can be useful for things 
like ring buffers. I don't really care that the math may be evaluation 
order dependent - math already *is* evaluation order dependent. I think 
it would be useful in spite of all the objections raised here because 
I've used it already. I just don't want to have to cobble together my 
own types. It would be better to have the compiler do it.

MDC

Dmitry A. Kazakov wrote:
> 
> What about a numeric attribute:
> 
> S'Saturate (X : T; L, R : <universal integer>)
>    return <universal integer>;
> 
> for any subtype S of a floating point T gives X converted to universal 
> integer type. The result is always within [L, R].
> 
> (What would you do with NaN?)
> 


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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Marin David Condic]

Interesting. And how many control systems have you built? :-) I've been 
doing this job for a while and the team of guys we have who do it seem 
to have a consensus going that we think the *best* accommodation to take 
on an overflow in our application would be to saturate the numbers. If 
it is a "bad design" then it is a "bad design" that is flying around in 
flight critical systems today. Because we think it is the best 
accommodation for the types of faults we might encounter, we have gone 
to the effort of building it ourselves. The thing is, it would be much 
more convenient if we didn't have to create our own packages and cobble 
it on to the side of the compiler. It would be easier to get it directly 
from the compiler. So I'm talking about a feature that is already in use 
and just making it more convenient for the user.

MDC

Dmitry A. Kazakov wrote:
> 
> 
> I think it is a bad desgin. You definitely do not need a staturated 
> arithmetics if you control something. The type of the data sent to an actor 
> is not (and should not be) same as the type used in computations. In my 
> view it should be:
> 



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

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Saturated Math

[Simon Wright]

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

>                                                          Corporate
> types wanting to know why you used Ada instead of C "just like
> everyone else..." I don't like having my day ruined like that. :-)

Of course C doesn't saturate either .. I guess banging the actuator
over to the other end stop is likely to have unintended consequences
too.

Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Dmitry A. Kazakov]

Marin David Condic wrote:

> Interesting. And how many control systems have you built? :-)

I am responsible for software design in our firm. So to say, I leave all the 
dirty work to others. (:-))

> I've been
> doing this job for a while and the team of guys we have who do it seem
> to have a consensus going that we think the *best* accommodation to take
> on an overflow in our application would be to saturate the numbers. If
> it is a "bad design" then it is a "bad design" that is flying around in
> flight critical systems today. Because we think it is the best
> accommodation for the types of faults we might encounter, we have gone
> to the effort of building it ourselves. The thing is, it would be much
> more convenient if we didn't have to create our own packages and cobble
> it on to the side of the compiler. It would be easier to get it directly
> from the compiler. So I'm talking about a feature that is already in use
> and just making it more convenient for the user.

You are talking about an implementation, not design. From design point of 
view:

1. Saturated arithmetics has no physical sense.

2. Values of different nature have to be mapped to different types. In this 
case you are on the safe side, not only when you send data to your DAC and 
have to *explicitly* convert (saturate) the value, but more importantly, 
when you compute the data in *normal* arithmetics with no pitfalls.

3. Better abstraction and factoring. The controlling algorithm would not 
depend on hardware dependent things which may change.

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

Re: Saturated Math

[Robert I. Eachus]

Mike Silva wrote:
> Would've saved Ariane 501's hindquarters too!

It might have, but then Ariane 502 would have destroyed itself, or 
Ariane 503 or whatever.

The beginning of the error cascade that started the destruction of 
Ariane 501 was an overflow treated as a hardware error--which it would 
have been on Ariane 4.

But what actually destroyed Ariane 501 was that the guidance computer 
sent commands to the engines to deflect beyond the structural limits of 
the entire stack.  This was another facet of reusing the Ariane 4 code 
with out checking it against the Ariane 5 requirements.  The physical 
parameters in the control system were wrong.  For very small 
deflections, using the wrong parameters was not harmful.  But the first 
time Ariane 5 hit wind shear it would have destroyed the stack.

The control loop was not stable if the required engine deflections were 
significant.  This would have lead to oscillations that eventually 
deflected the engines beyond what the stack could tolerate, and things 
would fall apart.  Even if it didn't, any resemblance between the result 
orbit and the intended orbit would have been accidental.

This was, IMHO, the real Ariane 5 code reuse disaster.  Not that 
unanticipated overflow could destroy the stack, but that it would have 
happened for any significant engine deflection.  The mass, thrust and 
stack moments for the Ariane 5 were so different from the physical 
parameters for the Ariane 4 that disaster was inevitable.