ada and robots

ada and robots

[John Bohn]

I am an Ada student. I have heard that Ada was designed for embeded
systems, but I haven't heard much about micro controller ada
programming. 

Does anyone know about any examples of the usage of Ada for robots
and programming micro controllers?

Thank you very much
John Bohn

Re: ada and robots

[Michael F Brenner]

The Ada language has the required features for programming controllers:
low level bit operations, absolute memory addressing, interface to 
assembler code, interrupt handling, etc. It also has a number of features
not required, but helpful for programming controllers: the best bug
catching at compile time, some of the best encapsulation, the ability
to express many algorithms without bug-prone pointers, good optimization,
ability to do tasking, etc. In a toy robot, the controllers do not need
much programming, usually an external scheduling computer does the
dynamics and kinematics, resulting in a set of curves that the controller
follows, programmed in an ASIC or a PROM as numbers with a very tiny
program to put those numbers into a memory mapped board register, and
the hardware does the rest. In autonomous robots, however, where each
tick of the clock requires computation a Kaman array of Kalman filters,
adjustment of the boundaries in a Voronoi diagram, and reclustering
of the distance and force matrix between obstacles, the controller
of a joint looks a lot more like a complex general-purpose computer
with specially designed I/O circuits. In the first case, the toy
robot, it does not matter which language you use because there are
so few actual instructions required, if the whole thing is table-driven,
or else the instructions are boiler-plate macros stamped out by some
finite state machines, where, again, source language is irrelevant,
they are just a bunch of gotos mixed with set-port commands at the machine
code level. In the second case, the sophisticated bug control and
packaging features of Ada can help develop the code faster than other
languages, regardless of whether Ada is the target language; that is, 
after developing in Ada, if you find that the code is mostly just a
bunch of FSAs anyway, you can stamp them out as boiler plate assembler code,
using those same FSAs with a different action matrix, and use that
assembler code as the target. However, in an autonomous robot, Ada might
be the best language for the final target as well.

Re: ada and robots

[Stephen Leake]

The NASA Space Station project was using Ada to write a robot control
system; we got one working in the lab that did some good demos, but then
the project was cancelled. We used Ada 83, targeting bare Intel 386 in a
Multibus. I was VERY glad we were using Ada; it gave precise control
over low-level bits, and at the same time enforced high-level
interfaces.

JPL did some Ada robotics, but then they switched to C++ and TCL/TKL.

You can see some of my Ada code for Robotics from my web page:

http://www710.gsfc.nasa.gov/~sal714/homepage.html

-- 
- Stephe

Re: ada and robots

[John Cook]

John Bohn wrote:
> 
> I am an Ada student. I have heard that Ada was designed for embeded
> systems, but I haven't heard much about micro controller ada
> programming.
> 
> Does anyone know about any examples of the usage of Ada for robots
> and programming micro controllers?
> 
> Thank you very much
> John Bohn


If you like ADA, that is, if you enjoy very very verbose code and a very
limited set of vendors then ADA is OK.  

However, if you want a small, terse language that is easily expandable,
has been proven for 30 years and has a huge set of vendors that target
the type of small systems a student can afford, look into C language. 
I'll admit that its harder to read than ADA but K&R wanted a portable
assembly language with a rich set of operators  and minimal constraints
so they invented C, and it works.  (And everyone uses it, unlike ADA).

just my $0.02

-John C.-**
-- 
Founder of Nashua Robot Builders, small computer/robot club in Nashua,
NH
jdcook@tiac.net 
http://www.tiac.net/users/bigqueue/others/robot/homepage.htm
Member of the national lawsuit to repeal the Communications Decency Act.
Happy ferret owner.

Re: ada and robots

[Tom Moran]

> K&R wanted a portable
> assembly language with a rich set of operators  and minimal constraints
> so they invented C
  How many people still use K&R C?  Would you call C++ a portable
assembly language?

Re: ada and robots

[Dale Stanbrough]

John Cook writes:

"If you like ADA, that is, if you enjoy very very verbose code and a very
 limited set of vendors then ADA is OK.  
 
 However, if you want a small, terse language that is easily expandable,
 has been proven for 30 years and has a huge set of vendors that target
 the type of small systems a student can afford, look into C language. 
 I'll admit that its harder to read than ADA but K&R wanted a portable
 assembly language with a rich set of operators  and minimal constraints
 so they invented C, and it works.  (And everyone uses it, unlike ADA)."


The level of Usenet debate never ceases to amaze me (or maybe it's just
debate in general).

Lots of claims made about C, and many inferences that similar capabilities
in Ada are not available.
Lets look at them...

"small terse language"
	agree

"easily expandable"
	perhaps, but it seems that small systems restrict rather than expand
	facilities. I wonder what features you are thinking of.

"proven for 30 years"
	So it has was written well before 1967, and has been _proven_ in the
	30 years hence? (I don't regard the first year of tinkering with a 
	language as proving it!). I always thought it was written in the '70's.
	Note that C proving itself has led to the introduction of constants,
	references, namespaces, prototypes etc etc etc. in recent years.

"huge set of vendors"
	Could well be. It's certainly easier for people to write a compiler
	for than Ada. Still what counts is is there a compiler/tools company
	for the stuff you are interested in.

"small systems a student can afford"
	The Meridian Ada compiler, which comes for free with a book, is rather
	cheap, and targets any of the 8086 family (which are cheap, no?).
	It is Ada83 however. So I think you agree with you.

"its harder to read than ADA"
	I think i'ld agree for most things (for arrays of ragged strings C is
	much easier to read, also there is a dichotomy b/w simple {} and the 
	named construct/end construct in terms of readability).

"but K&R wanted..."
	But? This is the strangest claim of all. Why is readability
	inimical to a portable assembly language (which i don't think C is)?
	You could easily change the reserverd words etc, and provide
	references a'la C++, which would dramatically improve it's
	readability.

"a rich set of operators"
	...and by implication Ada does not have. Maybe it doesn't have the
	same set of operators per se (such as "<<", ">>" etc), but it
	certainly has equivalent functionality, which is what really counts
	(functions shift_left, shift_right)

"minimal constraints"
	...and by implication Ada does not have. I'm not really sure what
	you are on about here. What feature does C have that Ada doesn't?

"and it works"
	...and by implication Ada doesn't. What a funny thing to say. In
	what way doesn't it work technically?

"(And everyone uses it, unlike ADA)"
	Well it don't think _everyone_ uses it. I agree with you that not
	everyone uses Ada, but universal quantification has always been  a
	rather heavy claim to support.


Whew!

Dale

Re: ada and robots

[John G. Volan]

Dale Stanbrough wrote:
> 
> John Cook writes:
> 
> "small systems a student can afford"
>         The Meridian Ada compiler, which comes for free with a book, is rather
>         cheap, and targets any of the 8086 family (which are cheap, no?).
>         It is Ada83 however. So I think you agree with you.

Come now, don't tell me you haven't heard of GNAT?  It runs on pretty
near everything (UNIX, DOS, Wintel, even Mac).  And you can download it
for free.  (Well, on a Mac you have to spend $99 to get Machten, a port
of BSD Unix that runs as a Mac app, but then you get GNAT for free. And
it does let you write standalone Mac apps in Ada.)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Joe Gwinn]

In article <5mv984$7kn@news.emi.com>, jejo@empireone.net (Jesse Johnson) wrote:

> Ada was designed by the DOD as a systems programming language
> for embedded systems in military vehicles, while C was designed as an
> application programming language to be run on top of systems.  This
> makes Ada inherently better suited for robot programming.  However,
> for someone like me who has done a number of years of application
> programming and is now trying robotics, it's easier to use C because I
> already know it.

Umm, C was written as a systems (that is, operating systems) programming
language, riding right on the metal.  The comparison was assembly code.  C
was intended to be in effect a machine-independent assembly language, so
that an OS (UNIX) written in C would be portable from platform to
platform.  

Read the Introduction section of K&R to get the short history and original
intent of C.  For a non-Ada comparison, read the Introduction section on
page 133 of the "Pascal User Manual and Report", 2nd ed, Jensen and Wirth,
Springer-Verlag 1974.  Recall that Pascal was the base language upon which
Ada was based.  Reading these side by side is quite illuminating.

So, one cannot conclude on the basis of original intent alone that Ada is
more suited to robot programming, as both were intended from the start to
ride the metal.  

In practice, C was much more successful than Ada83 at riding metal. 
Experience with Ada83 shows that it is very bad at direct control of
hardware, especially I/O hardware, and simply does not handle shared
memory correctly.  Ada95 is claimed to be better, but I don't have any
direct experience with it.  Actually, not many people do just yet.  I
suspect that most people are using C (perhaps called from Ada) for direct
control of I/O hardware and the like.

Most "Ada systems" I have seen built recently are actually mixed-language
systems, being a mix of C, C++, and Ada, with the Ada being in the
minority (maybe 25%), if one counts all the purchased COTS code in the
system.  Typically, the operating system, middleware, and GUI stuff are
all in C, and the application code is mostly in Ada (with C bindings, and
no Ada runtime).

Not all Ada compilers offer adequate support for such mixed-language
systems, especially when it comes time to debug on target (vice host)
systems.  This can be a severe problem, because it's generally impossible
to build a competitive offering without extensive use of COTS components,
which are almost always in C/C++, and impossible to get working soon
enough to matter without good debugging support.  Whatever set of
compilers and tools you plan to use should be demonstrated to do *exactly*
what you need done, with sufficient performance, before purchase.  Don't
assume that anything works until proven.  (A year ago, we very nearly
bought an Ada that couldn't even link a mixed-language (C and Ada83)
VxWorks system, let alone execute the code and debug.  Insisting on a true
and accurate demo saved our butts.)

I would also comment that DoD's recent recinding of the Ada Mandate will
likely cause the Ada compiler and tools market to shrink to perhaps as
little as one tenth of its prior size, and that significant added
investment in Ada compilers and tools is therefore unlikely, at least
until the size of the remaining market becomes clear.  A significant
shrink is widely expected because the many DoD customers who chose Ada
because of the mandate will now immediately vanish, and DoD's big push
towards COTS is in effect a push to C/C++.  The Ada market used to be at
most one tenth the size of the C market, and things took forever to get to
the Ada world.  Now, it will be one hundredth.  So, if something Ada is
not in hand today, don't wait.  It could be a long time coming.  

Joe Gwinn

Re: ada and robots

[John G. Volan]

Joe Gwinn wrote:

> Experience with Ada83 shows that it is very bad at direct control of
> hardware, especially I/O hardware, and simply does not handle shared
> memory correctly.  

Could you please elaborate a bit on the technical merits of this claim? 
Your assertion is a curious one, because in my experience Ada83 was very
useful for just this sort of application, when applied with a bit of
care and good judgment.  Before anyone on this group can evaluate the
validity of your claim, we have to discount the possibility that your
bad experiences might have been due to (1) the admittedly poor quality
some early Ada83 implementations (happily now _ancient_ history); (2)
poor understanding of the facilities of Ada83, and how best to apply
them; (3) willful _misunderstanding_ of the facilities of Ada83,
attempting to apply them as if programming in a different language,
thereby losing all the advantages of Ada and creating an artificial set
of "disadvantages"; (4) forced introduction of Ada83 into a culture
openly hostile to its adoption, making its failure in that culture a
foregone conclusion; or (5) all of the above.

> Ada95 is claimed to be better, but I don't have any
> direct experience with it.  

Hmm ... so what you're saying is you don't really have any useful recent
information for us, either way?  

>Actually, not many people do just yet.

Oh, there are a few.  I've done my share of low-level bit-twiddling with
Ada95, and before that, with Ada83. I've been getting away from the
low-level stuff lately, but I know of some other folks with some real
heavy-metal experience with Ada95.  Jim H., care to chime in here? :-)

However, in my experience, it's always been the _abstractions_ that have
saved my butt: Because of the (admittedly cultural) tendency in Ada to
encapsulate lower-level stuff into higher-level abstractions, when push
came to shove on efficiency you could go down into the abstractions,
pick a different implementation, and magically improve performance
across the board, without having to do a lot of massive ripping and
tearing in the application design.  But that takes a certain kind of
engineering skill sadly lacking in the typical silicon jockey weened on
C...

> I
> suspect that most people are using C (perhaps called from Ada) for direct
> control of I/O hardware and the like.

Most likely for cultural, rather than technical reasons.

> Most "Ada systems" I have seen built recently are actually mixed-language
> systems, being a mix of C, C++, and Ada, with the Ada being in the
> minority (maybe 25%), if one counts all the purchased COTS code in the
> system.  Typically, the operating system, middleware, and GUI stuff are
> all in C, and the application code is mostly in Ada (with C bindings, and
> no Ada runtime).

It's really a question of attitude: Is your glass 3/4 empty, or 1/4
full?

To me, given the sheer cultural and marketing inertia propping up C, a
25% inroad of Ada on a project sounds like a phenomenal success against
enormous odds. It demonstrates what many have been saying: Ada is great
for gluing together multi-language code, and for adding a much-needed
layer of abstraction over the miserable bit-twiddling that passes for
APIs these days. It also shows that Ada is a good choice for the code
that you actually have to write and maintain yourself (as opposed to the
code you simply buy from somewhere else).

> Not all Ada compilers offer adequate support for such mixed-language
> systems, especially when it comes time to debug on target (vice host)
> systems.  This can be a severe problem, because it's generally impossible
> to build a competitive offering without extensive use of COTS components,
> which are almost always in C/C++, and impossible to get working soon
> enough to matter without good debugging support.  

If the COTS products you bought are so poorly engineered and documented
that you need to diddle them with a debugger (of all things) to get them
to work, or even just to figure out how to actually interface with them,
then you've got some very serious problems that have nothing to do with
the quality of your Ada compiler. The fact that such products are
written in C or C++ is not exactly a glowing endorsement of either of
those two languages.

> Whatever set of
> compilers and tools you plan to use should be demonstrated to do *exactly*
> what you need done, with sufficient performance, before purchase.  Don't
> assume that anything works until proven.  (A year ago, we very nearly
> bought an Ada that couldn't even link a mixed-language (C and Ada83)
> VxWorks system, let alone execute the code and debug.  Insisting on a true
> and accurate demo saved our butts.)

That was, of course, wise.  But I wonder if the same stringent criteria
have ever been applied to those wonderful COTS products about which I've
heard so much glowing hype^H^H^H^H praise lately... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Joe Gwinn]

In article <33961528.2A9A@sprintmail.com>, johnvolan@sprintmail.com wrote:

> Joe Gwinn wrote:
> 
> > Experience with Ada83 shows that it is very bad at direct control of
> > hardware, especially I/O hardware, and simply does not handle shared
> > memory correctly.  
> 
> Could you please elaborate a bit on the technical merits of this claim? 
> Your assertion is a curious one, because in my experience Ada83 was very
> useful for just this sort of application, when applied with a bit of
> care and good judgment.  Before anyone on this group can evaluate the
> validity of your claim, we have to discount the possibility that your
> bad experiences might have been due to (1) the admittedly poor quality
> some early Ada83 implementations (happily now _ancient_ history); (2)
> poor understanding of the facilities of Ada83, and how best to apply
> them; (3) willful _misunderstanding_ of the facilities of Ada83,
> attempting to apply them as if programming in a different language,
> thereby losing all the advantages of Ada and creating an artificial set
> of "disadvantages"; (4) forced introduction of Ada83 into a culture
> openly hostile to its adoption, making its failure in that culture a
> foregone conclusion; or (5) all of the above.

OK.  Even if you choose to discount my experience as the blatherings of an
idiot.  But remember, I don't have to convince you of anything.  I do have
to deliver a working, reliable product.

Typically, there are only a few code development systems adequate to the
scale of our developments, and toolset quality is a major productivity and
therefore cost and schedule issue.  This is true of all languages, and Ada
is no exception.  Ada toolsets have always been a problem, due largely to
the small size of the Ada market relative to the C/C++ market. 
Engineering energy follows the money, and money follows market share.  It
doesn't matter at all if one language is better than another, the market
governs, right or wrong.

As for Ada83 experience, I have (or know of) both old and new experience,
and most Ada83 compilers were very difficult to use for direct hardware
control.  I suppose one could have made them work, but why would you?  If
it's that hard, it won't be reliable.  We often reverted to assembly code
for the machine control bits, long before C was a true option.  (We did
the same when the base language was Fortran or Pascal, for the same
reasons.)  

The shining exception to Ada83-can't-do-hardware was the late lamented SD
Ada, and some people had success with pre-Rational Verdix.  I think it
depended on which target system was chosen.  

As for Ada83 and shared memory, the problem was that the Ada83 compilers
all believed that only they changed memory, so it was OK to cache data
items in CPU registers for long periods of time.  For the most part, there
was no reliable (and portable) way to tell the compiler different, so we
performed various dances to ensure that Ada83 never knew the whole truth.

In the current development, the one with 25% Ada and the rest C/C++,
mentioned below, which is being coded as we speak, Ada talks only to
VxWorks (via a binding), and only the C-coded I/O drivers touch metal. 
This was decided on architectural grounds, not language issues: the rule
is that application code (regardless of language) is forbidden to touch
metal.  Confining hardware details to these I/O drivers makes the overall
system more portable and resistant to inevitable hardware changes.

I must say that our greatest problem with "willful _misunderstanding_ of
the facilities of Ada83" have been in the direction of incautious overuse
of some inappropriate features of Ada.  Just because a language has a
feature doesn't mean that the feature should be used in a specific
application.  This is true in all languages, and all teams have their
incautious members.

The team is a mixture of Ada lovers (including the chief programmer, who
loves SD Ada), C++ lovers (used for the GUIs), cynical agnostics (such as
myself), and programmers without portfolio.  


> > Ada95 is claimed to be better, but I don't have any
> > direct experience with it.  
> 
> Hmm ... so what you're saying is you don't really have any useful recent
> information for us, either way?  

That is what I said, only more politely.  What's the point you wish to make?  

Anyway, on Ada95, not yet.  We are just now benchmarking the Ada83 code in
which the project will be coded against both Ada83 and Ada95 compilers. 
For portability and from fear of the immature, we are staying in the Ada83
subset of Ada95.  


> >Actually, not many people do just yet.
> 
> Oh, there are a few.  I've done my share of low-level bit-twiddling with
> Ada95, and before that, with Ada83. I've been getting away from the
> low-level stuff lately, but I know of some other folks with some real
> heavy-metal experience with Ada95.  Jim H., care to chime in here? :-)

Just as I said: "not many" is the same as "a few".  As I said above, we
are in the process of trying an Ada95 compiler.  However, we will not test
the ability of Ada95 to do direct machine control, although one would hope
and pray that it is improved over Ada83.



> However, in my experience, it's always been the _abstractions_ that have
> saved my butt: Because of the (admittedly cultural) tendency in Ada to
> encapsulate lower-level stuff into higher-level abstractions, when push
> came to shove on efficiency you could go down into the abstractions,
> pick a different implementation, and magically improve performance
> across the board, without having to do a lot of massive ripping and
> tearing in the application design.  But that takes a certain kind of
> engineering skill sadly lacking in the typical silicon jockey weened on
> C...

Abstractions are language independent.  So is programmer skill.

 
> > I
> > suspect that most people are using C (perhaps called from Ada) for direct
> > control of I/O hardware and the like.
> 
> Most likely for cultural, rather than technical reasons.

No.  It's lazyness: cost and schedule.  Current COTS operating systems are
in C, as are I/O drivers for those operating systems.  We can get the code
and reuse it.  Using Ada to write an I/O driver for a C-coded operating
system doesn't seem like the shortest road home to me, especially if a
driver is already available.  Driver writing is difficult, and best
avoided.

 
> > Most "Ada systems" I have seen built recently are actually mixed-language
> > systems, being a mix of C, C++, and Ada, with the Ada being in the
> > minority (maybe 25%), if one counts all the purchased COTS code in the
> > system.  Typically, the operating system, middleware, and GUI stuff are
> > all in C, and the application code is mostly in Ada (with C bindings, and
> > no Ada runtime).
> 
> It's really a question of attitude: Is your glass 3/4 empty, or 1/4
> full?
> 
> To me, given the sheer cultural and marketing inertia propping up C, a
> 25% inroad of Ada on a project sounds like a phenomenal success against
> enormous odds. It demonstrates what many have been saying: Ada is great
> for gluing together multi-language code, and for adding a much-needed
> layer of abstraction over the miserable bit-twiddling that passes for
> APIs these days. It also shows that Ada is a good choice for the code
> that you actually have to write and maintain yourself (as opposed to the
> code you simply buy from somewhere else).

Use of Ada was mandated by our DoD customer.  Actually, they now regret
it, but it's too late to change.  And, Ada isn't gluing anything together,
it's being glued together with C.  None of the APIs know from bits, except
as the unit of data length.


> > Not all Ada compilers offer adequate support for such mixed-language
> > systems, especially when it comes time to debug on target (vice host)
> > systems.  This can be a severe problem, because it's generally impossible
> > to build a competitive offering without extensive use of COTS components,
> > which are almost always in C/C++, and impossible to get working soon
> > enough to matter without good debugging support.  
> 
> If the COTS products you bought are so poorly engineered and documented
> that you need to diddle them with a debugger (of all things) to get them
> to work, or even just to figure out how to actually interface with them,
> then you've got some very serious problems that have nothing to do with
> the quality of your Ada compiler. The fact that such products are
> written in C or C++ is not exactly a glowing endorsement of either of
> those two languages.

This is embedded realtime.  Built for speed, not comfort.  Yes, COTS
products aren't perfect.  Nothing is.  The language in which they are
written is irrelevant to their degree of perfection; it's a matter of how
much energy has or has not been spent on making the code work right.  If
we could find a perfect product, we would buy it.  And, yes, we do have to
debug the system before delivery.  So, debugging is critical to our
ability to deliver on time, etc. 


> > Whatever set of
> > compilers and tools you plan to use should be demonstrated to do *exactly*
> > what you need done, with sufficient performance, before purchase.  Don't
> > assume that anything works until proven.  (A year ago, we very nearly
> > bought an Ada that couldn't even link a mixed-language (C and Ada83)
> > VxWorks system, let alone execute the code and debug.  Insisting on a true
> > and accurate demo saved our butts.)
> 
> That was, of course, wise.  But I wonder if the same stringent criteria
> have ever been applied to those wonderful COTS products about which I've
> heard so much glowing hype^H^H^H^H praise lately... :-)

We always claim we will.  Sometimes we do.  It depends on the
personalities and scars of the team leaders.   It took 6 to 9 months of
broken-record harping and deflection of off-the-point demonstrations
before the abject failure of that toolset became undeniable, even to those
in full denial.  The will to believe, and to just go along, is very
powerful.

Joe Gwinn

Re: ada and robots

[Robert Dewar]

<<Joe said
                                                                                
<<As for Ada83 and shared memory, the problem was that the Ada83 compilers      
all believed that only they changed memory, so it was OK to cache data          
items in CPU registers for long periods of time.  For the most part, there      
was no reliable (and portable) way to tell the compiler different, so we        
performed various dances to ensure that Ada83 never knew the whole truth.>>     
                                                                                
                                                                                
Well for items that could be kept in registers, e.g. small scalars, which       
typically corresponds to the need for messing with IO mapped memory, I fail    
to see why the standard feature - pragma Shared - would not be exactly
what you needed. Please explain why pragma Shared did not do the job. if
you were using a compiler that did not implement pragma Shared, then it
was not an Ada 83 compiler, but a compiler for a subset of the language.

<<abstractions are language independent>>

That is nonsense. Languages have HUGE differences in abstraction capabilities.
Anyone who thinks COBOL has the same abtraction capabilities as say, Pascal,
knows NOTHING about either language.

Re: ada and robots

[Joe Gwinn]

In article <dewar.866303747@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> <<Joe said
>                                                                                

> <<As for Ada83 and shared memory, the problem was that the Ada83
compilers      
> all believed that only they changed memory, so it was OK to cache
data          
> items in CPU registers for long periods of time.  For the most part,
there      
> was no reliable (and portable) way to tell the compiler different, so
we        
> performed various dances to ensure that Ada83 never knew the whole
truth.>>     
>                                                                                

>                                                                                

> Well for items that could be kept in registers, e.g. small scalars,
which       
> typically corresponds to the need for messing with IO mapped memory, I
fail    
> to see why the standard feature - pragma Shared - would not be exactly
> what you needed. Please explain why pragma Shared did not do the job. if
> you were using a compiler that did not implement pragma Shared, then it
> was not an Ada 83 compiler, but a compiler for a subset of the language.

The problem was that not all Ada83 compilers implemented pragma shared
correctly, or the same, so we couldn't depend on pragma shared.  It was
simpler, and --oddly-- more portable to just use assembly.  Ada95 is
supposed to have fixed this problem, which was shared by pragma volatile.


> <<abstractions are language independent>>
> 
> That is nonsense. Languages have HUGE differences in abstraction capabilities.
> Anyone who thinks COBOL has the same abtraction capabilities as say, Pascal,
> knows NOTHING about either language.

Ahh ... let's talk only about modern, mainstream languages, like Ada and
C.  Or, we need also to pull in every cat and dog research language that
ever was, and I grant you that many of them are cripples.  Anyway, it
seems to matter more *who* is doing the abstracting than the details of
the language they use.

Joe Gwinn

Re: ada and robots

[Shmuel (Seymour J.) Metz]

Joe Gwinn wrote:
> 
> 
> Ahh ... let's talk only about modern, mainstream languages, like Ada and
> C.  
> 
> Joe Gwinn

*C* is modern? Dis I miss the <sarcasm> </sarcasm> tags around it?

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: ada and robots

[John G. Volan]

Joe Gwinn wrote:

> OK.  Even if you choose to discount my experience as the blatherings of an
> idiot.  

Not at all. An idiot could not have pushed my hot buttons, because his
blatherings would carry no weight. When an intelligent and thoughtful
engineer voices criticisms that are based on outdated information and/or
possible misunderstanding of the technology, that's when my hot buttons
get pushed.

Well, that's no excuse for be to go off the handle. It was hypocritical
of me to complain about personal attacks, and then engage in one, all on
the same day. For that I do apologize. However, with all due respect, I
believe your statements do a disservice to both the past situation with
Ada83, and the current situation with Ada95.

> But remember, I don't have to convince you of anything.  I do have
> to deliver a working, reliable product.

Fair enough.

> Typically, there are only a few code development systems adequate to the
> scale of our developments, and toolset quality is a major productivity and
> therefore cost and schedule issue.  This is true of all languages, and Ada
> is no exception.  Ada toolsets have always been a problem, due largely to
> the small size of the Ada market relative to the C/C++ market.
> Engineering energy follows the money, and money follows market share.  It
> doesn't matter at all if one language is better than another, the market
> governs, right or wrong.

This situation was lamentable for Ada83, but it is rapidly improving for
Ada95.

> As for Ada83 experience, I have (or know of) both old and new experience,

If you have _new_ experience with Ada83, that's a problem you need to
solve as soon as you can. The Ada95 compilers out there (especially
GNAT) are a vast improvement over those that were available for Ada83.
And Ada95 is the standard now; Ada _is_ Ada95.

> and most Ada83 compilers were very difficult to use for direct hardware
> control. I suppose one could have made them work, but why would you?  If
> it's that hard, it won't be reliable. 

I think you're overplaying the difficulties, even those that might have
existed in the past.  They might actually have been trivial to solve
even in Ada83, but they would have seemed insurmountable to anyone not
really motivated to find the Ada83 solution. In any event, early
experiences with Ada95 have indicated that it can do the job, so there
seems little point in bemoaning deficiencies (real or perceived) in
Ada83. 

> We often reverted to assembly code
> for the machine control bits, long before C was a true option.  (We did
> the same when the base language was Fortran or Pascal, for the same
> reasons.)

Always an option, but then such bits should be isolated as quickly as
possible and encapsulated into abstractions which can then be used by
the application logic (which would still represent the bulk of the
program). This is not an argument against writing a hardware control
application in Ada, it only argues that there may be isolated
specialized control functions that can only be done via assembly (in
which case, machine-code insertions would seem ideal). But it is not
clear whether even that much was really necessary in Ada83, and of
course it says nothing about Ada95...

> The shining exception to Ada83-can't-do-hardware was the late lamented SD
> Ada, and some people had success with pre-Rational Verdix.  I think it
> depended on which target system was chosen.

What bothers me about this is that, although you had some negative
experiences with some poor implementations of Ada83, you've also had
some positive experiences with some better implementations of Ada83.
This would argue that the problems you encountered were due to the
quality of particular implementations, not the suitability of the
language itself. Yet, despite this, your predisposition seems to be to
make blanket negative statements about the language. This is why I
suspect a purely cultural prejudice is at work here.

> As for Ada83 and shared memory, the problem was that the Ada83 compilers
> all believed that only they changed memory, so it was OK to cache data
> items in CPU registers for long periods of time.  For the most part, there
> was no reliable (and portable) way to tell the compiler different, so we
> performed various dances to ensure that Ada83 never knew the whole truth.

Surely pragma Volatile would have cured this? (Even in Ada83?)

> In the current development, the one with 25% Ada and the rest C/C++,
> mentioned below, which is being coded as we speak, Ada talks only to
> VxWorks (via a binding), and only the C-coded I/O drivers touch metal.
> This was decided on architectural grounds, not language issues: the rule
> is that application code (regardless of language) is forbidden to touch
> metal.  Confining hardware details to these I/O drivers makes the overall
> system more portable and resistant to inevitable hardware changes.

Fine, reuse is always preferable to writing from scratch. But this says
nothing about the suitability of Ada for low-level hardware control
where a base of driver software does not already exist.

> I must say that our greatest problem with "willful _misunderstanding_ of
> the facilities of Ada83" have been in the direction of incautious overuse
> of some inappropriate features of Ada.  Just because a language has a
> feature doesn't mean that the feature should be used in a specific
> application.  This is true in all languages, and all teams have their
> incautious members.

As you start getting some new Ada95 systems in (or just go ahead and
download GNAT and start playing :-) ), be sure to re-evaluate some of
those "inappropriate features" that might have bit you in the past. In
all likelihood, they were just a symptom of the poor quality of some of
the implementations back then. You may be quite surprised how good their
performance is today.

> > > Ada95 is claimed to be better, but I don't have any
> > > direct experience with it.
> >
> > Hmm ... so what you're saying is you don't really have any useful recent
> > information for us, either way?
> 
> That is what I said, only more politely.  What's the point you wish to make?

My point was that your information is out-of-date, yet you used it to
cast a general indictment of Ada83, and by implication Ada95.  When you
say that others have "claimed" Ada95 is better, but you can't
substantiate those claims, the implication is that those cannot be
substantiated. They can.

> Anyway, on Ada95, not yet.  We are just now benchmarking the Ada83 code in
> which the project will be coded against both Ada83 and Ada95 compilers.
> For portability and from fear of the immature, we are staying in the Ada83
> subset of Ada95.

Do the benchmarking, but don't be afraid to try the new features. Of
course, it does depend on the compiler, but some of those new features
(e.g., protected types rather than passive tasks) can allow you to
improve your software designs right now.

> > However, in my experience, it's always been the _abstractions_ that have
> > saved my butt... [snip] ... But that takes a certain kind of
> > engineering skill sadly lacking in the typical silicon jockey weened on
> > C...
> 
> Abstractions are language independent.  So is programmer skill.

Not in my experience. For better or worse, each language has an attached
culture that influences the quality of the engineers trained to program
in it. I've found that programmers with Ada experience were generally
better abstractionists than those with C experience.  I would trust an
Ada programmer programming in C much farther than a C programmer trying
to program in Ada.


> This is embedded realtime.  Built for speed, not comfort.  Yes, COTS
> products aren't perfect.  Nothing is.  The language in which they are
> written is irrelevant to their degree of perfection; it's a matter of how
> much energy has or has not been spent on making the code work right.  If
> we could find a perfect product, we would buy it.  And, yes, we do have to
> debug the system before delivery.  So, debugging is critical to our
> ability to deliver on time, etc.

Over-reliance on debugging is a cost-and-schedule black hole. A much
more profitable course is to: (1) demand excellent documentation of the
behavior of third-party COTS components; (2) regardless of the quality
of such documentation, rigorously test and benchmark the COTS components
to establish their actual behavior _before_ attempting to integrate
them; (3) for the application code, use technical peer reviews
("walkthroughs") at all stages of development -- requirements, design,
and coding -- to catch software flaws as early in the pipeline as
possible (the earlier an error is detected, the cheaper it is to fix);
(4) perform black-box unit testing on the host system for everything
except the lowest-level hardware-specific code (and even for the latter,
it is often useful to build a software simulation of the target hardware
and test against that); (4) use debugging-on-target only as a _very_
last resort. 

> We always claim we will.  Sometimes we do.  It depends on the
> personalities and scars of the team leaders.   It took 6 to 9 months of
> broken-record harping and deflection of off-the-point demonstrations
> before the abject failure of that toolset became undeniable, even to those
> in full denial.  The will to believe, and to just go along, is very
> powerful.

Just for the record, are you still talking about an Ada toolset here, or
about some set of COTS products?  If the former, it would be helpful to
this newsgroup if you identified it, so it can be avoided. We'll
understand, however, if you are reluctant to name names.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[RC]

In <3398E102.54CF@sprintmail.com> by "John G. Volan"
<johnvolan@sprintmail.com>
>> Abstractions are language independent.  So is programmer skill.

>Not in my experience. For better or worse, each language has an attached
>culture that influences the quality of the engineers trained to program
>in it. I've found that programmers with Ada experience were generally
>better abstractionists than those with C experience.  I would trust an
>Ada programmer programming in C much farther than a C programmer trying
>to program in Ada.

Seems reasonable.

I have no statistical evidence but presumably, an Ada programmer tends
to be proud of the readability of his software and attempts to write his
C in a similar style.

As hard as a one line C program fan tries, his Ada code must be
inherently more accessible than his prior equivalent C program.  So the
C world stands to gain from the influence of Ada programmers and C
programmers are unlikely to do that much damage to the Ada world.
Anyone who can do it in C it should have no trouble in Ada.


RC1

Re: ada and robots

[Joe Gwinn]

In article <3398E102.54CF@sprintmail.com>, johnvolan@sprintmail.com wrote:

> Joe Gwinn wrote:
> 
> > OK.  Even if you choose to discount my experience as the blatherings of an
> > idiot.  
> 
> Not at all. An idiot could not have pushed my hot buttons, because his
> blatherings would carry no weight. When an intelligent and thoughtful
> engineer voices criticisms that are based on outdated information and/or
> possible misunderstanding of the technology, that's when my hot buttons
> get pushed.

All information is outdated.  It's only a matter of how much so.

 
> Well, that's no excuse for be to go off the handle. It was hypocritical
> of me to complain about personal attacks, and then engage in one, all on
> the same day. For that I do apologize. 

Accepted.


> ...  However, with all due respect, I
> believe your statements do a disservice to both the past situation with
> Ada83, and the current situation with Ada95.

I've been hyped at a few times too many over the years.  I'll believe the
problems are fixed when I see that they are fixed, in my own lab.


> > Typically, there are only a few code development systems adequate to the
> > scale of our developments, and toolset quality is a major productivity and
> > therefore cost and schedule issue.  This is true of all languages, and Ada
> > is no exception.  Ada toolsets have always been a problem, due largely to
> > the small size of the Ada market relative to the C/C++ market.
> > Engineering energy follows the money, and money follows market share.  It
> > doesn't matter at all if one language is better than another, the market
> > governs, right or wrong.
> 
> This situation was lamentable for Ada83, but it is rapidly improving for
> Ada95.

So many people are saying.  We shall see; our experiments are just
beginning.  However, direct control of hardware by Ada is not in our
architecture, as only VxWorks I/O drivers are permitted to touch the
metal, so that issue will not be tested.


> > As for Ada83 experience, I have (or know of) both old and new experience,
> 
> If you have _new_ experience with Ada83, that's a problem you need to
> solve as soon as you can. The Ada95 compilers out there (especially
> GNAT) are a vast improvement over those that were available for Ada83.
> And Ada95 is the standard now; Ada _is_ Ada95.

Our current (as of last week) experience with Ada83 is that the generated
code is *very* slow; this is why we are flirting with Ada95, which appears
to be a factor faster.  C is a bit faster still than Ada95, but not so
much that one would choose one over the other on that alone.  When the
experiments are complete, I may publish actual test results.  


> > and most Ada83 compilers were very difficult to use for direct hardware
> > control. I suppose one could have made them work, but why would you?  If
> > it's that hard, it won't be reliable. 
> 
> I think you're overplaying the difficulties, even those that might have
> existed in the past.  They might actually have been trivial to solve
> even in Ada83, but they would have seemed insurmountable to anyone not
> really motivated to find the Ada83 solution. In any event, early
> experiences with Ada95 have indicated that it can do the job, so there
> seems little point in bemoaning deficiencies (real or perceived) in
> Ada83. 

See above.  By "reliable", I also meant to include "portable".  Even if I
got it to work under one compiler, the next one has its own set of
oddities.  See below.


> > We often reverted to assembly code
> > for the machine control bits, long before C was a true option.  (We did
> > the same when the base language was Fortran or Pascal, for the same
> > reasons.)
> 
> Always an option, but then such bits should be isolated as quickly as
> possible and encapsulated into abstractions which can then be used by
> the application logic (which would still represent the bulk of the
> program). This is not an argument against writing a hardware control
> application in Ada, it only argues that there may be isolated
> specialized control functions that can only be done via assembly (in
> which case, machine-code insertions would seem ideal). But it is not
> clear whether even that much was really necessary in Ada83, and of
> course it says nothing about Ada95...

With the Ada83 compilers of our experience, except for SD Ada, it *was*
necessary, and so it was safer to simply have a few assembly-coded (or
C-coded) machine control subroutines.  

I guess I don't see why people are so hard over on defending Ada here. 
It's not like we are talking about much code, and the only traditional HOL
intended to do anything like this is C, which is why one generally did
this stuff in assembly.  The fact that in my experience Ada doesn't do
hardware control well isn't a reason to use or not use Ada for a project,
and I have no religious objection to use of multiple languages in a
project.

 
> > The shining exception to Ada83-can't-do-hardware was the late lamented SD
> > Ada, and some people had success with pre-Rational Verdix.  I think it
> > depended on which target system was chosen.
> 
> What bothers me about this is that, although you had some negative
> experiences with some poor implementations of Ada83, you've also had
> some positive experiences with some better implementations of Ada83.
> This would argue that the problems you encountered were due to the
> quality of particular implementations, not the suitability of the
> language itself. Yet, despite this, your predisposition seems to be to
> make blanket negative statements about the language. This is why I
> suspect a purely cultural prejudice is at work here.

I guess that all but one then implementation of Ada83 was poor, then.  I
don't know that much has changed, because the Ada compiler vendors have
put their efforts into Ada95, leaving Ada83 on maintenance.  As one would
expect.  And certainly what the newsgroup is saying.


> > As for Ada83 and shared memory, the problem was that the Ada83 compilers
> > all believed that only they changed memory, so it was OK to cache data
> > items in CPU registers for long periods of time.  For the most part, there
> > was no reliable (and portable) way to tell the compiler different, so we
> > performed various dances to ensure that Ada83 never knew the whole truth.
> 
> Surely pragma Volatile would have cured this? (Even in Ada83?)

In theory, it should have.  However, only SD and perhaps DEC got the
meaning of "volatile" completely correct, so we couldn't depend on it, and
so couldn't use it.  Back to assembly.


> > In the current development, the one with 25% Ada and the rest C/C++,
> > mentioned below, which is being coded as we speak, Ada talks only to
> > VxWorks (via a binding), and only the C-coded I/O drivers touch metal.
> > This was decided on architectural grounds, not language issues: the rule
> > is that application code (regardless of language) is forbidden to touch
> > metal.  Confining hardware details to these I/O drivers makes the overall
> > system more portable and resistant to inevitable hardware changes.
> 
> Fine, reuse is always preferable to writing from scratch. But this says
> nothing about the suitability of Ada for low-level hardware control
> where a base of driver software does not already exist.

I didn't claim that it did.  Our project is what it is.


> > I must say that our greatest problem with "willful _misunderstanding_ of
> > the facilities of Ada83" have been in the direction of incautious overuse
> > of some inappropriate features of Ada.  Just because a language has a
> > feature doesn't mean that the feature should be used in a specific
> > application.  This is true in all languages, and all teams have their
> > incautious members.
> 
> As you start getting some new Ada95 systems in (or just go ahead and
> download GNAT and start playing :-) ), be sure to re-evaluate some of
> those "inappropriate features" that might have bit you in the past. In
> all likelihood, they were just a symptom of the poor quality of some of
> the implementations back then. You may be quite surprised how good their
> performance is today.

I'm not sure we have the budget or schedule for much playing, but some
will be done, under the rubric "pathfinding".

 
> > > > Ada95 is claimed to be better, but I don't have any
> > > > direct experience with it.
> > >
> > > Hmm ... so what you're saying is you don't really have any useful recent
> > > information for us, either way?
> > 
> > That is what I said, only more politely.  What's the point you wish to make?
> 
> My point was that your information is out-of-date, yet you used it to
> cast a general indictment of Ada83, and by implication Ada95.  When you
> say that others have "claimed" Ada95 is better, but you can't
> substantiate those claims, the implication is that those cannot be
> substantiated. They can.

I said just what I said, and implied nothing.  I thought I was quite clear
about what was known and what was rumoured.

 
> > Anyway, on Ada95, not yet.  We are just now benchmarking the Ada83 code in
> > which the project will be coded against both Ada83 and Ada95 compilers.
> > For portability and from fear of the immature, we are staying in the Ada83
> > subset of Ada95.
> 
> Do the benchmarking, but don't be afraid to try the new features. Of
> course, it does depend on the compiler, but some of those new features
> (e.g., protected types rather than passive tasks) can allow you to
> improve your software designs right now.

Actually, the benchmarks must stay in the Ada83 subset of Ada95, which is
after all the bulk of Ada95, so that we can directly compare performance,
size, etc.  The benchmarks are reasonably large bits of actual application
code, which wouldn't have any reason to use the new parts of Ada95 anyway.


> > > However, in my experience, it's always been the _abstractions_ that have
> > > saved my butt... [snip] ... But that takes a certain kind of
> > > engineering skill sadly lacking in the typical silicon jockey weened on
> > > C...
> > 
> > Abstractions are language independent.  So is programmer skill.
> 
> Not in my experience. For better or worse, each language has an attached
> culture that influences the quality of the engineers trained to program
> in it. I've found that programmers with Ada experience were generally
> better abstractionists than those with C experience.  I would trust an
> Ada programmer programming in C much farther than a C programmer trying
> to program in Ada.

In my experience, the best programmers were able to rise above the here
and now of whichever language and operating system they were then using. 
I don't know that I believe that any language, however good, can make good
programmers from bad programmers.  It's only a language.


> > This is embedded realtime.  Built for speed, not comfort.  Yes, COTS
> > products aren't perfect.  Nothing is.  The language in which they are
> > written is irrelevant to their degree of perfection; it's a matter of how
> > much energy has or has not been spent on making the code work right.  If
> > we could find a perfect product, we would buy it.  And, yes, we do have to
> > debug the system before delivery.  So, debugging is critical to our
> > ability to deliver on time, etc.
> 
> Over-reliance on debugging is a cost-and-schedule black hole. A much
> more profitable course is to: (1) demand excellent documentation of the
> behavior of third-party COTS components; (2) regardless of the quality
> of such documentation, rigorously test and benchmark the COTS components
> to establish their actual behavior _before_ attempting to integrate
> them; (3) for the application code, use technical peer reviews
> ("walkthroughs") at all stages of development -- requirements, design,
> and coding -- to catch software flaws as early in the pipeline as
> possible (the earlier an error is detected, the cheaper it is to fix);
> (4) perform black-box unit testing on the host system for everything
> except the lowest-level hardware-specific code (and even for the latter,
> it is often useful to build a software simulation of the target hardware
> and test against that); (4) use debugging-on-target only as a _very_
> last resort. 

Well, it's a nice theory.  Would that it were true in practice.  Somehow,
we always seem to end up in the lab at 3:00 AM.  If we were only smarter.


> > We always claim we will.  Sometimes we do.  It depends on the
> > personalities and scars of the team leaders.   It took 6 to 9 months of
> > broken-record harping and deflection of off-the-point demonstrations
> > before the abject failure of that toolset became undeniable, even to those
> > in full denial.  The will to believe, and to just go along, is very
> > powerful.
> 
> Just for the record, are you still talking about an Ada toolset here, or
> about some set of COTS products?  If the former, it would be helpful to
> this newsgroup if you identified it, so it can be avoided. We'll
> understand, however, if you are reluctant to name names.

Both; they are one in the same.  You have heard of them, too.

I don't know that I could afford the libel suit, even if I won it.  


Joe Gwinn

Re: ada and robots

[Pat Rogers]

Joe Gwinn <gwinn@res.ray.com> wrote in article
<gwinn-0306971836410001@smc19.ed.ray.com>...
> In article <5mv984$7kn@news.emi.com>, jejo@empireone.net (Jesse Johnson)
wrote:
[snip]

> In practice, C was much more successful than Ada83 at riding metal. 
> Experience with Ada83 shows that it is very bad at direct control of
> hardware, especially I/O hardware, and simply does not handle shared
> memory correctly.  Ada95 is claimed to be better, but I don't have any
> direct experience with it.  Actually, not many people do just yet.  I
> suspect that most people are using C (perhaps called from Ada) for direct
> control of I/O hardware and the like.

Your "experience" may be as indicated (you don't say whose) but mine has
been different.  In my experience Ada has been very good at control of
hardware.  I can't imagine what you are talking about with respect to not
handling shared memory correctly.  I've done it gleefully in both versions
of the language, thanks very much.  Is it perfect? Of course not.  What
programming language is?  Certainly not C, including "riding the metal".

> 
> Most "Ada systems" I have seen built recently are actually mixed-language
> systems, being a mix of C, C++, and Ada, with the Ada being in the
> minority (maybe 25%), if one counts all the purchased COTS code in the
> system.  Typically, the operating system, middleware, and GUI stuff are
> all in C, and the application code is mostly in Ada (with C bindings, and
> no Ada runtime).

No run-time, huh.  That would be interesting to see.

[snip]

> I would also comment that DoD's recent recinding of the Ada Mandate will
> likely cause the Ada compiler and tools market to shrink to perhaps as
> little as one tenth of its prior size, and that significant added
> investment in Ada compilers and tools is therefore unlikely, at least
> until the size of the remaining market becomes clear.  

The Hon. Sec. Paige has said that -- in contrast to rescinding the policy
-- it will follow the board's recommendation to fund the $15 million for
infrastructure.

I believe you when you say that you are out of date (at the top of your
post) with respect to Ada.

Re: ada and robots

[Joe Gwinn]

In article <01bc7132$11100fa0$4c0b6dce@my-pc.neosoft.com>, "Pat Rogers"
<progers@acm.org> wrote:

> Joe Gwinn <gwinn@res.ray.com> wrote in article
> <gwinn-0306971836410001@smc19.ed.ray.com>...
> > In article <5mv984$7kn@news.emi.com>, jejo@empireone.net (Jesse Johnson)
> wrote:
> [snip]

> > Most "Ada systems" I have seen built recently are actually mixed-language
> > systems, being a mix of C, C++, and Ada, with the Ada being in the
> > minority (maybe 25%), if one counts all the purchased COTS code in the
> > system.  Typically, the operating system, middleware, and GUI stuff are
> > all in C, and the application code is mostly in Ada (with C bindings, and
> > no Ada runtime).
> 
> No run-time, huh.  That would be interesting to see.

Some of our biggest problems with Ada83 came from the runtime, so the
usual solution was to truncate the runtime, and instead call the
underlying OS (or even CPU hardware) directly from Ada.  This was done
long before C turned up.


> > I would also comment that DoD's recent recinding of the Ada Mandate will
> > likely cause the Ada compiler and tools market to shrink to perhaps as
> > little as one tenth of its prior size, and that significant added
> > investment in Ada compilers and tools is therefore unlikely, at least
> > until the size of the remaining market becomes clear.  
> 
> The Hon. Sec. Paige has said that -- in contrast to rescinding the policy
> -- it will follow the board's recommendation to fund the $15 million for
> infrastructure.

So he's flip-flopped?  I saw his previous missive, a week or two ago, and
it was quite clear.  Actually, he cannot call his words back at this
point; the writing is on the wall.  If you were the product manager for an
ada compiler, wouldn't this stop you in your tracks, afraid to invest more
money, until the smoke cleared?  The very fact that the future of the
mandate is questioned in public and at that level of the DoD is the
story.  If not today, what of tomorrow?  The mandate's days are numbered. 
Will it last long enough for a new investment to be recovered?  A
gut-wrenching question.  Product mamgers get to bet their careers on such
questions.


Joe Gwinn

Re: ada and robots

[Robert Dewar]

Joe said

<<So he's flip-flopped?  I saw his previous missive, a week or two ago, and
it was quite clear.  Actually, he cannot call his words back at this
point; the writing is on the wall.  If you were the product manager for an
ada compiler, wouldn't this stop you in your tracks, afraid to invest more
money, until the smoke cleared?  The very fact that the future of the
mandate is questioned in public and at that level of the DoD is the
story.  If not today, what of tomorrow?  The mandate's days are numbered. 
Will it last long enough for a new investment to be recovered?  A
gut-wrenching question.  Product mamgers get to bet their careers on such
questions.>>

nope, there was no flip-flop here at all. If you perceive one it is because
you have misunderstood what you have read. Sometimes people read into things
that which they wish to perceive, and it is easy to tell what you wish to
perceive!

Re: ada and robots

[Ken Garlington]

Joe Gwinn wrote:
> 
> > > I would also comment that DoD's recent recinding of the Ada Mandate will
> > > likely cause the Ada compiler and tools market to shrink to perhaps as
> > > little as one tenth of its prior size, and that significant added
> > > investment in Ada compilers and tools is therefore unlikely, at least
> > > until the size of the remaining market becomes clear.
> >
> > The Hon. Sec. Paige has said that -- in contrast to rescinding the policy
> > -- it will follow the board's recommendation to fund the $15 million for
> > infrastructure.
> 
> So he's flip-flopped?  I saw his previous missive, a week or two ago, and
> it was quite clear.

These words?

.......................................................................

From: "Paige, Emmett Jr., , OSD/C3I +" <paigee@osd.pentagon.mil>
To: LTC Drew Hamilton <dj7560@eecs1.eecs.usma.edu>
Subject: Re: FW: Reason for Mr. Paige's Decision Unclear
Date: Mon, 10 Mar 1997 18:10:00 -0500

THANK GOD , THIS IS AMERICA.

THE BUCK STOPS HERE .  I HAVE TRIED EVERY ROUTE ONE COULD POSSIBLY HAVE
TO HAVE FOLKS RUN WITH ADA SINCE 1979 WHEN I FIRST GOT INVOLVED. THE
MANDATES HAVE NOT WORKED FOR WEAPON SYSTEMS,C3I SYSTEMS OR OUR BUSINESS
SYSTEMS.  IT HAS ONLY WORKED WHERE I PERSONALLY DECIDED TO FORCE THE
ACTION SUCH AS WITH STANFINS-REDESIGN AND SIDPERS III AS FAR AS MAJOR
SYSTEMS I WAS ASSOCIATED WITH ARE CONCERNED.

I AM VERY SATISFIED AND COMFORTABLE WITH THE ELIMINATION OF THE MANDATE.
WE WILL CONTUNIE TO SUPPORT THE ADA EFFORT TO THE TUNE THAT THE NRC
RECOMMENDED OF APPROX $15MIL PER YEAR. THAT SHOULD BE EVIDENT THAT OUR
INTEREST STILL EXISTS IN ADA.

.......................................................................

> Actually, he cannot call his words back at this
> point; the writing is on the wall.  If you were the product manager for an
> ada compiler, wouldn't this stop you in your tracks, afraid to invest more
> money, until the smoke cleared?  The very fact that the future of the
> mandate is questioned in public and at that level of the DoD is the
> story.

This, of course, implies that DoD contractors choose Ada because it is
mandated. In fact, as Mr. Paige notes above, the mandate may in fact
have
worked _against_ adoption in some areas.

I am currently working on a DoD contract with no language requirement;
we still use Ada. I think if we and other DoD contractors stop using
Ada,
then Ada vendors should be concerned, but so long as there is a viable
customer base, I expect there will be an Ada vendor base to support it.

> If not today, what of tomorrow?  The mandate's days are numbered.
> Will it last long enough for a new investment to be recovered?  A
> gut-wrenching question.  Product mamgers get to bet their careers on such
> questions.

Product managers who cannot survive the removal of Government mandates
have
more problems than choosing languages, now that we are in the age of
acquisition reform. Their "gut-wrenching question" is to decide whether
they should be working at McDonalds or Burger King :)

> 
> Joe Gwinn

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: ada and robots

[Robert Dewar]

<<> > > I would also comment that DoD's recent recinding of the Ada Mandate will
> > > likely cause the Ada compiler and tools market to shrink to perhaps as
> > > little as one tenth of its prior size, and that significant added
> > > investment in Ada compilers and tools is therefore unlikely, at least
> > > until the size of the remaining market becomes clear.>>

I think this was Joe Gwinn's comment (it is consistent with his general
sentiments), but I am not sure.

In any case, we certainly do not see the change in the DoD view of Ada having
any significant negative impact on our business, and on the contrary, we 
regard it as overall positive, since it helps clear the air. Our customers,
both in the US and abroad are Ada enthusiasts for whom the mandate is
in any case irrelevant.

Robert Dewar
Ada Core Technologies

Re: ada and robots

[Joe Gwinn]

In article <33A56EBE.748C@lmco.com>, Ken Garlington
<Kennie.E.Garlington@lmco.com> wrote:

> > So he's flip-flopped?  I saw his previous missive, a week or two ago, and
> > it was quite clear.
> 
> These words [below]?

Yes, and the missive or missives that preceeded it.

> ........................................................................
> 
> From: "Paige, Emmett Jr., , OSD/C3I +" <paigee@osd.pentagon.mil>
> To: LTC Drew Hamilton <dj7560@eecs1.eecs.usma.edu>
> Subject: Re: FW: Reason for Mr. Paige's Decision Unclear
> Date: Mon, 10 Mar 1997 18:10:00 -0500
> 
> THANK GOD , THIS IS AMERICA.
> 
> THE BUCK STOPS HERE .  I HAVE TRIED EVERY ROUTE ONE COULD POSSIBLY HAVE
> TO HAVE FOLKS RUN WITH ADA SINCE 1979 WHEN I FIRST GOT INVOLVED. THE
> MANDATES HAVE NOT WORKED FOR WEAPON SYSTEMS,C3I SYSTEMS OR OUR BUSINESS
> SYSTEMS.  IT HAS ONLY WORKED WHERE I PERSONALLY DECIDED TO FORCE THE
> ACTION SUCH AS WITH STANFINS-REDESIGN AND SIDPERS III AS FAR AS MAJOR
> SYSTEMS I WAS ASSOCIATED WITH ARE CONCERNED.

Now it can be told.

 
> I AM VERY SATISFIED AND COMFORTABLE WITH THE ELIMINATION OF THE MANDATE.
> WE WILL CONTUNIE TO SUPPORT THE ADA EFFORT TO THE TUNE THAT THE NRC
> RECOMMENDED OF APPROX $15MIL PER YEAR. THAT SHOULD BE EVIDENT THAT OUR
> INTEREST STILL EXISTS IN ADA.

As it should be.


> > Actually, he cannot call his words back at this
> > point; the writing is on the wall.  If you were the product manager for an
> > ada compiler, wouldn't this stop you in your tracks, afraid to invest more
> > money, until the smoke cleared?  The very fact that the future of the
> > mandate is questioned in public and at that level of the DoD is the
> > story.
> 
> This, of course, implies that DoD contractors choose Ada because it is
> mandated. In fact, as Mr. Paige notes above, the mandate may in fact
> have worked _against_ adoption in some areas.

I believe that his suspicion is likely correct.  I certainly saw that in
action.  

The limitations of early Ada compilers certainly didn't help, either.  Nor
did the approach of some in the Ada community, insisting that the problems
were really features.


> I am currently working on a DoD contract with no language requirement;
> we still use Ada. I think if we and other DoD contractors stop using
> Ada,
> then Ada vendors should be concerned, but so long as there is a viable
> customer base, I expect there will be an Ada vendor base to support it.

This is as it should have always been: no force-fits.  

The attractions of COTS software will nonetheless draw many DoD entities
to C/C++.  

In the aftermath of the AAS debacle, the FAA has turned against Ada, and
now gives us the choice of C or C++.


> > If not today, what of tomorrow?  The mandate's days are numbered.
> > Will it last long enough for a new investment to be recovered?  A
> > gut-wrenching question.  Product mamgers get to bet their careers on such
> > questions.
> 
> Product managers who cannot survive the removal of Government mandates
> have
> more problems than choosing languages, now that we are in the age of
> acquisition reform. Their "gut-wrenching question" is to decide whether
> they should be working at McDonalds or Burger King :)

Umm.  The survival question hinges upon their ability to make money on
added money invested in Ada tools of any and all kinds.  If their little
profit and loss center doesn't show a good return on investment, they will
soon be flipping burgers, which may cause them to have difficulty meeting
their mortgage.  Thus, they tend to be nervous sorts, skittish in
uncertain environments.  Removal of the mandate makes the environment much
less certain than before, so they tend to hold back.  It's that simple,
and has nothing to do with the merits of Ada.


Joe Gwinn

Re: ada and robots

[Mike Stark]

Joe Gwinn wrote:
<snip> 

> The attractions of COTS software will nonetheless draw many DoD entities
> to C/C++.

