[comp.lang.c] Errors aren't that simple

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/01/90)

From marick@m.cs.uiuc.edu:
> There are two assertions in Bill Wolfe's message:
> 1.  The C community releases an unacceptable number of errors.
> 2.  The C language is at least partly the *cause* of those errors.

  3.  Many members of the C community exhibit an unprofessional and
        irresponsible attitude regarding defect control and especially
        defect prevention.   

  4.  Those members of the C community who ARE responsible professionals
        are apparently not taking significant actions to raise the level
        of software engineering professionalism within the C community.  

   The unsafe constructs within C are themselves sufficient evidence to
   conclude that the C community, by choosing to use a language which has
   many highly unsafe constructs and an almost total disregard for error 
   prevention, does not hold error prevention in sufficiently high regard;
   the failure of a password security system because no boundary checks 
   were done on the length of the password (whereupon the intruder purposely
   supplied a double-length password and thereby ensured that the left and
   right sections of the password-validating data structure were compatible),
   and similar cases demonstrate that the C language poses a serious obstacle
   to the development of defect-minimal software.  For the cost of simply
   the recent national AT&T crash, I'd be willing to conjecture that all of 
   AT&T's software developers could have been trained in software engineering
   concepts and the Ada language, and supplied with Ada compilers as well.   

   The comments found in the Unix man pages I cited have been there for 
   at least a decade, apparently going unchallenged by the rest of the 
   C community.  This is despite the fact that the growth of C has been 
   widely attributed to the Unix operating system being given away to 
   so many universities -- if this attribution is correct, then Unix is
   also responsible for helping to create the widespread attitude within 
   the C community that defects are to be treated casually.  

   It is entirely true that other language communities (BASIC, COBOL, etc.)
   have problems along these lines which are arguably worse than those which
   are clearly associated with the C community.  On the other hand, there are
   other language communities which are doing a considerably better job of
   spreading software engineering concepts and providing linguistic support
   for their application (Ada, Eiffel, etc.).  The challenge for the C
   community is to join the language communities which are doing a good
   job in these respects, as opposed to holding its existing reputation
   as a community which contains an extremely high percentage of those who
   regard themselves as hackers, and whose products repeatedly make national 
   headlines with their spectacular failures.  Since C is a language which
   provides little or no support for defect prevention, one would expect
   that the C community would naturally compensate by being extremely 
   careful about always applying the very best software engineering 
   practices.  Unfortunately, I don't think even the most dedicated 
   C-backers would attempt to claim that this is presently the case.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

ekrell@ulysses.att.com (Eduardo Krell) (03/02/90)

In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   For the cost of simply
>   the recent national AT&T crash, I'd be willing to conjecture that all of 
>   AT&T's software developers could have been trained in software engineering
>   concepts and the Ada language, and supplied with Ada compilers as well.   

And what makes you think the network wouldn't have crashed if the software
had been written in Ada (you seem to imply this)? Do you know the details
of the cause of the crash?. You're just speculating that it was related
to the "unsafe" nature of C.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell@ulysses.att.com

peter@ficc.uu.net (Peter da Silva) (03/02/90)

In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
> Many members of the C community exhibit an unprofessional and
> irresponsible attitude regarding defect control and especially
> defect prevention.   

Many members of the programming community as a whole exhibit an
unprofessional and irresponsible attitude regarding defect control
and expecially defect prevention. 

C happens to be the most popular language on a wide range of hardware,
by the chance that it happens to be well adapted to writing reasonably
portable and reasonably efficient programs, without being particularly
hard to implement or having particularly many functional shortfalls. Most
other system programming languages are either harder to implement (such
as ADA), do not fit well into the normal program linking model (such as
Modula), or are simply inadequate without nonstandard extensions (most
dialects of Pascal).

Thus, simply by statistics one could predict that a large number of
programs written in C are likely to contain major bugs. There are a
large number of programs written in C, period.

Would you care to address the confusing and dangerous deficiencies in
the ADA language: operator overloading and the use of rendezvous for
interprocess communication, for example? Have you read C. A. R. Hoare's
Turing Award lecture, "The Emperor's New Clothes"?
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

mcilree@mrsvr.UUCP (Robert McIlree) (03/02/90)

