Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Fortran was NOT higher level than C.  Was: Computer architects
 leaving Intel...
Date: Wed, 4 Sep 2024 17:08:36 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <vba46k$3te58$1@dont-email.me>
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>
 <20240904113123.00002098@yahoo.com>
Injection-Date: Wed, 04 Sep 2024 19:08:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="04b9462bf8233c0522365da918e60878";
	logging-data="4110504"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18URjmkDuWCTYjFQMN22zTNxlAW/xFPeLw="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:KYEbt5xYcJZSGMs48fO76WqNzYg=
Bytes: 4810

Michael S <already5chosen@yahoo.com> schrieb:
> 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).

I did write Fortran, not FORTRAN :-)

I agree that C had many very useful things that pre-FORTRAN 90
did not have.  This is not surprising, since the authors of
C knew FORTRAN well.

[...]

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

You are arguing from the point of view of more than 30 years ago.

> 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. 

You forget arrays as first-class citizens, and a reasonable way
to pass multi-dimensional arrays.  Sure, you could roll them
on your own with pointer arithmetic, but...

> 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.

It didn't.

> The second feature is very specialized and rather minor.

Let's take a look at Fortran 95 vs. C99 (similar timeframe), and
thrown in the allocatable TR as well, which everybody implemented.

Fortran 95 already had (just going through
https://en.wikipedia.org/wiki/Fortran_95_language_features 
and looking at the features that C does not have)

- A sensible numeric model, where you can ask for a certain
  precision and range
- Usable multi-dimensional arrays
- Modules where you can specify accessibility
- Intent for dummy arguments
- Generics and overloaded operators
- Assumed-shape arrays, where you don't need to pass array
  bounds explicitly
- ALLOCATE and ALLOCATABLE variables, where the compiler
  cleans up after variables go out of scope
- Elemental operations and functions (so you can write
  foo + bar where foo is an array and bar is either an
  array or scalar)
- Array subobjects, you can specify a start, an end and
  a stride in any dimension
- Array intrinsics for shifting, packing, unpacking,
  sum, minmum value, ..., matrix multiplication and
  dot product

The main feature I find lacking is unsigned numbers, but at
least I'm doing something about that, a few decades later :-)