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.