From article <12643@ulysses.att.com>, by ekrell@ulysses.att.com (Eduardo Krell):
> In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>>   For the cost of simply
>>   the recent national AT&T crash, I'd be willing to conjecture that all of 
>>   AT&T's software developers could have been trained in software engineering
>>   concepts and the Ada language, and supplied with Ada compilers as well.   
> 
> And what makes you think the network wouldn't have crashed if the software
> had been written in Ada (you seem to imply this)? Do you know the details
> of the cause of the crash?. You're just speculating that it was related
> to the "unsafe" nature of C.

Let me add something to Eduardo's comments: The vast majority, if not
all, of AT&T's developers *are* trained in software engineering
concepts in-house. I know. I used to work at Bell Labs.  I learned
more about software engineering, methodologies, and development
lifecycles from that environment than in any other place I've worked,
before or since. At a minimum, that training was far better than what
it appears you have learned at Duke (bastion of CS that it is), Mr.
Wolfe - if simply by judging the quality of the school from your postings
of absolute conjecture and crap.

Oh, is the above a little unfair? Well, so is your indictment of C
without: a) facts and b) experience. Programming languages are not
the root of all evil. Failures are also linked to inadequate analysis,
lack of testing, poor development environments, and documentation
problems, to name a few. I'll reiterate to you that systems are not,
and never are 100% reliable. The AT&T crash was bound to happen
sooner or later, but not because the software was coded in C. Things
like software complexity and network topology issues come to mind
immediately, with nothing at all to do with language specificity.
Perhaps you can take the time to put down the Ada manual and learn
something about these topics, because the lack of depth in your
pronouncements is showing.

Unfortunately, very little of the drivel you have posted in these
forums touch on non-coding parts of the development lifecycle. You,
for one reason or another, simply ignore them and keep thumping your
Ada bible like some evangelical idiot. Ignorance of those topics
doesn't make you a software engineer. At best, it makes you a coder.
And coders, Mr. Wolfe, are a dime-a-dozen. So are religous wars on
which programming languages are "the best." If you're going to indict
the software engineering community for your percieved attrocities
and ignorace, perhaps you could start at the top - like in requirements
and management issues, which is where the majority of the problems
start. Blasting Joe-C-Programmer for the world's ills is just so much
hot air - which is to be expected from you, I'd reckon.



Bob McIlree

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/02/90)

From ekrell@ulysses.att.com (Eduardo Krell):
> And what makes you think the network wouldn't have crashed if the software
> had been written in Ada (you seem to imply this)? Do you know the details
> of the cause of the crash?. 

   The crash apparently was caused by a programmer who used a "break"
   within an if (which itself was within a switch) for the purpose of
   exiting the if; the real result was to exit the switch instead.  If
   C provided a case statement rather than a switch..break system, then
   the error would most likely have been prevented.

   See the recent discussion of this topic in comp.lang.c.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

stevee@ism780c.isc.com (Steve Ellingson) (03/02/90)

C is a language for consenting adults,
Pascal is a language for naughty children, and
Ada is a language for criminals!



			Steve

jacob@gore.com (Jacob Gore) (03/02/90)

/ comp.lang.c / billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) / Mar  1, 1990 /
>    The [AT&T long distance netrowk] crash apparently was caused by a
>    programmer who used a "break" 
>    within an if (which itself was within a switch) for the purpose of
>    exiting the if; the real result was to exit the switch instead.

So what else is new?  In the following Ada code the "exit" will exit the
loop instead of the 'if' statement:

	loop
		...
		if ... then
			...
			exit;
		end if;
		...
	end loop;

In C, 'break' exits switches and loops.  Not ifs.

>    If C provided a case statement rather than a switch..break system, then
>    the error would most likely have been prevented.

unless the whole thing was enclosed in a loop, which would be exited
instead of the 'if'.

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob

machaffi@fred.cs.washington.edu (Scott MacHaffie) (03/02/90)

In article <8192@hubcap.clemson.edu% billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
%   The unsafe constructs within C are themselves sufficient evidence to
%   conclude that the C community, by choosing to use a language which has
%   many highly unsafe constructs and an almost total disregard for error 
%   prevention, does not hold error prevention in sufficiently high regard;

paraphrase:
I can't write code worth a damn, so no one else can either.

%   the failure of a password security system because no boundary checks 
%   were done on the length of the password (whereupon the intruder purposely
%   supplied a double-length password and thereby ensured that the left and
%   right sections of the password-validating data structure were compatible),
%   and similar cases demonstrate that the C language poses a serious obstacle
%   to the development of defect-minimal software.  For the cost of simply

paraphrase:
Someone else fucked up (or I made it up, one of the two) so I can use
that as an argument.

%   the recent national AT&T crash, I'd be willing to conjecture that all of 
%   AT&T's software developers could have been trained in software engineering
%   concepts and the Ada language, and supplied with Ada compilers as well.   

paraphrase:
ADA is perfect. No one has ever written a piece of ADA code with bugs in it.
If AT&T had used ADA their code would have worked without being tested.

%   The comments found in the Unix man pages I cited have been there for 
%   at least a decade, apparently going unchallenged by the rest of the 
%   C community.  This is despite the fact that the growth of C has been 

paraphrase:
Unix had bugs TEN WHOLE YEARS ago!

%   widely attributed to the Unix operating system being given away to 
%   so many universities -- if this attribution is correct, then Unix is
%   also responsible for helping to create the widespread attitude within 
%   the C community that defects are to be treated casually.  

paraphrase:
Hey, now I can try to flame Unix, too! Maybe I should cross-post to comp.unix
-- I'm sure they would appreciate knowing that they can't do any software
engineering with their systems.

%   It is entirely true that other language communities (BASIC, COBOL, etc.)
%   have problems along these lines which are arguably worse than those which
%   are clearly associated with the C community.  On the other hand, there are

paraphrase:
What the fuck, I can try to flame EVERYONE. After all, I am perfect.

%   other language communities which are doing a considerably better job of
%   spreading software engineering concepts and providing linguistic support
%   for their application (Ada, Eiffel, etc.).  The challenge for the C

paraphrase:
If I say it enough, maybe someone will believe me.

%   community is to join the language communities which are doing a good
%   job in these respects, as opposed to holding its existing reputation
%   as a community which contains an extremely high percentage of those who
%   regard themselves as hackers, and whose products repeatedly make national 
%   headlines with their spectacular failures.  Since C is a language which

paraphrase:
Look, I have made-up statistics to prove my point! And I can also ignore
counter-examples!

%   provides little or no support for defect prevention, one would expect
%   that the C community would naturally compensate by being extremely 
%   careful about always applying the very best software engineering 
%   practices.  Unfortunately, I don't think even the most dedicated 
%   C-backers would attempt to claim that this is presently the case.

paraphrase:
I'm not a C programmer, but I can damn well speak for all of them.

jseidman@jarthur.Claremont.EDU (James Seidman) (03/02/90)

In article <470008@gore.com> jacob@gore.com (Jacob Gore) writes:
>/ comp.lang.c / billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
>(William Thomas Wolfe, 2847 ) / Mar  1, 1990 /
>>    The [AT&T long distance netrowk] crash apparently was caused by a
>>    programmer who used a "break" 
>>    within an if (which itself was within a switch) for the purpose of
>>    exiting the if; the real result was to exit the switch instead.
>
>So what else is new?  In the following Ada code the "exit" will exit the
>loop instead of the 'if' statement:
>[Exactly analogous Ada example deleted]
>In C, 'break' exits switches and loops.  Not ifs.

Of course, part of Bill's point is that anyone who is programming in Ada
will be trained in software engineering and therefore will not make
mistakes.  On the other hand we C programmers are all people who just
graduated from high school and are writing code without any formal
training.

He also has the point that if Unix was rewritten in Ada then it would have
no security holes.  Similarly, if the units(1) utility were written in Ada
it would automatically update currency values.  I might point out, however,
that there is at least one Ada compiler in existence which is itself written
in C, and therefore you should be very wary when using an Ada compiler in
case it's that one.  Now if only the Ada compiler was written in Ada
instead...

By the way, has anybody compared speeds of Ada and C implementations?  I
don't know about other platforms, but on our VMS system an Ada program which
simply prints "Hello World!" on the screen takes eight times longer to
compile than a similar C program, and the executable is 11 times longer in
length.  The execution time appears to be about three times slower as well.
I really think it's time for the Ada community to clean up its act and get
some faster compilers.  

As a parting shot, I will end this post with a list of all of the utilities
on our VMS *and* Unix systems which are written in Ada:

----- beginning of list -----
-----    end of list    -----

Fortunately, thanks to programmers like Bill Wolfe, they are all bug free.
-- 
-------------------------------------------------------------------------------
Jim Seidman, Harvey Mudd College, Claremont, CA 91711.  (714) 621-8000 x2026
DISCLAIMER: I don't even know if these are opinions, let alone those of
            anyone other than me.

chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (03/03/90)

From article <8201@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ):
>    The crash apparently was caused by a programmer who used a "break"
>    within an if (which itself was within a switch) for the purpose of
>    exiting the if; the real result was to exit the switch instead.  If
>    C provided a case statement rather than a switch..break system, then
>    the error would most likely have been prevented.

The problem was obviously the ignorance of the programmer.  Blaming the
fruits of that ignorance on the language in which he/she was programming
is a comperable error.   The syntax of the switch construct and the
functionality of break have been well defined for well over a decade.

It would be much more constructive, and more appropriate to software-eng,
to observe that such a primitive error would have been caught and fixed, 
before it had a chance to do any damage, if the organization in which the 
routine was developed observed the practice of code reviews.  This might
not be a popular answer in some circles, but it is the only competant
answer to this problem.

Chris Prael

frankw@hpcvra.CV.HP.COM (Frank Wales) (03/03/90)

In some article (William Thomas Wolfe, 2847 )
 billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From ekrell@ulysses.att.com (Eduardo Krell):
>> And what makes you think the network wouldn't have crashed if the software
>> had been written in Ada (you seem to imply this)? Do you know the details
>> of the cause of the crash?. 

>   The crash apparently was caused by a programmer who used a "break"
>   within an if (which itself was within a switch) for the purpose of
>   exiting the if; the real result was to exit the switch instead.  If
>   C provided a case statement rather than a switch..break system, then
>   the error would most likely have been prevented.

Well, actually, the crash was caused by software which didn't work
right.  Deducing the reasons behind this are an interesting academic
exercise, and may indeed point to language design problems, both for C
specifically and other languages in general, but for me at least, I just
note the problem as a potential difficulty in future programming, and
get on with the job.  I certainly don't slap myself on the forehead,
exclaiming:  "What a crock C is!  From now on, I'm going to use <your
favourite language> instead!"  Useful tools are hard to come by, and
take time to master.  I need a better reason than nit-pickety details
to discard one and learn another.

