Re: Why Ada is not the Commercial Lang of Choice

Re: Why Ada is not the Commercial Lang of Choice

[Robert I. Eachus]

Paul Van Bellinghen writes:
> 
> Claim:
> It is much easier in C, for example, to output a data word to
> an I/O device that is memory mapped.
> 
> Supporting Evidence:
> 1       One need only define a pointer
> 2       and assign it the memory mapped address
> 3       then store the desired data value to the contents of the pointer.
> 
> Example:
>  #define mem_map_addr B0100040
>  unsigned int *p;
> 
>  p = (unsigned int *) mem_map_addr;
> 
>  *p = 0x00344556;
> 
> Claim:
> It is harder to do it in Ada because i write it out in more words.

   Wait a second here.  The eqivalent Ada is:

   Mem_Map: Integer;
   for Mem_Map'Address use 16#B0100040#;
 begin
   Mem_Map := 16#00344556#;

   ...which is a little shorter in terms of characters, words, and
lines.  I could go into the bugs in both the Ada and the C--I'd want
pragma Volitile(Mem_Map); in both Ada and C.  Most compilers will get it
"right" but why take the risk.  Also, it might be necessary to call
System.Storage_Elements.To_Address, but I can't imagine any compiler for
a machine where 16#B01000040# is a meaningful address not allowing
literals for addresses.

-- 


                                               Robert I. Eachus

with Standard_Disclaimer;
use Standard_Disclaimer;

Re: Why Ada is not the Commercial Lang of Choice

[Dale Stanbrough]

Robert I. Eachus writes:

"   Wait a second here.  The eqivalent Ada is:
 
    Mem_Map: Integer;
    for Mem_Map'Address use 16#B0100040#;
  begin
    Mem_Map := 16#00344556#;"


We shouldn't of course forget the option of using underscores in numeric
literals, which to my continual amazement, no other language that i know of
has!
E.g.

    Mem_Map: Integer;
    for Mem_Map'Address use 16#B010_0040#;
  begin
    Mem_Map := 16#0034_4556#;"


This is such a simple feature, yet it improves readability no end.

Dale

Re: Why Ada is not the Commercial Lang of Choice

[Steve Jones - JON]

Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes:

[snip]
> 
> 
>     Mem_Map: Integer;
>     for Mem_Map'Address use 16#B010_0040#;
>   begin
>     Mem_Map := 16#0034_4556#;"

This reminds me of afriend working on the Madrid train system who was
informed that he wouldn't be able to write the controller software in
Ada because Ada couldn't handle hardware correctly.  My mate disagreed
and was given dispensation to prove it.  On one side a team of three
in C, on the other a rather good Ada programmer.

Guess which one came in first and had the least bugs ?  The timescale
differences were very large, mainly because using the Tasking model
the hardware interupts could be abstracted away.

I think Ada's problem here is that no one who has used C actually
belives that a language that incorporates data hiding and strong SE
principles can also access the bare metal effectively. Maybe Ada was
just a little too good.

-- 
|Un Loup en France  | Wolverhampton Wanderers, out of darkness cometh Bully|
|------------Cat 1, Cha, Cha, Cha -- NERC offical drinking song------------|
|----The above opinions rarely reflect my own and never my employers'------|
|Do not add me to mailing lists violations will be billed for time.        |

Re: Why Ada is not the Commercial Lang of Choice

[Anonymous]

<33A7FBFF.29D2@mitre.org> <5o9eca$aoi$1@goanna.cs.rmit.edu.au>

On 19 Jun 1997 11:14:45 +0200, Steve Jones - JON
<jon@hpodid2.eurocontrol.fr> wrote:

> Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes:
> 
> [snip]
> > 
> > 
> >     Mem_Map: Integer;
> >     for Mem_Map'Address use 16#B010_0040#;
> >   begin
> >     Mem_Map := 16#0034_4556#;"
> 
> This reminds me of afriend working on the Madrid train system who was
> informed that he wouldn't be able to write the controller software in
> Ada because Ada couldn't handle hardware correctly.  My mate disagreed
> and was given dispensation to prove it.  On one side a team of three
> in C, on the other a rather good Ada programmer.
> 
> Guess which one came in first and had the least bugs ?  The timescale
> differences were very large, mainly because using the Tasking model
> the hardware interupts could be abstracted away.
> 
> I think Ada's problem here is that no one who has used C actually
> belives that a language that incorporates data hiding and strong SE
> principles can also access the bare metal effectively. Maybe Ada was
> just a little too good.

Many of us would appreciate it if this could get into the Ada success
stories at AdaHome and the AdaIC (with a lot more detail and supporting
facts).

Thank you, Wolf in France.

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: Why Ada is not the Commercial Lang of Choice

[Peter Hermann]

Steve Jones - JON (jon@hpodid2.eurocontrol.fr) wrote:

> and was given dispensation to prove it.  On one side a team of three
> in C, on the other a rather good Ada programmer.

> Guess which one came in first and had the least bugs ?  The timescale
> differences were very large, mainly because using the Tasking model
> the hardware interupts could be abstracted away.

This is exactly that kind of tune, which should be molded
into short hot success stories backed with facts.
Do you see a chance to compile it?

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Why Ada is not the Commercial Lang of Choice

[Shmuel (Seymour J.) Metz]

Steve Jones - JON wrote:
> 
> I think Ada's problem here is that no one who has used C actually
> belives that a language that incorporates data hiding and strong SE
> principles can also access the bare metal effectively. Maybe Ada was
> just a little too good.

Nonesense! Just because someone has had the misfortune to use C doesn't
mean that his brain is rotten, or even that he likes the abysmal thing.
Some people use C because they are forced to, and are painfully aware of
its defects. For that matter, some people ase Ada because they are
forced to ;-)

> --
> |Un Loup en France  | Wolverhampton Wanderers, out of darkness cometh Bully|
> |------------Cat 1, Cha, Cha, Cha -- NERC offical drinking song------------|

-- 

                        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: Why Ada is not the Commercial Lang of Choice

[Robert A Duff]

In article <5o9eca$aoi$1@goanna.cs.rmit.edu.au>,
Dale Stanbrough  <dale@goanna.cs.rmit.EDU.AU> wrote:
>We shouldn't of course forget the option of using underscores in numeric
>literals, which to my continual amazement, no other language that i know of
>has!

Yeah, that's one of my pet peeves, too.  How many times have I read code
containing 10000000, and I have to use a magnifying glass to count, to
see whether that's a million, or ten million!  10_000_000 is so vastly
much more readable.

>    Mem_Map: Integer;
>    for Mem_Map'Address use 16#B010_0040#;

By the way, this will typically need a To_Address call, since in many
implementations, type Address is not an integer type.  The RM recommends
a private type, which I think is sensible.

- Bob

Re: Why Ada is not the Commercial Lang of Choice

[Paul Van Bellinghen]

This is all well and good when you know the exact address to set the
variable to. The problem comes with a variable of type "address" that
you need to perform masking on. I was unable to re-cast a variable of
type "address" (which was derived from unsigned integer) to an
unsigned integer  so that I could mask out the lower 48 bits. That's
why I went the "unchecked conversion" route. Ada seems to be so
strictly typed that even though a variable is typed or sub-typed as
unsigned integer, it is treated as a completely different type than a
variable typed as unsigned integer.

>>    Mem_Map: Integer;
>>    for Mem_Map'Address use 16#B010_0040#;
>
>By the way, this will typically need a To_Address call, since in many
>implementations, type Address is not an integer type.  The RM recommends
>a private type, which I think is sensible.
>
>- Bob

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Paul says

<<This is all well and good when you know the exact address to set the
variable to. The problem comes with a variable of type "address" that
you need to perform masking on. I was unable to re-cast a variable of
type "address" (which was derived from unsigned integer) to an
unsigned integer  so that I could mask out the lower 48 bits. That's
why I went the "unchecked conversion" route. Ada seems to be so
strictly typed that even though a variable is typed or sub-typed as
unsigned integer, it is treated as a completely different type than a
variable typed as unsigned integer.>>

Interesting that you choose an example where Ada has preferable semantics
to C. In C there is no way to treat an address as an integer, except to
do the equivalent of an unchecked conversion (i.e. a cast to an integral
type). This cast is tricky, because

(a) you have no way of declaring the integer type to which you will cast
it in a portable manner. In fact it is not even required that there be
such a type, though there usually will be (it might be int, or it might
be long, or it might be long long).

(b) when you do this cast in C, you have no idea what the equivalence will
be, so as soon as you do things like masking out lower order bits you are
in quite implementation dependent territory.


Now obviously no language can guarantee portable semantics for this type
of operation, but Ada does a much better job of providing appropriate
semantic facilities here. In particular there is a defined type
Integer_Address, which is precisely defined as an integer equivalent to
a linear address, if this makes sense for the machine. And one can convert
Address values to and from Integer_Address without using Unchecked_Conversion.

Going the "unchecked conversion" route in Ada 83, which lacks this capability
makes perfect sense, but how on earth could you present this as a difference
between Ada and C. The unchecked conversion from integer to address in Ada
has exactly the same semantics as the (unchecked) cast in C from integer
to address.

I often notice that when you get people to give actual examples in C of
code that they would like to present as demonstrating the inadequacies
of Ada, they actually turn out to be great examples of the superiority
of Ada over C, in the realm which people think of as belonging to C,
namely low level operations.

That's why it is a shame that Joe will not or cannot follow through on
giving specific examples. They very likely would be cases of this kind!

Re: Why Ada is not the Commercial Lang of Choice

[John G. Volan]

Robert Dewar wrote:
> 
> I often notice that when you get people to give actual examples in C of
> code that they would like to present as demonstrating the inadequacies
> of Ada, they actually turn out to be great examples of the superiority
> of Ada over C, in the realm which people think of as belonging to C,
> namely low level operations.
> 
> That's why it is a shame that Joe will not or cannot follow through on
> giving specific examples. They very likely would be cases of this kind!

Time to take the gloves off: It is not that Joe can not, it is that he
will not.  We've given him ample opportunity, but, as I suspected from
the start, he's more interested in damning Ada with vague generalities
and faint praise than in really engaging in a nuts-and-bolts discussion.

Joe's sort clings to a jaundiced opinion of Ada's capabilities, and is
rarely swayed even by direct evidence to the contrary, because this
jaundiced opinion is ever so comforting to them. I mean, if you've
invested your world-view in the notion that Ada is inadequate, then of
course you're not going to see any cost-benefit in presenting a concrete
example demonstrating your world-view -- because, heaven forbid, someone
might actually be able address your concrete example and show how your
world-view is wrong!

------------------------------------------------------------------------
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: Why Ada is not the Commercial Lang of Choice

[Shmuel (Seymour J.) Metz]

John G. Volan wrote:
> 
> Joe's sort clings to a jaundiced opinion of Ada's capabilities, and is
> rarely swayed even by direct evidence to the contrary, because this
> jaundiced opinion is ever so comforting to them. I mean, if you've
> invested your world-view in the notion that Ada is inadequate, then of
> course you're not going to see any cost-benefit in presenting a concrete
> example demonstrating your world-view -- because, heaven forbid, someone
> might actually be able address your concrete example and show how your
> world-view is wrong!

Ada *is* inadequate; but so is C. I'd certainly prefer to use Ada than C
or
(shudder) COBOL, both of which I've been forced to use. Most of the
inadequacies in Ada apply in spades to C.

 
> ------------------------------------------------------------------------
> 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? :-) ");
> ------------------------------------------------------------------------

-- 

                        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: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

John Volan said

<<Ada *is* inadequate; but so is C. I'd certainly prefer to use Ada than C
or
(shudder) COBOL, both of which I've been forced to use. Most of the
inadequacies in Ada apply in spades to C.
>>

Interesting, why the shudder at COBOL. I have written a lot of COBOL, and
find it quite amenable. For IS Systems, I would use the ranking:

Ada/95
COBOL
Ada/83
C

There are some respects in which i prefer COBOL to Ada. I find the approach
to dynamic (runtime) binding of modules in COBOL to be lighter and easier
than in Ada Annex E (I am talking about dynamic call). I also like the
easy local refinement syntax in COBOL.

Re: Why Ada is not the Commercial Lang of Choice

[Yasmiin S. Davis]

Robert Dewar wrote:
> 
> John Volan said
> 
> <<Ada *is* inadequate; but so is C. I'd certainly prefer to use Ada
> than C
> or
> (shudder) COBOL, both of which I've been forced to use. Most of the
> inadequacies in Ada apply in spades to C.

> Interesting, why the shudder at COBOL. I have written a lot of COBOL,
> and
> find it quite amenable. For IS Systems, I would use the ranking:

> Ada/95
> COBOL
> Ada/83
> C
> 
> There are some respects in which i prefer COBOL to Ada. I find the
> approach
> to dynamic (runtime) binding of modules in COBOL to be lighter and
> easier
> than in Ada Annex E (I am talking about dynamic call). I also like the
> easy local refinement syntax in COBOL.


Well at risk of starting a war -- while I like Ada and am not a C fan (
I am an ALGOL junkie in need of a fix), what the commercial would needs
to to business type programming ( i.e. the capture of domain knowledge /
business logic) is a new language  or at least not C++.  As a systems
architect I am seeing commercial institutions addopt C++ for this
purpose.  Having to reverse engineer an object model from C++ code for
and on going 3 tier client server systems for claims processing -- all I
can say is the first attempt to do mainyenance on that system will
result in the poor client company having to junk it.

Now yes we do have Object COBOL from Micro Focus -- I don't know how
much that is being used.

But my lament is the industry has been here before and learned its
lesson.  Remember those days before the wide availability of COBOL on
Minis when business apps were writen in Fortran ?  Well I have to say
giving the poor business programmer C or Ada or C++ is just as bad -- 
and its poor me who has to audit and read that code -- help.

Yasmiin

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Yasmiin said

<<But my lament is the industry has been here beefore and learned its
lesson.  Remember those days before the wide availability of COBOL on
Minis when business apps were writen in Fortran ?  Well I have to say
giving the poor business programmer C or Ada or C++ is just as bad --
and its poor me who has to audit and read that code -- help.
>>

