Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: ambiguous ? (God?  Will you for
Message-ID: <225800236@uxe.cso.uiuc.edu>
Date: 30 Oct 89 14:53:00 GMT
References: <11427@smoke.BRL.MIL>
Lines: 85
Nf-ID: #R:smoke.BRL.MIL:11427:uxe.cso.uiuc.edu:225800236:000:4816
Nf-From: uxe.cso.uiuc.edu!mcdonald    Oct 30 08:53:00 1989


I am finally going to enter this flame war. This may seem a flame,
and indeed its is a bit. But I think mine is a reasonable position:

The most important aspect to a computer language is capability - 
if there are things that simply can't be done, or can only be done
with horrible kludges, then that language is either seriously flawed
or is intended for a specific subset of uses (even if it can be shown to
be Turing complete, and therefore essentially general in an algorithmic
sense.)  

The second is ease of use. Are there enough constructs in the language to
cover the intended uses (hopefully ALL uses for a general purpose language)?


The third is ease of optimizability. Are there constructs in the language
that make it hard to optimize? IF so, are there ways to help the compiler?
If there are problem areas, do the things that cause problems themselves have
sufficient utility that they overridde the optimization difficulties?

I personally use only assembler, Fortran (F77 here, as I withhold
judgement on F8x), and C. Lets consider them:

CApability: Well, assembler wins big here. It can do anything. Period.
Fortran lacks quite a bit: no pointers. No sturctures. No access to
all the size integers and reals that a machine may have (i.e. only
one integer size.) Function pointers only in a very limited sense.
And, did you ever try to do simple stream io in Fortran? 
C has a big list of capabilities. It lacks two features of Fortran
(conformant array passing and complex data type), but those can
easily be simulated, through minor kludges. Not really a big loss.
It also lacks Fortran's misfeature of the concept of a file "record",
though this can of course easily be simulated in C if one wishes.
The C language lacks only two things in its official ANSI form,
and, thank God, on many architectures they work anyway: converting
a data pointer to a code pointer and vice versa, and addressing
of absolute addresses (for device drivers, etc.)

Ease of use:   assembler - for most purposes, it isn't easy to use.
LAck of control constructs is the problrm here, as is lack of 
simple expression syntax. But, to be honest, expressions are not really
hard to do. Fortran is easy to use - so long as you are willing to
accept its lack of capabilities and not try to force them in. But, 
if you NEED a pointer, oh my, what a horrible mess. (Folks, believe me
on this one. Its really true. The key is to use it for just the type
programs it was intended for 'Formula Translation'. The lack of 
pointers helps a lot - there are no NULL flame wars. There is no
need for an "fdecl" program :-).  C is both hard and easy - it
is easy to express just about anything - look at the plethora of
operators and control constructs. But it is often very hard to get
declarations right - I could never do certain declarations without
either  a guru or "cdecl.exe". Try "pointer to array of pointers
to functions returning pointer to array of pointers to char and
taking as arguments a char, a void *, and a pointer of the same type
as I am trying to declare right now". "" I never saw a purple cow,
and never hope to see one. But I can tell you now, I'd rather see than 
be one."" Despite all the flame wars about it, I some how am just
not bother by NULL or (char *) 0 or whatever. It seems easy to me.

Ease of optimizability: One did not use to try to optimize assembler,
but with certain new RISC processors there appears to be a need to
optimize (schedule?) hand written assembler code. How hard it is,
I don't know. C loses here. Fortran is carefully constructed to
allow optimization. For example, arguments to functions (or subroutines,
I'll ignore the diference) are not allowed to have side effects - at all -
you can write code that does have that but - but - it is explicitly
disallowed by the Fortran language standard. And no pointers mean
no pointer aliasing. And you can't fake it with arrays - those can
not be used in that way. Its not allowed. The existance of aliases
restricts and/or hinders optimization of C. To do much at all
in the way of certain sorts of optimizations.
you need a really smart global data-flow analyzer.  "Const", "volatile"
and the concept of "noalias" can help only somewhat. Some compilers
(Microsoft C, for example) have a command line switch that for
all practical purposes calls the optimizer of Fortran. It seems
to work on my code - but, then again, to little gain. I don't consider
this lack of optimizability a big loss compared to the gains in 
ease of use and capability. OF course, there are lots of areas where C
can be optimized as well as anythings else.

C comes off looking pretty good.
But so do, in my opinion, Fortran and assembler. It's those silly
European invented languages that lose big. You know - the P's and
M's and the A's.
Doug McDonald