If someone came to me and explained a bug in a piece of software he'd
written with: "well, if the semantics of C were different, it would have
worked okay," he would be the proud owner of what my father would have
called 'a swift kick up the arse'.  Where I come from, software in
*any* language is supposed to be tested.  If you feel the need to put
code in to handle something, you test that code.  If it isn't important
to make sure the code works right, you don't put it in.  And this is
*not* a C issue, this is a software development issue.  You can write
broken software in any language, regardless of its syntax, semantics or
size (they tell me size doesn't matter, but...).  Whatever the reason
for the defects, putting software in service without fixing them is wrong.

Can you tell me, Bill, that you *know* that if the semantics of C were
different, that no other problems would have arisen as a consequence
of the difference?

[Note for language zealots:  I am not attempting to defend the design of
 C here; it has its deficiencies, but it is still a useful language for
 many types of work.  I believe it is the most pragmatic language of its
 time, and that the most pragmatic language of today is Eiffel.  I don't
 think there is *any* language in which one can do useful work that
 doesn't also have cognitive pitfalls somewhere, including Ada.  I'd like
 to see the language which guarantees working software without testing.
 I think it would give me a good excuse to shout "yippee!" for once.]
--
Frank Wales, Guest of HP Corvallis, [frank@zen.co.uk||frankw@hpcvdq.cv.hp.com]
Zengrange Ltd., Greenfield Road., LEEDS, England, LS9 8DB.   (+1)-503-750-3086

sanders@sanders.austin.ibm.com (Tony Sanders) (03/06/90)

In addition to the multitudinous messages already written on this subject
I would like to add a couple thoughts.
In article <8192@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From marick@m.cs.uiuc.edu:
>> There are two assertions in Bill Wolfe's message:
>> 1.  The C community releases an unacceptable number of errors.
Bill, please tell us exactly what the error rate is.
I assume you must have some stats to back this up (maybe lines/errors?),
or are you just making stuff up?

>> 2.  The C language is at least partly the *cause* of those errors.
Nope, programmers that don't have a clue is mostly the cause of
those errors (referring to stupid errors that Bill claims were caused
by the C language).

>  3.  Many members of the C community exhibit an unprofessional and
>        irresponsible attitude regarding defect control and especially
>        defect prevention.   
>  4.  Those members of the C community who ARE responsible professionals
>        are apparently not taking significant actions to raise the level
>        of software engineering professionalism within the C community.  
On reason you might have this observation is because Joe Smith gets a
computer and *Shazam* he's a "real programmer" (CSMAJORS for short).

    (note: CSMAJORS here only refers to those people who got
	   the CS degree because it pays well, there are of
	   course "real programmers (tm)" that have CS degrees)

The current market demand for programmers exceeds the supply of "real
programmers (tm)" thereby creating a demand for CSMAJORS.  The reason
these people exist is because of the demand for people to fill
programming jobs.  If employers were not willing to pay top dollar for
these people as programmers they would not be programmers at all, they
would go and get themselves an MBA or whatever they could use to make
the most money.

>   The unsafe constructs within C are themselves sufficient evidence to
>   conclude that the C community, by choosing to use a language which has
>   many highly unsafe constructs and an almost total disregard for error 
>   prevention, does not hold error prevention in sufficiently high regard;
Bullshivicky!  What does the level of handholding a language provides
have to do with anything.  Making unsupportable claims undermines your
argument (again).

>                          as opposed to holding its existing reputation
>   as a community which contains an extremely high percentage of those who
>   regard themselves as hackers, and whose products repeatedly make national 
"regard themselves as hackers" is a key phrase here.  You are again
talking about the CSMAJORS, and this has nothing to do with the
"C-community".  This is a problem in any language, there are more
CSMAJORS programming in C simply because it is becoming the language
of choice (with good reason in my opinion).

In the future if you want to flame some group for all the buggy code
out there, go talk to the people who hire people who can't program.
-- sanders
Reply-To:  cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders
"she was an innocent bystander, it's a democracy" -- Jim Morrison

emuleomo@paul.rutgers.edu (Emuleomo) (03/07/90)

In article <17000003@hpcvra.CV.HP.COM>, frankw@hpcvra.CV.HP.COM (Frank Wales) writes:
> In some article (William Thomas Wolfe, 2847 )
>  billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
> >From ekrell@ulysses.att.com (Eduardo Krell):
> >> And what makes you think the network wouldn't have crashed if the software
> >> had been written in Ada (you seem to imply this)? Do you know the details
> >> of the cause of the crash?. 
> 
> >   The crash apparently was caused by a programmer who used a "break"
> >   within an if (which itself was within a switch) for the purpose of
> >   exiting the if; the real result was to exit the switch instead.  If
> >   C provided a case statement rather than a switch..break system, then
> >   the error would most likely have been prevented.
> 
> Well, actually, the crash was caused by software which didn't work

Actually, I think the 'break' as used in the switch stmt was one of the few
mistakes Dennis Ritchie made when designing the C language. By using
'break' both to end a 'case', and to exit a loop, he overloaded the meaning of
'break' and thus made it impossible to jump out of a switch that is embedded
within a loop without using a flag or a GOTO!
Was he trying to conserve keywords? In hindsight, I think 'endcase' would have 
been a better choice.
The other less serious flaw in C is the do...while contruct.
I kind of prefer PASCAL's repeat....until construct myself.
Anyway, 1.5 flaws in a language is still pretty good. I have used several 
languages ( >15) and in expressive power, it is difficult to beat C.
Thats why its fast becoming the lingua franca of programming.

--Emuleomo O.O. (emuleomo@yes.rutgers.edu)
-- 
** The ONLY thing we learn from history is that we don't learn from history!

cbuckley@vax1.tcd.ie (03/09/90)

In article <Mar.7.10.43.42.1990.17402@paul.rutgers.edu>, emuleomo@paul.rutgers.edu (Emuleomo) writes:

> Actually, I think the 'break' as used in the switch stmt was one of the few
> mistakes Dennis Ritchie made when designing the C language. By using
> 'break' both to end a 'case', and to exit a loop, he overloaded the meaning of
> 'break' and thus made it impossible to jump out of a switch that is embedded
> within a loop without using a flag or a GOTO!

I always thought "break" jumps out of the innermost construct - I presume you
mean that it is impossible to jump out of the loop as a result of one of the
cases in the switch() (which is imbdedded in the loop). At college, we're
taught that this is bad programming practice anyway! (Yes, yes, I *know* that
there are times when... etc... etc...)

> Was he trying to conserve keywords? In hindsight, I think 'endcase' would have 
> been a better choice.

However, I do kind of agree with this. It would make programs that bit easier
to read - especially as a "switch" cannot really be considered a loop, so it is
a bit peculiar to use a statement which implies "breaking" out of it.

> The other less serious flaw in C is the do...while contruct.
> I kind of prefer PASCAL's repeat....until construct myself.

How can this be a flaw? The two constructs are identical except for the fact
that the condition is reversed in do { } while();
If you *really* want a repeat{}until();, and you're not worried about using
#define to redefine language features (and no, I do *not* want to get back into
the "re: #define OR ||" argument over this), you can do :

