Re: Current status of Ada?

[Gary Scott <garylscott@sbcglobal.net>]

Peter C. Chapin wrote:

> Gary Scott wrote:
> 
> 
>>I don't disagree that this would be an impact of such a line of
>>questioning.  I have no information that this occurred.  It certainly
>>never happened with me.  However, I have discussed these issues with
>>many programmers and it is a somewhat pervasive attitude that not
>>keeping their C language skills honed places them at a competitive
>>disadvantage.
> 
> 
> This is a somewhat surprising attitude to me. Working with various
> languages increases one's repertoire of programming methods and design
> techniques. I should think that given a choice between a person who
> knows C and nothing but C, and a person who has written non-trivial code
> in C, Ada, Java, and (say) Lisp, the second person would be more likely
> to be a better programmer... or a better software engineer.

Yes, Working with multiple languages does.  I however had to do that on 
my own.  In one particular environment (test equipment), all of the 
models, real time data capture/processing, etc. were in extended Fortran 
77 plus imbedded and standaline assembly modules.  It wasn't that C 
would have improved the specific product at all, it was very well 
structured (although non-portable, but it was very hardware specific so 
it wouldn't be portable in any language).  It was the feeling that the 
world was passing them by as EVERYTHING was in Fortran 77.

At one point, the directive to use Ada applied to this environment as 
well so they began porting to Ada.  However, the Ada compiler was so new 
and inefficient (little optimization), the application set would no 
longer execute on a system with several times the memory and CPU 
capacity of the Fortran/assembly based one.  It eventually was 
completed, but this experience negatively tainted management against 
Ada.  No other attemps were ever made that I am aware of to use Ada for 
the test environments.  Likewise, there was no concerted attempt to 
understand WHY the Ada development foundered.  It was of course a 
mixture of operating system inefficiency, compiler inefficiency, and 
software/hardware architecture inefficiency.  The older system used 
extensive proprietary parallel processing, DMA, and shared memory and 
the new system used COTS message passing schemes.  Before the advent of 
fast CPUs, there simply was no other way to accomplish the task in a 
cost efficient manner than to use parallel processing.  With the advent 
of fast CPUs, much less thought goes into the hardware design with the 
thought that the CPU is so fast, we'll just emulate that part of the 
hardware in software or perform its processing job in a separate process 
or thread without really thinking through the overhead (cache 
utilization, interrupt processing, task switching time).

> 
> Peter


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford