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=1.6 required=5.0 tests=BAYES_00,INVALID_DATE, TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!samsung!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!haven!grebyn!ted From: ted@grebyn.com (Ted Holden) Newsgroups: comp.lang.ada Subject: Re: A farewell to Ada Message-ID: <14040@grebyn.com> Date: 21 Nov 89 20:11:53 GMT Organization: Grebyn Timesharing, Vienna, VA List-Id: From: mlewis: U. of Nebraska at Omaha >]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." Okay, I missed that sentence. I have heard this same basic story several times from friends with no mention of happy endings and didn't expect one; nor is this truly a happy ending. A happy ending would read that they simply used ordinary, good, reliable tools and solved their clients problem, not that they spent ten units of time dealing with a language for each three solving problems and then had to rewrite a major piece of their package when industry finally managed a lame response to a non-sensical mandate. The question of whether the new system resolved any problems regarding Ada memory allocation or generics was left up in the air. >]... 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... :-) Again subjective, again rubbish. I've heard too many people say that their projects simply could not be written in Ada at all, that the inherent clunk factor is just too great. Beyond that, you're leaving out a few things "on the lines": 1. "The host environment usually has better computing resources than the target. For example, the VAX is faster and uses 32-bit words while the 8186 is slow and uses 16-bit words. Thus, if care is not taken, this will lead to units which appear to operate correctly on the host when unit-tested but do not perform the same way on the target". So much for the Ada "standard'. 2. "Ada programmers need to understand how some of the most-used language constructs are compiled into target hardware instructions. An example is the number of arguments in a procedure call. The runtime performance of such a construct will be heavily influenced by the number of arguments vis-a-vis the number of registers the target processor has..." Why is it that C programmers don't have to walk around worrying about this kind of thing?? 3. "Table 1 shows a comparison of the percentage of the total effort for the development of three computer software configuration items: SCOTT Ada control processing CSCI, SCOTT assembley language digital signal processing SCSI, and another M/A-COM CSCI written in C..." This is obviously the same old approach to government affirmative action programs (here, for Ada); the Software Services CSCI was the token Ada module. Very obviously, for purposes of simplicity and/or portable code, any attempt to have the entire project in the same language could only have been achieved in C. >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. Your solution is technically superior and, yet, it runs two orders of magnitude slower than the old way? And you've only had since 1979 (the actual Ada spec) to get your act together? Why doesn't that sound right?? >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. Not in the case of Ada. Dead ducks don't bite (or shoot). >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. That seems to be the normal situation with Ada. Ever wonder why? >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. C users have no such problems. Ever wonder why? >Have a nice day. >Marc >-- >--------------------------------------------------------------------------- >Na khuya mne ehto gavno? | Internet: cs057@zeus.unl.edu Edinctvyeniy vid govna v etom mecte - Ada > preferred machine->| UUCP: uunet!btni!unocss!mlewis >--------------------------------------------------------------------------- Have a nice day, Ted Holden HTE