Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Fortran was NOT higher level than C.  Was: Computer architects
 leaving Intel...
Date: Wed, 4 Sep 2024 11:31:23 +0300
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <20240904113123.00002098@yahoo.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
	<memo.20240830164247.19028y@jgd.cix.co.uk>
	<vasruo$id3b$1@dont-email.me>
	<2024Aug30.195831@mips.complang.tuwien.ac.at>
	<vat5ap$jthk$2@dont-email.me>
	<vaunhb$vckc$1@dont-email.me>
	<vautmu$vr5r$1@dont-email.me>
	<2024Aug31.170347@mips.complang.tuwien.ac.at>
	<vavpnh$13tj0$2@dont-email.me>
	<vb00c2$150ia$1@dont-email.me>
	<505954890d8461c1f4082b1beecd453c@www.novabbs.org>
	<vb0kh2$12ukk$1@dont-email.me>
	<vb3smg$1ta6s$1@dont-email.me>
	<vb4q5o$12ukk$3@dont-email.me>
	<vb6a16$38aj5$1@dont-email.me>
	<jwv8qw8o7zg.fsf-monnier+comp.arch@gnu.org>
	<vb7q5q$3f6cg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 04 Sep 2024 10:30:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="96c04d2230436f3240bbc116213a9a17";
	logging-data="3944887"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Yn0CsAjLzSIwi5XV7iLBzNbXXuao1kSg="
Cancel-Lock: sha1:PuHF4h6iEJ/TInbLi/htegXim3A=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4189

On Tue, 3 Sep 2024 20:05:14 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
> >> My impression - based on hearsay for Rust as I have no experience
> >> - is that the key point of Rust is memory "safety".  I use
> >> scare-quotes here, since it is simply about correct use of dynamic
> >> memory and buffers.
> >>
> >> It is entirely possible to have correct use of memory in C,  
> >
> > If you look at the evolution of programming languages,
> > "higher-level" doesn't mean "you can do more stuff".  On the
> > contrary, making a language "higher-level" means deciding what it
> > is we want to make harder or even impossible.  
> 
> Really?
> 
> I thought Fortran was higher level than C, and you can do a lot
> more things in Fortran than in C.
> 
> Or rather, Fortran allows you to do things which are possible,
> but very cumbersome, in C.  Both are Turing complete, after all.

I'd say that C in the form that stabilized around 1975-1976 is
significantly higher level language than contemporary Fortran dialects
or even the next Fortran dialect (F77).

EQUIVALENCE is lower level than union.

COMMON is ALOT lower level both than C automatic storage and than
dynamic storage (malloc/free) although the later probably was not
considered part of the language in 1976.

IF cond GOTO 42 is lower level than if (!cond) {}

Call-by-reference as the only mode of parameter passing is lower level
than call-by-value. Especially so in context of C, because in C one can
easily emulate call-by-reference with pointers if/when such need arises.

Few other higher level concepts of C appear to have no equivalents at
all in contemporary Fortran: 
 block scopes for variables, including variables with static storage;
 struct; 
 enum.
 I don't remember for sure, but it seems that back then Fortran had no
 recursion. 
 Standardized preprocessor vs at best non-standard macro systems or at
 worst nothing at all. 
I'd guess there are more features of that sort that I forgot, but they
are less important than those I listed.

Overall, the differences in favor of C looks rather huge. 

On the other hand, I recollect only two higher level feature present in
old Fortran that were absent in pre-99 C - VLA and Complex. 
The first feature can be emulated in almost satisfactory manner by
dynamic allocation. Also, I am not sure that VLA were already part of
standard Fortran language in 1976.
The second feature is very specialized and rather minor.