🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #825

Re: NOT Educating FORTRAN programmers to use C

#825
From: Jim Giles
Date: Tue, 23 Jan 1990 01:55
68 lines
3916 bytes
From article <17036@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
> [...]
> But in C there is no difference between an pointer and an array except
> that the array is a constant.  And you can declare the argument to be
> an array if you want to.  I really don't see what point you are trying
> to make...

You just made it.  In C there is _NO_DIFFERENCE_ between a pointer and
an array.  In these other languages, there _IS_ a difference!  In a 
procedure in C, any two non-local pointers must be assumed _aliased_
to each other (and to all other non-local objects) because they _might_
be.  That is part of the legitimate functionality of pointers: dynamic
aliasing.  In all these other languages, this kind of aliasing is
illegal for array arguments and/or array globals.

Also, as a less important point, C doesn't let me declare array arguments
to procedures if they are multidimensional and the array bounds in each
dimension may change from call to call.  This means that I have to do
my own index calculations or define a macro to do them for me (which
may not optimize well since the compiler doesn't _know_ that array indexing
may be special cased).

> [...]
> So here is an example where C can do more optimization and Fortran has
> conveniences for numerical work.  It's a trade-off, just like those
> cases where it is Fortran that can do more optimization and C that is
> more convenient.

This is not true.  There is _NO_ case that I'm aware of that parenthesis
are _REQUIRED_ in Fortran (ADA, Pascal, etc.) when they are not also
_REQUIRED_ in C - and with the _SAME_ consequences with respect to
optimization.  It is with _OPTIONAL_ parenthesis that the languages
differ.  In C, the compiler ignores them, in all the other languages
the compiler must evaluate in parenthesis order.  So, the trade-off you
mention is under direct user control in all languages but C.

> [... bizarre assignment operators ...]
>                                             I expect that of those
> language designers who aren't interested in them, most have never
> programmed much in a language that uses them.  They are very
> convenient.

Or, perhaps these designers have actually read the literature of
programming language design.  There _have_ been experiments which
sought to discover the effect of such operators on user productivity.
No measurable difference was found in any such study I'm aware of.
Would you care to enlighten me with a counter-example?

> [... assignment as an expression-level operator or a statement-level one
> 
> Be more careful with your use of phrases such as "known to be".  There
> are a _lot_ of of programmers and language designers who claim the
> opposite.

I _AM_ careful with the phrase "known to be".  I use it to mean that
more than one experiment has been done (in this case: on user
productivity with expression/statement-level assignment as the
variable) and _ALL_ such experiments have shown the same thing
(namely, that productivity is better with assignment limited to
a statement-level operation).  "A _lot_ of programmers and language
designers can "claim" anything they want - as long as they represent
such claims as personal opinion, it's a free country.  But, if you
expect the majority of designers to take you seriously, you'd better
have something more convincing than personal opinion.  Now, if you are
aware of a study on this subject that I've missed, I'd again be
pleased if you would forward news of it.

J. Giles
Technical Details
Message-ID: <14203@lambda.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!cmcl2!lanl!lambda!jlg
References: <17036@megaron.cs.arizona.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <14203@lambda.UUCP>
Date: 23 Jan 90 01:55:03 GMT
References: <17036@megaron.cs.arizona.edu>
Lines: 68