eugene@pioneer.arpa (Eugene Miya N.) (08/19/87)
>In article <1065@vu-vlsi.UUCP> harman@vu-vlsi.UUCP (Glen Harman) writes: >> ... discussion about Ada and C for aeroSPACE ... > In article <12513@clyde.ATT.COM> spf@moss.UUCP (Steve Frysinger) says: >Learn them both. I hate these cross-referenced posting, but I recognize this as a vocational question not just a technical question. I also recognize that few people who are really using Ada have responded. I sent Glen mail, but I realize others will ignore it. First, vocation, I agree with Steve: learn both, or the ideas of both. What the Glens of the world have to realize is that companies don't hire you just because you know C or Ada, they hire you because you are supposed to be bright and flexible (gleem!). The world is trending toward multi-lingual programming environments: using many languages to solve problems [I'm even learning Icon now]. That is the point. No single language will solve all your problems, they are not designed that way. Second, policy. This is the real reason why I wanted to post this. In the case of the Space Station (note caps), the word very high is any software developer writing for the Station MUST use Ada. Recently, the AI groups in NASA had this dropped on them: no LISP (for Station). None what so ever. [I won't debate the intelligence of this decision.] Control is tight. This does not mean C won't fly on some self-contained packages, but it does set the tone (from pre-flight reviews) of the main Station software. This in turn affects other projects (excepting certain HAL/S based projects like Shuttle). If you want to work in aerospace (military or not), you can't ignore Ada. But learn other languages and be flexible. From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene
g-rh@cca.CCA.COM (Richard Harter) (08/20/87)
In article <2537@ames.arpa> eugene@pioneer.UUCP (Eugene Miya N.) writes: >Second, policy. This is the real reason why I wanted to post this. >In the case of the Space Station (note caps), the word very high is any >software developer writing for the Station MUST use Ada. This raises a question -- are there any C to Ada translation programs. We (SDMS Inc. CCA is just the machine that we use for Vax BSD work) have a product that sells into people who sell into DoD. My opinion of Ada is not germane; at some point we are going to have to come to terms with Ada and we may have to deal with the prospect of converting to Ada for some markets. I expect that other software vendors are in the same boat. Does such a package exist? Are there rumors that somebody is doing it? Any information on the possibility would be of interest. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
palmer@tybalt.caltech.edu (David Palmer) (08/20/87)
In article <2537@ames.arpa> eugene@pioneer.UUCP (Eugene Miya N.) writes: >Second, policy. This is the real reason why I wanted to post this. >In the case of the Space Station (note caps), the word very high is any >software developer writing for the Station MUST use Ada. Epigram: Ada is the 400-pound gorilla of programming languages. From the fortune cookie factory of David Palmer palmer@tybalt.caltech.edu ...rutgers!cit-vax!tybalt.caltech.edu!palmer The opinions expressed are those of an 8000 year old Atlantuan priestess named Mrla, and not necessarily those of her channel.
kent@xanth.UUCP (Kent Paul Dolan) (08/21/87)
In article <19093@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: >In article <2537@ames.arpa> eugene@pioneer.UUCP (Eugene Miya N.) writes: >>In the case of the Space Station (note caps), the word very high is any >>software developer writing for the Station MUST use Ada. > >This raises a question -- are there any C to Ada translation programs. >We (SDMS Inc. CCA is just the machine that we use for Vax BSD work) have >a product that sells into people who sell into DoD. My opinion of Ada >is not germane; at some point we are going to have to come to terms with >Ada and we may have to deal with the prospect of converting to Ada for >some markets. I expect that other software vendors are in the same boat. I'm sure such a translator could be written and may well already have been written. Using it would be the highest kind of foolishness, however. Ada(tm) is not just another way to write C, or FORTRAN, or COBOL. Ada, by design, embodies the "best informed understanding" of what a programming language needs to support the wisdom developed by software engineering theoreticians and practicioners. Used correctly, it can provide spectacular benefits. I sat in on a presentation in about 1984 by a vendor of business software of the typical "20% development costs, 80% maintenance costs" breed who detailed converting a suite of programs from Pascal (a rather nice to maintain language itself) to Ada, and saving 7/8ths of his maintenance costs! That is a better than two thirds cost savings over the lifetime of the code. This is what DOD paid for when they bought Ada, not just a mechanical translation with the same old maintenance headaches in the new program as in the old. I don't think "translated" programs would get a very friendly reception (I sure hope not); software needs to be rethought, and rewritten from scratch, fully using the software engineering tools that Ada provides, to bring Ada's benefits to the user/customer. Sorry to be so dogmatic about this (can you say "True Believer"?), but I've been through two mainframe conversions (one federal, one private) that used mechanical code translation, and it was a mistake, even when the translation was COBOL 68 to COBOL 74. The code ends up _less_ maintainable, not more, as the idiot machine butchers the carefully hand formatted comments, ignores improvements provided in ways to do things by the new language, and generally just blunders along. Kent, the man from xanth.
"VAXID1::VAXID1::MRGATE::\"A1::TUFFS1\"@atc.alcoa.COM" (08/21/87)
From: NAME: P. S. TUFFS FUNC: PCCT (16) TEL: (412) 337 2946 <TUFFS1 AT A1 AT VAXID1> An article from "ihnp4!wlbr!etn-rad!jru" (I don't know who this is since no name or paper address was given) comments: > ... Don't expect to see ADA used very widely outside of the DOD >environment... and goes on to argue that the reasons for this are that IBM dominates the commercial sectors and that COBOL will therefor remain the dominant language. Probably true, I don't have too much feel for the business end of the commercial sector. However, I feel compelled to add that I noted with joy the apparent endorsement of Ada by IBM, when they adopted a third party Ada compiler. This seems to me, a dedicated *non* IBM user, an indication that even IBM will adapt under pressure from the largest procurer of computer systems in the world, the Department of Defense. One more point, before you all die of boredom. There is a large installed base of computer systems in the commercial sector, programmed and used by Engineers who think that COBOL is some kind of radioactive isotope. Most of the computers they use have been programmed in FORTRAN, and I sincerely hope that Ada will replace FORTRAN in the engineering sector. Finally, how many organizations still believe in "roll-your-own" software from the ground up? My perception is that the commercial sector is adopting packages such as Lotus for some of their business work, and as these packages become better, surely they or something like them will replace COBOL. ----------------------------------------------------------------------- HANDLE: Simon Tuffs CSNET: TUFFS@ATC.ALCOA.COM PAPER: P.S.Tuffs, Alcoa Technical Center, Alcoa Center, Pa 15069 AT&T: (412) 337 2946 Disclaimer: These ideas are mere ramblings, and if they bear any relationship with reality I will be extremely surprised. They do not necessarily represent the views of my organization (but maybe one day they will).
blackje%sungod.tcpip@GE-CRD.ARPA (08/25/87)
Received: by sungod.steinmetz (3.2/1.1x Steinmetz) id AA02000; Tue, 25 Aug 87 10:18:39 EDT Date: Tue, 25 Aug 87 10:18:39 EDT From: emmett black <blackje@sungod> Posted-Date: Tue, 25 Aug 87 10:18:39 EDT Message-Id: <8708251418.AA02000@sungod.steinmetz> To: info-ada@ada20.isi.edu Subject: Re: "C" AND Ada concerning translating other languages to Ada -- I do sort of agree with Kent (the man from xanth) that converted programs should be "rethought" rather than just automagically and blindly translated.. And I also agree that those Cobol conversions he mentions create code that is less maintainable than the original... However, I do not quite agree that we should extend that observation into Ada... If you JUST blindly translate from some language into Ada and stop there -- then I still agree -- it's a mistake. But we did a FORTRAN to Ada translator -- which I thought was a mistake at first -- and did use it to translate a buncha stuff... and you DO get "BAD Ada" -- (GIGO, remember?) -- but DONT STOP THERE -- that bad Ada turned out to be significantly more useful in spotting all the nasties the FORTRAN programmers had slipped into the code and in providing a means for "reverse engineering" the FORTRAN -- making it EASIER to RETHINK and rewrite the old program -- because it was easier to get a grasp on what the original program was supposed to do in the first place. If somebody tried to turn in that first pass automagically translated into Ada program -- they should get a really unfriendly reception... but if they use that as a means to accelerate the re-engineering, then they did OK. --Emmett BlackJE@GE-CRD.ARPA