* Re: Why Ada is not the Commercial Lang of Choice
@ 1997-06-18 0:00 Robert I. Eachus
1997-06-18 0:00 ` Dale Stanbrough
` (2 more replies)
0 siblings, 3 replies; 61+ messages in thread
From: Robert I. Eachus @ 1997-06-18 0:00 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 Why Ada is not the Commercial Lang of Choice Robert I. Eachus @ 1997-06-18 0:00 ` Dale Stanbrough 1997-06-19 0:00 ` Robert A Duff ` (3 more replies) 1997-06-20 0:00 ` Robert Dewar 1997-06-21 0:00 ` Keith Thompson 2 siblings, 4 replies; 61+ messages in thread From: Dale Stanbrough @ 1997-06-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 ` Dale Stanbrough @ 1997-06-19 0:00 ` Robert A Duff 1997-06-21 0:00 ` Paul Van Bellinghen 1997-06-19 0:00 ` Steve Jones - JON ` (2 subsequent siblings) 3 siblings, 1 reply; 61+ messages in thread From: Robert A Duff @ 1997-06-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-19 0:00 ` Robert A Duff @ 1997-06-21 0:00 ` Paul Van Bellinghen 1997-06-20 0:00 ` Robert Dewar 0 siblings, 1 reply; 61+ messages in thread From: Paul Van Bellinghen @ 1997-06-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-21 0:00 ` Paul Van Bellinghen @ 1997-06-20 0:00 ` Robert Dewar 1997-06-23 0:00 ` John G. Volan 0 siblings, 1 reply; 61+ messages in thread From: Robert Dewar @ 1997-06-20 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` Robert Dewar @ 1997-06-23 0:00 ` John G. Volan 1997-07-03 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 1 reply; 61+ messages in thread From: John G. Volan @ 1997-06-23 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-23 0:00 ` John G. Volan @ 1997-07-03 0:00 ` Shmuel (Seymour J.) Metz 1997-07-03 0:00 ` Robert Dewar 1997-07-04 0:00 ` Paul Van Bellinghen 0 siblings, 2 replies; 61+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-07-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-03 0:00 ` Shmuel (Seymour J.) Metz @ 1997-07-03 0:00 ` Robert Dewar 1997-07-06 0:00 ` Yasmiin S. Davis 1997-07-07 0:00 ` Shmuel (Seymour J.) Metz 1997-07-04 0:00 ` Paul Van Bellinghen 1 sibling, 2 replies; 61+ messages in thread From: Robert Dewar @ 1997-07-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-03 0:00 ` Robert Dewar @ 1997-07-06 0:00 ` Yasmiin S. Davis 1997-07-06 0:00 ` Robert Dewar 1997-07-07 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 1 reply; 61+ messages in thread From: Yasmiin S. Davis @ 1997-07-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-06 0:00 ` Yasmiin S. Davis @ 1997-07-06 0:00 ` Robert Dewar 0 siblings, 0 replies; 61+ messages in thread From: Robert Dewar @ 1997-07-06 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-03 0:00 ` Robert Dewar 1997-07-06 0:00 ` Yasmiin S. Davis @ 1997-07-07 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 0 replies; 61+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-07-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-03 0:00 ` Shmuel (Seymour J.) Metz 1997-07-03 0:00 ` Robert Dewar @ 1997-07-04 0:00 ` Paul Van Bellinghen 1997-07-13 0:00 ` Ken Mays 1 sibling, 1 reply; 61+ messages in thread From: Paul Van Bellinghen @ 1997-07-04 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-04 0:00 ` Paul Van Bellinghen @ 1997-07-13 0:00 ` Ken Mays 1997-07-13 0:00 ` Robert Munck 0 siblings, 1 reply; 61+ messages in thread From: Ken Mays @ 1997-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-13 0:00 ` Ken Mays @ 1997-07-13 0:00 ` Robert Munck 1997-07-14 0:00 ` Ken Mays 0 siblings, 1 reply; 61+ messages in thread From: Robert Munck @ 1997-07-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-13 0:00 ` Robert Munck @ 1997-07-14 0:00 ` Ken Mays 0 siblings, 0 replies; 61+ messages in thread From: Ken Mays @ 1997-07-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 ` Dale Stanbrough 1997-06-19 0:00 ` Robert A Duff @ 1997-06-19 0:00 ` Steve Jones - JON 1997-06-19 0:00 ` Peter Hermann ` (2 more replies) 1997-06-20 0:00 ` Robert Dewar 1997-06-20 0:00 ` Don Harrison 3 siblings, 3 replies; 61+ messages in thread From: Steve Jones - JON @ 1997-06-19 0:00 UTC (permalink / raw) 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. | ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-19 0:00 ` Steve Jones - JON @ 1997-06-19 0:00 ` Peter Hermann 1997-06-19 0:00 ` Anonymous 1997-07-17 0:00 ` Shmuel (Seymour J.) Metz 2 siblings, 0 replies; 61+ messages in thread From: Peter Hermann @ 1997-06-19 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-19 0:00 ` Steve Jones - JON 1997-06-19 0:00 ` Peter Hermann @ 1997-06-19 0:00 ` Anonymous 1997-07-17 0:00 ` Shmuel (Seymour J.) Metz 2 siblings, 0 replies; 61+ messages in thread From: Anonymous @ 1997-06-19 0:00 UTC (permalink / raw) <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/ ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-19 0:00 ` Steve Jones - JON 1997-06-19 0:00 ` Peter Hermann 1997-06-19 0:00 ` Anonymous @ 1997-07-17 0:00 ` Shmuel (Seymour J.) Metz 2 siblings, 0 replies; 61+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-07-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 ` Dale Stanbrough 1997-06-19 0:00 ` Robert A Duff 1997-06-19 0:00 ` Steve Jones - JON @ 1997-06-20 0:00 ` Robert Dewar 1997-06-20 0:00 ` Don Harrison 3 siblings, 0 replies; 61+ messages in thread From: Robert Dewar @ 1997-06-20 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 ` Dale Stanbrough ` (2 preceding siblings ...) 1997-06-20 0:00 ` Robert Dewar @ 1997-06-20 0:00 ` Don Harrison 1997-06-20 0:00 ` Roy Grimm ` (4 more replies) 3 siblings, 5 replies; 61+ messages in thread From: Don Harrison @ 1997-06-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` Don Harrison @ 1997-06-20 0:00 ` Roy Grimm 1997-06-20 0:00 ` Donovan Baarda ` (3 subsequent siblings) 4 siblings, 0 replies; 61+ messages in thread From: Roy Grimm @ 1997-06-20 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` Don Harrison 1997-06-20 0:00 ` Roy Grimm @ 1997-06-20 0:00 ` Donovan Baarda 1997-06-20 0:00 ` Larry Kilgallen ` (2 subsequent siblings) 4 siblings, 0 replies; 61+ messages in thread From: Donovan Baarda @ 1997-06-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` Don Harrison 1997-06-20 0:00 ` Roy Grimm 1997-06-20 0:00 ` Donovan Baarda @ 1997-06-20 0:00 ` Larry Kilgallen 1997-06-20 0:00 ` Nick Leaton 1997-06-23 0:00 ` Don Harrison 1997-06-23 0:00 ` Robert Dewar 1997-06-23 0:00 ` Joachim Durchholz 4 siblings, 2 replies; 61+ messages in thread From: Larry Kilgallen @ 1997-06-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` Larry Kilgallen @ 1997-06-20 0:00 ` Nick Leaton 1997-06-23 0:00 ` Don Harrison 1 sibling, 0 replies; 61+ messages in thread From: Nick Leaton @ 1997-06-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` Larry Kilgallen 1997-06-20 0:00 ` Nick Leaton @ 1997-06-23 0:00 ` Don Harrison 1997-06-24 0:00 ` Bertrand Meyer 1 sibling, 1 reply; 61+ messages in thread From: Don Harrison @ 1997-06-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-23 0:00 ` Don Harrison @ 1997-06-24 0:00 ` Bertrand Meyer 1997-06-24 0:00 ` Nick Leaton 1997-07-22 0:00 ` Dr. Vladimir Il'ich Fomin 0 siblings, 2 replies; 61+ messages in thread From: Bertrand Meyer @ 1997-06-24 0:00 UTC (permalink / raw) 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 == ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-24 0:00 ` Bertrand Meyer @ 1997-06-24 0:00 ` Nick Leaton 1997-07-22 0:00 ` Dr. Vladimir Il'ich Fomin 1 sibling, 0 replies; 61+ messages in thread From: Nick Leaton @ 1997-06-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-24 0:00 ` Bertrand Meyer 1997-06-24 0:00 ` Nick Leaton @ 1997-07-22 0:00 ` Dr. Vladimir Il'ich Fomin 1 sibling, 0 replies; 61+ messages in thread From: Dr. Vladimir Il'ich Fomin @ 1997-07-22 0:00 UTC (permalink / raw) 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'::::.:.... ::::::::.,' `:::::... `---____-' `-____---' ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` Don Harrison ` (2 preceding siblings ...) 1997-06-20 0:00 ` Larry Kilgallen @ 1997-06-23 0:00 ` Robert Dewar 1997-06-24 0:00 ` Don Harrison 1997-06-23 0:00 ` Joachim Durchholz 4 siblings, 1 reply; 61+ messages in thread From: Robert Dewar @ 1997-06-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-23 0:00 ` Robert Dewar @ 1997-06-24 0:00 ` Don Harrison 1997-06-24 0:00 ` Robert Dewar 0 siblings, 1 reply; 61+ messages in thread From: Don Harrison @ 1997-06-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-24 0:00 ` Don Harrison @ 1997-06-24 0:00 ` Robert Dewar 0 siblings, 0 replies; 61+ messages in thread From: Robert Dewar @ 1997-06-24 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` Don Harrison ` (3 preceding siblings ...) 1997-06-23 0:00 ` Robert Dewar @ 1997-06-23 0:00 ` Joachim Durchholz 4 siblings, 0 replies; 61+ messages in thread From: Joachim Durchholz @ 1997-06-23 0:00 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 Why Ada is not the Commercial Lang of Choice Robert I. Eachus 1997-06-18 0:00 ` Dale Stanbrough @ 1997-06-20 0:00 ` Robert Dewar 1997-06-21 0:00 ` Keith Thompson 2 siblings, 0 replies; 61+ messages in thread From: Robert Dewar @ 1997-06-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 Why Ada is not the Commercial Lang of Choice Robert I. Eachus 1997-06-18 0:00 ` Dale Stanbrough 1997-06-20 0:00 ` Robert Dewar @ 1997-06-21 0:00 ` Keith Thompson 1997-06-21 0:00 ` Robert Dewar 1997-06-28 0:00 ` Robert I. Eachus 2 siblings, 2 replies; 61+ messages in thread From: Keith Thompson @ 1997-06-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-21 0:00 ` Keith Thompson @ 1997-06-21 0:00 ` Robert Dewar 1997-06-24 0:00 ` Ken Garlington 1997-06-28 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 61+ messages in thread From: Robert Dewar @ 1997-06-21 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-21 0:00 ` Robert Dewar @ 1997-06-24 0:00 ` Ken Garlington 1997-06-24 0:00 ` Robert Dewar 0 siblings, 1 reply; 61+ messages in thread From: Ken Garlington @ 1997-06-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-24 0:00 ` Ken Garlington @ 1997-06-24 0:00 ` Robert Dewar 0 siblings, 0 replies; 61+ messages in thread From: Robert Dewar @ 1997-06-24 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-21 0:00 ` Keith Thompson 1997-06-21 0:00 ` Robert Dewar @ 1997-06-28 0:00 ` Robert I. Eachus 1997-06-28 0:00 ` Robert Dewar 1 sibling, 1 reply; 61+ messages in thread From: Robert I. Eachus @ 1997-06-28 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-28 0:00 ` Robert I. Eachus @ 1997-06-28 0:00 ` Robert Dewar 0 siblings, 0 replies; 61+ messages in thread From: Robert Dewar @ 1997-06-28 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Why Ada is not the Commercial Lang of Choice @ 1997-06-13 0:00 Paul Van Bellinghen 1997-06-17 0:00 ` Robert Dewar ` (4 more replies) 0 siblings, 5 replies; 61+ messages in thread From: Paul Van Bellinghen @ 1997-06-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-13 0:00 Paul Van Bellinghen @ 1997-06-17 0:00 ` Robert Dewar 1997-06-20 0:00 ` nma123 1997-06-17 0:00 ` Dale Stanbrough ` (3 subsequent siblings) 4 siblings, 1 reply; 61+ messages in thread From: Robert Dewar @ 1997-06-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-17 0:00 ` Robert Dewar @ 1997-06-20 0:00 ` nma123 1997-06-24 0:00 ` Adam Beneschan 0 siblings, 1 reply; 61+ messages in thread From: nma123 @ 1997-06-20 0:00 UTC (permalink / raw) > >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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-20 0:00 ` nma123 @ 1997-06-24 0:00 ` Adam Beneschan 0 siblings, 0 replies; 61+ messages in thread From: Adam Beneschan @ 1997-06-24 0:00 UTC (permalink / raw) > >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.) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-13 0:00 Paul Van Bellinghen 1997-06-17 0:00 ` Robert Dewar @ 1997-06-17 0:00 ` Dale Stanbrough 1997-06-17 0:00 ` Robert Munck 1997-06-18 0:00 ` Ken Garlington 1997-06-18 0:00 ` Nick Roberts ` (2 subsequent siblings) 4 siblings, 2 replies; 61+ messages in thread From: Dale Stanbrough @ 1997-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-17 0:00 ` Dale Stanbrough @ 1997-06-17 0:00 ` Robert Munck 1997-06-18 0:00 ` Ken Garlington 1 sibling, 0 replies; 61+ messages in thread From: Robert Munck @ 1997-06-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-17 0:00 ` Dale Stanbrough 1997-06-17 0:00 ` Robert Munck @ 1997-06-18 0:00 ` Ken Garlington 1997-06-19 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1 sibling, 1 reply; 61+ messages in thread From: Ken Garlington @ 1997-06-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 ` Ken Garlington @ 1997-06-19 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-06-19 0:00 ` Ken Garlington 0 siblings, 1 reply; 61+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-06-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-19 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-06-19 0:00 ` Ken Garlington 0 siblings, 0 replies; 61+ messages in thread From: Ken Garlington @ 1997-06-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-13 0:00 Paul Van Bellinghen 1997-06-17 0:00 ` Robert Dewar 1997-06-17 0:00 ` Dale Stanbrough @ 1997-06-18 0:00 ` Nick Roberts 1997-06-18 0:00 ` Peter Hermann 1997-06-19 0:00 ` Steve Doiel 1997-07-22 0:00 ` Shmuel (Seymour J.) Metz 4 siblings, 1 reply; 61+ messages in thread From: Nick Roberts @ 1997-06-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 ` Nick Roberts @ 1997-06-18 0:00 ` Peter Hermann 1997-06-20 0:00 ` Robert Dewar 1997-06-25 0:00 ` Van Snyder 0 siblings, 2 replies; 61+ messages in thread From: Peter Hermann @ 1997-06-18 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 ` Peter Hermann @ 1997-06-20 0:00 ` Robert Dewar 1997-06-25 0:00 ` Van Snyder 1 sibling, 0 replies; 61+ messages in thread From: Robert Dewar @ 1997-06-20 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-18 0:00 ` Peter Hermann 1997-06-20 0:00 ` Robert Dewar @ 1997-06-25 0:00 ` Van Snyder 1997-06-26 0:00 ` Robert Dewar 1 sibling, 1 reply; 61+ messages in thread From: Van Snyder @ 1997-06-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-25 0:00 ` Van Snyder @ 1997-06-26 0:00 ` Robert Dewar 1997-06-30 0:00 ` Ralph Paul 0 siblings, 1 reply; 61+ messages in thread From: Robert Dewar @ 1997-06-26 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-26 0:00 ` Robert Dewar @ 1997-06-30 0:00 ` Ralph Paul 1997-07-02 0:00 ` Joerg Rodemann 0 siblings, 1 reply; 61+ messages in thread From: Ralph Paul @ 1997-06-30 0:00 UTC (permalink / raw) 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 (:-) ) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-30 0:00 ` Ralph Paul @ 1997-07-02 0:00 ` Joerg Rodemann 1997-07-02 0:00 ` Ralph Paul 1997-07-02 0:00 ` Joerg Rodemann 0 siblings, 2 replies; 61+ messages in thread From: Joerg Rodemann @ 1997-07-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-02 0:00 ` Joerg Rodemann @ 1997-07-02 0:00 ` Ralph Paul 1997-07-02 0:00 ` Joerg Rodemann 1 sibling, 0 replies; 61+ messages in thread From: Ralph Paul @ 1997-07-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-07-02 0:00 ` Joerg Rodemann 1997-07-02 0:00 ` Ralph Paul @ 1997-07-02 0:00 ` Joerg Rodemann 1 sibling, 0 replies; 61+ messages in thread From: Joerg Rodemann @ 1997-07-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-13 0:00 Paul Van Bellinghen ` (2 preceding siblings ...) 1997-06-18 0:00 ` Nick Roberts @ 1997-06-19 0:00 ` Steve Doiel 1997-06-19 0:00 ` Anonymous 1997-07-22 0:00 ` Shmuel (Seymour J.) Metz 4 siblings, 1 reply; 61+ messages in thread From: Steve Doiel @ 1997-06-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-19 0:00 ` Steve Doiel @ 1997-06-19 0:00 ` Anonymous 0 siblings, 0 replies; 61+ messages in thread From: Anonymous @ 1997-06-19 0:00 UTC (permalink / raw) <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/ ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Why Ada is not the Commercial Lang of Choice 1997-06-13 0:00 Paul Van Bellinghen ` (3 preceding siblings ...) 1997-06-19 0:00 ` Steve Doiel @ 1997-07-22 0:00 ` Shmuel (Seymour J.) Metz 4 siblings, 0 replies; 61+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-07-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~1997-07-22 0:00 UTC | newest] Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-06-18 0:00 Why Ada is not the Commercial Lang of Choice Robert I. Eachus 1997-06-18 0:00 ` Dale Stanbrough 1997-06-19 0:00 ` Robert A Duff 1997-06-21 0:00 ` Paul Van Bellinghen 1997-06-20 0:00 ` Robert Dewar 1997-06-23 0:00 ` John G. Volan 1997-07-03 0:00 ` Shmuel (Seymour J.) Metz 1997-07-03 0:00 ` Robert Dewar 1997-07-06 0:00 ` Yasmiin S. Davis 1997-07-06 0:00 ` Robert Dewar 1997-07-07 0:00 ` Shmuel (Seymour J.) Metz 1997-07-04 0:00 ` Paul Van Bellinghen 1997-07-13 0:00 ` Ken Mays 1997-07-13 0:00 ` Robert Munck 1997-07-14 0:00 ` Ken Mays 1997-06-19 0:00 ` Steve Jones - JON 1997-06-19 0:00 ` Peter Hermann 1997-06-19 0:00 ` Anonymous 1997-07-17 0:00 ` Shmuel (Seymour J.) Metz 1997-06-20 0:00 ` Robert Dewar 1997-06-20 0:00 ` Don Harrison 1997-06-20 0:00 ` Roy Grimm 1997-06-20 0:00 ` Donovan Baarda 1997-06-20 0:00 ` Larry Kilgallen 1997-06-20 0:00 ` Nick Leaton 1997-06-23 0:00 ` Don Harrison 1997-06-24 0:00 ` Bertrand Meyer 1997-06-24 0:00 ` Nick Leaton 1997-07-22 0:00 ` Dr. Vladimir Il'ich Fomin 1997-06-23 0:00 ` Robert Dewar 1997-06-24 0:00 ` Don Harrison 1997-06-24 0:00 ` Robert Dewar 1997-06-23 0:00 ` Joachim Durchholz 1997-06-20 0:00 ` Robert Dewar 1997-06-21 0:00 ` Keith Thompson 1997-06-21 0:00 ` Robert Dewar 1997-06-24 0:00 ` Ken Garlington 1997-06-24 0:00 ` Robert Dewar 1997-06-28 0:00 ` Robert I. Eachus 1997-06-28 0:00 ` Robert Dewar -- strict thread matches above, loose matches on Subject: below -- 1997-06-13 0:00 Paul Van Bellinghen 1997-06-17 0:00 ` Robert Dewar 1997-06-20 0:00 ` nma123 1997-06-24 0:00 ` Adam Beneschan 1997-06-17 0:00 ` Dale Stanbrough 1997-06-17 0:00 ` Robert Munck 1997-06-18 0:00 ` Ken Garlington 1997-06-19 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-06-19 0:00 ` Ken Garlington 1997-06-18 0:00 ` Nick Roberts 1997-06-18 0:00 ` Peter Hermann 1997-06-20 0:00 ` Robert Dewar 1997-06-25 0:00 ` Van Snyder 1997-06-26 0:00 ` Robert Dewar 1997-06-30 0:00 ` Ralph Paul 1997-07-02 0:00 ` Joerg Rodemann 1997-07-02 0:00 ` Ralph Paul 1997-07-02 0:00 ` Joerg Rodemann 1997-06-19 0:00 ` Steve Doiel 1997-06-19 0:00 ` Anonymous 1997-07-22 0:00 ` Shmuel (Seymour J.) Metz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox