Re: C is 'better' than Ada because...

[Craig Franck <clfranck@worldnet.att.net>]

Richard Riehle <rriehle@nunic.nu.edu> wrote:
>On 10 Aug 1996, Craig Franck wrote:
>
>> I agree with that, if you include PC programming as "a certain class of
>> problems". Most PC OS's are written in C/C++. It makes sense that
>> applications would then be coded in C/C++ as well.
>
>  No. Sorry. xin l^oi. Does not make sense. This statement reflects a
>  fundamental lack of understanding of selecting the right tool for
>  the right job. It also fails to recognize the importance of abstraction.
>
>  For example, for mathematical problem solving, there is a plethora
>  of better alternatives to C++.  For database solutions, C++ is far
>  behind the many available alternatives.

I agree that you are much better off using a database language for
database programming, no arguement there. You are also correct that if
other languages are available that are more suitable for the problem 
at hand, you should use them. There are trivial reasons for programming
both OS and applications; the strings might be represented in the
same fashion and the subroutine linkage would be the same. Also heavy
UNIX use forms a bias as well; it's helpfull to read the source code for
a system function to gain understanding of what the OS is up to. The 
ability to change and recompile the kernel is nice, but from the
point of view of real world software, this kind of fooling around
probably does more harm than good! I feel that the level of support 
for C/C++ on Windows and UNIX platforms is the best of any language.
Yes, you can program in Ada on a UNIX platform but I would point 
out that the compiler is written in C. If C/C++ are your primary 
languages for writting system software, when it's time to write
an application that might seen like the best language to use.
This is a bias on my part that, though I can not defend it, I 
find myself falling victim to time and time again. Like when I'm
writing : how many OSs or compilers are written in Ada? And not as
an acedemic exercise to prove it is possible, but in actual use?
 
>  The criteria selecting a programming language should include the
>  question, "How well does the language map to the problems I am
>  trying to solve?"  By problems, I mean the application problem, not
>  the computer problem.  If I am trying to solve a problem which
>  involves massive multi-dimensional matrices of with run-time
>  indeterminate magnitude, I would be best served by a language
>  and its associated libraries which map most directly to that
>  problem.
>
>  I regard C++ as just too flaky, for example, to be used for
>  safety-critical software. If it is OK to reboot when something
>  goes wrong, go ahead and use C++. If lives depend on the quality
>  of your software the selection of C++ is just short of insane.
>  Just my opinion, but not an opinion arrived at lightly.

Well alot of the code for the telephone switching system is written 
in C/C++. The system did become unstable do to (how ironic!) a poorly coded
switch statement back in 1990, but on the whole I don't think there
is much rebooting going on of the switching systems mainframes. If
I were to ride on the space shuttle, I would be concerned with how
well the software was written and tested, not what language it
was written in. Though some languages lend themselves to hard to 
catch problems and many subtle distinctions that take a while to
master. 
>> Pascal has more
>> support than Ada does in this area. I don't know of a vendor supporting
>> those platforms in Ada as well as is done with C/C++. So you go with
>> C/C++ due to the quality of the impementation, not the language.
>
>  For desktop systems such as Windows 95 and NT, this is probably not
>  far off. Support, even for MS-DOS, has not historically been as
>  strong in Ada as it has in other languages. This is changing, and
>  software publishers are escalating their support for tools and libraries
>  to make Ada more attractive on the desktop.
>
>  On the other hand, for safety-sensitive embedded systems, this is not
>  true.  Ada is clearly a superior alternative to C++ when it comes to
>  safe software, even though C++ continues to be used in this application
>  domain.  The original problem of poor management of the Ada policy by
>  the Department of Defense is difficult to overcome, but it is important
>  that we do overcome it in the interest of public safety.

Well see above, and call AT&T and tell them that that they better get 
started writing everything in Ada right away! :-) It is true that
Ada was designed from the start to yield better programs. Though it
was based on existing languages, there was no legacy code to have to
maintain when justifing language aspects. When the ANSI standard was
submitted for public review, I believe the strongest objection was 
that the language was *huge*, and this was before OO extension were
added.

>> I would also like to point out that technical superiority is not always
>> a good indicator of success.
>
>  No argument there.
>
>  [snip, snip ]
>
>> system that it is an Ada compiler. To even call it an Ada compiler it
>> must pass a validation suite.
>
>  Exactly!  Though passing validation does not ensure total quality, it
>  is a first step in that direction.
>
>> The problem information systems managers have is today you must
>> incorporate PC users. Why develope a schizophrenic additute of doing
>> one with the domant tool (C/C++) and the other with Ada? I can see keeping
>> working in COBOL, but if you were to switch, switch to C++.
>
>  Au contraire. Ada is unique in its direct support for legacy COBOL
>  systems through a set of data types, Annexes, and other pre-defined
>  packages.  In fact, no contemporary object-oriented programming
>  language is as hospitable to COBOL as Ada. Ada is a perfect fit for
>  the Information Systems Manager seeking solutions for modernizing
>  exisiting COBOL-based software.
>
>> I don't think AT&T is going to start coding thier switching systems
>> in Ada just because it a better language, either.
>
>  I am manifestly unimpressed by this argument.

For more unimpressedness, manifestly or otherwise, please reread above. :-) 

>> >  Today's C++ software is tomorrow's legacy system.
>> >
>>
>> Doubtfull, very doubtfull
>
>  After all is said, we can be assured that 100 years from now, our
>  successors, whatever they might be called, will regard our efforts
>  at designing software languages with the same high esteem we reserve
>  for mathematicians in the time of Charlemagne.

It is important to have a historical perspective on things.


Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...