I find this judgment surprising, but perhaps it is just uninformed. In
fact Ada 95 with a full implementation of the systems programming annex,
including high precision decimal arithmetic with control over rounding,
and full editing, very similar to what COBOL provides, is an extremely
attractive replacement for COBOL. In fact I really don't see any reason
to choose OO COBOL over Ada 95 for this kind of programming (other than
non-technical reasons like existing programmer knowledge, although these
days, with the Y2K problem looming, it is harder to hire competent COBOL
programmers (and more expensive) than to hire Ada programmers.

I quite understand that you have had trouble with C++ used for this purpose,
since it seems totally unsuitable, but I would be very interested if you
have audited Ada 95 code making use of the IS annex that you have found
unreadable (indeed it would be most interesting to know who is using
Ada 95 for this purpose today).

Re: Why Ada is not the Commercial Lang of Choice

[Shmuel (Seymour J.) Metz]

Robert Dewar wrote:
> 
> Interesting, why the shudder at COBOL. I have written a lot of COBOL, and
> find it quite amenable. For IS Systems, I would use the ranking:
> 
> Ada/95
> COBOL
> Ada/83
> C

I've lost touch with the language revisions on COBOL, but the last I
looked
thy were still using integers as keywords, e.g., 77, 88. That by itself
is
enough to provoke a world-class shudder.

FWIW I'd use the ranking:

	PL/I
	Ada 95
	Ada 83
	HLA
	COBOL
	C

I'm ignoring special purpose languages like ICON, REXX and SETL in the
ranking, since they don't have production quality compilers suitable for
number crunching, but they have their significant uses as well.

-- 

                        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: Why Ada is not the Commercial Lang of Choice

[Paul Van Bellinghen]

>Ada *is* inadequate; but so is C. I'd certainly prefer to use Ada than C
>or
>(shudder) COBOL, both of which I've been forced to use. Most of the
>inadequacies in Ada apply in spades to C.
>

When I started this thread, I simply argued that C was easier to use
than Ada, not that it is more robust. Of course Ada is more robust
than C. The question is whether a commercial firm can be convinced
that it will somehow make more money by using Ada over C/C++. I
suppose customer satisfaction in getting a less buggy product should
be an incentive. Also, for a multiprocessor environment, tasking can
be used very effectively in creating a system that runs tasks in
parallel, making the user application S/W faster and easier to use.

Re: Why Ada is not the Commercial Lang of Choice

[Ken Mays]

Its not so much as what language is better than any other language, its
what is the appropriate tool for the task. Ada95 works well with
embedded software projects. C/C++ works well with Unix programming and
other types of work. Java works well for cross platform/Internet work.
Can one language do it all? Its possible, but would take a major
undertaking. Its like telling everyone to speak and write English. Its
possible, but everyone will not conform. 

C++ is the commercial langauge of choice. Ada95 is DOD/avionics. Then
there is Java and COBOL/RPG. The other languages like Smalltalk and
ABAP/4 are for the adventerous.

Ken Mays
SAIC



>Paul Van Bellinghen wrote:
> 
> >Ada *is* inadequate; but so is C. I'd certainly prefer to use Ada than C
> >or
> >(shudder) COBOL, both of which I've been forced to use. Most of the
> >inadequacies in Ada apply in spades to C.

Re: Why Ada is not the Commercial Lang of Choice

[Robert Munck]

On Sun, 13 Jul 1997 12:17:07 -0500, Ken Mays
<kenneth.l.mays@cpmx.saic.com> wrote:

>Its not so much as what language is better than any other language, its
>what is the appropriate tool for the task. Ada95 works well with
>embedded software projects. 

and graphics applications,
and financial/business programs,
and scientific (heavy arithmetic) programs,
and word processing,
and operating systems, and etc. etc.

All of which I've done in both Ada and in the common-knowledge
"appropriate" language for that genera (assembler, FORTRAN,
COBOL, SNOBOL, Pascal/Modula, PL/S, etc).

>C/C++ works well with Unix programming and other types of work.

UNIX gives you so many problems with platform incompatability,
unexpected side-effects from upgrades to the OS, compilers,
and other programs, and general inconsistencies that you don't
notice how expensive C/C++ make it is to debug, maintain, and
upgrade your source code.

> Java works well for cross platform/Internet work.

But why bother, when you can use the Intermetrics Ada 95 to
Java Virtual Machine to write code that runs in all the same
conditions and doesn't have the problems of Java's C legacy?


>C++ is the commercial langauge of choice. 

for those who haven't really made an informed choice, and
for those who are doing coding rather than software engineering,
and for those who are trading a quick-and-dirty release ASAP for
horrible maintenance and upgrade headaches in the future. 
This may be the reason for the "flash-in-the-pan" nature of
so many start-ups in our business; they get an initial product
out fast in C++, but can't upgrade, add new programmers to the 
project, or even reduce the bug count because the code is
unreadable.

(Btw, I liked COBOL when I was working on a large financial
system in it, but couldn't stand to go back to it after I'd done
a similar project in Ada.)

Bob Munck
Mill Creek Systems LC

Re: Why Ada is not the Commercial Lang of Choice

[Ken Mays]

Actually, you're right. Ada95 has the advantage of being more
maintainable than C++. C++ is the commercial language of choice since
it is the most common language (not because it is the best language).
Many games and projects are written in C/C++ so its easier for many
companies to hire C programmers than Ada programmers. Graphics libraries
and others source code is easier to come by so that's why people howl
when you say "Ada is better." 

I remember when companies use to program games in Pascal and BASIC. If
someone really wants to debate how great Ada95 is, then lets do a test
with a utility like SendMail V8.8.6. We can convert it over to Ada95
code (there is a utility that can do this) and then fix the remaining
bugs in the code (if its too hard then rewrite it from scratch in Ada95
code). Actually, I would rather rewrite the code so don't I don't miss
someone else's bugs!

What I'm trying to point out is that many of us call ourselves software
engineers but won't prove what "software engineering" really is. MIT
students have maintained the GNU site for years but I don't see them
preaching about converting the GNU software to Ada. Most jobs will hire
C/C++ programmers in attempt to train them to Ada later..then it might
be Ada83 if they are unlucky.

Ada95 SHOULD be the commercial language of choice for Software
Engineering. As for the typical hacking of code and "quick and dirty"
programming, C/C++ will be around for quite a while. Its a shame, but
many companies will waiver using C or C++ over Ada95!!!!! Go tell Apple
to rewrite MacOS V8.0 in Ada95 and see what they will tell you. How
about IBM making Ada95 the langauge of choice for OS/2 programming?
How about MicroSoft stating that all future development will be in
Ada95? Does it sound far-fetched??? Time will tell.


Ken
SAIC
"You don't have to pay for college. Get an honorary degree!"

Robert Munck wrote:
> 
> On Sun, 13 Jul 1997 12:17:07 -0500, Ken Mays
> <kenneth.l.mays@cpmx.saic.com> wrote:
> 
> >Its not so much as what language is better than any other language, its
> >what is the appropriate tool for the task. Ada95 works well with
> >embedded software projects.
> 
> and graphics applications,
> and financial/business programs,
> and scientific (heavy arithmetic) programs,
> and word processing,
> and operating systems, and etc. etc.
> 
> All of which I've done in both Ada and in the common-knowledge
> "appropriate" language for that genera (assembler, FORTRAN,
> COBOL, SNOBOL, Pascal/Modula, PL/S, etc).
> 
> >C/C++ works well with Unix programming and other types of work.
> 
> UNIX gives you so many problems with platform incompatability,
> unexpected side-effects from upgrades to the OS, compilers,
> and other programs, and general inconsistencies that you don't
> notice how expensive C/C++ make it is to debug, maintain, and
> upgrade your source code.
> 
> > Java works well for cross platform/Internet work.
> 
> But why bother, when you can use the Intermetrics Ada 95 to
> Java Virtual Machine to write code that runs in all the same
> conditions and doesn't have the problems of Java's C legacy?
> 
> >C++ is the commercial langauge of choice.
> 
> for those who haven't really made an informed choice, and
> for those who are doing coding rather than software engineering,
> and for those who are trading a quick-and-dirty release ASAP for
> horrible maintenance and upgrade headaches in the future.
> This may be the reason for the "flash-in-the-pan" nature of
> so many start-ups in our business; they get an initial product
> out fast in C++, but can't upgrade, add new programmers to the
> project, or even reduce the bug count because the code is
> unreadable.
> 
> (Btw, I liked COBOL when I was working on a large financial
> system in it, but couldn't stand to go back to it after I'd done
> a similar project in Ada.)
> 
> Bob Munck
> Mill Creek Systems LC

Re: Why Ada is not the Commercial Lang of Choice

[Don Harrison]

Dale Stanbrough wrote:

:We shouldn't of course forget the option of using underscores in numeric
:literals, which to my continual amazement, no other language that i know of
:has!

Well, you can stop being amazed because Eiffel allows them. :)  

However, they differ in that digits must be grouped in threes. Grouping in 
threes is an arbitrary choice and, IMO, too restrictive. For example, it makes 
no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal 
because it allows different groupings within the same literal.

Something in between is probably optimal - like allowing any grouping but with
the restriction that it must be consistent within a literal.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Why Ada is not the Commercial Lang of Choice

[Larry Kilgallen]

In article <EC1zG2.DFo@syd.csa.com.au>, donh@syd.csa.com.au (Don Harrison) writes:

> However, they differ in that digits must be grouped in threes. Grouping in 
> threes is an arbitrary choice and, IMO, too restrictive. For example, it makes 
> no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal 
> because it allows different groupings within the same literal.
> 
> Something in between is probably optimal - like allowing any grouping but with
> the restriction that it must be consistent within a literal.

I can envision an application using part numbers, where the first
two digits indicate the plant that built the part  and the last
two represent the revision number. In that case, 21_302_561_03
might be a much more natural representation than 2_130_256_103.
In fact, absent some other well-known (to humans) aspect of the
part numbering scheme, it would also provide a better scanning
profile than 21_30_25_61_03.

Larry Kilgallen

Re: Why Ada is not the Commercial Lang of Choice

[Nick Leaton]

Larry Kilgallen wrote:
> 
> In article <EC1zG2.DFo@syd.csa.com.au>, donh@syd.csa.com.au (Don Harrison) writes:
> 
> > However, they differ in that digits must be grouped in threes. Grouping in
> > threes is an arbitrary choice and, IMO, too restrictive. For example, it makes
> > no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal
> > because it allows different groupings within the same literal.
> >
> > Something in between is probably optimal - like allowing any grouping but with
> > the restriction that it must be consistent within a literal.
> 
> I can envision an application using part numbers, where the first
> two digits indicate the plant that built the part  and the last
> two represent the revision number. In that case, 21_302_561_03
> might be a much more natural representation than 2_130_256_103.
> In fact, absent some other well-known (to humans) aspect of the
> part numbering scheme, it would also provide a better scanning
> profile than 21_30_25_61_03.
> 

I agree with the original idea, that splitting numbers in threes doesn't
make sense if you are dealing with a binary number. Also, if you were
Japanese, then splitting in 4 makes more sense.

However, your part number example is not a good one. You should be
splitting it into two. You have two attributes, plant number and 
revision number. You then have a separate problem of how to display the
information, which is turning the two pieces of information into a
string, which is displayable. How you store the information is then a
separate problem, where you may do something like storing an integer
value, of plant_number * 100 + revision_number.
-- 

Nick

Re: Why Ada is not the Commercial Lang of Choice

[Don Harrison]

I wrote:

:> However, they differ in that digits must be grouped in threes. Grouping in 
:> threes is an arbitrary choice and, IMO, too restrictive. For example, it makes 
:> no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal 
:> because it allows different groupings within the same literal.
:> 
:> Something in between is probably optimal - like allowing any grouping but with
:> the restriction that it must be consistent within a literal.

Two situations have been suggested where free placement would be desirable:

  a) Use of numbers for identity, and
  b) Binary representations with different boundaries.


Larry Kilgallen wrote:

:I can envision an application using part numbers, where the first
:two digits indicate the plant that built the part  and the last
:two represent the revision number. In that case, 21_302_561_03
:might be a much more natural representation than 2_130_256_103.
:In fact, absent some other well-known (to humans) aspect of the
:part numbering scheme, it would also provide a better scanning
:profile than 21_30_25_61_03.

Maybe a better way of indicating identity would be to use a class PART_NUMBER 
containing the various sub-components and use strings for I/O. If you use
integers, you get unwanted arithmetic operations that are inappropriate for 
part numbers.


Donovan Baarda wrote:

:Nahh, why limit things? Arbitary placement of underscores is handy when
:you want to define an integer literal bit-field where bits are clustered
:on arbitary boundarys.

True.


Roy Grimm wrote:

:I like having the freedom to place underscores where I need them.  In
:some of the work I do, I have to break up and assemble 32 bit words
:composed of varying segments.  I like having the ability to use a mask
:that looks like this:
:
:2#0_00_00000_1111111111111111_00000000#
:
:On the other hand, the same incoming bus data can be masked as so:
:
:2#0_00_1111111_1111111_1111111_00000000#
:
:In this case, having the flexibility is really nice.  I guess it really
:has to do with the context of the job you're doing.

Agree. I suspect the only situations where you would need the flexibility is
for binary representations. Otherwise, regular placement should suffice.
 

Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Why Ada is not the Commercial Lang of Choice

[Bertrand Meyer]

Just a note that since clearly a majority of people
think the placement of underscores in integers
should be free I agree that the Eiffel rule
(group digits by packets of three) should be demoted
from a language constraint to a mere style recommendation.

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
Web: http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel straight from those who invented it ==

Re: Why Ada is not the Commercial Lang of Choice

[Nick Leaton]

Bertrand Meyer wrote:
> 
> Just a note that since clearly a majority of people
> think the placement of underscores in integers
> should be free I agree that the Eiffel rule
> (group digits by packets of three) should be demoted
> from a language constraint to a mere style recommendation.
> 

And that underscores should be allowed in floating point
representations.

Some compilers will not freeze or finalise underscored floating point
numbers.

-- 

Nick

Re: Why Ada is not the Commercial Lang of Choice

[Dr. Vladimir Il'ich Fomin]

On Tue, 24 Jun 1997 10:23:44 -0700, in <33B002A0.2781E494@eiffel.com>, Bertrand Meyer <Bertrand.Meyer@eiffel.com> wrote:
>Just a note that since clearly a majority of people
>think the placement of underscores in integers
>should be free I agree that the Eiffel rule
>(group digits by packets of three) should be demoted
>from a language constraint to a mere style recommendation.

Better tell us how come you ship Eiffel CDs with two child pornography
JPEGs in the "unused" area - probably picked up from your hard disk when
you mastered the CD!! One JPEG, entitled "6&8suck.jpg" shows two little
boys performing fellatio on Bertrand Meyer.  Another file, called
"7assfuck.jpg" shows Betrand Meyer buggering a small boy.  Many other
examples of child pornography can probably be found on Bertrand 
Meyer's hard disk.  What a disgusting pervert!!

>Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
>805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
>Web: http://www.eiffel.com, with instructions for free download
>== ISE Eiffel 4: Eiffel straight from those who invented it ==


      .                ,      
       `.    ____    ,'::.   
         `-d8%XX88b-':... . 
   .  .  :88%,+,iX.8.:.. .      Dr. Vladimir Il'ich Fomin
  . .   d.%%/:: \iX8..... .      
. . .   :%%{::Q .}iX.8 . .      rec.food.borscht
 . .   d.%%}:/.\ {iX8.b .      
 .  .  .%.{;'.;:`:}iX.8.. .     rec.food.drink.vodka
: .  . o%%/. /l\::\iX8::.. .    
 ....  .%{. //l\\::}iX}.:..    
: ..   {%{.{{ *:}}:}iB:::.:.   "Did you beat up a faggot today?" 
.:.. . :.%\.\\l//:/i:}::.:.  
:.::. .  j%`.`-';'i.P:::.:.
::.:.:. .:x.%`+'iX:P:::.:..  Please e-mail all your MLM offers
::::.:.... 8%%A:8.}:::.:..   and business opportunities to:
::::.::.:..j:(*).P::::.::..  news-admin-net-abuse-policy@uunet.uu.net
 ::::.:.:...x.V8P::::.:...  
 :::::.::.:..`l'::::.:.... 
   ::::::::.,' `:::::...     
  `---____-'     `-____---'

Re: Why Ada is not the Commercial Lang of Choice

[Donovan Baarda]

On Fri, 20 Jun 1997 02:40:50 GMT, Don Harrison <donh@syd.csa.com.au> wrote:
>Dale Stanbrough wrote:
>
>:We shouldn't of course forget the option of using underscores in numeric
>:literals, which to my continual amazement, no other language that i know of
>:has!
>
>Well, you can stop being amazed because Eiffel allows them. :)  
>
>However, they differ in that digits must be grouped in threes. Grouping in 
>threes is an arbitrary choice and, IMO, too restrictive. For example, it makes 
>no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal 
>because it allows different groupings within the same literal.
>
>Something in between is probably optimal - like allowing any grouping but with
>the restriction that it must be consistent within a literal.
>
Nahh, why limit things? Arbitary placement of underscores is handy when
you want to define an integer literal bit-field where bits are clustered
on arbitary boundarys.

From a compiler implementation point of view, enforcing underscore
placement limitations is more hassle than not enforcing them.

ABO

Re: Why Ada is not the Commercial Lang of Choice

[Roy Grimm]

Don Harrison wrote:
> 
> Dale Stanbrough wrote:
> 
> :We shouldn't of course forget the option of using underscores in numeric
> :literals, which to my continual amazement, no other language that i know of
> :has!
> 
> Well, you can stop being amazed because Eiffel allows them. :)

Will wonders never cease? :P

> However, they differ in that digits must be grouped in threes. Grouping in
> threes is an arbitrary choice and, IMO, too restrictive. For example, it makes
> no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal
> because it allows different groupings within the same literal.
> 
> Something in between is probably optimal - like allowing any grouping but with
> the restriction that it must be consistent within a literal.

I like having the freedom to place underscores where I need them.  In
some of the work I do, I have to break up and assemble 32 bit words
composed of varying segments.  I like having the ability to use a mask
that looks like this:

2#0_00_00000_1111111111111111_00000000#

On the other hand, the same incoming bus data can be masked as so:

2#0_00_1111111_1111111_1111111_00000000#

In this case, having the flexibility is really nice.  I guess it really
has to do with the context of the job you're doing.

-- 
Voicing my own opinion, not speaking as a company representative.

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.no.spam.com
    (remove the no.spam. to get my real address)

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Don said

<<However, they differ in that digits must be grouped in threes. Grouping in
threes is an arbitrary choice and, IMO, too restrictive. For example, it makes
no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal
because it allows different groupings within the same literal.

Something in between is probably optimal - like allowing any grouping but with
the restriction that it must be consistent within a literal.
>>

I strongly disagree, it is none of the language's business how I want to
group things, since it depends on the abstract semantics of the item 
involved:

  Last_OK_Date : constant := 99_12_31;

is perfectly reasonable.

Re: Why Ada is not the Commercial Lang of Choice

[Don Harrison]

Robert Dewar wrote:

:Don said
:
:<<However, they differ in that digits must be grouped in threes. Grouping in
:threes is an arbitrary choice and, IMO, too restrictive. For example, it makes
:no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal
:because it allows different groupings within the same literal.
:
:Something in between is probably optimal - like allowing any grouping but with
:the restriction that it must be consistent within a literal.
:>>
:
:I strongly disagree, it is none of the language's business how I want to
:group things, since it depends on the abstract semantics of the item 
:involved:
:
:  Last_OK_Date : constant := 99_12_31;
:
:is perfectly reasonable.

Really? I would have thought such use of integers created a huge potential 
for abuse. For example,

  with Text_io;
  procedure Nonsense is
    Last_OK_Date : constant := 99_12_31;
    Last_Balance : constant := 3_000;
  begin
    Text_io.Put_line (Integer'Image (Last_OK_Date + Last_Balance) );
  end;

I think I'll stick to records (or Eiffel classes) for composite types composed 
of numeric identity data such as dates, part numbers and Social Security numbers.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Don Harrison says, rather irrelevantly:

<<:Don said
:
:<<However, they differ in that digits must be grouped in threes. Grouping in
:threes is an arbitrary choice and, IMO, too restrictive. For example, it makes
:no sense for base 2 literals. OTOH, I think Ada's free placement is too liberal
:because it allows different groupings within the same literal.
:
:Something in between is probably optimal - like allowing any grouping but with
:the restriction that it must be consistent within a literal.
:>>
:
:I strongly disagree, it is none of the language's business how I want to
:group things, since it depends on the abstract semantics of the item
:involved:
:
:  Last_OK_Date : constant := 99_12_31;
:
:is perfectly reasonable.

Really? I would have thought such use of integers created a huge potential
for abuse. For example,
>>


Why irrelevant? Because this post is not about whether or not it is a good
idea to use integers as dates, it is about the use of underlines if you
*do* use integers as dates. For example, if you are using a library
routine that expects an integer for the date, then it is nice to be
able to spell the constants that way. (when using canned library
routines, one does not generally have the luxury of refusing to use
the interface on the grounds that you don't like the design!

So when I say this is reasonable, (I thought it was obvious from
context), I mean it is reasonable to use underscores as written,
rather than be forced, as in Eiffel, to use 991_231!

Re: Why Ada is not the Commercial Lang of Choice

[Joachim Durchholz]

> However, they differ in that digits must be grouped in threes.
> Grouping in  threes is an arbitrary choice and, IMO, too restrictive.
> For example, it makes no sense for base 2 literals.

Besides, I've been told that the Japanese group by *four* digits. (That 
famous "Banzai" cry meaning "tenthousand years" also makes much more 
sense this way - it's rather the equivalent of "thousand years" then.)

Anybody with a real background to confirm (or falsify) this?

Regards,
-Joachim
---
Please don't send unsolicited ads.

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Dale says

<<We shouldn't of course forget the option of using underscores in numeric
literals, which to my continual amazement, no other language that i know of
has!
E.g.
 
    Mem_Map: Integer;
    for Mem_Map'Address use 16#B010_0040#;
  begin
    Mem_Map := 16#0034_4556#;"
 
 
This is such a simple feature, yet it improves readability no end.
 >>


Sorry Dale, your suggestion is totally unacceptable, it increases the length
of the program by two characters.


And oh yes, since sarcasm on this group seems to get easily misread, here is a


         :-)

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Robert Eachus said

<<"right" but why take the risk.  Also, it might be necessary to call
System.Storage_Elements.To_Address, but I can't imagine any compiler for
a machine where 16#B01000040# is a meaningful address not allowing
literals for addresses.>>

While I agree with your nice post (gee, you can shorten the number of
characters still further by using "for use at" instead of "for address use" :-)

I must disagree with this statement. The RM recommends that Address be a 
private type, many compilers, including the RM, follow this advice, and
hence the use of To_Address would be required.

And, gasp! that would mean the Ada code has more characters than the C code!!!

What is amazing is that anyone could think that brevity is an absolute
indicator of usability of a programming language.

Attitudes constantly amaze!

One of the criticisms of COBOL is that it is wordy. When I gave a talk
at Berkeley on COBOL (it was called something like "All the things you
should know about COBOL and probably don't"), I spent the first few minutes
debunking this absurd notion (programs in COBOL after often shorter than
corresponding code in C or Pascal), and the next few minutes complaining that
this is in any case a totally irrelevant metric.

Re: Why Ada is not the Commercial Lang of Choice

[Keith Thompson]

In <33A7FBFF.29D2@mitre.org> "Robert I. Eachus" <eachus@mitre.org> writes:
[...]
>    Wait a second here.  The eqivalent Ada is:
> 
>    Mem_Map: Integer;
>    for Mem_Map'Address use 16#B0100040#;
>  begin
>    Mem_Map := 16#00344556#;
> 
>    ...which is a little shorter in terms of characters, words, and
> lines.  I could go into the bugs in both the Ada and the C--I'd want
> pragma Volitile(Mem_Map); in both Ada and C.  Most compilers will get it
> "right" but why take the risk.  Also, it might be necessary to call
> System.Storage_Elements.To_Address, but I can't imagine any compiler for
> a machine where 16#B01000040# is a meaningful address not allowing
> literals for addresses.

Imagine harder.  8-)}

The implementation advice in RM95-13.7(37) says: "Address should be of
a private type."

GNAT follows this advice (the full type is modular, but that doesn't
make literals available).  ObjectAda makes System.Address an access
type.

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
5040 Shoreham Place, San Diego, CA, USA, 92122-5989
"Zathras warn Zathras, but Zathras never listen to Zathras." -- Zathras

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Keith said

<<GNAT follows this advice (the full type is modular, but that doesn't
make literals available).  ObjectAda makes System.Address an access
type.
>>

That follows an old custom in Alsys compilers, where Address has always
been an access type. What I do not like about this choice is that it means
that the compiler always wants to initialize address values to the null
pointer. This default initialization seems appropriate for access types,
but I usually find it to be unwelcome junk overhead for addresses.

The modular representation seems more natural for modern machines.
Historically one of the reasons for the Alsys choice was that the modular
choice is NOT a good choice for the old junk segmented 286 architecture,
and indeed if we still had to fight that machine, I would probably follow
the access type decision, since it is indeed more portable in this sense.

(yes, yes, I know, the 32-bit x86 architecture still has segmentation, for
gruesome details, see my book on Microprocessors - when Hennessey reviewed
this section of the book, he wrote a large note asking "does anyone use
this nonsense?" -- the answer to his question is pretty much no :-)

Re: Why Ada is not the Commercial Lang of Choice

[Ken Garlington]

Robert Dewar wrote:
> 
> Keith said
> 
> <<GNAT follows this advice (the full type is modular, but that doesn't
> make literals available).  ObjectAda makes System.Address an access
> type.
> >>
> 
> That follows an old custom in Alsys compilers, where Address has always
> been an access type. What I do not like about this choice is that it means
> that the compiler always wants to initialize address values to the null
> pointer. This default initialization seems appropriate for access types,
> but I usually find it to be unwelcome junk overhead for addresses.
> 
> The modular representation seems more natural for modern machines.
> Historically one of the reasons for the Alsys choice was that the modular
> choice is NOT a good choice for the old junk segmented 286 architecture,
> and indeed if we still had to fight that machine, I would probably follow
> the access type decision, since it is indeed more portable in this sense.
> 
> (yes, yes, I know, the 32-bit x86 architecture still has segmentation, for
> gruesome details, see my book on Microprocessors - when Hennessey reviewed
> this section of the book, he wrote a large note asking "does anyone use
> this nonsense?" -- the answer to his question is pretty much no :-)

Of course, some of us still use 16-bit machines with segmentation (e.g.
MIL-STD-1750), but since by and large you can't get Ada 95 on such
machines,
it doesn't cause problems for Ada vendors.

--
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: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Ken said

<<Of course, some of us still use 16-bit machines with segmentation (e.g.
MIL-STD-1750), but since by and large you can't get Ada 95 on such
machines,
it doesn't cause problems for Ada vendors.
>>

Actually there are Ada 95 compilers for this machine, and no doubt there are
other strange machines around where the modular representation for
Address does not make sense. But I would not exactly call these modern
machines :-) And my original note was hedged precisely because there are
still some machines like this around!

Re: Why Ada is not the Commercial Lang of Choice

[Robert I. Eachus]

I said:

   > ....  Also, it might be necessary to call
   > System.Storage_Elements.To_Address, but I can't imagine any compiler for
   > a machine where 16#B01000040# is a meaningful address not allowing
   > literals for addresses.

In article <EC471t.Ltp@thomsoft.com> kst@sd.aonix.com (Keith Thompson) writes:

   > Imagine harder.  8-)}

   Gee, didn't I put enough smileys around?  My point was that if
addresses over three Gig are hard-wired, the compiler should support
such explicit nonsense.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Robert Eachus said

<<   Gee, didn't I put enough smileys around?  My point was that if
addresses over three Gig are hard-wired, the compiler should support
such explicit nonsense.
>>

It is perfectly reasonable to have virtual addresses this large. And
perfectly reasonable to have address clauses for such virtual addresses.
It i9s not however, ever a reasonable expectaion to have ANY literals
for addresses, since address is most likiely a private type if the
recommendation of the RM is followed.

Why Ada is not the Commercial Lang of Choice

[Paul Van Bellinghen]

I've been a real-time embeded Software Engineer since 1975. I've used
assembly,Pascal & Fortran (not in real-time), C, and now Ada. I think
that there are basicly two reasons why Ada did not replace C as the
real-time embeded language of choice - in the commercial world and
recently in the military. 

1. Ada is not and never was a programmer's language. It was never
meant to be. It was imposed upon companies that the DOD contracts in
an effort  to create more reliable (i.e. bug free) products. They saw
how much time and money was spent in fixing problems after a system
was delivered and operational in the field. It is excessivly
type-casted and cumbersome to use.

2. Ada is realy a high level language. C is more intermediate level.
This makes C more well suited to real-time embedded systems that are
really electronic products that use microprocessors to control
electronic devices in a functional manner. It is much easier in C, for
example, to output a data word to an I/O device that is memory mapped.
One need only define a pointer and assign it the memory mapped
address, then store the desired data value to the contents of the
pointer.

#define mem_map_addr B0100040
unsigned int *p;

p = (unsigned int *) mem_map_addr;

*p = 0x00344556;


In Ada you can either define P to be an access variable of type
unsigned interger (if this type is defined in your compiler as mod
2**32 for example) and assign it the address or else, if you know the
exact address you want to assign it, define it as type address (from
machine types) and just assign it the desired address to it (for p use
at B0100040, etc..) and then assign it the data value. 

This is not so bad. However, now try to perform some manipulation on
the address value. Suppose you had to mask off the lower 48 bits of
the address to get the start of the memory sector, as I had to do
recently.

in C:

unsigned int *sector 
 sector = (unsigned int *) ((unsigned int) p & 0xFF000000);

notice the easy way you can re-cast variables.

In Ada, I had to define sector as an access variable of type
internal_address which was defined as unsigned integer (mod 2**32)
within the appropriate range of memory values. I defined p to be of
type internal_address, not of type address since address type has no
operations associated with it in machine_types (I probably could have
defined these myself, I guess). I needed an unchecked conversion
function to convert type address (I was stuck with this type since I
was implementing my own version of a procedure (that input address
types) to write to EEPROM memory in a target debug monitor) to
internal_address. After converting the memory address to
internal_address via the unchecked conversion function, I was then
able to mask off the lower 48 bits (I originally used a logical "and"
function but switched to using the V_I_BITS package to keep it
compatable with Ada 83). Now I was able to assign sector address the
resulting internal_address value of the sector.

Re: Why Ada is not the Commercial Lang of Choice

[Dale Stanbrough]

Paul Van Bellinghen writes:


Claim:
It is much easier in C, for example, to output a data word to
an I/O device that is memory mapped.

Supporting Evidence:
1	One need only define a pointer
2	and assign it the memory mapped address
3	then store the desired data value to the contents of the pointer.

Example:
 #define mem_map_addr B0100040
 unsigned int *p;
 
 p = (unsigned int *) mem_map_addr;
 
 *p = 0x00344556;


Claim:
It is harder to do it in Ada because i write it out in more words.

Supporting Evidence
1	[You define a type, then a pointer]
2	and assign it the address
3	and then assign it the data value
4	[you have other options, notably an address clause for an item]

Example:
None given.


Yes, it is all so much more clearer now. Thank you Paul.


Dale

Re: Why Ada is not the Commercial Lang of Choice

[Robert Munck]

On 17 Jun 1997 08:30:33 GMT, Dale Stanbrough
<dale@goanna.cs.rmit.EDU.AU> wrote:

>Paul Van Bellinghen writes:
>Claim:
>It is much easier in C, for example, to output a data word to
>an I/O device that is memory mapped.
>
>Yes, it is all so much more clearer now. Thank you Paul.

Hey, come on, Dale.  Sarcasm doesn't do him or Ada any 
good, and just encourages the image of Ada people as
arrogant.  Show him the Ada to do the same job that
he shows in C, with appropriate "programmer-friendly"
constructs.

Bob Munck
Mill Creek Systems LC

Re: Why Ada is not the Commercial Lang of Choice

[Ken Garlington]

Paul Van Bellinghen writes:
> 
> Claim:
> It is much easier in C, for example, to output a data word to
> an I/O device that is memory mapped.
> 
> Supporting Evidence:
> 1       One need only define a pointer
> 2       and assign it the memory mapped address
> 3       then store the desired data value to the contents of the pointer.

In Ada, something like:

   Memory_Mapped_Address : constant := 16#0100040#;

   Memory_Mapped_Value : Interfaces.C.unsigned; -- just to keep type
compatibility
   for Memory_Mapped_Value'Address use Memory_Mapped_Address;

   Memory_Mapped_Value := 16#00344556#;

And the neat thing is, Memory_Mapped_Value will always be mapped to the
area of memory you want! No worries about your pointer being corrupted
--
because there isn't a pointer! Who knows, now that the compiler knows
that the address is fixed, you might even get more efficient code!

> 
> Example:
>  #define mem_map_addr B0100040
>  unsigned int *p;
> 
>  p = (unsigned int *) mem_map_addr;
> 
>  *p = 0x00344556;

Claim: The Ada does the same thing, in the same number of lines, and it
does it
more safety, more clearly, and (gasp) possibly more efficiently!

--
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: Why Ada is not the Commercial Lang of Choice

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

Ken Garlington <Kennie.E.Garlington@lmco.com> writes:

> 
> Paul Van Bellinghen writes:
> > 
> > Claim:
> > It is much easier in C, for example, to output a data word to
> > an I/O device that is memory mapped.
> > 
> > Supporting Evidence:
> > 1       One need only define a pointer
> > 2       and assign it the memory mapped address
> > 3       then store the desired data value to the contents of the pointer.
> 
> In Ada, something like:
> 
>    Memory_Mapped_Address : constant := 16#0100040#;
> 
>    Memory_Mapped_Value : Interfaces.C.unsigned; -- just to keep type
> compatibility
>    for Memory_Mapped_Value'Address use Memory_Mapped_Address;
> 
>    Memory_Mapped_Value := 16#00344556#;
> 
> And the neat thing is, Memory_Mapped_Value will always be mapped to the
> area of memory you want! No worries about your pointer being corrupted
> --
> because there isn't a pointer! Who knows, now that the compiler knows
> that the address is fixed, you might even get more efficient code!


You don't need the pointer in C either. Just 

#define Memory_Mapped_Value (*(int *) 0x0100040)

Memory_Mapped_Value = 0x00344556;

has the same effect, except for the scope of Memory_Mapped_Value.


> 
> > 
> > Example:
> >  #define mem_map_addr B0100040
> >  unsigned int *p;
> > 
> >  p = (unsigned int *) mem_map_addr;
> > 
> >  *p = 0x00344556;
> 
> Claim: The Ada does the same thing, in the same number of lines, and it
> does it
> more safety, more clearly, and (gasp) possibly more efficiently!
> 
> --
> 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

Btw., I have been thinking about not being able to assign an explicit
value to the tag of a discriminant union. It will certainly be a
problem, if you intend to store your unions in a file, and read this
file with another Ada program compiled with another compiler.
This would work well in C, because you would typically use an enum
with explicit assignment of values. Now, I am aware that in C, the tag
field is not mandatory, so it's not really a fair comparison, but it
means that you cannot output the union directly. 

Yes, I am aware that it will not be portable from one kind of CPU to
another anyway, and that you can circumvent the problem by converting
to an external data representation, but there are instances where you
want to reduce the overhead as much as possible, for instance when
working in the lower layers of a DBMS.

It seems to me that in Ada, (almost) all problems can be solved,
according to the standard, but in practice, the implementations are
different enough that it does not work in some cases. In C, the
standard does not guarantee that it works, but it will, in all but a
few cases. The actual difference in terms of what is portable isn't
all that great.

That said, from my former experience with Ada, I would personally
rather build a system in Ada than in C/C++ if compilers and
development systems are available at a reasonable price. 
The project I'm working on, originally intended to use Ada (about 7
years ago), but reverted to C++ after seeing the following
difficulties:

1. EVERY potential customer asked why it was written Ada, and not in C++, and
it was clearly seen as a serious drawback.
2. Compilers very very expensive, even compared to C++.
3. Compilers were not available for all the target operating
systems. (it turned out that we now use only Unix anyway, but that's
another story)

I am still convinced that it would have been better to use Ada. We
have had a fair share of bugs which would typically not have occured
if we were using Ada, especially in the homegrown multi-tasking
system. However, from measurements I have been doing, the homegrown
multitasking is also very much faster than using Ada tasks. Of course,
we could avoid using Ada tasks, but then much (not all) of the benefit
of Ada would disappear as well.  And in case you wonder, the task
switching time becomes very significant when you are running 100 -
1000 transactions per second.  But I would rather get it right first,
then optimize.

Re: Why Ada is not the Commercial Lang of Choice

[Ken Garlington]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:
> 
> Ken Garlington <Kennie.E.Garlington@lmco.com> writes:
> 
> >
> > Paul Van Bellinghen writes:
> > >
> > > Claim:
> > > It is much easier in C, for example, to output a data word to
> > > an I/O device that is memory mapped.
> > >
> > > Supporting Evidence:
> > > 1       One need only define a pointer
> > > 2       and assign it the memory mapped address
> > > 3       then store the desired data value to the contents of the pointer.
> >
> > In Ada, something like:
> >
> >    Memory_Mapped_Address : constant := 16#0100040#;
> >
> >    Memory_Mapped_Value : Interfaces.C.unsigned; -- just to keep type
> > compatibility
> >    for Memory_Mapped_Value'Address use Memory_Mapped_Address;
> >
> >    Memory_Mapped_Value := 16#00344556#;
> >
> > And the neat thing is, Memory_Mapped_Value will always be mapped to the
> > area of memory you want! No worries about your pointer being corrupted
> > --
> > because there isn't a pointer! Who knows, now that the compiler knows
> > that the address is fixed, you might even get more efficient code!
> 
> You don't need the pointer in C either. Just
> 
> #define Memory_Mapped_Value (*(int *) 0x0100040)
> 
> Memory_Mapped_Value = 0x00344556;
> 
> has the same effect, except for the scope of Memory_Mapped_Value.

Then why did the original poster include it? Maybe he wanted to
be proven wrong :)

Claim #2: As is usually the case, trying to prove the superiority
of one language vs. another by small variantions in the number of
lines of code required to implement a capability is a waste
of time.


> 
> >
> > >
> > > Example:
> > >  #define mem_map_addr B0100040
> > >  unsigned int *p;
> > >
> > >  p = (unsigned int *) mem_map_addr;
> > >
> > >  *p = 0x00344556;
> >
> > Claim: The Ada does the same thing, in the same number of lines, and it
> > does it
> > more safety, more clearly, and (gasp) possibly more efficiently!
> >
> > --
> > 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
> 
> Btw., I have been thinking about not being able to assign an explicit
> value to the tag of a discriminant union. It will certainly be a
> problem, if you intend to store your unions in a file, and read this
> file with another Ada program compiled with another compiler.
> This would work well in C, because you would typically use an enum
> with explicit assignment of values. Now, I am aware that in C, the tag
> field is not mandatory, so it's not really a fair comparison, but it
> means that you cannot output the union directly.
> 
> Yes, I am aware that it will not be portable from one kind of CPU to
> another anyway, and that you can circumvent the problem by converting
> to an external data representation, but there are instances where you
> want to reduce the overhead as much as possible, for instance when
> working in the lower layers of a DBMS.
> 
> It seems to me that in Ada, (almost) all problems can be solved,
> according to the standard, but in practice, the implementations are
> different enough that it does not work in some cases. In C, the
> standard does not guarantee that it works, but it will, in all but a
> few cases. The actual difference in terms of what is portable isn't
> all that great.
> 
> That said, from my former experience with Ada, I would personally
> rather build a system in Ada than in C/C++ if compilers and
> development systems are available at a reasonable price.
> The project I'm working on, originally intended to use Ada (about 7
> years ago), but reverted to C++ after seeing the following
> difficulties:
> 
> 1. EVERY potential customer asked why it was written Ada, and not in C++, and
> it was clearly seen as a serious drawback.
> 2. Compilers very very expensive, even compared to C++.
> 3. Compilers were not available for all the target operating
> systems. (it turned out that we now use only Unix anyway, but that's
> another story)
> 
> I am still convinced that it would have been better to use Ada. We
> have had a fair share of bugs which would typically not have occured
> if we were using Ada, especially in the homegrown multi-tasking
> system. However, from measurements I have been doing, the homegrown
> multitasking is also very much faster than using Ada tasks. Of course,
> we could avoid using Ada tasks, but then much (not all) of the benefit
> of Ada would disappear as well.  And in case you wonder, the task
> switching time becomes very significant when you are running 100 -
> 1000 transactions per second.  But I would rather get it right first,
> then optimize.

--
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: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Paul says

<<1. Ada is not and never was a programmer's language. It was never
meant to be. It was imposed upon companies that the DOD contracts in
an effort  to create more reliable (i.e. bug free) products. They saw
how much time and money was spent in fixing problems after a system
was delivered and operational in the field. It is excessivly
type-casted and cumbersome to use.>>

This is of course complete nonsense. Many programmers find Ada a very
comfortable language to program in. 

More significant is that to my taste, any programmer who finds Ada to
be excessively strongly typed is just the sort of programmer I do ONT
NOT want on any project I am involved in.

I think in practice that a strong point of Ada is that it tends to filter
out the hacking mentality that gives rise to such viewpoints. It is hard
to quantify this effect, but it is definitely significant.

Re: Why Ada is not the Commercial Lang of Choice

[nma123]

>
>Paul says
>
><<1. Ada is not and never was a programmer's language. It was never
>meant to be. It was imposed upon companies that the DOD contracts in
>an effort  to create more reliable (i.e. bug free) products. They saw
>how much time and money was spent in fixing problems after a system
>was delivered and operational in the field. It is excessivly
>type-casted and cumbersome to use.>>
>

Let me hear you say again that after you wasted 2 days chasing a bug
in someone's C program that would never have happend in an
Ada program becuase the Ada compiler will let you know about it right
away.

If, for a period of one week,  I can collect one cent for each day wasted by 
every C programmer chasing bugs that would otherwise be cought by 
an Ada compiler, I bet I would have enough money collected to balance 
the United States fedral budget, or come close to doing so. 

But again, if every one used a strong typed language such as Ada, there 
will be little bugs to fix, and for those programmers  who make their livining 
fixing and maintaining  others' C code will start having a hard time finding 
more work to do :)

so please every one, keep writing in C  !

Nasser

Re: Why Ada is not the Commercial Lang of Choice

[Adam Beneschan]

>
>Paul says
>
><<1. Ada is not and never was a programmer's language. It was never
>meant to be. It was imposed upon companies that the DOD contracts in
>an effort  to create more reliable (i.e. bug free) products. They saw
>how much time and money was spent in fixing problems after a system
>was delivered and operational in the field. It is excessivly
>type-casted and cumbersome to use.>>

The above statement is curious.  It implies that there's a dichotomy
between a "programmer's language" and a "language designed to create
more reliable products."  The implication of this is that a
"programmer" is not concerned with how reliable his or her programs
are. 

I beg to differ.  To me, a "real" programmer (or, should I say, a
professional programmer) does care about reliability, and has no
desire to produce a program that has bugs in it.  A real programmer,
therefore, should IMHO appreciate a language that assists her or him
in creating more reliable software.  So, if the correct terminology is
used, the first statement above should really read:

"Ada is not and never was a hacker's language."

I think everyone can agree with that.

                                -- Adam

(P.S. I do not mean to insult those of you who are programmers at
heart, who would like to write bug-free software, but can't because
your company says it has to go out the door yesterday whether it works
or not.)

Re: Why Ada is not the Commercial Lang of Choice

[Nick Roberts]

Paul Van Bellinghen <pvanbell@mhv.net> wrote in article
<33a1c14d.155787285@news.mhv.net> reasons for C being more successful than
Ada for embedded applications.

You concentrate on an example of a technical advantage of C over Ada, and
you present this example well. I feel many Ada advocates would argue that
the Ada way you outlined was better (for being more explicit) than the C
code. However, I feel sure that the C code would be just as acceptable
provided it was documented sufficiently (perhaps with a good comment), and
I'm sure many programmers would be irked by the more cumbersome methods
imposed by Ada.

However, I do feel that the predominant reasons for C achieving greater
success than Ada, both in the embedded arena and everywhere else, are
commercial, not technical. C is a more pragmatic language than Ada: it is
easier (cheaper) to implement a C compiler than an Ada compiler. It has
also had a long head start (at least ten years, I would reckon) in the
market place.

I think it is a little premature to 'write off' Ada just yet!

Nick.

Re: Why Ada is not the Commercial Lang of Choice

[Peter Hermann]

Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:
> I'm sure many programmers would be irked by the more cumbersome methods
> imposed by Ada.

The opposite is true. You are displaying complete lack of experience.
This is not meant as an insult but should be read in a technical sense,
i.e. please don't worry, be happy.

The reason why I am posting this is simply my sharp disagreement with
the word "cumbersome". This can't be left unanswered.

Experience indicates that in particular those people with long-term
experience in very large software systems with those worn-out programming
languages like Fortran or C are deeply appreciating Ada's inherent
active support for bug free code. Being well introduced into the language,
there are no obstacles in the way to smoothly and easily write down
correct code. The only "cumbersome" thing is, that Ada forces to 
do the things right just from the beginning.
There is nearly no freedom left to initially implant unintentional bugs,
therefore Ada does not donate the great satisfaction produced by
the time-consuming process of bug searching. However,
many beginner-programmers need this narcotic and I recommend them
to program in C or Fortran: Yes, it is a great feeling when
a bug is found as a result of a day- or week-long search --
The feeling is "I did a great job", notwithstanding the genius 
(which I absolutely admit is there)
may not have been spent for the project's aim.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Nick Roberts said

<<> I'm sure many programmers would be irked by the more cumbersome methods
> imposed by Ada.>>

That is probably true, if by cubersome, you mean the requirement to be
clearer about what you are doing, especially if you are doing nasty low
level things.

But is this a negative or positive indication?

If programmers in general did a wonderful job with existing tools of generating
reliable applications that were on time and on budget, and easy to maintain,
then we would question changes in methods that might irk them.

But since, at least in my judgment, this is not the case, perhaps a little
irking is most appropriate.

After all, when C started to be used widely, there was an army of assembly
language programmers who were irked by the cumbersome stuff in C.

One of the advantages of Ada is that it does prove irksome to those who
insist on hacking away at an excessively low level. Some programmers
adjust, some stay irked. The latter depart, quality of code improves :-)

Re: Why Ada is not the Commercial Lang of Choice

[Van Snyder]

In article <5o84gh$1a0s@info4.rus.uni-stuttgart.de>, ica2ph@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:

|> Experience indicates that in particular those people with long-term
|> experience in very large software systems with those worn-out programming
|> languages like Fortran or C ...

Do you know that Eisenhower is no longer the president of U.S.A, and that
Adenauer is dead?

Fortran 95 is _very_different_ from Fortran 66 in the respects about which you
are probably complaining (but it's hard to tell, because you offer no
specifics).

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Why Ada is not the Commercial Lang of Choice

[Robert Dewar]

Van Snyder says

<<Fortran 95 is _very_different_ from Fortran 66 in the respects about which you
are probably complaining (but it's hard to tell, because you offer no
specifics).
>>

Right, and naturally the use of Fortran 95 is pretty much universal among
Fortran programmers at this stage!

:-) (for the sarcasm detection impaired :-)

Re: Why Ada is not the Commercial Lang of Choice

[Ralph Paul]

Robert Dewar wrote:
> 
> Van Snyder says
> 
> <<Fortran 95 is _very_different_ from Fortran 66 in the respects about which you
> are probably complaining (but it's hard to tell, because you offer no
> specifics).
> >>
> 
> Right, and naturally the use of Fortran 95 is pretty much universal among
> Fortran programmers at this stage!
> 
> :-) (for the sarcasm detection impaired :-)

Fortran 95 is universal especially with those punching card trained
folks on VMS, .... (:-). Boy do I love those old timer programs =:-( 
( Fortran 4 sounds about right, maybe ?)

The problem with Fortan9x is not so much with language but with the fact
that
most people can still use like Fortran 77. ( Just my daily experience in
a big German aerospace company). 
More important than the language itself, whether it is Ada, Java,
Python,
C++,... , is the need to teach people to apply software engineering
skills.
Learning Ada seems to help in that respect (:-).

Regards,

Ralph Paul

( ex University of Stuttgart but still trying to convince people of the
  benefits of software engineering with Ada (:-) )

Re: Why Ada is not the Commercial Lang of Choice

[Joerg Rodemann]

Dear readers!

I would like to add some comments:

Ralph Paul (repaul@ibm.net) wrote:
> > Right, and naturally the use of Fortran 95 is pretty much universal among
> > Fortran programmers at this stage!

> Fortran 95 is universal especially with those punching card trained
> folks on VMS, .... (:-). Boy do I love those old timer programs =:-( 
> ( Fortran 4 sounds about right, maybe ?)

I didn't know there are already Fortran 95 Compilers...has that standard
been defined in the meanwhile?

> The problem with Fortan9x is not so much with language but with the fact
> that
> most people can still use like Fortran 77. ( Just my daily experience in
> a big German aerospace company). 

There was an article in the last issue of Supercomputing about removing
old features from Fortran to get a really modern and useful language: F. 
I ask thee, why aren't they just using something that already exists, is
tested and has a lot more feature they can imagine at the moment? My opinion
on this is: use Fortran-77 where you have old code...for new things use a
more modern approach: Software Engineering techniques plus a proper language.
(Which might be Ada or something else...no, not C++, at least not before
every compiler is ISO conformant! The missing features do leave me with a lot
of problems an no-elegant solutions. Java may be suitable for small 
projects.)

> C++,... , is the need to teach people to apply software engineering
> skills.
> Learning Ada seems to help in that respect (:-).

Agreed: my experience during my studies was that students are introduced to
those old-fashioned hacking languages like Fortran and C. Although Fortran
may be quite suitable for smaller numerics or when you want to use existing
libraries. But you need months to remove the students habits they gained with
these languages. I believe the use of a strongly typed language with 
facilities for modularization would support the students to develop a sense
for simple and maintainable solutions. Ada might be a proper beginner's 
language (although it is a big language, at the beginning the teacher should
be able to restrict the needed knowledge.) as well as Modula-2/3 or Oberon.
Java seems not very good to me for a beginners puproses because it leeds
to inlinining of everything if they switch to C or C++. I like separation
of spec and body pretty much.

Yours

Joerg.

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-----------------------------+-----------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Why Ada is not the Commercial Lang of Choice

[Joerg Rodemann]

Dear readers!

Oops! I have correct myself a little bit:

Joerg Rodemann (rodemann@mathematik.uni-ulm.de) wrote:
> There was an article in the last issue of Supercomputing about removing
> old features from Fortran to get a really modern and useful language: F. 

It was not in Supercomputing but in "Scientific Computing".

Sorry

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-----------------------------+-----------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Why Ada is not the Commercial Lang of Choice

[Ralph Paul]

Joerg Rodemann wrote:

> I didn't know there are already Fortran 95 Compilers...has that standard
> been defined in the meanwhile?

To be honest I don't know either if it has become a standard. I just
continued
what Robert Dewar started (;-).

 
> > C++,... , is the need to teach people to apply software engineering
> > skills.
> > Learning Ada seems to help in that respect (:-).
> 
> Agreed: my experience during my studies was that students are introduced to
> those old-fashioned hacking languages like Fortran and C. Although Fortran
> may be quite suitable for smaller numerics or when you want to use existing
> libraries. But you need months to remove the students habits they gained with
> these languages. I believe the use of a strongly typed language with
> facilities for modularization would support the students to develop a sense
> for simple and maintainable solutions. Ada might be a proper beginner's
> language (although it is a big language, at the beginning the teacher should
> be able to restrict the needed knowledge.) as well as Modula-2/3 or Oberon.
> Java seems not very good to me for a beginners puproses because it leeds
> to inlinining of everything if they switch to C or C++. I like separation
> of spec and body pretty much.
> 

I agree with you absolutly. The problem at my company is that we are
under
such tremendous time pressure ( and political pressure too -- see
Spiegel article)
that I would not even get a chance to request reimplementing existing
software in
Ada95. Also aerospace engineers tend to be really conservative when it
comes
to their favorite tool (Fortran). 

It's just very strange that engineers are trained a long time in
applying
engineering methods to find solutions to new problems but when it comes
to
solving software problems there is almost no training. Most of the time
it's
more or less chaotic. Therefore I love Ada becaus along with learning a
new
language you learn a little bit about software engineering. Even if you
use
Fortran afterwards. Learning Ada can sort of open your eyes.

( Hope you understand my gospel (;-))


Later,

Ralph Paul

Re: Why Ada is not the Commercial Lang of Choice

[Steve Doiel]

In article <33a1c14d.155787285@news.mhv.net>, pvanbell@mhv.net says...
>
>I've been a real-time embeded Software Engineer since 1975. I've used
>assembly,Pascal & Fortran (not in real-time), C, and now Ada. I think
>that there are basicly two reasons why Ada did not replace C as the
>real-time embeded language of choice - in the commercial world and
>recently in the military. 
>
>
>1. Ada is not and never was a programmer's language...[snip]
>
>2. Ada is realy a high level language...[snip]

I disagree with both statements (other replies give specific examples).

I attribute Ada's lack of market penetration to it's lack (until recently)
of inexpensive development tools.

For the past 15-20 years you could buy inexpensive Pascal and C compilers
from a number of vendors.  While Ada has been around for quite some time
now, until recently it was just too expensive for the casual user.  It has
only been since the advent of GNAT that I have even looked seriously at
the language.

IMHO
Steve Doiel

Re: Why Ada is not the Commercial Lang of Choice

[Anonymous]

<33a1c14d.155787285@news.mhv.net>

On 19 Jun 1997 02:00:24 GMT, steved@pacifier.com (Steve Doiel) wrote:

> In article <33a1c14d.155787285@news.mhv.net>, pvanbell@mhv.net says...
> >
> >I've been a real-time embeded Software Engineer since 1975. I've used
> >assembly,Pascal & Fortran (not in real-time), C, and now Ada. I think
> >that there are basicly two reasons why Ada did not replace C as the
> >real-time embeded language of choice - in the commercial world and
> >recently in the military. 
> >
> >
> >1. Ada is not and never was a programmer's language...[snip]
> >
> >2. Ada is realy a high level language...[snip]
> 
> I disagree with both statements (other replies give specific examples).

I disagree with your disagreement with 2. Ada is really a high-level
language, and C really is a low-level language. Capers Jones has
classified languages as low, middle, and high level based on the average
number of statements need to code a function point. C, at >100, is a
low-level language. Ada, at < 50, is a high-level language.

Maybe you're disagreeing that this is a reason for Ada not being popular
..

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: Why Ada is not the Commercial Lang of Choice

[Shmuel (Seymour J.) Metz]

Paul Van Bellinghen wrote:
> 
> 1. Ada is not and never was a programmer's language. 

I've only been programming since 1960, but IMHO Ada is much more of a
programmer's
language than is C. At least Ada 83 is; I know 95 only from reading,
which often doesn't convey the full flavor. Please don't confuse
"programmer" with "hacker"; a programmer is concerned with issues of
maintainability and code reuse.

They started us on machine language so that we would appreciate the
assembler, and
ever since then I have felt that the computer should relieve the
programmer of the
grunt work as much as the state of the art allows.

Now, I am not saying that Ada is my favorite language (I prefer PL/I),
or that it is
universal (ICON and SETL do much better in theri respective domains), or
that Ada is
perfect (I could criticize it at great length.) But it *is* very much a
programmers language.

> It is excessivly type-casted and cumbersome to use.

"Execessively" is such a subjective term; while there may be area's
where Ada's type
rules are poorly thought out, there are areas where they could usefully
be tightened.
As for cumbersome, I found C to be far more cumbersome than Ada.
 
> 2. Ada is realy a high level language. C is more intermediate level.
> This makes C more well suited to real-time embedded systems that are
> really electronic products that use microprocessors to control
> electronic devices in a functional manner. It is much easier in C, for
> example, to output a data word to an I/O device that is memory mapped.

You mean like display buffers? I not only used Ada for that, but my Ada
version was
faster than the assembler version it replaced.
 
-- 

                        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.