Re: Programming language vote - results

["Gary L. Scott" <scottg@flash.net>]

Sorry, this is a little off-topic...

Robert S. White wrote:

> 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.

Of course, this was partly a problem of "design philosophy".  The
problem was that they didn't seem to know when to stop in the low level
routines.  But they eventually found a happy medium.  Spent a lot of
money doing so though.

>
>
>   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.

That was my point.  "OO" not Ada specifically.  By the time the project
is over, the hardware will be obsolete (actually already is in terms of
commercial products (CPU speed anyway)).  So the schedule has basically
extended beyond what was originally intended as the middle of its life
span with no product in sight, lots of money spent.  We could have just
rehosted the JOVIAL and saved schedule, money, and had significantly
more reserve in the computer at completion.

>
>
> >..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?

Well, early on they had to turn off optimization in order to figure out
why nothing was working.  To be fair there were significant hardware
problems as well that had to be worked around in software.

>
>
> >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?

Depends a little on your point of view and the design of the code.  The
JOVIAL code is a lot easier to read/understand than the Ada code.  This
by itself can lead to advantages in terms of maintenance.  We have been
able to create very "modular" JOVIAL code which can essentially be
dropped in/taken out with little impact to other functions.  This is as
valid of an approach as true "OO" in many cases.
_____________________________________________________________________

> Robert S. White         -- An embedded systems software engineer
> e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter



--
Gary L. Scott
scottg@flash.net