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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11390f,4c42ac518eba0bbe X-Google-Attributes: gid11390f,public X-Google-Thread: fd7c9,4c42ac518eba0bbe X-Google-Attributes: gidfd7c9,public X-Google-Thread: 103376,4c42ac518eba0bbe X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,4c42ac518eba0bbe X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,4c42ac518eba0bbe X-Google-Attributes: gid109fba,public X-Google-Thread: 1094ba,4c42ac518eba0bbe X-Google-Attributes: gid1094ba,public From: nospam@somewhere.ia.us (Robert S. White) Subject: Re: Programming language vote - results Date: 1997/10/13 Message-ID: <61uc5n$o3i$1@flood.weeg.uiowa.edu>#1/1 X-Deja-AN: 280294781 References: <343fbb5a.0@news.iprolink.ch> <343FD05C.8986A557@flash.net> Organization: designing/implementing avionics during the day Newsgroups: comp.lang.ada,comp.lang.apl,comp.lang.c,comp.lang.c++,comp.lang.forth,comp.lang.fortran Date: 1997-10-13T00:00:00+00:00 List-Id: In article <343FD05C.8986A557@flash.net>, scottg@flash.net says... > >Oh the horror stories about Ada just about anyone in the defense >industry could tell you...(inefficiency, bloat, development delays, >budget overruns)...I dare you to fit a Jovial application that already >max's out a computer's capabilities in the same box using OO techniques >in Ada. I bounce between Jovial (worse yet J73/I) and Ada all the time at work. Yes _some_compiler implementations are not as good as others - but others are just fine. Ever look at the code quality of Tartan Ada? Don't blame the language when coders go OO beserk. In _real_life_ we watch our processor utilization carefully and use pragma inline and turn off runtime checks in the "hot spot" code routines. You _can_ use Stucture Analysis with Ada to come up with an equivalent software design just like you used to get with Jovial. But it is so much easier to maintain and modify software that is designed with an object oriented (or at least object based) high level structure. You do have to know when to stop at low level routines, have to watch out for inefficiencies from virtual dispatching (avoid late binding), heap usage, and subroutine nesting. But the problem you describe with an already "max'd out" application written in Jovial (or C) using older Structure Analysis/(functional decomposition), would also have problems if you used any other OO capable language (C++, Eiffel, Delphi, etc.) and OOA/OOD without concern for processor utilization. >..In fact, multiply memory and CPU throughput by 10 and try it. I have seen an Ada implementation take about 10 - 15% more (1.1x to 1.15x) than a very mature (very efficient code) J73/I compiler on same processor target when equivalent compiler switches thrown. Never - never have I seen a 10x case due to the compilers alone. Even way back in 1984 with early immature compilers worse case max was 3x. Did your compiler that you are complaining about even have peephole optimization? >You will likely be forced to back off OO quite a bit, making an even >bigger mess of maintainability/reusability... And the original Jovial was wonderful in those areas? _____________________________________________________________________ Robert S. White -- An embedded systems software engineer e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter