Re: Fortran was NOT higher level than C. Was: Computer architects leaving Intel...

On Wed, 4 Sep 2024 17:08:36 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

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,

In theory, this is an advantage. In practice - not so much.
Old Fortran lacked two key features that make 1st-class arrays really
useful - array length as an attribute and pass-by-value.
So, one can enjoy his 1st class citizenship only with borders
of procedure.

and a reasonable way
to pass multi-dimensional arrays.

Considering total absence of inter-module check of matching dimensions,
it's probably caused more troubles than it solved.

Sure, you could roll them
on your own with pointer arithmetic, but...
>

OTOH, while C does not have formal concept of array slices, they are
very easily and conveniently emulated in practice. Surely, not quite as
nicely syntactically as in Modern Fortran, but equal to it on practical
ground. According to my understanding, emulation of slices in Old
FORTRAN is more cumbersome.

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

May be, it's good in theoretical sense, also I am not sure even about
it. I most certainly don't like it as numerics professional (which I am
formally not, but a lot closer to being such than an average programmer
or an average physicists/chemist/biologist).
I very much prefer IEEE-754 approach of fixed list of types with very
strictly specified properties.

- Usable multi-dimensional arrays
- Modules where you can specify accessibility
- Intent for dummy arguments
- Generics and overloaded operators

Handy, but dangerous.

- 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

How does it differ from automatic variables that C together with nearly
all other Algol derivatives, had from the very beginning?

- Elemental operations and functions (so you can write
  foo + bar where foo is an array and bar is either an
  array or scalar)

Yes, it is handy for certain classes of matrix and array processing.
Still less powerful than similar features of Matlab and esp.
of Gnu/Octave, where you have both matrix operations like * and
cell-by-cell operations like .*
Unfortunately, the meaning of code that  intensively uses this features
not always obvious to reader.
C code that achieves the same effect with utility functions is looks
much less nice, but at least it does not suffer from above mentioned
problem.

- 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 :-)

I don't know much about typical users of Modern Fortran, but would
think that those coming from other languages, esp. from Python, would
appreciate built-in infinite-precision integers much more than unsigned
integers.
BTW, do your unsigned integers have defined behavior in case of
overflow? Is it defined as a modulo 2**size?
If the answers are yes, then may be you can find better name than
'unsigned'?