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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!tank!eecae!upba!dsndata!unocss!mlewis From: mlewis@unocss..unl.edu (mlewis) Newsgroups: comp.lang.ada Subject: misquoting or misreading Keywords: c, articles on ada Message-ID: <892@unocss..unl.edu> Date: 20 Nov 89 03:49:02 GMT Organization: U. of Nebraska at Omaha List-Id: Sorry, the original has expired here: Mr. Holden writes [a bunch of one-sided garbage including:] ]have to be able to read between the lines, but this isn't terribly ]difficult. For instance, a large section of articles in the December 88 ]Journal of Electronic Defense began with the title "Ada: Maybe Not So Bad ]After All". Remember, Ada has been around since 1979. If that were the ]best anybody could say about C after ten years, C compiler salesmen would ]be starving and dying like flies. Yes, it helps to be able to read between the lines, but then it also helps to be able to read what's ON the lines. Ada has been bad-mouthed as the PL/1 of the nineties since it was first proposed, and the title implies that maybe there is some benefit to be gained from using Ada, a clear conclusion presented by the editorial with that title. Can you say understatement? I knew you could. Same for exaggeration: Ada has only been "around" since '83, not '79. ]Another article in the same issue describes the use of Ada in connection ]with a real-time embedded digital signal processing application. Since ]Ada tasking could not be made fast enough for such work, the engineers ]adapted a commercial run-time system, VRTX, and informed all programmers: ] "Thou shalt not use Ada tasking, but rather VRTX tasking. ] "Thou shalt not use Ada dynamic memory allocation... ] "Thou shalt not use Ada generics; too slow... Yes, the time-frame of that project was such that (as clearly stated in the article) there was ONLY ONE COMPILER AVAILABLE. On that compiler, rendezvous took 15 msec, rather than the 1 msec required by the project, which necessitated the use of VRTX to handle the high-speed task scheduling. However, at the end of page 45, it says "After acquiring an improved runtime performance compiler, the software services package was implemented completely using Ada tasking and rendezvous features." The tasking restrictions were based on a limitation in the single Ada compiler available, the dynamic allocation restrictions were a result of the "fix" applied to that limitation: VRTX. Generics were not restricted. The application was NOT DSP, btw, but the control processor for a DSP system. The implication is that had Ada been available for a TMS320, the DSP would have been done in Ada as well. ]... Needless to say, the Rube-Goldbergesque system they ended up with was ]considerably less maintainable than they might have gotten just using C. If that is the case, then it needs saying. There was no mention of maintainability in the article. Whence comes this conclusion? The authors clearly liked Ada, and would not have done the job any other way. Indeed, the biggest problem I read "between the lines" was that their programmers were programming in some language (probably C or Fortran) and coding the programs in Ada. The first item under the heading "Lessons Learned" is: "Do not underestimate the importance of *properly* learning the language." (emphasis mine). But, let's see what else was NOT between the lines in this article: "...Ada takes a long time to design and code. Once on the target hardware, however, Ada requires significantly less effort to complete integration and test." "...the use of Ada resulted in a 12% increase in productivity over assembly language and 27% over C." (That is the single most concise condemnation of C I have ever seen... :-) The authors of this article are Hassan El-Ghoroury and Patrick Marsh, of M/A-COM Government Systems. The author of the editorial Mr. Holden didn't read is Dr. Hugo Poza, VP of Avionics for Lockheed/Sanders Associates. I have been lurking here for about a month, since I was offered a job which requires that I learn Ada. The more I play with it, the more I like it. I dislike C in all its thousands of dialects, but would like to point out a very minor difficulty with Mr Holden's comparison between C and Ada. C was (by Mr. Holden's argument, as well as historical documentation: ie., he's right) designed to run efficiently ON A PDP MACHINE. As was Unix. That these two systems run on other architectures at all well is a tribute to 21 years of development by thousands of HACKERS (in the proper sense of the term). Give Ada a few more years to mature. Ada was not designed with a specific architecture in mind at all, and so is inherently more portable than C. But I am not here to bash C. I just wanted to point out that if you are going to slam something, especially by comparison, you best have ALL your ducks lined up nicely, or they might turn around and shoot back. My only problem with Ada at this point is the cost ($ and hardware resources) of a compiler for my XT clone. Both IntegrAda and Janus require more memory than DOS 4.01 leaves available. This is BAD DESIGN. There is no excuse for a 551K executable in a PC (pass 2 of Integrada). Janus Ada requires >580K available to run, and rumor has it that the Integrada compiler is a repackaged Janus compiler. Have a nice day. Marc -- --------------------------------------------------------------------------- Na khuya mne ehto gavno? | Internet: cs057@zeus.unl.edu preferred machine->| UUCP: uunet!btni!unocss!mlewis ---------------------------------------------------------------------------