From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8c8bbb1419c8e81a X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Waiver question Date: 1997/04/21 Message-ID: <335BB40D.4FD2@lmtas.lmco.com>#1/1 X-Deja-AN: 236445010 References: <33585385.C8D@lmtas.lmco.com> Organization: Lockheed Martin Tactical Aircraft Systems Newsgroups: comp.lang.ada Date: 1997-04-21T00:00:00+00:00 List-Id: Robert Dewar wrote: > > Ken said > > << * DSP engineers would rather program in C++ than Ada, since it > makes them more valuable in the larger commericial marker. As a > result, there is much higher attrition when DSP engineers are > required to program in Ada, and so the development cost is higher. > > * Most DSP tools are for C/C++. The number of DSP tools for Ada > will shrink, given that the DoD has decided not to mandate Ada > anymore. > > * Most existing DSP code is in C/C++. Therefore, reuse is easier > if the new code is also written in C++. > >> > > The first argument seems pretty bogus to me -- Ken, is this just a guess, > or is it based on informal ancedotal experience (if so I have anecdotes > to refute it), or is it based on hard data -- if the latter, ;et's see > the data. According to the waiver request, this statement is based on 40 exit interviews at the company in question. If you know of a significant pool of DSP programmers who want to work in Ada, or don't want to work in C++ (or both), that information would be useful. > The second argument is also speculative. From where I sit it seems likely > to be quite wrong. Again, you need data to back his up. For the TI DSP family, I know of only one Ada 83 vendor (TI/Tartan) and no Ada 95 vendors. The AdaIC databases confirm my understanding. There appears to be more than one C/C++ vendor (TI is one) for this family, however. The request does not cite a specific number. There does seem to be a lot of DSP support tools that are oriented to C/C++; see http://www.embedded.com/97/sr9704.htm This does not make a strong case for Ada for this class of DSPs. Of course, if someone has data that indicates that Ada support for TI DSPs is growing, or that C++ is small/declining, that would be useful information. > The third argument is the only relevant one to consider, and here the > issue is solely whether there are good Ada tools that can interface > to the existing C/C++ code that is to be reused. True, however, the NRC report does point out that having to write Ada wrappers is a disincentive to the use of Ada. Since Ada 83 would have to be used, these wrappers would not be able to take advantage of Ada 95's improvements in this area. This might not be a strong argument by itself, but it does seem to be a disadvantage. > I think that's the only real issue. Rather than make bogus generalizations > about DSP's as a class. The proper issue is to look at the very specific > circcumstances. given the DSP or DSP's to be chosen, what Ada tools are > available, or could be made available, and how well would they work? A > waiver is reasonable or not depending on the answer to this question! > > Remember here that TI recently voted with significant $$$ in their > confidence in the viability and importance of Ada on DSP's. I find > tthat more convincing than Ken's dataless speculations! Of course, I didn't WRITE the waiver; I'm just READING it. No need to get your blood pressure up. :) I hope you're right regarding TI's motives for purchasing Tartan. However, I think we'll have to wait and see what TI/Tartan does with all those $$$s. -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com