* Re: Why don't large companies use Ada? @ 1994-12-06 13:06 Paige Vinall 1994-12-07 14:15 ` Norman H. Cohen 1994-12-09 2:31 ` Why don't large companies use Ada? Michael Feldman 0 siblings, 2 replies; 32+ messages in thread From: Paige Vinall @ 1994-12-06 13:06 UTC (permalink / raw) In INFO-ADA Digest - 5 Dec 1994 (item 11)No. Michael Feldman <mfeldman@SEAS.GWU .EDU> writes: >Yes. > >But unless I mis-read the post from the IBM chap the other day, >ISUB does more than logically swap the indices, it actually >transposes the array. I don't think I kept that post, but I do >think that's what he said. > If an ISUB dfined array is passed to a procedure, PL/I will compute an image of it. >Has PL/1 supported ISUB all along? I do not remember it from my >PL/1 days 20 or so years ago. I think so. Paige Vinall - PL/I Development Manager, IBM Internet: vinall@vnet.ibm.com, Phone: (408) 463-2106 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Why don't large companies use Ada? 1994-12-06 13:06 Why don't large companies use Ada? Paige Vinall @ 1994-12-07 14:15 ` Norman H. Cohen 1994-12-10 20:55 ` Array mappings Michael Feldman 1994-12-09 2:31 ` Why don't large companies use Ada? Michael Feldman 1 sibling, 1 reply; 32+ messages in thread From: Norman H. Cohen @ 1994-12-07 14:15 UTC (permalink / raw) In article <9412061309.AA02026@ajpo.sei.cmu.edu>, Paige Vinall <vinall@VNET.IBM.COM> writes: |> In INFO-ADA Digest - 5 Dec 1994 (item 11)No. Michael Feldman <mfeldman@SEAS.GWU |> .EDU> writes: |> >Yes. |> > |> >But unless I mis-read the post from the IBM chap the other day, |> >ISUB does more than logically swap the indices, it actually |> >transposes the array. I don't think I kept that post, but I do |> >think that's what he said. |> > |> |> If an ISUB dfined array is passed to a procedure, PL/I |> will compute an image of it. The way to use ISUB when passing PL/I arrays to Fortran (or, as it was called back then, FORTRAN) is to declare an ordinary array that is filled in column-major (i.e., as Fortran expects it). If, inisde the PL/I program, you want to view the data as arranged in row-major order, then declare an ISUB that creates a virtual transposed copy of the array. It is the ordinary array that is passed to Fortran, so it is unnecessary to create a transposed copy of the array. (If the array is to be passed from one PL/I procedure to another, the ordinary array can be passed and the ISUB declaration repeated in the called procedure.) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* Array mappings 1994-12-07 14:15 ` Norman H. Cohen @ 1994-12-10 20:55 ` Michael Feldman 1994-12-13 15:01 ` Norman H. Cohen 0 siblings, 1 reply; 32+ messages in thread From: Michael Feldman @ 1994-12-10 20:55 UTC (permalink / raw) In article <3c4g1u$uh6@watnews1.watson.ibm.com>, Norman H. Cohen <ncohen@watson.ibm.com> wrote: >The way to use ISUB when passing PL/I arrays to Fortran (or, as it was >called back then, FORTRAN) is to declare an ordinary array that is filled >in column-major (i.e., as Fortran expects it). If, inisde the PL/I >program, you want to view the data as arranged in row-major order, then >declare an ISUB that creates a virtual transposed copy of the array. ^^^^^^^ OK, this makes it clear. >It is the ordinary array that is passed to Fortran, so it is unnecessary >to create a transposed copy of the array. (If the array is to be passed >from one PL/I procedure to another, the ordinary array can be passed and >the ISUB declaration repeated in the called procedure.) Aha. This is nice stuff. Perhaps I moved to other things before this was implemented (or at least well-known) in PL/I. That this was implemented in PL/I in the mid-70's, or even earlier, a fact presumably known to the Ada 83 designers, makes me even more curious why a similar facility was not provided in Ada 83. pragma Interface handles the subprogram interface but there is no corresponding way to handle the data structure interface. This is odd - Ada 93 deliberately leaves array mappings (like all representations) unspecified, so (presumably) as to allow flexibility in the implementations. Was a pragma equivalent to Convention thought to be "feature overkill"? Finally, even if it was not predefined, such an implementation-defined pragma would have been legal. Given that there were quite a number of implementation-defined pragmas in Ada 83 - including such things as Export, to allow callbacks - why did not this one turn up. I am still waiting for an implementer to say "we looked at that market carefully and concluded it was not worth the trouble." Till then, I stick to my conjecture that nobody really looked at all that Fortran and thought about how to sell into that crowd. It's water over the dam, of course, because of Interfaces.Fortran in Ada 95. But will we see timely implementations of it (other than GNAT, which supports it in version 2)? Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-10 20:55 ` Array mappings Michael Feldman @ 1994-12-13 15:01 ` Norman H. Cohen 1994-12-16 18:55 ` Michael Feldman 0 siblings, 1 reply; 32+ messages in thread From: Norman H. Cohen @ 1994-12-13 15:01 UTC (permalink / raw) In article <3cd4ju$11h@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes: |> This is odd - Ada 93 deliberately leaves array mappings (like all |> representations) unspecified, so (presumably) as to allow flexibility |> in the implementations. Was a pragma equivalent to Convention thought |> to be "feature overkill"? Ada 83 had an explicit hook for this sort of thing: implementation- defined representation pragmas. The philosophy behind Chapter 13 in the Ada-83 RM was to be as unconstraining as possible, trusting implementors to "do the right thing" for their platforms. It eventually became clear that the designers of Ada 83 had been too trusting, and the ARG started to develop a series of binding interpretations tightening up the requirements for support of representation clauses, the one language-defined representation pragma (Pack), and unchecked conversion. Some of these interpretations received final approval from WG9, but consideration of the others was overcome by events--the promulgation of a full-fledged revised standard addressing the same issues. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-13 15:01 ` Norman H. Cohen @ 1994-12-16 18:55 ` Michael Feldman 1994-12-17 0:43 ` Keith Thompson 1994-12-17 17:41 ` Robert Dewar 0 siblings, 2 replies; 32+ messages in thread From: Michael Feldman @ 1994-12-16 18:55 UTC (permalink / raw) In article <3ckd14$1cqf@watnews1.watson.ibm.com>, Norman H. Cohen <ncohen@watson.ibm.com> wrote: >In article <3cd4ju$11h@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu >(Michael Feldman) writes: > >|> This is odd - Ada 93 deliberately leaves array mappings (like all >|> representations) unspecified, so (presumably) as to allow flexibility >|> in the implementations. Was a pragma equivalent to Convention thought >|> to be "feature overkill"? > >Ada 83 had an explicit hook for this sort of thing: implementation- >defined representation pragmas. The philosophy behind Chapter 13 in the >Ada-83 RM was to be as unconstraining as possible, trusting implementors >to "do the right thing" for their platforms. Sigh...and, as far as I know, nobody took the bait and made an implementation- dependent pragma to do Fortran-friendly arrays. I'm still rockin' on my hobbyhorse, waiting for some Ada company to say "Mike, we really talked to a good sample of all those engineers out there beyond DoD, and concluded that this feature was not worth the investment." Did anybody do it? There are a _lot_ of Fotranners out there, in organizations with lots of money (the DoE labs, for example). Might have been a lucrative market. Did _anyone_ try to tap it? Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-16 18:55 ` Michael Feldman @ 1994-12-17 0:43 ` Keith Thompson 1994-12-17 17:17 ` Reaching traditional engineering, was: " Michael Feldman 1994-12-17 20:42 ` Rolf Ebert 1994-12-17 17:41 ` Robert Dewar 1 sibling, 2 replies; 32+ messages in thread From: Keith Thompson @ 1994-12-17 0:43 UTC (permalink / raw) In <3csnqi$3ee@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: > Sigh...and, as far as I know, nobody took the bait and made an > implementation- dependent pragma to do Fortran-friendly arrays. > > I'm still rockin' on my hobbyhorse, waiting for some Ada company > to say "Mike, we really talked to a good sample of all those > engineers out there beyond DoD, and concluded that this feature > was not worth the investment." I don't know whether or not the marketing department of any Ada company did this; I'm just a programmer. However, how sure are you that it *would* have been worth the investment? Can you produce a Fortran-using engineer who rejected Ada 83, but would have used it if it had supported Fortan-friendly arrays? You've said in the past that many engineers rejected PL/I because it doesn't support Fortran-style arrays, but several postings in this newsgroup indicate that it does. In particular, Robert Dewar wrote: > Michael, I think you are confused about ISUB, and barking up a wrong tree > to say that Ada 9X is superior to PL/1 here. ISUB is a much more powerful > feature than pragma Convention Fortran in Ada 9X, and subsumes it. I can easily imagine an Ada 83 compiler vendor adding an implementation-defined pragma similar to Ada 95's pragma Convention(Fortran) and *still* not being able to sell to all those engineers hooked on Fortran. Perhaps there was a marketing failure for both PL/I and Ada, but it's not as simple a failure as the one you portray. If you have any ideas on how to sell Ada to Fortran users, I'll be happy to forward them to our marketing department. -- Keith Thompson (The_Other_Keith) kst@alsys.com TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc. 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 When you're a nail, every problem looks like a hammer. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Reaching traditional engineering, was: Array mappings 1994-12-17 0:43 ` Keith Thompson @ 1994-12-17 17:17 ` Michael Feldman 1994-12-18 1:34 ` Robert Dewar 1994-12-17 20:42 ` Rolf Ebert 1 sibling, 1 reply; 32+ messages in thread From: Michael Feldman @ 1994-12-17 17:17 UTC (permalink / raw) In article <D0xJBp.1zp@alsys.com>, Keith Thompson <kst@alsys.com> wrote: >In <3csnqi$3ee@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: >I don't know whether or not the marketing department of any Ada company >did this; I'm just a programmer. However, how sure are you that it >*would* have been worth the investment? Can you produce a Fortran-using >engineer who rejected Ada 83, but would have used it if it had supported >Fortan-friendly arrays? I'm not at all sure if it's worth the investment. I'm looking for some kind of reassurance that someone looked as seriously at the engineering community as they (apparently) did at other domains like UI, IS, realtime, etc. I have run into engineers who have expressed surprise at how powerful Ada could be in their domain, and wonderment that the Ada vendors haven't knocked on their doors. The key things these engineers have focused on have been array mappings, math functions, and complex numbers; they are quite amazed that it took the Ada community nearly ten years to produce a quasi-standard math library. "If they cared about us, how come we can't even call square root in a portable way?" Etc. >You've said in the past that many engineers rejected PL/I because it >doesn't support Fortran-style arrays, but several postings in this >newsgroup indicate that it does. [snip] Yes, clearly the ISUB business in PL/1 is quite powerful; that I didn't know about it, nor, apparently, did any of those engineers I spoke to at the time, suggests that we were pretty poorly educated on PL/1. I don't recall it in a textbook, though I may simply have missed it. I have some old PL/1 books around the office; I'll check. It's nice to know the feature is there. >I can easily imagine an Ada 83 compiler vendor adding an >implementation-defined pragma similar to Ada 95's pragma >Convention(Fortran) and *still* not being able to sell to all those >engineers hooked on Fortran. That is certainly a possibility. See below. >Perhaps there was a marketing failure for both PL/I and Ada, but it's >not as simple a failure as the one you portray. If you have any ideas >on how to sell Ada to Fortran users, I'll be happy to forward them to >our marketing department. Well, I was certainly never privy to the marketing efforts of the vendors, except for a few relationships I had that were specifically oriented to improving Ada's acceptance in universities. The various university programs that came out of those discussions show that I and other colleagues the vendors consulted were not without influence. Did the vendors consult with similar folks in other domains, especially in engineering, putting them under nondisclosure and really picking their brains? In discussing the general state of things with vendors, in conference panels, listening to various conference talks, etc., it is obvious that there's been a fair amount of effort put into finding out the needs of various customer domains. The vendors all understood what was missing in the C interface area, to support better UI development for example (so we got e.g. implementation-specific callback pragmas). Surveying the IS community made it clear that decimal types, picture-directed IO, etc., would make Ada more attractive to those customers. Real-timers were supported by lots of implementation-specific work on tasking, or even non-tasking alternative runtimes. You get the idea. Vendors often reply to questions about this or that feature with "we're supporting our customers; the customer is always right." This is entirely appropriate. What has struck me as strange is that there's been very little public discussion on how to reach the _engineers_ and other scientists who populate the Fortran user community. It's not as though they were small and poor; lots of effort and, presumably, money has gone into producing the Fortran 90 standard and High Performance Fortran. "Scientific programming" is far from dead; that community is alive and kicking. So it seems that this community should have been a logical target audience for Ada, especially given the nicely defined numerics, powerful array operations, etc. The idea of Fortran-friendly arrays is just a logical extension, and could have been done legally with that extra pragma. Obviously no compiler feature is free, but it's hard to imagine it being terribly expensive either. Same goes for complex numbers. Yet Ada seems to be not only unused but substantially unknown in that community; indeed, I am running into engineers who are moving away from Fortran only to jump on the C bandwagon. So the question remains: have the Ada companies tested the waters in the traditional engineering population and been completely discouraged by the response, or have they simply not gone after it at all? As you said, Keith, you are a programmer. I'm a technical guy too, not a marketing one. But it really saddens me to look around at all that Fortran out there, know how easily much of it could be interfaced to new Ada code (at least if it's well-designed Fortran with clean subprogram interfaces), and yet see almost nothing happening. Maybe our opportunity is long gone, OBE with the advent of Fortran 90 and HPF. Or maybe it's not. Who has data? The data I see, in this group and elsewhere, is almost always on the C/C++ opportunities. Who is doing the market studies of the traditional engineering community? Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Reaching traditional engineering, was: Array mappings 1994-12-17 17:17 ` Reaching traditional engineering, was: " Michael Feldman @ 1994-12-18 1:34 ` Robert Dewar 1994-12-19 2:11 ` Michael Feldman 1994-12-21 16:17 ` Kevin Weise 0 siblings, 2 replies; 32+ messages in thread From: Robert Dewar @ 1994-12-18 1:34 UTC (permalink / raw) I assume you are aware of the Cray/Ada effort which was certainly aimed at least partly at their Fortran community. As for FOrtran engineers wondering why Ada sales people had not knocked on their door -- that's easy, none of the Ada companies could have BEGUN to afford this level of marketing effort! ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Reaching traditional engineering, was: Array mappings 1994-12-18 1:34 ` Robert Dewar @ 1994-12-19 2:11 ` Michael Feldman 1994-12-21 16:17 ` Kevin Weise 1 sibling, 0 replies; 32+ messages in thread From: Michael Feldman @ 1994-12-19 2:11 UTC (permalink / raw) In article <3d03j7$q21@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >I assume you are aware of the Cray/Ada effort which was certainly aimed >at least partly at their Fortran community. I'm vaguely aware of it. Not one engineer I ever asked was aware of it. (Yes, I asked a few...:-)) >As for FOrtran engineers wondering why Ada sales people had not knocked >on their door -- that's easy, none of the Ada companies could have BEGUN >to afford this level of marketing effort! How sad. By this argument, no small company can ever grow larger, because it cannot afford to spend money to let people know about it. Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Reaching traditional engineering, was: Array mappings 1994-12-18 1:34 ` Robert Dewar 1994-12-19 2:11 ` Michael Feldman @ 1994-12-21 16:17 ` Kevin Weise 1994-12-21 13:29 ` David Emery ` (2 more replies) 1 sibling, 3 replies; 32+ messages in thread From: Kevin Weise @ 1994-12-21 16:17 UTC (permalink / raw) In article <3d03j7$q21@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >I assume you are aware of the Cray/Ada effort which was certainly aimed >at least partly at their Fortran community. > Well, I have to respond to this one. WADR, Robert, my wife has been doing benchmarking of various Ada compilers on various target platforms for some time now. My discussions with her lead me to conclude that the Cray Ada effort was basically a token effort, possibly just done in response to, or in anticipation of, a contract for a DoD contractor. The compiler itself is easy to break (esp. with generics), and generates poor code (yes, I know, it uses a common back end with all other language translators). Unless they've fixed it recently, a delay statement is guaranteed to result in a wait of *AT LEAST* 2.0 seconds, regardless of the requested value. While all this is not illegal, it certainly does not entice any engineer to switch to Ada. When it comes to Cray Ada, JUST SAY NO! (Actually, my personal opinion is, when it comes to the Cray, just say SGI! And we know they have a good Ada implementation!) ---------------------------------------------------------------- Kevin J. Weise weisek@source.asset.com COLSA Corporation Voice - (205) 922-1512 ext. 2115 6726 Odyssey Drive FAX - (205) 971-0002 Huntsville, AL 35806 {Standard Disclaimers about my opinions & my employer's opinions} {... which are in conflict often enough} ---------------------------------------------------------------- "Admire those who seek the truth; avoid those who find it." Marcel Proust ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Reaching traditional engineering, was: Array mappings 1994-12-21 16:17 ` Kevin Weise @ 1994-12-21 13:29 ` David Emery 1994-12-22 2:40 ` Michael Feldman 1994-12-22 10:20 ` Reaching traditional engineering Introspect Technologies 1994-12-27 3:37 ` Reaching traditional engineering, was: Array mappings Richard G. Hash 2 siblings, 1 reply; 32+ messages in thread From: David Emery @ 1994-12-21 13:29 UTC (permalink / raw) Does anyone know the 'root technology' for the Cray compiler, i.e. who the OEM was? For some reason I think this was Telesoft, but I have absolutely no factual basis for that belief, other than a stray neuron firing... dave -- --The preceeding opinions do not necessarily reflect the opinions of --The MITRE Corporation or its sponsors. -- "A good plan violently executed -NOW- is better than a perfect plan -- next week" George Patton -- "Any damn fool can write a plan. It's the execution that gets you -- all screwed up" James Hollingsworth ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Reaching traditional engineering, was: Array mappings 1994-12-21 13:29 ` David Emery @ 1994-12-22 2:40 ` Michael Feldman 0 siblings, 0 replies; 32+ messages in thread From: Michael Feldman @ 1994-12-22 2:40 UTC (permalink / raw) In article <EMERY.94Dec21132946@goldfinger.mitre.org>, David Emery <emery@goldfinger.mitre.org> wrote: >Does anyone know the 'root technology' for the Cray compiler, i.e. who >the OEM was? The one I saw was indeed a port of TeleSoft's TeleGen2. Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Reaching traditional engineering 1994-12-21 16:17 ` Kevin Weise 1994-12-21 13:29 ` David Emery @ 1994-12-22 10:20 ` Introspect Technologies 1994-12-22 20:49 ` Richard Riehle 1994-12-23 9:09 ` Peter Hermann 1994-12-27 3:37 ` Reaching traditional engineering, was: Array mappings Richard G. Hash 2 siblings, 2 replies; 32+ messages in thread From: Introspect Technologies @ 1994-12-22 10:20 UTC (permalink / raw) Kevin Weise (weisek@source.asset.com) wrote: : In article <3d03j7$q21@gnat.cs.nyu.edu>, : Robert Dewar <dewar@cs.nyu.edu> wrote: : >I assume you are aware of the Cray/Ada effort which was certainly aimed : >at least partly at their Fortran community. : > : Well, I have to respond to this one. WADR, Robert, my wife has been doing : benchmarking of various Ada compilers on various target platforms for : some time now. My discussions with her lead me to conclude that the : Cray Ada effort was basically a token effort, possibly just done in : response to, or in anticipation of, a contract for a DoD contractor. I used Cray Ada for a couple of years at the National Test Facility. The primary motivation for the development of the Ada compiler was juicy DoD/SDI/R&D-type contracts. The NTF was (at the time) taking the mandate seriously and insisted that Cray provide an Ada compiler as a condition for keeping their machines on-site. I don't know whether the government provided any funding to Cray to help them along. The compiler development group was (is?) very dedicated to Ada and expressed their hopes that Ada would catch on in the scientific community. I don't think Cray put any marketing push behind it, however. : The compiler itself is easy to break (esp. with generics), I never saw this behavior. On the contrary, the compiler was reasonably robust. The biggest headaches were with the (very primitive) Telesoft library manager that they ported to the Cray. : and generates : poor code (yes, I know, it uses a common back end with all other : language translators). My benchmarks (remember, this is 2-3 years ago) showed that standard computations in Cray Ada (including range and bounds checking, etc) took approximately 10% longer than Cray C and 20% longer than Cray Fortran. This is certainly not "poor code". The optimizer worked fine and Cray taught a class in how to write vectorizable code. The Cray architecture is very peculiar and requires a specific (and unusual) style of coding. I can see how someone could get poor performance if they didn't know "the tricks". In fact, writing to get the best performance often necessitated writing Ada in a very "non-Ada" way (very frustrating!). : Unless they've fixed it recently, a delay statement : is guaranteed to result in a wait of *AT LEAST* 2.0 seconds, regardless : of the requested value. While all this is not illegal, it certainly does : not entice any engineer to switch to Ada. We never used Cray tasking or delays so I can't speak to this issue. : When it comes to Cray Ada, JUST SAY NO! (Actually, my personal opinion : is, when it comes to the Cray, just say SGI! And we know they have a : good Ada implementation!) IMHO, the problem with Cray Ada was the Cray machines, not Ada. The speed advantages of a vector-based architecture are not worth all the programming hoops you have to jump through, especially if your application doesn't lend itself to vectorization. I agree that SGI (and DEC and HP and other general-purpose computers) are more cost-effective and are better hosts and targets for Ada development. : ---------------------------------------------------------------- : Kevin J. Weise weisek@source.asset.com : COLSA Corporation Voice - (205) 922-1512 ext. 2115 : ---------------------------------------------------------------- : "Admire those who seek the truth; : avoid those who find it." Marcel Proust Douglas Arndt (member, Team Ada!) Introspect Technologies, Inc. PO Box 1135 Colorado Springs, CO 80901-1135 (719) 634-5744 (719) 634-1163 fax intros@usa.net --------------------------------------------------------------------------- "Facts are just facts. You can't have opinions about facts." - Professor Peter Schickele --------------------------------------------------------------------------- -- ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Reaching traditional engineering 1994-12-22 10:20 ` Reaching traditional engineering Introspect Technologies @ 1994-12-22 20:49 ` Richard Riehle 1994-12-23 9:09 ` Peter Hermann 1 sibling, 0 replies; 32+ messages in thread From: Richard Riehle @ 1994-12-22 20:49 UTC (permalink / raw) In article <3dbjtq$kfl@earth.usa.net> intros@earth (Introspect Technologies) writes: >Kevin Weise (weisek@source.asset.com) wrote: >: Well, I have to respond to this one. WADR, Robert, my wife has been doing >: benchmarking of various Ada compilers on various target platforms for >: some time now. My discussions with her lead me to conclude that the >: Cray Ada effort was basically a token effort, possibly just done in >: response to, or in anticipation of, a contract for a DoD contractor. > Ah, yes. The famous "checkbox" compiler. I have had fun with this one too. It seems that some hardware vendors in th eighties built minimally validatable compilers so they could enter a "checkmark" in the box on some form that said "Validated Ada." They then failed to give any serious support to Ada, believing they had fulfilled their obligation. My experience was with Tandem with their homebrew compiler. No one ever took it seriously, and Tandem is now without a validated compiler. They seem to have decided that the DoD market is not important. Or did they simply see that the DoD was not taking Ada seriously, either. Many of these hardware vendors no longer have a direct interest in Ada. This seems to include HP, IBM, Tandem, among others. But perhaps we should simply say "Good Riddance," since checkbox compilers did as much to damage Ada's reputation as anything. Richard Riehle AdaWorks Software Engineering -------------------------------------------------------------------------- "I'm not bad. I'm just drawn that way." Jessica, "Who Killed Roger Rabbit" "I'm not bad. My compilers just behave that way." Ada, in a wistful moment. -------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Reaching traditional engineering 1994-12-22 10:20 ` Reaching traditional engineering Introspect Technologies 1994-12-22 20:49 ` Richard Riehle @ 1994-12-23 9:09 ` Peter Hermann 1 sibling, 0 replies; 32+ messages in thread From: Peter Hermann @ 1994-12-23 9:09 UTC (permalink / raw) Introspect Technologies (intros@earth) wrote: [lots of snips!] : The compiler development group was (is?) very dedicated to Ada and : expressed their hopes that Ada would catch on in the scientific community. : I don't think Cray put any marketing push behind it, however. Cray personnel even were reluctant to inform about their Ada compiler when asked for. : : When it comes to Cray Ada, JUST SAY NO! (Actually, my personal opinion : : is, when it comes to the Cray, just say SGI! And we know they have a : : good Ada implementation!) : IMHO, the problem with Cray Ada was the Cray machines, not Ada. The : speed advantages of a vector-based architecture are not worth all the : programming hoops you have to jump through, especially if your : application doesn't lend itself to vectorization. I agree that SGI (and : DEC and HP and other general-purpose computers) are more cost-effective : and are better hosts and targets for Ada development. Such problems appear quit natural when the Compiler is a port from an other architecture. A not so recognized (as deserved) vectorizing Ada compiler is that of Convex. To my knowledge, it was the first vectorizing Ada compiler. Good experience: I had a phantastic support by the service people of Convex at that time, especially from the highly motivated Ada compiler group. This cannot be left unsaid, because it's not usual. -- 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] 32+ messages in thread
* Re: Reaching traditional engineering, was: Array mappings 1994-12-21 16:17 ` Kevin Weise 1994-12-21 13:29 ` David Emery 1994-12-22 10:20 ` Reaching traditional engineering Introspect Technologies @ 1994-12-27 3:37 ` Richard G. Hash 2 siblings, 0 replies; 32+ messages in thread From: Richard G. Hash @ 1994-12-27 3:37 UTC (permalink / raw) > >I assume you are aware of the Cray/Ada effort which was certainly aimed > >at least partly at their Fortran community. > > > My discussions with her lead me to conclude that the > Cray Ada effort was basically a token effort, possibly just done in > response to, or in anticipation of, a contract for a DoD contractor. > The compiler itself is easy to break (esp. with generics), and generates > poor code ... I don't know if Telesoft was planning on big DoD money, but they were strenously encouraged for *years* by a certain oil company to come up with a decent Cray Ada compiler. The same oil company then found out that the folks who superoptimized the Cray Fortran compiler didn't work at Cray any longer, and Cray themself conceeded they "basically couldn't explain how it worked" at that point in time (this was several+ years ago). So much for technology sharing... It was rather a large disappointment, but I'm not sure I would call it a token effort either. -- Richard G. Hash email: rgh@shell.com Shell Development Company, Bellaire Research Center phone: (713) 245-7311 Member Team Ada Free Ada94 compilers: cs.nyu.edu:/pub/gnat ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-17 0:43 ` Keith Thompson 1994-12-17 17:17 ` Reaching traditional engineering, was: " Michael Feldman @ 1994-12-17 20:42 ` Rolf Ebert 1994-12-19 2:19 ` Michael Feldman 1 sibling, 1 reply; 32+ messages in thread From: Rolf Ebert @ 1994-12-17 20:42 UTC (permalink / raw) >>>>> "Keith" == Keith Thompson <kst@alsys.com> writes: Keith> In <3csnqi$3ee@felix.seas.gwu.edu> mfeldman@seas.gwu.edu Keith> (Michael Feldman) writes: >> Sigh...and, as far as I know, nobody took the bait and made an >> implementation- dependent pragma to do Fortran-friendly arrays. >> >> I'm still rockin' on my hobbyhorse, waiting for some Ada company >> to say "Mike, we really talked to a good sample of all those >> engineers out there beyond DoD, and concluded that this feature >> was not worth the investment." Keith> I don't know whether or not the marketing department of any Keith> Ada company did this; I'm just a programmer. However, how Keith> sure are you that it *would* have been worth the investment? Keith> Can you produce a Fortran-using engineer who rejected Ada 83, Keith> but would have used it if it had supported Fortan-friendly Keith> arrays? When I started to work in a thermal engineering lab about 5 years ago, we all decided to use Ada for our every day programming and for the one big simulation project. Most of the engineers only had Fortran experience and had already a lot of code that we wanted reuse by interfacing from Ada. Fortran friendly arrays would have been a big advantage, but Ada failed for other reasons, too. Some problems were calculating exp(2x) instead of exp(x) (we lost a whole week on this), not correctly passsing parameters from the 7th parameter on, etc... Yes, I know these are compiler issues, but Ada was blamed for it. Today nobody uses Ada anymore in this lab. They all turned back to Fortran and C. Keith> -- Keith Thompson (The_Other_Keith) kst@alsys.com Keith> TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc. 10251 Vista Sorrento Keith> Parkway, Suite 300, San Diego, CA, USA, 92121-2718 When Keith> you're a nail, every problem looks like a hammer. Rolf -- Rolf Ebert Beratung fuer Energiesysteme und Informatik Erich Kaestner Str. 17 Conseil en Energetique et Informatique D - 80796 Muenchen (Team Ada) Tel.: +49-89-30.77.88.00 Germany Fax.: +49-89-30.77.91.00 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-17 20:42 ` Rolf Ebert @ 1994-12-19 2:19 ` Michael Feldman 1994-12-19 3:46 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: Michael Feldman @ 1994-12-19 2:19 UTC (permalink / raw) In article <RE.94Dec17214238@waporo.muc.de>, Rolf Ebert <re@waporo.muc.de> wrote: >When I started to work in a thermal engineering lab about 5 years ago, >we all decided to use Ada for our every day programming and for the one >big simulation project. Most of the engineers only had Fortran >experience and had already a lot of code that we wanted reuse by >interfacing from Ada. Finally! A note from someone who was there! >Fortran friendly arrays would have been a big advantage, but Ada failed >for other reasons, too. Some problems were calculating exp(2x) instead >of exp(x) (we lost a whole week on this), not correctly passsing >parameters from the 7th parameter on, etc... Yes, I know these are >compiler issues, but Ada was blamed for it. Certainly they were. I doubt they would've had the energy or money, or inclination, to shop for another, less buggy compiler. Presumably they spent a big chunk of the budget on the buggy one... >Today nobody uses Ada anymore in this lab. They all turned back to >Fortran and C. Deep sigh. I rest my case. An Ada implementer who really cared about this potential market would've delivered compilers that did the right thing for this group of customers. Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-19 2:19 ` Michael Feldman @ 1994-12-19 3:46 ` Robert Dewar 1994-12-19 5:53 ` Mark S. Hathaway 1994-12-22 17:08 ` Richard G. Hash 2 siblings, 0 replies; 32+ messages in thread From: Robert Dewar @ 1994-12-19 3:46 UTC (permalink / raw) "An Ada implementor who really cared would have delivered [more reliable compilers]" This is really silly. THe implication that bugs in early Ada compilers were due to lack of care and concern for specific markets has no basis in fact. Ada has always had extremely high reliability requirements in all markets (one can argue that the embedded real-time market is a much higher reliability-requirement market than numerical computation). Sure early Ada compilers had bugs (early anything compilers have bugs), but this was a matter of maturity, and you can be sure that all Ada vendors were working extremely hard to improve reliability. Perhaps they did not succeed as well as you might hope, but to ascribe that to deliberate lack of care won't wash." If you rest your case on this weak and unsupportable observation, it is indeed a weak case! ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-19 2:19 ` Michael Feldman 1994-12-19 3:46 ` Robert Dewar @ 1994-12-19 5:53 ` Mark S. Hathaway 1994-12-19 14:27 ` Robert Dewar 1994-12-22 17:08 ` Richard G. Hash 2 siblings, 1 reply; 32+ messages in thread From: Mark S. Hathaway @ 1994-12-19 5:53 UTC (permalink / raw) > In article <3d2qk0$qop@felix.seas.gwu.edu>, > mfeldman@seas.gwu.edu (Michael Feldman) writes: >> In article <RE.94Dec17214238@waporo.muc.de>, >> Rolf Ebert <re@waporo.muc.de> wrote: >>When I started to work in a thermal engineering lab about 5 years ago, >>we all decided to use Ada for our every day programming and for the one >>big simulation project. Most of the engineers only had Fortran >>experience and had already a lot of code that we wanted reuse by >>interfacing from Ada. > Finally! A note from someone who was there! >>Fortran friendly arrays would have been a big advantage, but Ada failed >>for other reasons, too. Some problems were calculating exp(2x) instead >>of exp(x) (we lost a whole week on this), not correctly passsing >>parameters from the 7th parameter on, etc... Yes, I know these are >>compiler issues, but Ada was blamed for it. > Certainly they were. I doubt they would've had the energy or money, > or inclination, to shop for another, less buggy compiler. Presumably > they spent a big chunk of the budget on the buggy one... >>Today nobody uses Ada anymore in this lab. They all turned back to >>Fortran and C. > Deep sigh. I rest my case. An Ada implementer who really cared about this > potential market would've delivered compilers that did the right thing > for this group of customers. First, let me say that there is good reason for optimism. Ada95 should dispell many of the doubts and comparison problems (to C or C++) and that should help keep Ada alive and well. Now the bad news. :-) Many people feel that anything the U.S. government touches turns to crap. That feeling toward the government has probably shaded the opinions of many people toward Ada ('83) or Ada95. A superior product might help turn that opinion around, but it will require much effort and salesmanship. The problems of wooing Fortran users is an example of the problem. If there was an attitude that encouraged the migration ofFortran users, or even COBOL users, to Ada95 rather than just the efforts to produce a superior product then maybe Ada95 could grow more. To expect these people to move to Ada 95 without providing a smooth transition path is hopeful, but not necessarily going to be fruitful. C and C++ have had "the jump" on Ada and Modula-n in several instances, but I think Ada95, as a language, probably deserves more support than C++. There will have to be a free enterprise spirit to go after market share for it to catch up. If it remains the province of government deparments who may not even want it then it will probably just die a slow lingering death. Semper fi, and all that kinda stuff Mark S. Hathaway <hathawa2@marshall.edu> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-19 5:53 ` Mark S. Hathaway @ 1994-12-19 14:27 ` Robert Dewar 0 siblings, 0 replies; 32+ messages in thread From: Robert Dewar @ 1994-12-19 14:27 UTC (permalink / raw) Following up on Mark's comments, I feel that the COBOL market is in practice a much better opportunity for Ada 95 than the Fortran market. I have three reasons for thinking this: 1. It is a much bigger market, and is now in the business of climbing off mainframes, so systems are being rethought anyway. 2. The COBOL world has always been much more forward thinking when it comes to language. This is the land of 4GL's, and it is interesting for instance to note the interest in Smalltalk. People are by no means wedded to COBOL, and they are looking around. 3. For a Fortran user, Ada 95 and C++ look somewhat similar. Sure we can argue the usual "Ada is better because xxx" line where xxx has to do with reliability etc. etc. but in terms of raw functionality, C++ and Ada 95 look rather similar (and both are weaker than Fortran 90 when it comes to manipulating multi-dimensional arrays). When I say weaker here, I am talking about for example the slicing features of F90. Of course I still think that F90 users would be ahead in using Ada 95, because they would gain so much from the improved abstraction features, but as I said this is a sell based on somewhat abstract issues :-) On the other hand, C++ does NOT look good to COBOL folks. It signally lacks facilities for decimal arithmetic, which cannot be smoothly integrated (consider handling of literals for example) into C++. On the other hand, Ada 95 has gone out of its way to be COBOL friendly, and even includes editing modeled directly on COBOL pictures. C ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-19 2:19 ` Michael Feldman 1994-12-19 3:46 ` Robert Dewar 1994-12-19 5:53 ` Mark S. Hathaway @ 1994-12-22 17:08 ` Richard G. Hash 1995-01-03 3:26 ` Fred McCall 2 siblings, 1 reply; 32+ messages in thread From: Richard G. Hash @ 1994-12-22 17:08 UTC (permalink / raw) In <3d2qk0$qop@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: > >Fortran friendly arrays would have been a big advantage, but Ada failed > >for other reasons, too. Some problems were calculating exp(2x) instead > >of exp(x) (we lost a whole week on this), not correctly passsing > >parameters from the 7th parameter on, etc... Yes, I know these are > >compiler issues, but Ada was blamed for it. [...] > Deep sigh. I rest my case. An Ada implementer who really cared about this > potential market would've delivered compilers that did the right thing > for this group of customers. > Mike Feldman I just can't buy this, and I was there (if you consider seismic processing an 'engineer' type thing). I agree that Fortran friendly arrays would have been nice, along with a couple thousand other things. But they just didn't rate more than a blip on the map compared to, oh, let's say, working compilers? Ones where you didn't have to recompile a quarter million lines once a week because the library structure got hosed up with great regularity (recompiling was an event which took about 30 hours at the time). Ones where the generated code was 9 times slower than equivalent Fortran code. Ones where the 7th argument to a routine didn't end up in the weeds. Ones that had actual working math libraries that gave the right results. Let's face it, if you were introduced to Ada in 1986 and were trying to convert a bunch of Fortran programmers over - you had an uphill struggle. The compilers were not all that great back then (there were some exceptions, I'll grant you), and the optimizations were not what they are today. Fairly or not, they gave the impression of slow, buggy, pain the the derriere ^&@#$^, and were the butt of many a joke. Can you not remember back? On machines like the Cray, the Fortran compilers were superb, and you could tune a piece of code so tight it would make your head spin. The Ada compiler(s?) available just could not compete very well. I don't think the compiler vendors weren't trying, it was just a matter of scale. Vendors had been tuning Fortran compilers and their code generation for a decade or more, Ada was new on the scene, and I think it was a little tougher to implement than many folks thought. By and large, to the Fortran community, it was a matter of "why bother with the hassle", things work well enough as they are. I would like to think that things are quite different now. -- Richard G. Hash email: rgh@shell.com Shell Development Company, Bellaire Research Center phone: (713) 245-7311 Member Team Ada Free Ada94 compilers: cs.nyu.edu:/pub/gnat ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-22 17:08 ` Richard G. Hash @ 1995-01-03 3:26 ` Fred McCall 0 siblings, 0 replies; 32+ messages in thread From: Fred McCall @ 1995-01-03 3:26 UTC (permalink / raw) In <rgh.788116097@camo> rgh@shell.com Richard G. Hash writes: >I agree that Fortran friendly arrays would have been nice, along with a >couple thousand other things. But they just didn't rate more than a blip >on the map compared to, oh, let's say, working compilers? Ones where you >didn't have to recompile a quarter million lines once a week because the >library structure got hosed up with great regularity (recompiling was an >event which took about 30 hours at the time). Ones where the generated >code was 9 times slower than equivalent Fortran code. Ones where the 7th >argument to a routine didn't end up in the weeds. Ones that had actual >working math libraries that gave the right results. > >Let's face it, if you were introduced to Ada in 1986 and were trying >to convert a bunch of Fortran programmers over - you had an uphill >struggle. The compilers were not all that great back then (there were >some exceptions, I'll grant you), and the optimizations were not what >they are today. Fairly or not, they gave the impression of slow, buggy, >pain the the derriere ^&@#$^, and were the butt of many a joke. Can you >not remember back? All I have to do is remember back to December of last year (a couple of weeks ago). The description given above for the state of the practice in 1986 sounds appropriate for my experiences with current releases of tools in 1994. Ada is a lovely language in theory, but if you actually use some of the features (like generics, array slices, etc.) compilers/toolsets do wrong/inefficient things. It's been a long time; the tools should be *much* better than they are, given how much they cost. -- "Insisting on perfect safety is for people who don't have the balls to live in the real world." -- Mary Shafer, NASA Ames Dryden --------------------------------------------------------------------------- merlin@annwfn.com -- I don't speak for others and they don't speak for me. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-16 18:55 ` Michael Feldman 1994-12-17 0:43 ` Keith Thompson @ 1994-12-17 17:41 ` Robert Dewar 1994-12-18 0:03 ` Dik T. Winter 1994-12-19 2:01 ` Michael Feldman 1 sibling, 2 replies; 32+ messages in thread From: Robert Dewar @ 1994-12-17 17:41 UTC (permalink / raw) Mike, you sure have posted lots of messages on the Fortran array issue. My own feeling is that this is a nice feature, but not particularly critical. Having to reorder array subscripts is not exactly the biggest barrier to the use of Ada arrays in Fortran programs! You ask if vendors explicitly ran around trying to "dig up" this market. I doubt it. Instead they probably assumed that this was not a major issue, because no customers bought it up. As for it being a possibly lucrative market, I VERY much doubt it. THere were much more important targets of opportunity than this one. It is true that it would not have been very hard to implement, which just goes to show the estimate of value placed on this feature by vendors, and personally I think that this was a reasonable estimate. Ada 9X requires this support. Whether that requirement is justified remains to be seen. That will really show whether Mike is right. If we see a huge army of Fortran programmers suddenly saying "great, now that I can write my subscripts the "right" way round in Ada 95, I will switch to using Ada", then we will know that Mike was rigt, and that Ada vendors missed an important opportunity. Note: Many Fortran programmers are moving to C, C doesn't have any help for Fortran array ordering, and I never heard of this being an adoption barrier. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-17 17:41 ` Robert Dewar @ 1994-12-18 0:03 ` Dik T. Winter 1994-12-19 2:08 ` Michael Feldman 1994-12-19 2:01 ` Michael Feldman 1 sibling, 1 reply; 32+ messages in thread From: Dik T. Winter @ 1994-12-18 0:03 UTC (permalink / raw) In article <3cv7t2$no2@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes: > Ada 9X requires this support. Whether that requirement is justified > remains to be seen. > I think this came from suggestions out of the Ada Europe Numerics WG, strange enough. I think it is a non-issue; but I started with Algol 60, followed by Algol-68, and only after that came Fortran; and I did think they did arrays the wrong way. I know that after heavy requests CDC modified their Algol-68 compiler such that it could handle arrays both ways. I do not think the feature has been used so very much. The only time when it is really useful is when you want to interface to the large base of numerical libraries in Fortran. But as Robert says, C has the same problem (more actually). -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098 home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik@cwi.nl ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-18 0:03 ` Dik T. Winter @ 1994-12-19 2:08 ` Michael Feldman 0 siblings, 0 replies; 32+ messages in thread From: Michael Feldman @ 1994-12-19 2:08 UTC (permalink / raw) In article <D0zC5A.H0r@cwi.nl>, Dik T. Winter <dik@cwi.nl> wrote: >I do not think the feature has been used so very much. The only >time when it is really useful is when you want to interface to the large >base of numerical libraries in Fortran. You seem to be saying that interfacing "to the large base of numerical libraries in Fortran" is not important. This seems a bit strange, given that re-using code like this is supposed to be what reuse is about. So what if it's written in Fortran? If it's easy to interface new code to it, that new code might as well be written in Ada. >But as Robert says, C has the >same problem (more actually). Quite true. So how are the newly-converted C programmers doing this? (Could it be that they are being provided with C versions of at least some of that Fortran stuff? Could it be that the C suppliers are really going out to target Fortranners?) I think we are back in the same chicken-and-egg problem. Ada is a small market because Ada is a small market, which guarantees that Ada will always be a small market. Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-17 17:41 ` Robert Dewar 1994-12-18 0:03 ` Dik T. Winter @ 1994-12-19 2:01 ` Michael Feldman 1994-12-19 3:41 ` Robert Dewar 1994-12-19 19:10 ` Matt Kennel 1 sibling, 2 replies; 32+ messages in thread From: Michael Feldman @ 1994-12-19 2:01 UTC (permalink / raw) In article <3cv7t2$no2@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Mike, you sure have posted lots of messages on the Fortran array issue. My >own feeling is that this is a nice feature, but not particularly critical. Well, clearly we are all entitled to our own feelings. :-) >Having to reorder array subscripts is not exactly the biggest barrier to >the use of Ada arrays in Fortran programs! Which barriers are bigger? >You ask if vendors explicitly >ran around trying to "dig up" this market. I doubt it. Instead they probably >assumed that this was not a major issue, because no customers bought it up. This may well be true. The array issue is really only subsidiary to the bigger one of whether it is possible to attract more of the "traditional" engineering/science community to Ada. I'm still waiting (I may wait a long time...:-)) to hear someone who was there say "the engineering market was thoroughly studied and we concluded that it was hopeless." At the risk of pre-judging, I think the Ada vendors were - during the years when it might have made a difference - so fixated on the DoD "embedded systems" customers that it never occurred to them to do serious study of all those non-realtime people whose computers are used to _compute_ - in DoD, DoE, and elsewhere. Judging from the activity around Fortran 90, that is _not_ a negligible market. >As for it being a possibly lucrative market, I VERY much doubt it. THere >were much more important targets of opportunity than this one. Such as? >It is true that it would not have been very hard to implement, which just >goes to show the estimate of value placed on this feature by vendors, and >personally I think that this was a reasonable estimate. I don't know. With absolutely no data to go on, and no vendors coming forward to supply any, I can only speculate. The fact remains that Ada is not exactly a big player in engineering. >Ada 9X requires this support. Whether that requirement is justified >remains to be seen. That will really show whether Mike is right. If we >see a huge army of Fortran programmers suddenly saying "great, now that >I can write my subscripts the "right" way round in Ada 95, I will switch >to using Ada", then we will know that Mike was rigt, and that Ada vendors >missed an important opportunity. Well, given that F90 provides nearly all the language maturity that an engineer would need, I see it as rather unlikely at this point. I don;t think the array subscript issue is the only adoption barrier, but the aggregate of this and other issues (the lack of a quasi-standard math library, for example) contributed, I'm sure. Actually, I think that in this as in other domains where Ada has poor penetration, the barriers were mostly nontechnical. But certainly fixing the obvious technical holes might have taken some excuses away. >Note: Many Fortran programmers are moving to C, C doesn't have any help >for Fortran array ordering, and I never heard of this being an adoption >barrier. Why do you suppose they are moving to C? Apparently C is giving them something Fortran couldn't. Or is it just the same "mob psychology"? Don't you think it's worth an attempt to get Ada into that game? Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-19 2:01 ` Michael Feldman @ 1994-12-19 3:41 ` Robert Dewar 1994-12-20 3:23 ` Michael Feldman 1994-12-19 19:10 ` Matt Kennel 1 sibling, 1 reply; 32+ messages in thread From: Robert Dewar @ 1994-12-19 3:41 UTC (permalink / raw) Mike, I know you enjoy vendor bashing, but let's keep facts straignt (and this particular point is one I have made before). You DEFINITELY cannot say that Alsys was "fixated" on the DoD market when it was first formed. For years, it agressively persued the non-DoD market, and please note that there is not very much US DoD business in France, where Alsys had some considerable success in penetrating various application fields. Indeed, Jean always thought of Ada as a general purpose language with possible application to a wide variety of fields. Some people even criticized Jean for not being sufficiently concentrated on the US DoD market! As for your question of what is more important than the array ordering matter, I would say two things: Realiability and maturity (note the posting we already saw on this issue) Performance. This is a really tough one, Fortran compilers typically have been squeezed furiously on performance of numerical loops, and are where you find the most aggressive optimization of this type of code. The effort of competing in code quality with mature optimizing Fortran compilers was and is huge and very expensive. You keep saying that what you want to be sure is that vendors did extensive market surveys of this part of the market. I don't know how much business experience you have, but this is the sort of thing that is often recommended by people without such experience. THe fact of the matter is that meaningful surveys of markets are VERY difficult and VERY expensive. The trick in a market like the Ada market is to be able to guess where to go WITHOUT blowing huge amounts of capital in studies like this that do not turn out to be useful. My own feeling is that the performance issue was so central at the time, that there was little chance for Ada to make serious headway (one of the problems with the Cray compiler was that, espeically early on, it was a little bit less efficient than Fortran). As to why numerical people are moving to C, it is partly because they are moving to work stations where C is perceived as part of the general environment, and yes, I do think this represents an opportunity! ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-19 3:41 ` Robert Dewar @ 1994-12-20 3:23 ` Michael Feldman 1994-12-20 14:09 ` Robert Dewar 0 siblings, 1 reply; 32+ messages in thread From: Michael Feldman @ 1994-12-20 3:23 UTC (permalink / raw) In article <3d2ve2$pig@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Mike, I know you enjoy vendor bashing, but let's keep facts straignt (and >this particular point is one I have made before). You DEFINITELY cannot >say that Alsys was "fixated" on the DoD market when it was first formed. Well, if what I was doing was "bashing" the vendors (though I prefer to see it as trying to goad them into action), I suppose Alsys can be excluded (I'll take your word for it). >For years, it agressively persued the non-DoD market, and please note that >there is not very much US DoD business in France, where Alsys had some >considerable success in penetrating various application fields. Absolutely. Alsys and Rational and others have had greater success in Europe than over here. Most of the non-DoD "success stories" - at least the ones that are discussed openly enough to publish - have been European ones. (Avionics is, I think, the exception - that's been a success story everywhere.) > >Indeed, Jean always thought of Ada as a general purpose language with >possible application to a wide variety of fields. Some people even >criticized Jean for not being sufficiently concentrated on the US DoD >market! But did he pursue the _non-DoD_ US market as aggressively as over in Europe? It's conceivable that he did, but not much has resulted (unless the real non-DoD stories are "under wraps", which is certainly possible). >As for your question of what is more important than the array ordering >matter, I would say two things: > Realiability and maturity (note the posting we already saw on this issue) > Performance. This is a really tough one, Fortran compilers typically have > been squeezed furiously on performance of numerical loops, and are where > you find the most aggressive optimization of this type of code. The > effort of competing in code quality with mature optimizing Fortran > compilers was and is huge and very expensive. I wouldn't claim to be an optimization expert, but I have the impression that those "squeezing" algorithms and heuristics are pretty much language-independent. Am I right on this? And is it not the case that e.g. Ada's clear and highly-regulated FOR statement might even make such optimizations easier for Ada? >You keep saying that what you want to be sure is that vendors did extensive >market surveys of this part of the market. I don't know how much business >experience you have, but this is the sort of thing that is often recommended >by people without such experience. Well, obviously eyes, ears, common sense, and 30 years in computing only take me so far, but in fact these are all I have. Not much business experience, I'll admit. >THe fact of the matter is that meaningful >surveys of markets are VERY difficult and VERY expensive. The trick in a >market like the Ada market is to be able to guess where to go WITHOUT blowing >huge amounts of capital in studies like this that do not turn out to be >useful. My business naivete may be showing again, but if this is the case, it might've been effective for the vendors to pool their marketing (as opposed to sales) dollars. That is the theory behind this Ada 9X-sponsored _marketing_ campaign - to raise awareness of potential untapped market sectors. But an association of vendors could do that without federal dollars. It would have been in everyone's interest to do so, by the "rising tide lifts all boats" theory. Is it naive to contemplate a market survey done by a group of companies that set aside their competitive instincts long enough to do this? Clearly the government's intent is to turn this stuff over to the newly-formed ARA. Will ARA pick up the ball and run with it? Back to the point. So have the successful software companies just been lucky? Maybe _no_ company whose only or main products are compilers and surrounding tools can be _really_ successful, because there are only a relatively small number of developers. The real money is in end-user products, I guess. >My own feeling is that the performance issue was so central at the time, >that there was little chance for Ada to make serious headway (one of the >problems with the Cray compiler was that, espeically early on, it was a >little bit less efficient than Fortran). Well, I guess it's hard for immature Ada compilers to compete with mature Fortran ones. Yet, if indeed engineers are moving to C, the C compilers must be efficient enough to meet their needs. >As to why numerical people are moving to C, it is partly because they are >moving to work stations where C is perceived as part of the general >environment, and yes, I do think this represents an opportunity! OK, let's go for it! Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-20 3:23 ` Michael Feldman @ 1994-12-20 14:09 ` Robert Dewar 0 siblings, 0 replies; 32+ messages in thread From: Robert Dewar @ 1994-12-20 14:09 UTC (permalink / raw) Mike wonders about the difficulty of applying traditional fortran optimization techniques to Ada. There is no conceptual problem in writing highly optimizing Ada backends. I don't think the "highly structured for loop" of Ada is any particular help, it is essentially identical to the do loop of Fortran in any case. THe only conceptual problem arises as a result of the dynamic lower bounds, which threaten to generate extra instructions in some cases, although address reduction in loops will generally eliminate this extra work in most loops. Another approach is to use virtual origins for arrays, which is our eventual plan in GNAT. The difficulty is that the amount of technical resources to do a highly optimizing backend of this case is HUGE, and I can't believe it would have been worth the investment of tens of person years to develop Ada optimization to this level, especially early on. Furthermore, such an expenditure of effort would have harmed stability and reliability. Fortran users tend to be more concerned with speed than with reliability (the infamous Cray division which gives wrong results very fast is an indicator of this general attitude), and that of course is the wrong way round for most Ada users. Obviously the way to get high performance is to borrow an existing backend, which of course is what we have done with GNAT. The performance of GNAT for a simple arithmetic loop should be entirely comparable to that of GNU Fortran or GNU C, which is pretty darned good, but probably STILL not as good as the really hot commercial Fortran compilers on which huge optimziation efforts have been spent. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Array mappings 1994-12-19 2:01 ` Michael Feldman 1994-12-19 3:41 ` Robert Dewar @ 1994-12-19 19:10 ` Matt Kennel 1 sibling, 0 replies; 32+ messages in thread From: Matt Kennel @ 1994-12-19 19:10 UTC (permalink / raw) Michael Feldman (mfeldman@seas.gwu.edu) wrote: : >Ada 9X requires this support. Whether that requirement is justified : >remains to be seen. That will really show whether Mike is right. If we : >see a huge army of Fortran programmers suddenly saying "great, now that : >I can write my subscripts the "right" way round in Ada 95, I will switch : >to using Ada", then we will know that Mike was rigt, and that Ada vendors : >missed an important opportunity. Well maybe it is a bit too late now since, : Well, given that F90 provides nearly all the language maturity that : an engineer would need, not quite, but given F90 is such an enormous improvement over f77 in many of those particular problem areas that might have motivated Fortran programmers to switch to Ada83, it will be harder now. ; I see it as rather unlikely at this point. : I don;t think the array subscript issue is the only adoption barrier, : but the aggregate of this and other issues (the lack of a quasi-standard : math library, for example) contributed, I'm sure. Actually, I think that : in this as in other domains where Ada has poor penetration, the barriers : were mostly nontechnical. But certainly fixing the obvious technical holes : might have taken some excuses away. It also sends a little bit of the right signal "We care about you." Indeed, I'm personally surprised that Ada83 didn't do this. Given my vague prejudices as being of "Supposed to be used for DOD stuff" (which includes lots of numerical simulation) and "has nearly every feature known to man in 1980" :-+ I would have thought that at least Ada would do it even if nothing else did. : >Note: Many Fortran programmers are moving to C, C doesn't have any help : >for Fortran array ordering, and I never heard of this being an adoption : >barrier. Oh sure it is. It's just that sometimes other benefits are better and you have to make a tradeoff. I've never heard of anybody *liking* the fact that they can't do things as they're used to in fortran, or that C pointers may be aliased. Other reasons to move to C are that common GUI libraries and Unix system library calls are nearly natural in C. : Mike Feldman -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Why don't large companies use Ada? 1994-12-06 13:06 Why don't large companies use Ada? Paige Vinall 1994-12-07 14:15 ` Norman H. Cohen @ 1994-12-09 2:31 ` Michael Feldman 1 sibling, 0 replies; 32+ messages in thread From: Michael Feldman @ 1994-12-09 2:31 UTC (permalink / raw) In article <9412061309.AA02026@ajpo.sei.cmu.edu>, Paige Vinall <vinall@VNET.IBM.COM> wrote: >If an ISUB dfined array is passed to a procedure, PL/I >will compute an image of it. That's what I thought. >>Has PL/1 supported ISUB all along? I do not remember it from my >>PL/1 days 20 or so years ago. >I think so. OK, fine. This is a very different animal from representing the array in Fortran-friendly terms in the first place. Since Ada allows the implementer to choose the representation, she can choose column-major. Mike Feldman ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~1995-01-03 3:26 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1994-12-06 13:06 Why don't large companies use Ada? Paige Vinall 1994-12-07 14:15 ` Norman H. Cohen 1994-12-10 20:55 ` Array mappings Michael Feldman 1994-12-13 15:01 ` Norman H. Cohen 1994-12-16 18:55 ` Michael Feldman 1994-12-17 0:43 ` Keith Thompson 1994-12-17 17:17 ` Reaching traditional engineering, was: " Michael Feldman 1994-12-18 1:34 ` Robert Dewar 1994-12-19 2:11 ` Michael Feldman 1994-12-21 16:17 ` Kevin Weise 1994-12-21 13:29 ` David Emery 1994-12-22 2:40 ` Michael Feldman 1994-12-22 10:20 ` Reaching traditional engineering Introspect Technologies 1994-12-22 20:49 ` Richard Riehle 1994-12-23 9:09 ` Peter Hermann 1994-12-27 3:37 ` Reaching traditional engineering, was: Array mappings Richard G. Hash 1994-12-17 20:42 ` Rolf Ebert 1994-12-19 2:19 ` Michael Feldman 1994-12-19 3:46 ` Robert Dewar 1994-12-19 5:53 ` Mark S. Hathaway 1994-12-19 14:27 ` Robert Dewar 1994-12-22 17:08 ` Richard G. Hash 1995-01-03 3:26 ` Fred McCall 1994-12-17 17:41 ` Robert Dewar 1994-12-18 0:03 ` Dik T. Winter 1994-12-19 2:08 ` Michael Feldman 1994-12-19 2:01 ` Michael Feldman 1994-12-19 3:41 ` Robert Dewar 1994-12-20 3:23 ` Michael Feldman 1994-12-20 14:09 ` Robert Dewar 1994-12-19 19:10 ` Matt Kennel 1994-12-09 2:31 ` Why don't large companies use Ada? Michael Feldman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox