home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / ada / 3954 < prev    next >
Encoding:
Text File  |  1993-01-12  |  3.0 KB  |  66 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!think.com!linus!linus.mitre.org!linus!mbunix!eachus
  3. From: eachus@goldfinger.mitre.org (Robert I. Eachus)
  4. Subject: Re: First-Time C
  5. In-Reply-To: garyp@rmtc.paramax.com's message of Mon, 11 Jan 1993 21:06:36 GMT
  6. Message-ID: <EACHUS.93Jan12104230@goldfinger.mitre.org>
  7. Sender: news@linus.mitre.org (News Service)
  8. Nntp-Posting-Host: goldfinger.mitre.org
  9. Organization: The Mitre Corp., Bedford, MA.
  10. References: <1993Jan11.210636.8396@gvl.unisys.com>
  11. Date: Tue, 12 Jan 1993 15:42:30 GMT
  12. Lines: 52
  13.  
  14. In article <1993Jan11.210636.8396@gvl.unisys.com> garyp@rmtc.paramax.com (Gary Palangian [RMTC/ISP]) writes:
  15.  
  16. >       Our customer is probably going to make a decision to move from
  17. >   Ada to C on my project...
  18.  
  19.    I find this statement very confusing...  There are some projects,
  20. even very large projects, where progamming everything in Ada is
  21. appropriate.  There are other projects, especially small projects,
  22. where doing everything in C makes sense.  But I cannot imagine a
  23. project where switching from all Ada to all C makes any sort of sense.
  24. The most time and effort in an Ada project is in the design phase, the
  25. most time and effort in a C project is usually spent in integration
  26. and test.  Switching from Ada to C would seem to guarentee the worst
  27. of both worlds.  (It would be nice if design in C, code and test in
  28. Ada was the BEST of both worlds, but I don't think that free lunch
  29. exists.)
  30.  
  31. >       I would appreciate concise and concrete information for
  32. >  managing large systems development using C, especially from those
  33. >  with an Ada background.
  34.  
  35.    Don't, use Ada instead!  (So much for concise and concrete. :-)
  36.  
  37.    If you need to do this for a large system, using Ada as a
  38. compilable design language has a lot of advantages, but you must both
  39. restrict the Ada used and maintain the design during the coding
  40. process.  This works well but can cause personnel problems.  Everyone
  41. ends up knowing both Ada and C if they didn't when the project
  42. started, and from experience unwilling to work on another C project.
  43. (Try spending a couple of years seeing all the advantages of Ada, but
  44. none of the disadvantages, and vice-versa for C.  It's not fair, but
  45. that's the way one project I know of that did this ended up.  This was
  46. back in 1984-86, when no compilers supported the chapter 13 features
  47. needed for a DBMS so it was a "right" decision.)
  48.  
  49.    The best of all possible worlds for your project, however, may be
  50. to mix Ada and C.  Use Ada for the high-level design and structure,
  51. and whenever appropriate write the (function) bodies in C.  This
  52. allows you to use the strengths of both languages which are in very
  53. different areas.  (You will also find that most of the bugs are in the
  54. C code.  For the most part this will be because the parts where C is
  55. most appropriate are the trickest routines to get right in any
  56. case...)
  57.  
  58.     Have  fun,
  59. --
  60.  
  61.                     Robert I. Eachus
  62.  
  63. with Standard_Disclaimer;
  64. use  Standard_Disclaimer;
  65. function Message (Text: in Clever_Ideas) return Better_Ideas is...
  66.