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

[jsa@alexandria (Jon S Anthony)]

In article <4vb399$kt8@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> >> 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
> >
> >How would you know?  My guess is that the things have several backups
> >in case of failures (software or hardware).
> 
> I know from talking to people, and reading books. A recent popular

Actually, I was refering to the bit (which I screwed up quoting) that
crashes and reboots don't often happen.  Again, this isn't something
you would typically hear about if backups picked up when the primaries
crapped out.


> book discused the notion of the C switch statement as a language defect
> and pointed to the long distance phone service for AT&T becoming unstable. 

Yes, of course, this is a well known case and the C switch statement is
clearly and widely acknowledged to be defective.

[[Historical Aside: Somewhere I think I saw something to the effect
that the C switch statement was a kind of artifact from RATFOR
(another K&R wonder) which used C like syntax but compiled to Fortran.
The story goes that the switch was compiled to computed gotos and used
the "break" as an easy hint to insert the goto to the "drop through
point".  Now, I know that C's immediate predecessors/heritage were B
and BCPL.  (I also know that the original "Software Tools" book was
written using RATFOR.)  So, does anyone know if this is utter rubbish
or has a grain of truth?]]


> >actively helpful to passively benign to actively pernicious.  May as
> >well use the actively helpful.
> 
> The point I was tring to make is you can write bad code in any 
> language. Good programmers and software support are as important
> as the language.

Anyone with a clue knows this and obviously would agree.  This is old
news.  The simple point is that if you have something that helps, why
not use it????

>Puting training wheels on a language by being 
> able to write : FOR I IN Data 'RANGE LOOP
>                   Put(Data(I), 3);
>                 END LOOP;
> because programmers can't count, may be helpfull.

Well, this is not a particularly good example, but it does show that A)
you don't get it and B) that it does help prevent _maintenance_ problems.

The Data'Range construct has nothing to do with being able to count or
not.  It ensures that the loop will work no matter _what_ the bounds
are.  You can change them all you want and the loop will still have
the proper termination condition with no changes.  You can even change
the index type to some enumeration (where counting is just plain
irrelevant).  No problem.  In fact, the bounds can be dynamically
determined and the loop will still work just fine.  In short, this is
a very simple example of _abstraction_ support in the language: No
matter _what_ the bounds are, the loop should process the whole array
and the programmer should not be messing around with the details of
such bounds because they are irrelevant.


> >AT&T is irrelevant.  For several reasons.  Not the least of which is
> >that they have more old dog inertia than is humanly comprehensible.
> 
> AT&T is perhaps irrelevant to you. But for some people Ada 
> is irrelevant. Perhaps it is from irrelevancy that ignorance 
> springs.

Absolutely true.  On all points.


> I feel that as a language becomes larger and larger, learning
> and implementing that language becomes more and more difficult.

First part (learning): False.  If the language is well designed and
orthogonal in its constructs and minimizes feature interaction this is
not true.  For example, learning the "Pascal" or "C" equivalent part
of Ada is as easy (and probably easier because of more consistent
syntax) than learning either Pascal or C.

Second part (implementing): True.


> But maybe its just a legend amoung C programmers that Ada is 
> big.

Well, compared to C, Ada _is_ big.  It has a _lot_ of support that C
just passes over and punts to the implementor or leaves up the
particular implementation.  Compared to Basic, C's big.  Compared to
Prolog C's enormous.  Shrug.


> Well, how well someone is "clued in" on something is a relative 
> thing. I feel I know more about Ada now then when I started posting
> on this thread. If you view this learning process as "ignorance on
> parade" that is fine with me!

I have no issue with "learning" at all.  I have no issue with any of
this really, I just don't understand why the process has to be one of:

a) various false statements asserted as though true
b) Falsity of such statements  pointed out.
a') more false statements asserted as though true.
b') more correction
a'')...
b'')...
...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com