mlewis@unocss..unl.edu (mlewis) (11/20/89)
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
---------------------------------------------------------------------------grover%brahmand@Sun.COM (Vinod Grover) (11/21/89)
In article <892@unocss..unl.edu> mlewis@unocss..unl.edu (mlewis) writes: >say understatement? I knew you could. Same for exaggeration: Ada has >only been "around" since '83, not '79. Ada'83 has been around since 82, perhaps earlier in DRAFT form. However, before that was the Ada'80 which became Ada'82.