[comp.lang.c] ADA/C Flame wars

cspw.rures@p0.f4.n494.z5.fidonet.org (cspw rures) (03/26/90)

 
I can't resist adding to the sterile ADA/C flame war.
 
Neither of the languages can guarantee even the most fundamental
algebraic properties about their expressions: e.g. that
     f(x) + f(x)
is always the same as
     2 * f(x)
and that
     f(x) + g(x)
is always the same as
     g(x) + f(x).
 
Imperative languages (any that permit re-assignment/side-effects
into memory locations in a time-dependant way) are inherently
"unsafe" and difficult to reason about formally.
 
The C community (a huge generalization!) recognize that the style of
computation is useful and fun in spite of (because of?) this feature.
They suffer no gradiose illusions about the language per se providing
security and reliability, and recognize that programs do not have to
be perfect to be useful.  (I think it was Plauger's Programming Pearls
that describes a programming community were using a fairly slow
type-setting package with about 10 known bugs.   Asked the question
"If you had a choice of fixing these bugs or doubling the speed
of the package, which would you chooose",  the respondents inevitably
chose the latter.)
 
By contrast, the ADA community (and some others) seem to be
suggesting that mere surface changes in the language will somehow
fix deep underlying semantic problems.  I can only see this as
a blatant attempt to mislead the fund givers and managers (those who
wear their suits and browse the manual pages, you know, and are
'put off' by the flippant realism that they find).
 
It is obvious that each language may have a niche, and that the
questions above may have got different answers if the sofware was a
missile guidance system.  What seems strange is that the C community
seem to recognize both sides of the coin, and generally accept that
some guys in some large-scale or sensitive software systems need ADA.
The converse does not seem true: the C community comes under vitriolic
attacks for writing useful software with a damn good price/performance
ratio.
 
Variable-based programming is inherently tricky.  Telling us that ADA
will solve our problems is like suggesting that we wear earmuffs
while playing Russian Roulette, so that the noise won't hurt our
ears.  By all means use the earmuffs, but stop trying to tell us
that this makes the game safe!
 
Pete Wentworth



--  
uucp: uunet!m2xenix!puddle!5!494!4.0!cspw.rures
Internet: cspw.rures@p0.f4.n494.z5.fidonet.org

jensting@skinfaxe.diku.dk (Jens Tingleff) (03/27/90)

cspw.rures@p0.f4.n494.z5.fidonet.org (cspw rures) writes:


> 
>I can't resist adding to the sterile ADA/C flame war.
> 
>Neither of the languages can guarantee even the most fundamental
>algebraic properties about their expressions: e.g. that
>     f(x) + f(x)
>is always the same as
>     2 * f(x)
>and that
>     f(x) + g(x)
>is always the same as
>     g(x) + f(x).

Gee, I wish I had a language that did this (that's the question
you wanted, isn't it ?, well I asked it !!). I guess you're trying
to make a statement about side-efects, because your next sentence is

> 
>Imperative languages (any that permit re-assignment/side-effects
>into memory locations in a time-dependant way) are inherently
>"unsafe" and difficult to reason about formally.

Shure. You try writing to a file, a screen, a piece of paper
without any variable-alteration, and be sure to post an article
about it (without changing any variables, of course) ;^) .

	Jens

jensting@diku.dk is
Jens Tingleff MSc EE, Research Assistent at DIKU
	Institute of Computer Science, Copenhagen University
Snail mail: DIKU Universitetsparken 1 DK2100 KBH O

adrian@mti.mti.com (Adrian McCarthy) (03/27/90)

In article <3010.260C8D7E@puddle.fidonet.org>
cspw.rures@p0.f4.n494.z5.fidonet.org (cspw rures) writes:

>Neither of the languages can guarantee even the most fundamental
>algebraic properties about their expressions: e.g. that
>     f(x) + f(x) = 2 * f(x)
>and that
>     f(x) + g(x) = g(x) + f(x).

I believe that the Turing language can make these guarantees.  I've
heard that it does not permit side-effects in functions.

> (I think it was Plauger's Programming Pearls
>that describes a programming community were using a fairly slow
>type-setting package with about 10 known bugs.   Asked the question
>"If you had a choice of fixing these bugs or doubling the speed
>of the package, which would you chooose",  the respondents inevitably
>chose the latter.)

If anybody cares, I say fix the bugs.  The double-speed version can
crash in half the time!  :-)/2

Aid.
adrian@mti.com
Standard disclaimers.

[line fodder]
[line fodder]
[line fodder]

fischer@iesd.auc.dk (Lars P. Fischer) (03/27/90)

In article <1990Mar26.184417.25844@diku.dk> jensting@skinfaxe.diku.dk (Jens Tingleff) writes:
>... You try writing to a file, a screen, a piece of paper
>without any variable-alteration, and be sure to post an article
>about it ...

Too late, I'm afraid. The trick is called Lazy Evaluation. Check out
Miranda(TM), Haskell, and others. In fact, lazy lists are all you
need.

The point is that C is powerful, fast, and dangerous, while functional
languages are even more powerful, slow, and safe. Make your choice. Ada
pretends to be powerful, fast, and safe, but really is weak, slow,
and dangerous (1/2 :-).

The ideal would be to have a language that allowed for an easy way to
prove correctness, with the assistance of "proof checkers" and so on,
while still providing the speed and control of C. Alas, we don't have
that (yet).

/Lars
(In case you're interested in lazy evaluation, check out Turners
articles on Miranda and KRC).
--
Lars Fischer,  fischer@iesd.auc.dk   | The difference between genius and 
CS Dept., Univ. of Aalborg, DENMARK. | idiocy is that genius has its limits.