#define repeat do
#define until(x) while(!(x))

*********NOTE - I would NEVER do this!!!!!!!***************
*********PLEASE do NOT send angry followups!***************
*********I KNOW it is unsound programming practice*********
*********I KNOW it defeats the compiler's error-trapping***

but this is really unnecessary, as do...while is just as flexible as
repeat...until - after all, every condition has a reverse.


exit(0);
Colm

+-----------------------------------------------------------------+
| Colm Buckley. (Computer Science, Trinity College, Dublin)       |
|                                                                 |
| EMAIL      : cbuckley@vax1.tcd.ie                               |
| Phone      : Dublin 770101                                      |
+---+---------------------------------------------------------+---+
    |       Beware of a programmer with a screwdriver...      |
    +---------------------------------------------------------+

marsden@ecs.umass.edu (03/13/90)

In article <39412@ism780c.isc.com>, stevee@ism780c.isc.com (Steve Ellingson) writes:
> C is a language for consenting adults,
> Pascal is a language for naughty children, and
> Ada is a language for criminals!
> 

As you all know:
    Languages don't kill algorithms, Programmers do.
&   If C were outlawed, only "real programmers" would have C.   (hmm....)

----------------------------------------------------------------------------
internet : marsden@ecs.umass.edu               Ben Marsden
BITNet   : marsden@umaecs                      Engineering Computer Services
                                               Univ. of Massachusetts
phone    : (413) 545-4655                      Amherst, MA 01003

I think, and speak, for (a *very* small subset of) all humanity.
Disclaimer: the State is not responsible...

kevin@ttidca.TTI.COM (Kevin Carothers) (03/21/90)

In article <39412@ism780c.isc.com>, stevee@ism780c.isc.com (Steve Ellingson) writes:
> C is a language for consenting adults,
  My favorite.

> Pascal is a language for naughty children, and
  My wife's favorite

> Ada is a language for criminals!
  My previous employers favorite.

 I'm sorry. I have to ask...
 Since Each of these above as occupied a station in my past, for whom,
 pray tell, are Fortran and Cobol for?

--
    Kevin Carothers           {philabs,csun,psivax}!ttidca!kevin

archer@elysium.sgi.com (Archer Sully) (03/22/90)

In article <11183@ttidca.TTI.COM> kevin@ttidca.TTI.COM (Kevin Carothers) writes:

>In article <39412@ism780c.isc.com>, stevee@ism780c.isc.com (Steve Ellingson) writes:
>> C is a language for consenting adults,
>  My favorite.

>> Pascal is a language for naughty children, and
>  My wife's favorite

>> Ada is a language for criminals!
>  My previous employers favorite.

> I'm sorry. I have to ask...
> Since Each of these above as occupied a station in my past, for whom,
> pray tell, are Fortran and Cobol for?

Managers, and other Neanderthals.

Archer Sully 	      |  I'm 27 years old.  That's 54 in Nerd Years
(archer@esd.sgi.com)  | 	-- Keith Rienzi

john@newave.UUCP (John A. Weeks III) (03/22/90)

In article <11183@ttidca.TTI.COM> kevin@ttidcb.tti.com (Kevin Carothers) writes:
>  My favorite.
>  My wife's favorite
>  My previous employers favorite.

> I'm sorry. I have to ask...
> Since Each of these above as occupied a station in my past, for whom,
> pray tell, are Fortran and Cobol for?

Fortran--for those who like to do things fast
Cobol--for those who like to make money

-john-

-- 
===============================================================================
John A. Weeks III               (612) 942-6969               john@newave.mn.org
NeWave Communications                ...uunet!rosevax!bungia!wd0gol!newave!john
===============================================================================