Which makes sense for the MIS applications -- I would be wary of
embedding COTS
inside a weapons system though.
> 
> In the aftermath of the AAS debacle, the FAA has turned against Ada, and
> now gives us the choice of C or C++.
> 
God save us all!  The AAS debacle was due to a lot of factors, IMO
primarily
requirements instability and failure to do any useful risk management. 
The 
FAA would do far better to procure and adapt ATC systems already in use
in
Europe or Canada (and readers of Dr. Feldman's periodic postings on
non-DoD
usage know what language _those_ are implemented in ;) than to start
over from
scratch in C or C++.  As a taxpayer, I am apalled by the waste of money
in
starting over.  As an airline passenger, I don't want the controller in
the
tower at Dulles to have his system crash while _my_ flight is in the
landing
pattern.  Just about every common OO language, and especially Ada and
Eiffel,
are more appropriate for safety critical systems!

-- 
--------------------------------------------------------------------------------
Michael Stark                                                  
NASA/GSFC                                           
Phone: (301) 286-5048                                   Code 551
Fax:    (301) 286-0245                                   Greenbelt, MD
20771
 e-mail: michael.e.stark@gsfc.nasa.gov
"I don't give them hell.  I tell the truth and they THINK it's hell!" 
Harry S. Truman
--------------------------------------------------------------------------------

Re: ada and robots

[Joe Gwinn]

In article <33B51B61.2E26@gsfc.nasa.gov>, Mike Stark
<michael.e.stark@gsfc.nasa.gov> wrote:

> Joe Gwinn wrote:
> <snip> 
> 
> > The attractions of COTS software will nonetheless draw many DoD entities
> > to C/C++.
> 
> Which makes sense for the MIS applications -- I would be wary of
> embedding COTS inside a weapons system though.

Well, don't look now, because that's exactly what's happened.  And, by the
way, C is far ahead of Ada in the Air Traffic field, with or without the
FAA.


> > In the aftermath of the AAS debacle, the FAA has turned against Ada, and
> > now gives us the choice of C or C++.
> > 
> God save us all!  The AAS debacle was due to a lot of factors, IMO
> primarily
> requirements instability and failure to do any useful risk management. 
> The 
> FAA would do far better to procure and adapt ATC systems already in use
> in
> Europe or Canada (and readers of Dr. Feldman's periodic postings on
> non-DoD
> usage know what language _those_ are implemented in ;) than to start
> over from
> scratch in C or C++.  As a taxpayer, I am apalled by the waste of money
> in
> starting over.  As an airline passenger, I don't want the controller in
> the
> tower at Dulles to have his system crash while _my_ flight is in the
> landing
> pattern.  Just about every common OO language, and especially Ada and
> Eiffel,
> are more appropriate for safety critical systems!

I generally agree.  I didn't claim that Ada was the reason that AAS
crashed.  I doubt that any language, however perfect, could have saved
AAS.  It's a long and ugly story.   But, fair or not, the FAA has in fact
turned away from Ada.


Joe Gwinn

Re: ada and robots

[Jon S Anthony]

> memory correctly.  Ada95 is claimed to be better, but I don't have
> any direct experience with it.

Significantly better.  Quite different.


> Actually, not many people do just yet.

Au contrair - many are using it.

Get it _free_ if you like (binaries for most everything) at

ftp://cs.nyu.edu/pub/gnat/

> I suspect that most people are using C (perhaps called from Ada) for
> direct control of I/O hardware and the like.

Well, that's also quite possible as Ada95 provides out of the box
standard built in connection to C (and Fortran).

> Not all Ada compilers offer adequate support for such mixed-language

All Ada95 compilers do.

> VxWorks system, let alone execute the code and debug.  Insisting on a true
> and accurate demo saved our butts.)

Sound enough advice.  You can check this for yourself with Ada95 via
the free (industrial strength, I might add) compilers mentioned above.


> likely cause the Ada compiler and tools market to shrink to perhaps as
> little as one tenth of its prior size, and that significant added
> investment in Ada compilers and tools is therefore unlikely, at least

Nothing like good ol' FUD.  These 1/10's and 1/100's are just pulled
from where the sun doesn't shine.  Where are the studies?  Quote them
please.


> until the size of the remaining market becomes clear.  A significant
> shrink is widely expected

By who (or is that "whom"?)?  In any event, the opposite has seemed to
have been happening.  This is largely the result of free and cheap
compilers with full typical Windoze IDEs - check Aonix for example:
http://www.thomsoft.com/Products/Ada/ada.html

Also, only in the land of software would anyone actually suggest that
one should not use a better tool, technique, process, whatever to
build your product, because most of your _competition_ is using the
inferior tool, technique, process, whatever.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ada and robots

[Joe Gwinn]

In article <JSA.97Jun4200305@alexandria.organon.com>,
jsa@alexandria.organon.com (Jon S Anthony) wrote:

> > Not all Ada compilers offer adequate support for such mixed-language
> 
> All Ada95 compilers do.

That has not been our experience, especially when debugging of tasks
containing procedures in different languages.  The common (and inadequate)
solution is two independent and isolated debugging systems, one per
language, with no way to follow the thread of execution whereever it may
go.  We can use such a system, but why would we?  Getting systems to work
is hard enough as it is.


> > likely cause the Ada compiler and tools market to shrink to perhaps as
> > little as one tenth of its prior size, and that significant added
> > investment in Ada compilers and tools is therefore unlikely, at least
> 
> Nothing like good ol' FUD.  These 1/10's and 1/100's are just pulled
> from where the sun doesn't shine.  Where are the studies?  Quote them
> please.

Been reading them for years.  Some came from the Ada Joint Program
Office.  Don't have the references right at hand.  Do you have any studies
that say that Ada exceeds C?  I hope not.  They cannot be right.  The
difference isn't 10%, it's at least 10:1.  If if were the case that the
markets of C and Ada were in rough parity, we wouldn't get laughed at when
we ask various COTS vendors if they have an Ada interface to their
product.

Go into any technical bookstore and measure the relative shelf space
devoted to the various languages.  That's as good a metric as any, and
easy.  The stores know what does and does not sell, and the stores don't
care what the books are about, so long as people buy them.


> > until the size of the remaining market becomes clear.  A significant
> > shrink is widely expected
> 
> By who (or is that "whom"?)?  In any event, the opposite has seemed to
> have been happening.  This is largely the result of free and cheap
> compilers with full typical Windoze IDEs - check Aonix for example:
> http://www.thomsoft.com/Products/Ada/ada.html

People I have talked to.  Haven't seen anything published just yet, but
the mandate issue just came up.  I don't really believe that the market
share of Ada has been growing realtive to C/C++.  Do you?  


> Also, only in the land of software would anyone actually suggest that
> one should not use a better tool, technique, process, whatever to
> build your product, because most of your _competition_ is using the
> inferior tool, technique, process, whatever.

Ah, it depends on your definition of "better".  The basic issue in how
good the tools are for a language is simply the size of that language's
market.  The technical details of the language are basically irrelevant,
and the best language doesn't necessarily win.


Joe Gwinn

Re: ada and robots

[Robert Dewar]

Joe said

<<That has not been our experience, especially when debugging of tasks
containing procedures in different languages.  The common (and inadequate)
solution is two independent and isolated debugging systems, one per
language, with no way to follow the thread of execution whereever it may
go.  We can use such a system, but why would we?  Getting systems to work
is hard enough as it is.>>

Note that you were responding *specifically* to a point about Ada 95. Since
you are certainly not as far as I know a customer of ACT, you must be using
other Ada 95 compilers (and more than one) to make such a judgment about
the common solution (which certainly is not true of GNAT, and not true
of at least some other Ada 95 compilers with which I am familiar).

Can you please be more specific, or are you speaking from general (incorrect)
hearsay without any real experience -- I guess the latter. 

As for the tools market, what makes you think the Ada and C tools markets
are disjoint. Many tools that work for C work just fine for Ada (in an open
systems context such as the approach GNAT uses, it would be surprising if it
were otherwise). For example, it is perfectly possible to use a CM tool like
Clearcase with GNAT. Yes, it is nice if a little bit of tailoring of these
tools can be done. For example, Purify works pretty well with GNAT, and a
fair number of our customers have used it successfully. However, it would
work better if a little bit of specialization work were done. The Ada market
may not be able to support the investmeent necessary for duplicating the
production of tools like this, but it can and will support the investment
for their specialization where this is worth while.

Another example, GDB is a pretty competent multi-target multi-language
debugger. Even in its completely Ada-unknowledgable form, it is usable
with Ada 95 (usable enough that most of the developers on the GNAT project
have never used anything else -- this is largely because of its very
effective ability to call user level functions, so that debugging functions
can be placed in the image). GDB is a large and complicated program, with a
lot of complex target dependent stuff (e.g. it needs to know about stack
formats). We certainly do not have the resources to duplicate this work.
But we *do* have the resources to specialize GDB so that it knows more
about Ada. The current Ada mode is a first step in that direction, but a
lot more is coming in this direction.

Similarly, a lot of work has been done on visual interfaces for GDB (there
are several, including DDD, GDBTK, PMGDB, and a new one that we are creating
from scratch). We could not afford to duplicate this entire collection, but
it is highly desirable to have a choice, since personal tastes vary a lot
in this area. We can afford to do a little Ada specialization (and it is
interesting to note for example that the folks taking care of DDD, though
certainly not Ada mainstream people, have on their own steam made some
nice modifications to DDD to better accomodate Ada).

Yes, Ada is a much smaller market than C++, so it is not worth while for
tool makers to spend huge amounts of effort rebuilding their tools from
scratch for Ada. It is however by no means a zero size market, so a number
of tool makers are quite interested in capturing this incremental market
if it means doing relatively small amounts of incremental work on their
existing tools.

This is what makes it practical for Ada 95 to develop and maintain a strong
set of tools, even if and though Ada 95 remains a small market compared to
C++ or Java or whatever language-du-jour is.

Robert Dewar
Ada Core Technologies.

Re: ada and robots

[Robert Dewar]

Joe said

<<In practice, C was much more successful than Ada83 at riding metal. 
Experience with Ada83 shows that it is very bad at direct control of
hardware, especially I/O hardware, and simply does not handle shared
memory correctly.>>

Please explain this claim. Please post sample code that you think is
defined in C and handles shared memory correctly ...

Re: ada and robots

[Joe Gwinn]

In article <dewar.865941342@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe said
> 
> <<In practice, C was much more successful than Ada83 at riding metal. 
> Experience with Ada83 shows that it is very bad at direct control of
> hardware, especially I/O hardware, and simply does not handle shared
> memory correctly.>>
> 
> Please explain this claim. Please post sample code that you think is
> defined in C and handles shared memory correctly ...

There is tons of such code available for free on the internet.  Just look
for I/O drivers, such as for UNIX and VxWorks. VxWorks Board Support
Packages are another example.  

Even C-coded I/O drivers and kernel initialization sequences resort to
some assembly code.  

As for shared memory, look into the handling of driver comm pools, queues
shared between tasks and also with ISRs.  And so on.

For UNIX drivers, there are multiple books available on exactly how to
write such drivers, all in C.  Most include (annotated) sample driver
code.  

I would submit that there is ample evidence that C can be used for direct
hardware control, and for shared memory.  

I would not claim that all who have tried such things have succeeded,
regardless of language.  Many programmers couldn't write an I/O driver if
their life depended on it.


Joe Gwinn

Re: ada and robots

[Robert Dewar]

I asked Joe for specific code, and he responded:

<<There is tons of such code available for free on the internet.  Just look
for I/O drivers, such as for UNIX and VxWorks. VxWorks Board Support
Packages are another example.  
 
Even C-coded I/O drivers and kernel initialization sequences resort to
some assembly code.  
 
As for shared memory, look into the handling of driver comm pools, queues
shared between tasks and also with ISRs.  And so on.
 >>

Sorry that is not what I asked for. I asked for specific code. If you are
just repeating what others have told you, fine, such second hand information
is often ill-informed and inaccurate. But if on the other hand, you have a
real technical point to make, please illustrate it with very specific code.

(P.S. I have written lots of device drivers, and I cannot think of anything
I have ever done that could not be done in Ada), but if you think you have
such an example, let's see it!

Re: ada and robots

[George Haddad]

Robert Dewar wrote:
> (P.S. I have written lots of device drivers, and I cannot think of anything
> I have ever done that could not be done in Ada), but if you think you have
> such an example, let's see it!

   I have the greatest respect for you, Prof. Dewar, and read avidly
most of your posts here in comp.lang.ada.  That having been said, it
would seem that, in the above paragraph, you are giving us only vague
(though undoubtedly well-informed and accurate :-)) assurances of the
sort you would scorn to receive in such a discussion.  Which device
drivers _did_ you write in Ada?  :-)
-- 
*****************************************************************
I found these opinions on my doorstep, would you please give them a good
home?

Re: ada and robots

[Matthew S. Whiting]

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


Robert Dewar wrote:
> 
> I asked Joe for specific code, and he responded:
> 
> <<There is tons of such code available for free on the internet.  Just look
> for I/O drivers, such as for UNIX and VxWorks. VxWorks Board Support
> Packages are another example.
> 
> Even C-coded I/O drivers and kernel initialization sequences resort to
> some assembly code.
> 
> As for shared memory, look into the handling of driver comm pools, queues
> shared between tasks and also with ISRs.  And so on.
>  >>
> 
> Sorry that is not what I asked for. I asked for specific code. If you are
> just repeating what others have told you, fine, such second hand information
> is often ill-informed and inaccurate. But if on the other hand, you have a
> real technical point to make, please illustrate it with very specific code.
> 
> (P.S. I have written lots of device drivers, and I cannot think of anything
> I have ever done that could not be done in Ada), but if you think you have
> such an example, let's see it!

Robert,

I'm not Joe, but I've been having a similar line of, shall we say,
"discussion" with a colleague where I work.  Here's his reply when I
asked for specific issues that C or C++ could easily handle that were
difficult or impossible to handle in Ada.  I'm not an Ada expert so I'm
not qualifed to respond to his list point-by-point, and you may not wish
to take the time, but here at least are some specific points rather than
vague generalities.  As background, the author of the note below is
currently quite proficient in C and C++ and formerly programmed in Ada
(Ada83) for a defense industry contractor.  He's taken a cursory look at
Ada95, but remains convinced that Ada is inferior to C++ (and probably
even C) for the kinds of systems we develop (industrial process, machine
and motion control systems primarily).

I've tried to sanitize the message below to eliminate the name of my
company and the author.  Hopefully, I succeeded (Netscape has no "find"
function when doing a newsgroup reply ... sigh).

Matt

>Matt,
>
>OK � I am glad you are not a Macintosh advocate too. I guess this Ada debate
>is too much like debating PC vs. Macintosh (or I guess this is how I associate
>the Ada camp trying to get acceptance). The debate is very similar. Ha ha �
>
>I remember the discussion with [another colleague] and my comments about Ada. I
>remember stating that Ada was by no means a good language of choice for doing
>low-level complex programming, but you could use Ada (as well as many other
>languages that are also non-efficient). I said, "Ada is not as effective or
>efficient as C/C++ in writing device drivers (low-level programming)�", which
>I do not think any programmer could argue due to many factors:
>
>*      Ada's strong typing does not allow very complex structures to be
>manipulated and/or used efficiently due to its typing scheme (which in turn
>causes a programmer to code many more lines of code, or to structure a
>particular data set in a ineffective manner, or not at all). 
>*      Ada does not support discriminant unions (which are extremely useful,
>almost required). In fact, discriminant union support is required within the
>data structures that are used within the [one of our systems] data architecture; >and in fact,
>are very critical for supporting applications that need to support many data
>types within a limited memory area. Ada does have some hacks to get around
>some of these issues (using the USE AT construct) but still can not get
>around certain design issues. For example, if a designer wanted to build a
>data area that would store strings, booleans, ints, longs, float, and doubles
>all under one type called MyType (which was defined as a structure that
>contained a type discriminant, and a union to hold the desired value) and
>then pass an array of these elements (with mixed types) to a routine for
>processing� A Ada programmer might as well forget it�  Also, I believe this
>is an issue when declaring an object array with Ada95 where all elements must
>be of the defined type; yet using the C++ array template, one may store
>objects of different types into the same array.
>*      Ada does not support conforment arrays. You can not pass an array with 5
>elements to a routine one time and then pass an array of 10 elements the next
>because of the typing. This is an extremely critical aspect that is extremely
>difficult to get around within Ada compared with C/C++ or Pascal. Moreover,
>this functionality is almost required when processing communications packets
>that may be variable-sized.
>*      Ada does not support variable length parameter lists. This is a very tacky
>aspect of the language, which in turn, causes many more lines of code to be
>generated to support some functionality that requires different data inputs.
>This limitation can greatly effect a programs function (overload) count due
>to this limitation. For example, lets look at the following simple
>non-critical I/O code:
>
>C Code: 
>
>printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
>nForce- %f\n", roll, torque, velocity, force);
>
>Ada Code:
>
>Ada.Text_IO.New_Line(2);
>Ada.Text_IO.Put("The roller outputs for Roll[");
>Ada.Int_IO.Put(roll);
>Ada.Text_IO.Put("] are:");
>Ada.Text_IO.New_Line;
>Ada.Text_IO.Put("Torque-");
>Ada.Real_IO.Put(torque);
>Ada.Text_IO.New_Line;
>Ada.Text_IO.Put("Velocity-");
>Ada.Real_IO.Put(velocity);
>Ada.Text_IO.New_Line;
>Ada.Text_IO.Put("Force-");
>Ada.Real_IO.Put(force);
>Ada.Text_IO.New_Line;
>
>I don't think a lot of debug text I/O to a VT320 screen included in a system
>for debug would be very nice � And this is a simple example of why variable
>length parameter lists are so very important. Just think if you had a
>Parser() routine that could parse a variable length input list of 20
>parameters �, you sure would have a lot of Ada routines for each list item to
>write and maintain.
>
>*      DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a superset of CORBA
>IDL and offers many complex data types that are essential for low-level,
>high-performance system applications that are not supported in Ada, Java, �
>This lack or inability of the language to handle complex data structures can
>again increase the lines of coding.
>*      Interface Packages - Another extremely dangerous issue with Ada is the fact
>that under certain OS's we may be required to write the interface bindings to
>vendor routines, and these may not be commercially available. And looking at
>our current IO vendors, they appear to be supplying C/C++ libraries, which
>almost guarantees that we will need C bindings to what OS we're using.
>VxWorks may have bindings, but what about pSOS, and other potential OS's. I
>do not see to many IO vendors supplying Ada routines for the hardware�
>
>
>Here are just a few items that truly make Ada very ineffective and
>inefficient to program in � And many of them focus around the inability of
>the language to support complex (but required) data structures and types, as
>well as, the intolerable type scheme. The fact the Ada has the following
>semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
>Unchecked_Deallocation; one might ask why Ada needs such dangerous elements
>within the language unless they are required so that the language can perform
>certain tasks (which require them). Once elements such as these are used (and
>they must in many low-level systems programs), the touted type-safe, robust
>Ada system is no longer� but now in the same field as many other languages.
>
>
>There truly are many more serious negatives with Ada programming versus
>C/C++. I, as well as many others, realize that one must design and program a
>system correctly (with proper CM and SQA) but feel that C++ by far gives a
>programmer much more programming efficiencies than Ada; and in the long run a
>better performing and reliable system.
>
>I think I could go on and on about many different areas that would be
>negatives for [our company] (regarding resourcing, software development, vendor
>support, tool & analysis support, �) but I don't want to keep re-living these
>facts. I feel that C++ and C are buy far the best solution for [our company]. We
>are currently using C/C++, many vendors that we have are using C++ (and do
>not support Ada), DSP development has now moved to C, etc., along with the
>items I placed in my decision analysis.
>
>Hopefully I have given you enough reasons why Ada is not any programmers
>choice for low-level systems programming. If not, we should try writing a
>device driver for a simple timer card for NT. I think it would become
>extremely clear at that point.

Re: ada and robots

[Stephen Leake]

Matthew S. Whiting wrote:
 ( second hand list of supposed Ada deficiencies )

> >*      Ada's strong typing does not allow very complex structures to b=
e
> >manipulated and/or used efficiently due to its typing scheme (which in=
 turn
> >causes a programmer to code many more lines of code, or to structure a=

> >particular data set in a ineffective manner, or not at all).

This is not specific enough; for a counter argument, see the Ada Booch
components, at: http://www.rivatech.com:80/booch/

> >*      Ada does not support discriminant unions (which are extremely u=
seful,
> >almost required). In fact, discriminant union support is required with=
in the
> >data structures that are used within the [one of our systems] data arc=
hitecture; >and in fact,
> >are very critical for supporting applications that need to support man=
y data
> >types within a limited memory area. Ada does have some hacks to get ar=
ound
> >some of these issues (using the USE AT construct) but still can not ge=
t
> >around certain design issues. For example, if a designer wanted to bui=
ld a
> >data area that would store strings, booleans, ints, longs, float, and =
doubles
> >all under one type called MyType (which was defined as a structure tha=
t
> >contained a type discriminant, and a union to hold the desired value) =
and
> >then pass an array of these elements (with mixed types) to a routine f=
or
> >processing=85 A Ada programmer might as well forget it=85  Also, I bel=
ieve this
> >is an issue when declaring an object array with Ada95 where all elemen=
ts must
> >be of the defined type; yet using the C++ array template, one may stor=
e
> >objects of different types into the same array.

This is precisely the Ada discriminant record:

type Label_Type is (String, Boolean, Int, Float);

type MyType (Label : Label_Type :=3D String) is record
   case Label is
   when String =3D>
      String_Value : String (1 .. 80);
   when Boolean =3D>
      Boolean_Value : Boolean;
   when Int =3D>
      Int_Value : Integer;
   when Float =3D>
      Float_Value : Float;
   end case;
end record;

These can be stored in an array.
      =

> >*      Ada does not support conforment arrays. You can not pass an arr=
ay with 5
> >elements to a routine one time and then pass an array of 10 elements t=
he next
> >because of the typing. This is an extremely critical aspect that is ex=
tremely
> >difficult to get around within Ada compared with C/C++ or Pascal. More=
over,
> >this functionality is almost required when processing communications p=
ackets
> >that may be variable-sized.

Wrong again; this is precisely what a String is! The Ada terminology is
"unconstrained arrays".

type String is array (POSITIVE range <>) of character;

procedure Put (Item : in String);

> >*      Ada does not support variable length parameter lists. This is a=
 very tacky
> >aspect of the language, which in turn, causes many more lines of code =
to be
> >generated to support some functionality that requires different data i=
nputs.
> >This limitation can greatly effect a programs function (overload) coun=
t due
> >to this limitation. =


This is true. The reason is type safety and run-time simplicity. When
porting GCC to a new processor, one of my biggest problems was getting
variable arguments working; I'm still finding bugs related to this! But
even given a correct implementation, variable argument lists are just
not type safe. Ada provides alternatives that are safe (see MyType
above).

> >*      DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a super=
set of CORBA
> >IDL and offers many complex data types that are essential for low-leve=
l,
> >high-performance system applications that are not supported in Ada, Ja=
va, =85
> >This lack or inability of the language to handle complex data structur=
es can
> >again increase the lines of coding.

What are the specific types that DCOM requires that (supposedly) cannot
be defined in Ada? This is arguing from ignorance.

> >*      Interface Packages - Another extremely dangerous issue with Ada=
 is the fact
> >that under certain OS's we may be required to write the interface bind=
ings to
> >vendor routines, and these may not be commercially available. And look=
ing at
> >our current IO vendors, they appear to be supplying C/C++ libraries, w=
hich
> >almost guarantees that we will need C bindings to what OS we're using.=

> >VxWorks may have bindings, but what about pSOS, and other potential OS=
's. I
> >do not see to many IO vendors supplying Ada routines for the hardware=85=


This is not an argument against the language itself, but it is relevant.
Currently, there are more bindings available for C; projects that use
Ada will have to write bindings themselves. This will change as Ada
becomes more popular.

A side benefit of writing your own bindings is that you become more
aware of the details of the system you are binding to; this is sometimes
a good thing.

> >
> >
> >Here are just a few items that truly make Ada very ineffective and
> >inefficient to program in =85 And many of them focus around the inabil=
ity of
> >the language to support complex (but required) data structures and typ=
es, as
> >well as, the intolerable type scheme. =


Ada supports all the complex data structures and types that C does;
please give real examples! The fact that one programmer finds the strong
typing "intolerable" does not mean it is not up to the job.

> >The fact the Ada has the following
> >semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
> >Unchecked_Deallocation; one might ask why Ada needs such dangerous ele=
ments
> >within the language unless they are required so that the language can =
perform
> >certain tasks (which require them). Once elements such as these are us=
ed (and
> >they must in many low-level systems programs), the touted type-safe, r=
obust
> >Ada system is no longer=85 but now in the same field as many other lan=
guages.

Yes, Ada has dangerous features; so does C, C++, and any other
real-world language. The point is that proper system design isolates use
of these dangerous features to small sections of code, and hides them
behind well-defined abstractions. Then the full strong typing of Ada
protects the rest of the system. C and C++ cannot do this.

To paraphrase Robert Dewar, the moral of this story is "don't presume to
critique a language you have not used extensively". In this case, the
critiquer appears to not have used Ada at all!
-- =

- Stephe

Re: ada and robots

[Robert A Duff]

In article <33A69E46.3230@gsfc.nasa.gov>,
Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:
>This is true. The reason is type safety and run-time simplicity. When
>porting GCC to a new processor, one of my biggest problems was getting
>variable arguments working; I'm still finding bugs related to this! But
>even given a correct implementation, variable argument lists are just
>not type safe. Ada provides alternatives that are safe (see MyType
>above).

Variable-length argument lists are not *inherently* un-type-safe.  They
are so in C.  But I can imagine a language in which they are type safe.

Ada doesn't have them because it would complicate the language.

- Bob

Re: ada and robots

[jim granville]

---- Ada & Robots ---
As this thread has diverged to become a language/religion discussion,
I thought some real code, from real applications, might help.

This code is not Ada, but Modula-2 / IEC1131, which are Ada 'subsets'.
( ie are much closer to Ada in style, syntax, and approach, than to C )

For ROBOT applications, Ada is too large to fit in small controllers,
but
Modula-2 has all the TYPE and SCOPE benefits of Ada, and it actually
fits _very well_ on the C51 core - we have REAL CONTROL apps running in
89C1051's, with 1K of FLASH ROM.

Unlike C, M2 has true BOOLEAN types, which overlay well on the C51
Boolean Engine.
A C51 core also struggles to efficently support C's wide use of
pointers.
( commonly seen in C's are 3 byte, run time interpreted, SLOW pointers..
)

All of the below can be coded in M2, C, and Assembler for that matter.
It can just be done quicker, with fewer errors, in Modula-2.
( a good example of a user supplied C error, is below )

Conclusion : Choose the highest level language that will do the job.
It may be Ada, BASIC, C, Clarion, Delphi, Forth, Modula-2, Visual
BASIC...
( or sometimes, even Assembler )

This code fragment in Modula2, is from a MM53200 'Garage Door' style
decoder, coded for a 89C2051.
Total code size, for a self testing receiver, is 227 bytes.

This code uses the BITSET feature of Modula-2, to greate a PACKED
BOOLEAN
ARRAY of 24 Data bits, into 3 BYTES.
   CASE BitTimeL OF
   | OneMIN..OneMAX :
     INCL(RxCODE[RxCtr >> 3],RxCtr);
   | ZeroMIN..ZeroMAX :   (* default is a Zero *)
   ELSE                   (* bad value, so reset *)
    TF0 := TRUE;          (* catch Reset, next pass  *)
    RxCtr := 0;
   END;
   INC(RxCtr);

This code illustrates two methods of loading, one 'collects' BOOLEANs
and
is highly readable, the other uses BINARY format.
 IE := {EA,ET0,ES};
 IE := 2#1001_0010;     (* EA.EC.ET2.ES.ET1.EX1.ET0.EX0 *)

This code is from a DUAL 6 BIT Picket fence D to A converter.
Total code, for Dual DAC is 95 bytes.
It allows appx 33KHz clock rates, and can run as a background DAC.
More, or less, BITS / Channels are easy to add / remove.
Such DACs are highly linear, use just 1 PIN per DAC, and are ideal for
integration to control voltage outputs.

 DACaPIN := DACa;
 DACbPIN := DACb;
 (* does ONE of these IF statements ONLY *)
 IF PWM.0 THEN          (* 32 Pickets, odd numbers *)
  DACa := DAC_A.5;      (* Uses BYTE BITADDRESSABLE syntax *)
  DACb := DAC_B.5;
 ELSIF PWM.1 THEN       (* 16 Pickets xxxx10 *)
  DACa := DAC_A.4;
  DACb := DAC_B.4;
 ELSIF PWM.2 THEN       (*  8 Pickets xxx100 *)
  DACa := DAC_A.3;
  DACb := DAC_B.3;
 .... etc....

This code flips the BIT order in a BYTE, for COMMS protocol usage.
TYPE hT = ARRAY [0..15] OF BYTE;
                   (*  0   1   2  3    4  5   6  7  8 9 A B   C  D  E  F
*)
CONST MirrorTable =
hT(0H,08H,04H,0CH,02H,0AH,6,0EH,1,9,5,0DH,3,0BH,7,0FH);

PROCEDURE MirrorF(Par : SHORTCARD REGISTER_2) : SHORTCARD; (* 16
bytes,14uS *)
BEGIN
   RETURN(ROTATE(MirrorTable[Par AND 0FH],4) OR MirrorTable[Par >> 4]);
END MirrorF;

And here is some C code, doing the same thing...
This compiles, runs, and works - to a point, It has a BUG that appears
ONLY SOMETIMES. Whilst the Modula-2 compiler would have caught this at
compile time, this C user may have to wait until the customer
calls : ' You know, sometimes.... '

const char Inv[] = {0x00,        //  0000 --> 0000
              0x08,        //  0001 --> 1000
              0x04,        //  0010 --> 0100
              0x0c,        //  0011 --> 1100
              0x0a,        //  0101 --> 1010
              0x06,        //  0110 --> 0110
              0x0e,        //  0111 --> 1110
              0x01,        //  1000 --> 0001
              0x09,        //  1001 --> 1001
              0x05,        //  1010 --> 0101
              0x0d,        //  1011 --> 1101
              0x03,        //  1100 --> 0011
              0x0b,        //  1101 --> 1011
              0x07,        //  1110 --> 0111
              0x0f};       //  1111 --> 1111

char Invert(char cByte)
{
   return ((Inv[cByte & 0xf] << 4) | Inv[(cByte & 0xf0)>>4]);
}

- jim granville

-- 
======= Manufacturers of Serious Design Tools for uC and PLD  =========
= Optimising Modula-2 Structured Text compilers for ALL 80X51 variants
= Reusable object modules, for i2c, SPI and SPL bus interfaces
= Safe, Readable & Fast code - Step up from Assembler and C
= Emulators / Programmers for ATMEL 89C1051, 2051, 89C51 89S8252 89C55
= *NEW* Bondout ICE for 89C51/89C52/89C55 
= for more info, Email : DesignTools@xtra.co.nz  Subject : c51Tools

Re: ada and robots

[Robert Dewar]

Jim Granville posts a useful example in Modula. This will translate
very clearly and straightforwardly into Ada (I am sure someone here
will post the translation :-) so I am a little puzzled at Jim's claim
that Ada is somehow unsuitable for this task -- I guess it must just
come from knowing Modula better than Ada :-)\

Re(dux): Ada for small machines (was Re: ada and robots)

[Ken Garlington]

Robert Dewar wrote:
> 
> Jim Granville posts a useful example in Modula. This will translate
> very clearly and straightforwardly into Ada (I am sure someone here
> will post the translation :-) so I am a little puzzled at Jim's claim
> that Ada is somehow unsuitable for this task -- I guess it must just
> come from knowing Modula better than Ada :-)\

I believe Jim's problems stems from the inability to build, using Ada,
"REAL CONTROL apps running in 89C1051's, with 1K of FLASH ROM." This
is, of course, due to the lack of Ada compilers in this area, possibly
caused in part by the need to build a tasking RTE for this target, and
most definitely caused in part by the perception by Ada vendors that
no one would use Ada for such a target. (This perception did not stop
Jim's company from building a Modula compiler for this target, however).

It's nice to say that Ada could be used here, given a compiler, but in
the real world the lack of an Ada compiler for such targets (and the
lack of interest by any Ada vendors to support such targets) makes
Ada an impractical choice. 

(I left comp.robotics.misc on this thread, since this is the real
impediment
for using Ada in some robotics applications - no compiler is available
for
several popular micro-controllers.)

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Re(dux): Ada for small machines (was Re: ada and robots)

[Robert Dewar]

Ken said

<<I believe Jim's problems stems from the inability to build, using Ada,
"REAL CONTROL apps running in 89C1051's, with 1K of FLASH ROM." This
is, of course, due to the lack of Ada compilers in this area, possibly
caused in part by the need to build a tasking RTE for this target, and
most definitely caused in part by the perception by Ada vendors that
no one would use Ada for such a target. (This perception did not stop
Jim's company from building a Modula compiler for this target, however).
>>

The issue of building the tasking runtime is a minor one. The issue of
not believing that there would be a market is the real issue. Speaking
for us we build ports if any of the following is true

  a) it is clear that there is a wide demand for the port
       (demand = demand from paying customers)

  b) the port is funded (that is why there is an OS/2 port for example,
	the government funded this port)

  c) it is easy to build the port, and it seems useful enough to be worth
	the effort (the Linux port got built this way initially)

  d) some volunteer contributes the port (the DOS port got built this way)

None of these factors seems to be present for the 89C1051.

Sure, if there is no Ada compiler for a machine, the best technical advice
is not to consider writing in Ada. But what happens in this and many similar
threads is to make the jump from "there is no Ada compiler" to "It is 
impossible or difficult to build an Ada compiler" for a given target.

I am sure that Jim's company uses a similar list to the above, and I can
think of any number of reeasons why the calculation looks different for
him than it does to us.

Re: ada and robots

[Matthew Heaney]

In article <33AAC183.34C0@xtra.co.nz>, DesignTools@xtra.co.nz wrote:

I'm not a Modula programmer; perhaps you can walk me through some of your
code examples.

>This code uses the BITSET feature of Modula-2, to greate a PACKED
>BOOLEAN
>ARRAY of 24 Data bits, into 3 BYTES.

This can be done in Ada.

type Bit_Array is 
   array (Positive range 0 .. 23) of Boolean;

for Bit_Array'Size use 24;
for Bit_Array'Component_Size use 1;

or in this case you could just

pragma Pack (Bit_Array);

Ada guarantees that for an array for which the component size is 1 (and
type Boolean is guaranteed to be size 1), that array components are aligned
on contiguous bits.

>   CASE BitTimeL OF
>   | OneMIN..OneMAX :
>     INCL(RxCODE[RxCtr >> 3],RxCtr);
>   | ZeroMIN..ZeroMAX :   (* default is a Zero *)
>   ELSE                   (* bad value, so reset *)
>    TF0 := TRUE;          (* catch Reset, next pass  *)
>    RxCtr := 0;
>   END;
>   INC(RxCtr);

Can you explain what's going on here?

INCL means add an item to a set, right?   If so, you just set the
corresponding bit of the bit array to True.

Of course, we could declare a full-blown set abstract data type,
implemented as a bit array, but when you're twiddling bits anyway, one
doesn't usually bother.

>This code illustrates two methods of loading, one 'collects' BOOLEANs
>and
>is highly readable, the other uses BINARY format.
> IE := {EA,ET0,ES};
> IE := 2#1001_0010;     (* EA.EC.ET2.ES.ET1.EX1.ET0.EX0 *)

type Bit_Array_Range is (EA, EC, ET2, ES, ET1, EX1, ETO, EXO);
type Bit_Array is array (Bit_Array_Range) of Boolean;
pragma Pack (Bit_Array);

To do the first, you can use aggregate assignment:

IE : Bit_Array := (EA, ETO, ES => True, others => False);

To do the second, you have to use unchecked conversion:

function To_Bit_Array is
   new Unchecked_Conversion (
      Source => Interfaces.Unsigned_8, 
      Target => Bit_Array);

IE : Bit_Array := To_Bit_Array (2#1001_0010#);

Oh well, an extra line of code, to do the instantiation.

>This code is from a DUAL 6 BIT Picket fence D to A converter.
>Total code, for Dual DAC is 95 bytes.
>It allows appx 33KHz clock rates, and can run as a background DAC.
>More, or less, BITS / Channels are easy to add / remove.
>Such DACs are highly linear, use just 1 PIN per DAC, and are ideal for
>integration to control voltage outputs.

>  DACa := DAC_A.5;      (* Uses BYTE BITADDRESSABLE syntax *)

If you mean get at an individual bit, that can be done if the type is
already declared as a bit array, or else using unchecked_conversion to a
bit array.

   DAC_A (5)

or

  To_Bit_Array(DAC_A)(5)

You may need an extra pair of parens here; I don't have my Ada 95 compiler
handy.


>This code flips the BIT order in a BYTE, for COMMS protocol usage.
>TYPE hT = ARRAY [0..15] OF BYTE;
>                   (*  0   1   2  3    4  5   6  7  8 9 A B   C  D  E  F
>*)
>CONST MirrorTable =
>hT(0H,08H,04H,0CH,02H,0AH,6,0EH,1,9,5,0DH,3,0BH,7,0FH);
>
>PROCEDURE MirrorF(Par : SHORTCARD REGISTER_2) : SHORTCARD; (* 16
>bytes,14uS *)
>BEGIN
>   RETURN(ROTATE(MirrorTable[Par AND 0FH],4) OR MirrorTable[Par >> 4]);
>END MirrorF;

type hT is array (0 .. 15) of Unsigned_8;
 -- we may have to declare the array index subtype as a modular type
 -- ie type hT is array (Unsigned_8) of Unsigned_8;
 -- but I've never done that, and I don't have my compiler handy...

Mirror_Table : constant hT := 
 (16#0#, 16#8#, ...);

function Mirror_F (Par : Unsigned_8) return Unsigned_8 is
begin
   return Rotate_Right (Mirror_Table (Par and 16#0F#), 4) or
                 Mirror_Table (Shift_Right (Par, 4));
end;

or something like that. 

If my knowledge of Modula were better (I only have Wirth's book, which I
haven't even read), there might be a slicker Ada way to do this, instead of
as a straight translation.

The point is, however, that Ada is no less expressive than Modula with
respect to its low-level facilities.  Nor do I suppose its code generation
is any less efficient, if the types in package Interfaces are used.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: ada and robots

[Shmuel (Seymour J.) Metz]

Matthew Heaney wrote:
> 
> Of course, we could declare a full-blown set abstract data type,
> implemented as a bit array, 

A type providing sets of small integers is quite remote from "a 
full-blown set abstract data type"; the confusion can be traced to the
Pascal influence. If you want to see a language with "a full-blown set
abstract data type", look a SETL, whic I understand was the original 
implimentation language for GNAT.

> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> <mailto:matthew_heaney@acm.org>
> (818) 985-1271

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: ada and robots

[Robert Dewar]

<<

A type providing sets of small integers is quite remote from "a

full-blown set abstract data type"; the confusion can be traced to the

Pascal influence. If you want to see a language with "a full-blown set

abstract data type", look a SETL, whic I understand was the original

implimentation language for GNAT.>>


This is a miscconception, GNAT was always written
in Ada (first in Ada 83, later more and more Ada 95 features were used).

The confusion is with an earilr compioler  Ada/Ed, which was a quite separate effort.

Re: ada and robots

[Jon S Anthony]

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


In article <33A5D644.37A3@epix.net> "Matthew S. Whiting" <whiting@epix.net> writes:

<A request for some answers to a co-workers specific "reasons" for why
Ada is not "efficient">

> vague generalities.  As background, the author of the note below is
> currently quite proficient in C and C++ and formerly programmed in Ada
> (Ada83)

As indicated below, the last claim in this statement is very difficult
to believe.  Certainly the fellow does _not_ know even elementary
level Ada.


> >*      Ada does not support discriminant unions (which are extremely useful,
> >almost required). In fact, discriminant union support is required within the
> >data structures that are used within the [one of our systems] data architecture; >and in fact,

At first I thought he meant UNdiscriminated union - the sort of thing
you often see in C stuff (where there is no field in the struct
denoting at runtime which variant of the union is currently active).


> >some of these issues (using the USE AT construct) but still can not get
> >around certain design issues. For example, if a designer wanted to build a
> >data area that would store strings, booleans, ints, longs, float, and doubles
> >all under one type called MyType (which was defined as a structure that
> >contained a type discriminant, and a union to hold the desired value) and
> >then pass an array of these elements (with mixed types) to a routine for
> >processing� A Ada programmer might as well forget it

But then I read this and realized he really _did_ mean discriminated
union.  This is trivial in Ada (including Ada83) and I've done the
very thing he mentions many times.  Here's a canonical form:

    type My_Type ( Kind : Kind_Type ) is record
        case Kind is
    	    when Stg =>
    		S_Val : String_Ref;
    	    when Bool  =>
    		B_Val : Boolean;
    	    when Int   =>
    		I_Val : Integer;
    	    when Long  =>
    		L_Val : Long_Integer;
    	    when Flt   =>
    		F_Val : Float;
    	    when Dbl   =>
    		D_Val : Long_Float;
        end case;
    end record;

type My_Array_Type is array ( Natural range <> ) of My_Type;

...

function F ( X : My_Array_Type ) return ... is
...
    for I in X'range loop
        case X.Kind is
            when int => ...
        ...
end F;


So, at this point (as you can understand) this person's credibility is
closing in on zero.


> >be of the defined type; yet using the C++ array template, one may store
> >objects of different types into the same array.

This is just plain wrong - even for C++!!!  The only thing letting you
store different type objects into a C++ array is if the type is
somehow polymorphic (NOT the array, but its element type).

A template works (more or less) like a generic in Ada (where a generic
array type could be exported - but there is no good reason to do this
in Ada as it already directly supports arrays).

A typical array template in C++ gives you nothing more than what you
can get in Ada by merely writing:

(a)    type Some_Array_Type is array ( Natural range <> ) of Element_Type;

Then you can write:

    A : Some_Array_Type(0..Get_The_Desired_Size);

    B : Some_Array_Type := Some_Initial_Value;

etc.

So, there is the extra step of giving (a) for each element type - but
then you don't need to write or use a template - which your compiler
probably can't compile anyway and which you will almost certainly get
different results from different compilers (and your arrays will be
more efficient).

If you really want a single polymorphic array type, then make the
element type polymorphic:

    type Object_Type is tagged ...

    type Element_Type is access all Object'Class


> >* Ada does not support conforment arrays. You can not pass an array
> with 5 >elements to a routine one time and then pass an array of 10
> elements the next >because of the typing. This is an extremely
> critical aspect that is extremely >difficult to get around within
> Ada compared with C/C++ or Pascal.

This is outright embarrassing for this person.  This is exactly what
unconstrained arrays give you and you get much more expressivity with
them than with C or C++ or Pascal or many others.  Function F above
shows this very thing in action (this is all _very trivial_ and
elementary Ada forms - i.e., anyone will know this stuff after only a
brief aquaintence with the language).  A trivial example using
Some_Array_Type where Element_Type has an "+" operation defined and an
appropriate Identity_Element (for example, if Element_Type is Integer,
and "+" is regular addition, then Identity_Element is 0):

function Sum ( X : Some_Array_Type ) return Element_Type is
    S : Element_Type := Identity_Elememt;
begin
    for I in X'range loop
        S := S + X(I);  -- Dispatch to correct "+"
    end loop;
    return S;
end Sum;


...
    ... Sum((1, 2, 3, 4));  -- returns 10
    ... Sum(("a", "B", "C", "d"));  -- returns "aBCd"


> >* Ada does not support variable length parameter lists. This is a
> very tacky >aspect of the language, which in turn, causes many more
> lines of code to be >generated to support some functionality that
> requires different data inputs.

This is really silly.  Just use an array of discriminated types and
pass an explicit aggregate:

    -- Call F with varying number of arguments:
    --
    ... F(( (Int, 2), (Flt, Pi), (Stg, "Hi There") ));
    ... F(( (Bool, True), (Dbl, E) ));

You can also use default parameters for this sort of thing and use
named notation:

function X ( Amps : Current_Type := 0.0;  Voltage : Power_Type := ...);

   ... X(Voltage => My_Power);
   ... X(Amps => My_Current, Voltage => Some_Power);


> >printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
> >nForce- %f\n", roll, torque, velocity, force);
> >
> >Ada Code:

This is ridiculous.  "Everybody" knows a) you can make printf in Ada
via overloads of "+" on the data types or b) just write the thing
using the more direct equivalent:

Real Ada code (not strawman rubbish) (Lf is a 1 char string of Ascii.LF):

 Put( Lf & Lf &
     "The roller outputs for Roll(" & Integer'Image(Roll) & ") are:" & lf &
     "Torque-" & Float'Image(torque) & lf &
     "Velocity-" & Float'Image(velocity) & lf &
     "Force-" & Float'Image(force) & lf);

> >for debug would be very nice � And this is a simple example of
> why variable >length parameter lists are so very important. Just
> think if you had a

This is not an example of why variable length parameter lists are
important (I'm not convinced they even _are_ important).  This is just
a silly thing where you want to call an I/O function once.  Trivial
and BFD.


> >Parser() routine that could parse a variable length input list of
> 20 >parameters �, you sure would have a lot of Ada routines for
> each list item to >write and maintain.

No you wouldn't.  Well, if this fellow were hacking it up you might,
but that only shows his own incompetence - not a problem with Ada.


> >* DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a
> superset of CORBA >IDL

DCE IDL is not a superset of CORBA IDL.  It is a different thing
offering similar functionality.


> and offers many complex data types that are essential for low-level,
> >high-performance system applications that are not supported in Ada,
> Java, �

Like what?  Really - this guy does not know what he is talking about.


> >This lack or inability of the language to handle complex data
> structures can >again increase the lines of coding.

What complex data structures?  Discriminated unions?  They are trivial
and hardly "complex".


> >* Interface Packages - Another extremely dangerous issue with Ada
> is the fact >that under certain OS's we may be required to write the
> interface bindings to >vendor routines, and these may not be
> commercially available.

No, this too is wrong.  You can directly access the libraries just
like you would from C/C++.  NOTE: when I say "just like in C/C++"
here, I mean just that.  It will be no more safe or clear than what
you get in those languages.  But then, that is what you would have to
do if using C or C++.  So this is neither a disadvantage nor an
advantage.


> >almost guarantees that we will need C bindings to what OS we're using.

No - just grab the routines you want and use the same low level calls
as you would in C/C++.  The smart thing would be to put this rubbish
in a package body and export an OS _independent_ abstraction (for
which you could plug in various OS dependent bodies) - I've done this
and it's cake.


> >VxWorks may have bindings, but what about pSOS, and other potential OS's. I
> >do not see to many IO vendors supplying Ada routines for the hardware�

Same here.


> >Here are just a few items that truly make Ada very ineffective and
> >inefficient to program in �

Too bad for this person, they are _all_ in error.  In fact, it seems
clear he does not even understand C++ templates (well, to be fair,
probably nobody really does...)


> And many of them focus around the inability of >the language to
> support complex (but required) data structures and types, as

Like what - discriminated unions??  We've seen he is just plain wrong
about this.


> >well as, the intolerable type scheme. The fact the Ada has the
> following >semantics: USE AT, Unchecked_Conversion,
> Unchecked_Access, and >Unchecked_Deallocation; one might ask why Ada
> needs such dangerous elements >within the language unless they are
> required so that the language can perform >certain tasks (which
> require them).

They are there in order for you to break the type system **IF** you
determine this is really necessary.  And they are specifically ugly in
order to a) call your attention to the fact that something funny is
happening here and b) to in some measure prevent you from willy-nilly
sinking to such low level design at the drop of a hat.


> >There truly are many more serious negatives with Ada programming versus
> >C/C++.

Well - he hasn't managed to come up with even one yet.


> >I think I could go on and on about many different areas that would be

And I suppose this would be a littany of errors as well.


> >Hopefully I have given you enough reasons why Ada is not any programmers

Sorry - he hasn't haven't given _any_!!  In fact, he's given reasons
why using Ada would be a _good_ idea.  Every example this person gives
is _easier_ to do in Ada!!


> >device driver for a simple timer card for NT. I think it would become
> >extremely clear at that point.

Well, if this person is writing it, I would believe it would be
screwed up.  You need a competent Ada person, then it would be obvious
that this too would be a non-issue.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ada and robots

[Matthew S. Whiting]

I greatly appreciate Jon's rebuttal.  He was quite specific and included
only minimal name calling.  Likewise Robert Duff's comments were fairly
much to the point.  I'm not sure how to reconcile the disagreement
between Jon and Robert with respect to whether 1.5 of the points made
were legitimate or not, but this provides a good reason for me to study
Ada a little more to make my own judgement.  Robert Dewar's complaint of
lack of source code equating to lack of specificity is noted, but Jon
seemed to have enough detail to provide useful commentary.  And the note
did include SOME source code!  Samuel's sarcasm provides me nothing
useful in my ongoing effort to convince my colleague to give Ada a
deeper evaluation.  Lastly, Stephen's comments are helpful as well.  I
appreciate the time you all took to respond, especially those with
useful responses!  I'm not sure which is worse, the ignorance of many C
and C++ programmers or the arrogance of many Ada programmers...

Matt (a lowly engineering manager trying to get my engineers to use the
best available tools and techniques)

Re: ada and robots

[Robert A Duff]

In article <33A7427F.6646@epix.net>,
Matthew S. Whiting <whiting@epix.net> wrote:
>...  I'm not sure how to reconcile the disagreement
>between Jon and Robert with respect to whether 1.5 of the points made
>were legitimate or not, ...

Well, I guess I was being generous.  The ".5" was for "variable length
argument lists".  I was admitting that they can be a nice convenience.
However, I must say that I completely reject the idea that C in
particular is "better" in this regard, since it sacrifices type checking
for variable length argument lists.  And since you can conveniently
concatenate strings for output, the printf example is not compelling.
My position is: it would be nice (a little bit) to have var-length arg
lists, but only if the language did them in a type-safe way.

Anyway, I thought the issue was whether Ada can deal with low-level
programming such as in device drivers.  And the printf example, and
var-length arg lists, have nothing in particular to do with that.

The "1" was for "lack of bindings", and I still agree with your
colleague that this is a problem in choosing Ada.  On the other hand,
it's not *that* bad -- Ada 95 has quite nice facilities for interfacing
to C.

>... but this provides a good reason for me to study
>Ada a little more to make my own judgement.

Good idea.  I'd be interested in hearing what the outcome is --
e.g. whether or not your colleague ever changes his mind, or comes up
with a real example of device-driver-ish code that can't be written
easily in Ada.

- Bob

Re: ada and robots

[Jon S Anthony]

In article <33A7427F.6646@epix.net> "Matthew S. Whiting" <whiting@epix.net> writes:

> much to the point.  I'm not sure how to reconcile the disagreement
> between Jon and Robert with respect to whether 1.5 of the points made
> were legitimate or not, but this provides a good reason for me to study
> Ada a little more to make my own judgement.

Which of these are you thinking about?  The varying argument list?
Robert is correct - it is not _directly_ supported, but the effect can
be rather simply achieved.  This is something to really watch out for
and why the so called "Dewar Effect" of learning a language's idioms
can be important.  Just because X does not have Y's construct C for
doing Blah doesn't mean that the _effect_ of Blah given by C is not
directly expressible in X.  It typically only means it is expressed
differently.

In any case, your last point is exactly correct - make your own
_informed_ judgement.


> appreciate the time you all took to respond, especially those with
> useful responses!  I'm not sure which is worse, the ignorance of many C
> and C++ programmers or the arrogance of many Ada programmers...

Good question.  Arrogance is certainly more annoying while ignorance
is much more frustrating and difficult to work through.  Probably a
wash...


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: ada and robots

[John G. Volan]

Jon S Anthony wrote:
> 
> In article <33A7427F.6646@epix.net> "Matthew S. Whiting" <whiting@epix.net> writes:
> > I'm not sure which is worse, the ignorance of many C
> > and C++ programmers or the arrogance of many Ada programmers...
> 
> Good question.  Arrogance is certainly more annoying while ignorance
> is much more frustrating and difficult to work through.  Probably a
> wash...

Ignorance is far worse than arrogance.  According to the ancient Greeks,
arrogance (i.e., hubris) sooner or later destines you to a tragic
downfall (i.e., "tragic" in the classical sense of "due to a flaw in
your own character").  Whereas, "against ignorance, the gods themselves
contend in vain."

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Samuel Mize]

Matthew S. Whiting wrote:
> Samuel's sarcasm provides me nothing
...
> I'm not sure which is worse, the ignorance of many C
> and C++ programmers or the arrogance of many Ada programmers...

I'd vote for the arrogance of ignorant C/C++ programmers who
post abusive messages on comp.lang.ada.  Sorry if you took the
brunt of my annoyance with other people.

I hope the tone didn't keep you from reading the content.

The difference between Ada and C coding really is often a matter
of attitude: whether you are willing to take time up front to
design, or want to jump right in and code, then take the time
at the end to debug.

I suggest you look over the web sites at the end of the weekly
README: HOW TO GET HELP message.  (The rest of the message is
just netiquette for first-time posters.)

--
-- Samuel Mize    (817) 619-8622    smize@link.com    "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: ada and robots

[Matthew S. Whiting]

Samuel Mize wrote:
> 
> Matthew S. Whiting wrote:
> > Samuel's sarcasm provides me nothing
> ...
> > I'm not sure which is worse, the ignorance of many C
> > and C++ programmers or the arrogance of many Ada programmers...
> 
> I'd vote for the arrogance of ignorant C/C++ programmers who
> post abusive messages on comp.lang.ada.  Sorry if you took the
> brunt of my annoyance with other people.

I've got skin thicker than most alligators.  :-)
 
> I hope the tone didn't keep you from reading the content.

It did not.  And I did check the new "Ada Can do It!" section at AdaHome
dealing with Ada myths.
 
> The difference between Ada and C coding really is often a matter
> of attitude: whether you are willing to take time up front to
> design, or want to jump right in and code, then take the time
> at the end to debug.

I agree.  Unfortunately, changing the attitudes of people that work for
or with you is typically non-trivial.

Matt

Re: ada and robots

[Samuel Mize]

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


Note that I make some comments about the person Mr. Whiting quoted,
but none about Mr. Whiting.  Some quotations reformatted for length.

Stephen Leake wrote:
> 
> Matthew S. Whiting wrote:
>  ( second hand list of supposed Ada deficiencies )
...
> > >*      Ada does not support discriminant unions (which are
...
> This is precisely the Ada discriminant record:

Ah, but you can't hand-code the discriminant values.  This makes it
harder to interface to existing C code, which of course makes C
fundamentally better.

Besides, you can't load the variable with one type and then read it
as another type.  In C it's simple and safe, while in Ada it requires
Unchecked_Conversion, which everyone knows is dangerous.


> > >Also, I believe this
> > >is an issue when declaring an object array with Ada95 where all
> > >elements must be of the defined type; yet using the C++ array
> > >template, one may store objects of different types into the same
> > >array.

Is this template something that couldn't be done with a generic,
or a tagged type?  Or is the complainer just ignorant?


> > >*      Ada does not support variable length parameter lists. This
> > >is a very tacky aspect of the language, which in turn, causes
> > >many more lines of code to be generated to support some
> > >functionality that requires different data inputs.  This
> > >limitation can greatly effect a programs function (overload)
> > >count due to this limitation.
> 
> This is true. The reason is type safety and run-time simplicity. When
> porting GCC to a new processor, one of my biggest problems was getting
> variable arguments working; I'm still finding bugs related to this!
> But even given a correct implementation, variable argument lists are
> just not type safe. Ada provides alternatives that are safe (see
> MyType above).

At the slightest error, a procedure with a variable-length parameter
list will read undefined values off the end of the stack.  What
happens if you make this call in C:
   printf ("%s%s%d%e");

For safer ways to get variable-length lists of parameters, see the "Ada
Can Do It" writeup at www.adahome.com.


> > >*      Interface Packages - Another extremely dangerous issue with
> > >Ada is the fact that under certain OS's we may be required to
> > >write the interface bindings to vendor routines, and these may
> > >not be commercially available.

Why is this dangerous?  Can't they afford a week's worth of effort to
write a thin partial binding?  Or is he just too stupid to write one?


> A side benefit of writing your own bindings is that you become more
> aware of the details of the system you are binding to; this is
> sometimes a good thing.

Plus you can write the interface layer to provide the abstractions you
need in your programs.  Plus, when you port to another OS, you have
isolated all the system dependencies -- unless you're talking about
system functions that have ISO standard bindings, this is likely to
cost you some effort if you are using vendor-supplied bindings.


> > >USE AT, Unchecked_Conversion, Unchecked_Access, and
> > >Unchecked_Deallocation; one might ask why Ada needs such dangerous
> > >elements within the language unless they are required so that the
> > >language can perform certain tasks (which require them).

Duh.  I don't leave my power tools plugged in and laying around the
workshop, let alone keep them with me wherever I go.

> > >... Once elements such as these are used (and
> > >they must in many low-level systems programs), the touted
> > > type-safe, robust Ada system is no longer� but now in the same
> > >field as many other languages.

In the limited and well-identified areas where unchecked programming
is being done, yes.  In those parts of your code -- typically less
than 5% if you design carefully -- you have to be as paranoid, and do
as much scut-level debugging, as a C programmer.

In the rest of your code, the compiler is helping you avoid fencepost
errors, rogue pointers, accidental misuse of data, and so on.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
But the real core of the complainant's thought process is clear: he
says that Ada isn't a "programmer's language," and often refers to
the (to him) serious problem of writing more code to do something.

What he means is that it isn't a hacking language.

He's right.  It isn't a language for hackers.  It's a language
for software designers -- people who want automated help designing
and building a program that works right EVERY time, reliably, for
a long time, that you can modify and port to new systems.

It IS hard to just sit down and bang out code in Ada.  You have to
pick a coherent design, lay out specs that express that design, and
code to your design.  If you're going to use things in a different
way than you specified -- for instance, view an integer as an array
of bytes -- you have to tell the compiler what you're doing.

Those "extra" lines of code tell the compiler what you're thinking,
and how you mean things to work.  Then the compiler can check you
and spot your mistakes.  Some people don't like this approach.
They say with great vigor that a good programmer should be allowed
to do anything by the compiler, trusting to his skill and care to
get things right.  They are deeply certain that they need no help
managing the complexity of their own code.  They are usually quite
skilled at debugging.

Many Ada programmers have only rudimentary debugging skills, even
after years of building successful programs.  Think about it.

Samuel Mize

--
-- Samuel Mize    (817) 619-8622    smize@link.com    "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: ada and robots

[Steve O'Neill]

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


Samuel Mize wrote:
> Besides, you can't load the variable with one type and then read it
> as another type.  In C it's simple and safe, while in Ada it requires
> Unchecked_Conversion, which everyone knows is dangerous.

It's simple in C but not necessarily safe.  

and Mr. Whiting said
>>>>USE AT, Unchecked_Conversion, Unchecked_Access, and
>>>>Unchecked_Deallocation; one might ask why Ada needs such dangerous
>>>>elements within the language unless they are required so that the
>>>>language can perform certain tasks (which require them).

I am constantly flabbergasted by the argument that Unchecked_Conversion
and its close cousins are dangerous while uncontrolled and un-obvious
use of typecasting and address manipulation in C are acceptable.  Let's
face it folks, when you're playing around at this level it's all
inherently dangerous.  But there are times when this level of control is
necessary.  The point that I like about Ada is that it makes you
recognize that you are in dangerous territory while C hands you the rope
with which to hang yourself.  In my endeavours I try to layer
applications such that the application has some insulation from the
metal.  Ada lets me do this quite well, thank you.

>>>>... Once elements such as these are used (and
>>>>they must in many low-level systems programs), the touted
>>>> type-safe, robust Ada system is no longer� but now in the same
>>>>field as many other languages.

Maybe so, but at least I can more easily identify those areas of
"thin-ice".
 
-- 
Steve O'Neill                    Sr. Software Engineer
Sanders                          Nashua, New Hampshire
(603) 885-9765 (voice)           (603) 885-2483 (fax)

Re: ada and robots

[Anonymous]

<338CDA96.53EA@halcyon.com> <338F5D7D.6C03@tiac.net>
<338F9D05.5EB3@bix.com> <5mqpj3$bc5$1@goanna.cs.rmit.edu.au>
<33930245.12A1@sprintmail.com> <5mv984$7kn@news.emi.com>
<gwinn-0306971836410001@smc19.ed.ray.com> <dewar.865941342@merv>
<gwinn-1006971907100001@dh5055139.res.ray.com> <dewar.866044546@merv>
<33A5D644.37A3@epix.net> <33A6D407.53416C1E@link.com>

On Wed, 18 Jun 1997 10:14:06 -0400, Steve O'Neill
<"x0955$"@sanders.lockheed.com> wrote:

> Samuel Mize wrote:
> > Besides, you can't load the variable with one type and then read it
> > as another type.  In C it's simple and safe, while in Ada it requires
> > Unchecked_Conversion, which everyone knows is dangerous.
> 
> It's simple in C but not necessarily safe.  
> 
> and Mr. Whiting said
> >>>>USE AT, Unchecked_Conversion, Unchecked_Access, and
> >>>>Unchecked_Deallocation; one might ask why Ada needs such dangerous
> >>>>elements within the language unless they are required so that the
> >>>>language can perform certain tasks (which require them).
> 
> I am constantly flabbergasted by the argument that Unchecked_Conversion
> and its close cousins are dangerous while uncontrolled and un-obvious
> use of typecasting and address manipulation in C are acceptable.
..

I agree with your point, but I interpreted Mize's comment as sarcasm
agreeing with you too.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: ada and robots

[Kenneth W. Sodemann]

On Tue, 17 Jun 1997 13:14:31 -0500, Samuel Mize <smize@link.com>
wrote:

>Note that I make some comments about the person Mr. Whiting quoted,
>but none about Mr. Whiting.  Some quotations reformatted for length.
>
>Stephen Leake wrote:
>> 
>> Matthew S. Whiting wrote:
>>  ( second hand list of supposed Ada deficiencies )
>...
>> > >*      Ada does not support discriminant unions (which are
>...
>> This is precisely the Ada discriminant record:
>
>Ah, but you can't hand-code the discriminant values.  This makes it
>harder to interface to existing C code, which of course makes C
>fundamentally better.
>
>Besides, you can't load the variable with one type and then read it
>as another type.  In C it's simple and safe, while in Ada it requires
>Unchecked_Conversion, which everyone knows is dangerous.
>

You are being sarcastic here, right?  

If not, I will have to say I disagree.  Unions in C are far from
"safe", and Unchecked_Conversion is certainly not more dangerous than
unions.

[snip]

--
Kenneth W. Sodemann
kwsodema@avistainc.com
http://www.avistainc.com

Re: ada and robots

[Stephen Leake]

Samuel Mize wrote:
> 
> Note that I make some comments about the person Mr. Whiting quoted,
> but none about Mr. Whiting.  Some quotations reformatted for length.
> 
> Stephen Leake wrote:
> >
> > Matthew S. Whiting wrote:
> >  ( second hand list of supposed Ada deficiencies )
> ...
> > > >*      Ada does not support discriminant unions (which are
> ...
> > This is precisely the Ada discriminant record:
> 
> Ah, but you can't hand-code the discriminant values.  This makes it
> harder to interface to existing C code, which of course makes C
> fundamentally better.
> 
Um, yes you can; that's what an enumeration representation clause is
for; see RM13.4

> Besides, you can't load the variable with one type and then read it
> as another type.  In C it's simple and safe, while in Ada it requires
> Unchecked_Conversion, which everyone knows is dangerous.

Um, this just means Ada _labels_ unchecked conversion as dangerous. In C
it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?)

> -- Samuel Mize    (817) 619-8622    smize@link.com    "Team Ada"
> -- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

-- 
- Stephe

Re: ada and robots

[Robert Dewar]

<<> Besides, you can't load the variable with one type and then read it
> as another type.  In C it's simple and safe, while in Ada it requires
> Unchecked_Conversion, which everyone knows is dangerous.
 
Um, this just means Ada _labels_ unchecked conversion as dangerous. In C
it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?)>>



Maybe he did not think it needed a smiley :-)

The essence of sarcasm as a form is that you say something ludicrous in
a serious manner, to display just how ludicrous it is (a good example,
Jonathan Swift's "A Modest Proposal").

But it is certainly *amazing* how many people did not automatically
read the sarcasm into this statement.

On the other hand, given some of the posts here, may be it is not so
amazing after all :-) :-)
\

Re: ada and robots

[Robert Dewar]

Matthew Whiting's anonymous friend once again posts a whole bunch of reasons
why Ada cannot be used to do marvellous things. Of course a lot of these
points are just technically misinformed (the nonsense about conformant
arrays stands out particularly, but also the business about printf seems
a bit pathetic too).

But what is really annoying is that once again, we have vague uninformed
statements, which we could correct, but that is not what we asked for,
we asked for a piece of representative code.

The really convincing argument that these "let-me-alone-and-write-in-C"
[reminds me of Hacker's Senior's lyrics in The Maiden and the Mandate, but
that was in fun :-)] could provide is

   *CODE*

that we could look at, and agree, yes, hmmm! indeed that would be tough to
do in Ada, we see what you mean.

But none of these guys seem willing to actually provide such!

Re: ada and robots

[Robert A Duff]

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


In article <33A5D644.37A3@epix.net>,
Matthew S. Whiting <whiting@epix.net> wrote:
>Robert Dewar wrote:
>> 
>> I asked Joe for specific code, ...

>I'm not Joe, but I've been having a similar line of, shall we say,
>"discussion" with a colleague where I work.  Here's his reply when I
>asked for specific issues that C or C++ could easily handle that were
>difficult or impossible to handle in Ada.  

Still not specific.  Robert asked for specific C code, and we still
haven't seen any.  Your colleague gives us (1) vague generalities, and
(2) misinformation.

>>*      Ada's strong typing does not allow very complex structures to be
>>manipulated and/or used efficiently due to its typing scheme (which in turn
>>causes a programmer to code many more lines of code, or to structure a
>>particular data set in a ineffective manner, or not at all). 

This is an example of (1).  You should insist that your colleague show
the C code for at least one such example.  Only *then* can we argue
about whether Ada can't do it, or can't do it well.  From the above, I
have no idea what he's talking about.

>>*      Ada does not support discriminant unions (which are extremely useful,
>>almost required). In fact, discriminant union support is required within the
>>data structures that are used within the [one of our systems] data architecture; >and in fact,
>>are very critical for supporting applications that need to support many data
>>types within a limited memory area. Ada does have some hacks to get around
>>some of these issues (using the USE AT construct) but still can not get
>>around certain design issues. For example, if a designer wanted to build a
>>data area that would store strings, booleans, ints, longs, float, and doubles
>>all under one type called MyType (which was defined as a structure that
>>contained a type discriminant, and a union to hold the desired value) and
>>then pass an array of these elements (with mixed types) to a routine for
>>processing� A Ada programmer might as well forget it�  Also, I believe this
>>is an issue when declaring an object array with Ada95 where all elements must
>>be of the defined type; yet using the C++ array template, one may store
>>objects of different types into the same array.

Ada *does* have discriminated unions, and can do the above (passing
array, blah blah blah).  The only problem I can see here is that Ada
insists that the discriminant be part of the object, whereas some
hardware-defined data structures encode the "discriminant" in weird
ways.

>>*      Ada does not support conforment arrays. You can not pass an array with 5
>>elements to a routine one time and then pass an array of 10 elements the next
>>because of the typing. ...

This is so vastly wrong (for both Ada 83 and Ada 95) that I have a hard
time believing that your colleague ever wrote an Ada program.  I mean,
the simplest "Hello, world" program in Ada uses this feature -- how
could he have missed it?

>>*      Ada does not support variable length parameter lists.

Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
with why C is better or worse at accessing low-level hardware
functionality.  It was left out of Ada to simplify the language.

>... This is a very tacky
>>aspect of the language, which in turn, causes many more lines of code to be
>>generated to support some functionality that requires different data inputs.
>>This limitation can greatly effect a programs function (overload) count due
>>to this limitation. For example, lets look at the following simple
>>non-critical I/O code:
>>
>>C Code: 
>>
>>printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
>>nForce- %f\n", roll, torque, velocity, force);
>>
>>Ada Code:
>>
>>Ada.Text_IO.New_Line(2);
>>Ada.Text_IO.Put("The roller outputs for Roll[");
>>Ada.Int_IO.Put(roll);
>>Ada.Text_IO.Put("] are:");
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Torque-");
>>Ada.Real_IO.Put(torque);
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Velocity-");
>>Ada.Real_IO.Put(velocity);
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Force-");
>>Ada.Real_IO.Put(force);
>>Ada.Text_IO.New_Line;

In Ada, I would write something like this:

    use Ada.Text_IO;
    ...
    New_Line(2);
    Put_Line(" The roller outputs for Roll[" & Image(Roll)
             & "] are:");
    Put_Line(" Torque-" & Image(Torque));
    Put_Line(" Velocity-" & Image(Velocity));
    Put_Line(" Force-" & Image(Force));

Given suitable Image functions (which I always define), or else use the
standard 'Image attribute.  We can argue about whether this is better or
worse than the corresponding C code, but it's nowhere near as bad as
the Ada code your colleague wrote.  I claim my Ada code is far better
than the C code, since it does type checking.

>>I don't think a lot of debug text I/O to a VT320 screen included in a system
>>for debug would be very nice � And this is a simple example of why variable
>>length parameter lists are so very important. Just think if you had a
>>Parser() routine that could parse a variable length input list of 20
>>parameters �, you sure would have a lot of Ada routines for each list item to
>>write and maintain.

I agree that variable-length parameter lists are a nice convenience.
However, your colleague is wrong: in Ada, you would *not* have 20
overloadings here -- you would have a procedure that takes a single
parameter of some sort of array or sequence type.

>>*      DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a superset of CORBA
>>IDL and offers many complex data types that are essential for low-level,
>>high-performance system applications that are not supported in Ada, Java, �
>>This lack or inability of the language to handle complex data structures can
>>again increase the lines of coding.

I don't know DCE IDL enough to comment.

>>*      Interface Packages - Another extremely dangerous issue with Ada is the fact
>>that under certain OS's we may be required to write the interface bindings to
>>vendor routines, and these may not be commercially available.

Granted.  This is a problem with using Ada.

>>Here are just a few items that truly make Ada very ineffective and
>>inefficient to program in � And many of them focus around the inability of
>>the language to support complex (but required) data structures and types, as
>>well as, the intolerable type scheme. The fact the Ada has the following
>>semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
>>Unchecked_Deallocation; one might ask why Ada needs such dangerous elements
>>within the language unless they are required so that the language can perform
>>certain tasks (which require them). Once elements such as these are used (and
>>they must in many low-level systems programs), the touted type-safe, robust
>>Ada system is no longer� but now in the same field as many other languages.

This is a bogus argument.  Just because one part of a program uses a
low-level features like Unch_Conv, doesn't mean that *all* of the
benefits of Ada are lost to the *entire* program.

>>There truly are many more serious negatives with Ada programming versus
>>C/C++.

I count one and a half in the above.  So lets see the "many more".

Again, let's see the C.  Real code.  Ask your colleague to show us some
C code (for a device driver, or part of one, for example), and let's see
whether Ada is up to the job.  I will freely admit that Ada has many
flaws, but the above series of incorrect claims about Ada doesn't help.

- Bob

Re: ada and robots

[Ken Garlington]

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


Robert A Duff wrote:
> 
> >>*      Ada does not support variable length parameter lists.
> 
> Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
> with why C is better or worse at accessing low-level hardware
> functionality.  It was left out of Ada to simplify the language.

Well, in fact it does (from the client perspective) because of
overloading.
DEC Ada uses this extensively in their libraries. Yes, it requires more
lines of code when writing the object, but no additional lines of code
to call it. Therefore, it's just as convienient... unless you're just
hacking
some code together, of course.

> >>*      Interface Packages - Another extremely dangerous issue with Ada is the fact
> >>that under certain OS's we may be required to write the interface bindings to
> >>vendor routines, and these may not be commercially available.
> 
> Granted.  This is a problem with using Ada.

However, it's not an "extremely dangerous" issue, particularly given
automated C-to-Ada
conversion. It may be a productivity issue, at best.

> 
> >>Here are just a few items that truly make Ada very ineffective and
> >>inefficient to program in � And many of them focus around the inability of
> >>the language to support complex (but required) data structures and types, as
> >>well as, the intolerable type scheme. The fact the Ada has the following
> >>semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
> >>Unchecked_Deallocation; one might ask why Ada needs such dangerous elements
> >>within the language unless they are required so that the language can perform
> >>certain tasks (which require them). Once elements such as these are used (and
> >>they must in many low-level systems programs), the touted type-safe, robust
> >>Ada system is no longer� but now in the same field as many other languages.
> 
> This is a bogus argument.  Just because one part of a program uses a
> low-level features like Unch_Conv, doesn't mean that *all* of the
> benefits of Ada are lost to the *entire* program.

Presumably, any "C" routine that calls assembly code loses all of the
benefits of
a higher-order language, by the same reasoning.

> Again, let's see the C.  Real code.  Ask your colleague to show us some
> C code (for a device driver, or part of one, for example), and let's see
> whether Ada is up to the job.  I will freely admit that Ada has many
> flaws, but the above series of incorrect claims about Ada doesn't help.

Let's do the opposite: Write an assembly program that can't be coded in
C (or other high-order language), and use that to show that we must all
code in assembly. How about: Do a ones-and-zeros ripple test
of all of memory, including the stack and heap.

> 
> - Bob

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: ada and robots

[Shmuel (Seymour J.) Metz]

Ken Garlington wrote:
> 
> > Again, let's see the C.  Real code.  Ask your colleague to show us some
> > C code (for a device driver, or part of one, for example), and let's see
> > whether Ada is up to the job.  I will freely admit that Ada has many
> > flaws, but the above series of incorrect claims about Ada doesn't help.
> 
> Let's do the opposite: Write an assembly program that can't be coded in
> C (or other high-order language), and use that to show that we must all
> code in assembly. How about: Do a ones-and-zeros ripple test
> of all of memory, including the stack and heap.

As a sidelight, I was once tasked with improving the performance of a
service routine written in Intel assembly language; my replacement
version was in Ada and was dramatically faster. This doesn't prove that
Ada is more efficient than assembly language, but rather that there is a
lot more to efficiency than just the choice of language.

> --
> LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
> Who uses Ada? See http://www.lmasc.lmco.com/f22
> For job listings, other info: http://www.lmtas.com or
> http://www.lmco.com

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: ada and robots

[Robert Dewar]

Bob Duff wrote

(regarding variable length parameter lists in Ada, lack thereof)

<<Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
with why C is better or worse at accessing low-level hardware
functionality.  It was left out of Ada to simplify the language.
 

I disagree, there are two issues here. Variable length lists of homogenous
types (which can include of course collectoins of pointers to different
subtype instances of a class) can perfectly well be passed. For example,
a routine called put_lines that outputs a series of lines can be called

put_lines (("line1", "line2", "line3"));

This kind of "implicit rowing" first appeared in Algol68, and is a very
convenient way of dealing with variable length parameter lists.

However, what the C folks might want is the completely general capability
for variable length lists of arbitrary heterogenous types. This is possible
in C, but is seriously type unsafe. Furthermore, there is no obvious way it
can be made type safe. Hence this feature definitely should be rejected, as
should any programmer who feels they cannot program without it.

To be fair, it is possible to get something like this by means of an implicit
uniting coercion, but it is really very little trouble to introduce this
explicitly.

So for example, suppose you want a routine that takes an arbitrary list
of integers and floats (could obviously be extended), then you could make
a routine in Ada that looked like

  printf ("the value of x is % and the value of y is %",
            (I(integer expr), F(float expr)));

which seems close enough to the C notation if this is really what you want.

Re: ada and robots

[Adam Beneschan]

bobduff@world.std.com (Robert A Duff) writes:

 >>>*      Ada does not support variable length parameter lists.
 >
 >Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
 >with why C is better or worse at accessing low-level hardware
 >functionality.  It was left out of Ada to simplify the language.

I haven't been following this thread, so my apologies if I post
something that duplicates something someone else has written.

I don't miss having variable length parameter lists, because there are
a couple easy ways to accomplish practically the same thing.  One
technique is to declare a routine something like this:

    function Build_String (Input1, Input2, Input3, Input4, 
                           Input5, Input6, Input7, Input8 : String := "")
                return String;

Now, I have a way to make variable-length parameter calls, up to eight
parameters:

    Text_IO.Put_Line (Build_String ("a", "b"));
    Text_IO.Put_Line (Build_String ("a", "b", "c", "d", "e"));

etc.  (Of course, this type of solution assumes that you'll never
legitimately want to use "" as a parameter.)

Another solution, which works better if the parameter types are
scalars, is to use an array as a parameter.  I've written code like
this: 

    type Option_Type is (Allow_Hex, Allow_Underscore,
                         No_Decimal_Point, ...)
    type Option_Array is array (natural range <>) of Option_Type;
    procedure Parse_String (Source  : in string;
                            Options : in Option_Array;
                            etc.)

and now I can call

    Parse_String (S, (Allow_Underscore, No_Decimal_Point));
    Parse_String (S, (Allow_Underscore, No_Decimal_Point, Allow_Hex));

putting as many options as I like in the array parameter.  (C doesn't
allow you to create an in-line array like this to pass to a function,
or even to assign to an array variable.  In fact, I'm surprised the
anti-Ada poster gave us something like

 >>>C Code: 
 >>>
 >>>printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
 >>>nForce- %f\n", roll, torque, velocity, force);
 >>>
 >>>Ada Code:
 >>>
 >>>Ada.Text_IO.New_Line(2);
 >>>Ada.Text_IO.Put("The roller outputs for Roll[");
 >>>Ada.Int_IO.Put(roll);
 >>>Ada.Text_IO.Put("] are:");
 >>>Ada.Text_IO.New_Line;
 >>>Ada.Text_IO.Put("Torque-");
 >>>Ada.Real_IO.Put(torque);
 >>>Ada.Text_IO.New_Line;
 >>>Ada.Text_IO.Put("Velocity-");
 >>>Ada.Real_IO.Put(velocity);
 >>>Ada.Text_IO.New_Line;
 >>>Ada.Text_IO.Put("Force-");
 >>>Ada.Real_IO.Put(force);
 >>>Ada.Text_IO.New_Line;
  
when it's so easy to answer:

C code:

   array_variable[0] = 7;
   array_variable[1] = x + 1;
   array_variable[2] = x + 2;
   array_variable[3] = (x - y) % 5;
   array_variable[4] = -3;

Ada code: 

   Array_Variable := (7, X + 1, X + 2, (X - Y) mod 5, -3);

)

I've even used this technique to write an Ada 83 version of printf().
Of course, you can't declare an array whose elements aren't the same
type, but all you have to do is declare a variant record type that
could hold any type you would want to output:

    type String_P is access string;
    type Data_Type is (V_Integer, V_Float, V_String);
    type Heterogeneous_Data (DType : Data_Type) is record
        case Dtype is
            when V_Integer =>   Int_Data    : Integer;
            when V_Float   =>   Float_Data  : Float;
            when V_String  =>   String_Data : String_P;
        end case;
    end record;

Now, declare an overloaded function that converts any data type to
Heterogeneous_Data.  Some people like overloading unary "+" for this.
Declare an array of Heterogeneous_Data, and use it as the parameter to
your Printf.  This does take some code to set up, but once it is, you
can use it easily:

    Printf ("\n\n The roller outputs for Roll[%d] are:" & 
                "\n Torque-%f\nVelocity-%f\nForce- %f\n",
            (+Roll, +Torque, +Velocity, +Force));

and voila, a Printf that's actually capable of checking the types,
something that C's printf() doesn't do well.  (The object-oriented
features of both Ada 95 and C++ provide ways to handle heterogeneous
data like that more cleanly.)  I used to use a Printf routine like
this, until I found that writing code like Bob's:

 >In Ada, I would write something like this:
 >
 >    use Ada.Text_IO;
 >    ...
 >    New_Line(2);
 >    Put_Line(" The roller outputs for Roll[" & Image(Roll)
 >             & "] are:");
 >    Put_Line(" Torque-" & Image(Torque));
 >    Put_Line(" Velocity-" & Image(Velocity));
 >    Put_Line(" Force-" & Image(Force));

was easier to read and maintain, in my opinion.  This is an option we
Ada programmers have, since we have a string concatenation operator.

Just my contribution to the holy wars . . .

                                -- Adam

Re: ada and robots

[Martin A. Stembel]

Jesse Johnson wrote:
> 
> I came into this thread late, so I'm sorry if this has already been
> said.  Ada was designed by the DOD as a systems programming language
> for embedded systems in military vehicles, while C was designed as an
> application programming language to be run on top of systems.  This

I always thought K&R came up with C for systems programming...Unix comes
to mind...

> makes Ada inherently better suited for robot programming.  However,

Well now, that all depends on the characteristics of OS/Kernel on which
your run-time was implemented.  Ada on SCO Unix would definately not be
inherently better suited for closing a position loop than another
language running on OS-9 or LynxOS.  All other things being equal, I'ld
probably choose Ada because I have more experience with it.  Generally
though, I've found that a good programmer can write quality code in any
language, and the bad ones will muck things up no matter how much the
language tries to hold their hand.

> for someone like me who has done a number of years of application
> programming and is now trying robotics, it's easier to use C because I
> already know it.
> 
>                         Jesse Johnson
>                         jejo@empireone.net

Re: ada and robots

[RC]

In <33930245.12A1@sprintmail.com> by "John G. Volan"
<johnvolan@sprintmail.com>
>Dale Stanbrough wrote:
>> 
>> John Cook writes:
>> 
>> "small systems a student can afford"
>>         The Meridian Ada compiler, which comes for free with a book, is rather
>>         cheap, and targets any of the 8086 family (which are cheap, no?).
>>         It is Ada83 however. So I think you agree with you.
>
>Come now, don't tell me you haven't heard of GNAT?  It runs on pretty
>near everything (UNIX, DOS, Wintel, even Mac).  And you can download it
>for free.  (Well, on a Mac you have to spend $99 to get Machten, a port
>of BSD Unix that runs as a Mac app, but then you get GNAT for free. And
>it does let you write standalone Mac apps in Ada.)

Isn't this written in C?  Seems a bit defeatist.

RC1

Re: ada and robots

[Larry Kilgallen]

In article <ytxyoLAxaYlzUw5R@clanchy.demon.co.uk>, RC <rc1@clanchy.demon.co.uk> writes:
> In <33930245.12A1@sprintmail.com> by "John G. Volan"
> <johnvolan@sprintmail.com>

>>Come now, don't tell me you haven't heard of GNAT?  It runs on pretty
>>near everything (UNIX, DOS, Wintel, even Mac).  And you can download it
>>for free.  (Well, on a Mac you have to spend $99 to get Machten, a port
>>of BSD Unix that runs as a Mac app, but then you get GNAT for free. And
>>it does let you write standalone Mac apps in Ada.)
> 
> Isn't this written in C?  Seems a bit defeatist.

1. Not exactly.

2. To insist that all products one uses be written a particular
   language narrows the field considerably.  When choosing a
   compiler I would be guided by past experience of others more
   that the theoretical probability of a certain number of defects.
   For choosing an airplane run by computer my emphasis would change.

Larry Kilgallen

Re: ada and robots

[John G. Volan]

RC wrote:
> 
> In <33930245.12A1@sprintmail.com> by "John G. Volan"
> <johnvolan@sprintmail.com>
> >Come now, don't tell me you haven't heard of GNAT? [snip]
> 
> Isn't this written in C?  Seems a bit defeatist.

Before you go perpetuating myths, get your facts straight. GNAT is
written in Ada95, and compiles itself.  It is one of several language
front-end modules (including C, C++, Modula3, and Fortran) that are
plugged into GCC's multi-language optimizing back-end code-generation
system, which was indeed written in C.  Sounds to me like an excellent
example of mixed-language programming and reuse.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Jon S Anthony]

In article <ytxyoLAxaYlzUw5R@clanchy.demon.co.uk> RC <rc1@clanchy.demon.co.uk> writes:

> >Come now, don't tell me you haven't heard of GNAT?  It runs on pretty
> >near everything (UNIX, DOS, Wintel, even Mac).  And you can download it
> >for free.  (Well, on a Mac you have to spend $99 to get Machten, a port
> >of BSD Unix that runs as a Mac app, but then you get GNAT for free. And
> >it does let you write standalone Mac apps in Ada.)
> 
> Isn't this written in C?  Seems a bit defeatist.

No.  Isn't spouting off without checking any facts, irresponsible
behavior?

> RC1

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ada and robots

[Nick Roberts]

Tom Moran <tmoran@bix.com> wrote in article <338F9D05.5EB3@bix.com>...
> > K&R wanted a portable
> > assembly language with a rich set of operators  and minimal constraints
> > so they invented C
>   How many people still use K&R C?  Would you call C++ a portable
> assembly language?


I think I'd go further and suggest that a higher level language than Ada
might be more suitable to your purpose (depending on what you are really
trying to do). Are you familiar with Prolog or Lisp? There are many
different robotics-specific languages, also. You may even find that using a
programming language of any kind is not what you require (perhaps an
adaptive learning system implemented at hardware level would work better).
What are you trying to achieve, ultimately?

Nick.

Re: ada and robots

[Jan Galkowski]

Nick Roberts wrote:
> 
[snip]

> 
> I think I'd go further and suggest that a higher level language than Ada
> might be more suitable to your purpose (depending on what you are really
> trying to do). Are you familiar with Prolog or Lisp? There are many
> different robotics-specific languages, also. You may even find that using a
> programming language of any kind is not what you require (perhaps an
> adaptive learning system implemented at hardware level would work better).

I agree with Nick.  Although lowest level control of motors
and sensors might well be done with C++, as well as calculations
which just have to be fast, things like motion planning, force
feedback, assembly planning, interpretation of touch fields are
all things that cry for higher order implementation.  

A characteristic of assembly control is that one needs to consider
that every action one tries may fail, and plan a backup route for
it.  Thus, if this were done in Ada, you'd put a failure handler
with a different body about each and every motion statement.
This is verbose. 

I've never used it for robot programming, even in a pretending
way, but I've often thought Icon, with its builtin treatment of
failures, might be a good thing to use.

> What are you trying to achieve, ultimately?

Yes, definitely: "Robot programming" isn't a monolithic application.
There are the hobbyists robots, there are the relatively 
unintelligent repetition-based robots for which no programming
language is suitable (programmed by motion macros), and then
there are sophisticated systems which try mechanical assemblies.

>

[snip]
-- 
 Jan Theodore Galkowski, 
 developer, statistician,
   Digicomp Research Corporation,
   Ithaca, NY 14850-5720
 jan@digicomp.com 
 (also jtgalkowski@worldnet.att.net)

Re: ada and robots

[Albert K. Lee]

So does anybody have any answers for the original poster?  That guy
who was asking quite innocently about specific techniques and tools
for embedded programming using the Ada language?

I am interested as well and would rather see answers than read thru
incessant language wars.


-Albert

Re: ada and robots

[dana]

In article <slrn5pch85.avm.aklee@bonsai.net>, aklee@no_spam.bonsai.net
(Albert K. Lee) wrote:

> So does anybody have any answers for the original poster?  That guy
> who was asking quite innocently about specific techniques and tools
> for embedded programming using the Ada language?
> 
> I am interested as well and would rather see answers than read thru
> incessant language wars.
> 
> 
> -Albert

I think the general lack of response back to the group could be taken as
response in the negative.  I e-mail the original poster with a more
detailed response but I'll post a summary here for all you curious folks. 


I assume the original question was REALY about looking for compilers for
the calss of low cost 8 -16 bit processors typically used in hobbyist type
robots.  ("Hobbyist", not to demean these robots, just classify them) 
That question raises several other on obvious questions.  

1)    Q:  are there any Ada compilers for 8051s, PIC-1X's, 6502, 80C196KB,
etc micro controllers?

      A:  No, or at least not many.  It's hard to put an exact reason as
to why but it is thought that these MCs are just "too small" in terms of
address space etc to support a multitasking language/runtime.  Hello world
generated by DDCI's sun cross 80386EX compiler is JUST under 16k with the
non-tasking runtime.  I've seen similar performance from other Ada
compilers.  The whole answer is much longer but has been discussed at
length in this group.  Now, that being said, it is still worth a check of
adahome to see what the vendors have.  I could be wrong.  It wouldn't be
the first time:-)


2)    Q:  Is Ada used in robotics?  This is a question several occasional
posters to this group could have answered.  But the answers weren't
exactly what the original poster was looking for.  Robotics is a vary
broad field ranging from little critters skittering about on the floor
with 8 bit micro controllers to large kinematically redundant manipulator
mechanisms with multiple 32 bit high performance processors.  

      A:  Yes and No.  No, due to the use of 8-16 bit MCs in critterbots,
Ada is _probably_ not a good candidate for them.  But with the falling
cost and power requirements and the fact that 1M of RAM could be purchased
with the change on the floor of my mini van, I think a 32 bit MC could be
used in criterbots very soon.  Yes, the former robot lab at goddard space
flight center, as well as at least one robot lab at NIST controlled their
robots with 25Mhz 386/387's running software written in Ada.  These
research efforts are long gone in history.   I participated in the effort
at GSFC.  I also worked on a more recent effort where robot applications
were written in C++, running on LynxOS running on Pentiums.  

As another poster stated, "good or poor software can be written in any
language".  Quite true.  The individual programer and project probably
have a greater impact at this level.  I however have written robot control
software in C, C++, and Ada and from my personal anicdotal experience, my
C had the lowest productivity in terms of functionality per time period,
and the highest rate of flaws found per function.  My C++ just nosed out
my Ada83 in apparent productivity per time period BUT had a much higher
flaw rate and the flaws were much more difficult to remove than the Ada83
flaws.  Debugging large systems by rummaging through the entrails of core
dumps is VERY slow.  The few cases where I have seen C/C++ head to head
with Ada on the same or similar projects, the post release flaw rate was
where C/C++ got murdered.  They did usually beat the Ada implementation in
productivity.  But this is starting to sound like a language war.  

The SEI (software engineering institute) CMM (capability maturity model),
as I interpret it, seems to indicate that intelligent language selection
is an activity of VERY mature software organizations (wouldn't switching
languages, however, seem like an immature undertaking?) because of the
long term historical data needed to spot deficiencies in languages.  It's
easy to look over a language like Ada, C, C++, Java and say "Language X
will be the BEST to write robot code!" Being correct in this is quite a
bit trickier.  Sometimes library availability drives this decision.  I'm
still looking for the deffinitive answer on how immature organizations
should choose programming languages.  

Where one stands on this issue, also depends quite a lot on where one used
to sit!  If _I_ were to write robot controller software, and _I_ could
choose the language, I would dig out my old 9-tracks tapes of Ada robot
library code and catapult myself and my project ahead by many thousands of
lines of tested re-useable code.  Other, not so lucky people, might not
have millions of dollars worth of public domain code on a tape in their
closet (-8-0).  When I suggested that by choosing Ada we might save
whopping large amounts of time and money with reuse to a former employer,
they looked at me like a bug.  

The original poster also mentioned how Ada was designed to be targeted at
the "embedded market".  I think this causes some confusion.  The "Embedded
market" ranges from small 2kbyte programs, writte in assembler, running on
microcontrollers, to megga-line projects distributed across hundreds of
processors controlling life and mission critical activities.  Ada was
targeted towards the traditional "medium to large" projects.  I think this
is where DOD was getting their butts kicked with cost overruns, schedule
slips and project failures.  

It's a question of scale.  One guy banging out ASM can handle a simple
programming project.  There are lots of personal electronic and other
devices successfully brought to market with this approach and thats just
fine for them.  The disaster occurs when the "one dude hacking" model is
scaled up to larger projects.  This sort of thing is the nucleus for many
books on software project management.  Which would be a good point to
depart from this discussion.

Re: ada and robots

[John G. Volan]

dana@indyweb.net wrote:
> 
> In article <slrn5pch85.avm.aklee@bonsai.net>, aklee@no_spam.bonsai.net
> (Albert K. Lee) wrote:
> 
> > So does anybody have any answers for the original poster?  That guy
> > who was asking quite innocently about specific techniques and tools
> > for embedded programming using the Ada language?
[snip]
> I think the general lack of response back to the group could be taken as
> response in the negative.  

I dunno. This newsgroup has been uncharacteristically quiet lately, the
usual contributors seem to have dropped off the map. Is there some Ada
conference going on this week? 

> I e-mail the original poster with a more
> detailed response but I'll post a summary here for all you curious folks.
> 
> I assume the original question was REALY about looking for compilers for
> the calss of low cost 8 -16 bit processors typically used in hobbyist type
> robots.  ("Hobbyist", not to demean these robots, just classify them)
> That question raises several other on obvious questions.
... 

Dana's points are well-taken, but let me steer the discussion slightly
into a different avenue: If we're talking "hobbyist" category work, then
what about GNAT?

If any of the GNAT team are listening, I'll defer to their wisdom of
course, but in the meantime:

- In the 8-16 bit processor category, when this question has been asked
in the past, the general consensus appears to be that indeed, such
systems are "too small" to port GNAT to.  In fact, I believe 8-bit
processors would be too small for Ada itself (ah, at last, an actual
language-suitability fact!) because, for instance, Standard.Integer is
expected to be optimally supported on the given target hardware, and it
is required to cover at least a 16-bit range of integer values. 
(Doesn't C have a similar requirement for int?)  For 16-bit processors,
I believe Robert Dewar has basically discounted the possibility of
porting GNAT, but I wonder if he just meant that a 16-bit processor is
an unlikely _host_ for GNAT?  It would be worth checking the GCC configs
to see whether your prospective 16-bit target architecture was already
supported there. If it is, then it's not that hard to configure and
build a GNAT cross-compiler for it. If the platform isn't already
supported, doing a fresh port of GCC is somewhat more difficult (you
have to create a description of your target instruction set using
Register Transfer Language, and so forth), but it's not entirely
impossible.

(There's the obvious question about whether tasking can be supported if
you don't already have a threads library for the target platform, but
you may have already decided to jettison tasking anyway. And of course
things such as Text_IO are problematic without OS support.)

- GNAT looks much more feasible for processors in the 32-bit range, and
as Dana points out, the price of these has been falling. Cross-compiler
configurations of GNAT and the GNU tools are certainly feasible in this
category. Someone out there may already have done this for your
prospective architecture. I've lost the original post, but if you're
still listening, what processors did you have in mind?  Would you
consider, let's say, a 680x0 or a 80X86?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[dana]

In article <339974E0.335E@sprintmail.com>, johnvolan@sprintmail.com wrote:

> 
> Dana's points are well-taken, but let me steer the discussion slightly
> into a different avenue: If we're talking "hobbyist" category work, then
> what about GNAT?
> 
<snip>

> - GNAT looks much more feasible for processors in the 32-bit range, and
> as Dana points out, the price of these has been falling. Cross-compiler
> configurations of GNAT and the GNU tools are certainly feasible in this
> category. Someone out there may already have done this for your
> prospective architecture. I've lost the original post, but if you're
> still listening, what processors did you have in mind?  Would you
> consider, let's say, a 680x0 or a 80X86?


I just got my EE Times and with the usual product guide/ad section.  There
on the front page is what we've been looking for.  

--------------------------------------------------------------------------
The SMX/386/40 PC module from ZF Microsystems.  a complete 40MHz 386 pc in
a 2.2x3.0x0.45 module with 2M of dram, IDE drive controller, floppy
controller, 2 serial ports, parallel port, 256K of boot flash, BIOS,
(pretty much what i've paid $2000 for in 1989) single +5v supply, 750Ma
current!!  The module is $104 in 1,000's and on a pc104 card for $269.  
--------------------------------------------------------------------------
My guess is that it's a 386-EX-40 in a module w/$15 worth of DRAM and $5
worth of flash.  The price will fall to the floor over time.  Goodby 8051,
pic-16.  this little baby will (more or less) run the same binaries as
most every desktop machine on the planet.  This looks like the 32 bit
processor has finaly reached the mid price embedded market.  The fact that
you won't need e-prom burners, ICE's etc to use this dude might actually
make it a contender for hobyists.

I have no connectoin to ZF micro systems.  I've always thought that the
day would arrive when entire computer systems could be built into unitized
matchbox sized modules.