[theodorethomas]

People mention the no-aliasing, the compilers, the intrinsics, the libraries, and the expressivity but one aspect of the difference is ignored and it is this: C is a language for specifying behaviour of hardware (time sequence of detailed states), Fortran is a language for specifying computation of values. Fortran abstracts far more of the hardware than C and consequently, a Fortran compiler can benefit from quantum processors, mind-readers or time-machines, should they ever be invented.

A Fortran program that reads its input, calculates and finally writes out its output does not have to execute any particular instruction at all. As long as the answer is "AS IF" it had done the user-specified computation, the Fortran compiler has done its job. In between I/O, it submerges into the ineffable like a Cold War SSBN.

C is about the instruments, the players and the conductor, Fortran is about the music.

[dTal]

Maybe this was once true, but the hardware that C was designed for specifying the behavior of was a PDP-11. Nowadays you are programming an abstract C-ish virtual machine that provides certain semantic guarantees that don't necessarily map terribly well to the physical hardware. For example, if you write to a memory address, and then read from the memory address in the "next instruction", you expect the change to be immediate, even though the code is actually running on a pipeline that could be dozens of instructions deep, with several layers of cache between the core and system memory. So in a sense there's not really a qualitative difference between C and Fortran - they are both for specifying a sequence of operations on an abstract machine, relying on the compiler to implement that machine - and indeed modern optimizing C compilers actually provide very few guarantees about specific assembly instructions to be executed, happily rewriting or omitting code so long as it executes "as if" it ran on the C virtual machine.

See "C is not a low-level language" - https://queue.acm.org/detail.cfm?id=3212479

[theodorethomas]

I don't see how C can match Fortran's abstraction level and still reliably control hardware that uses memory-mapped I/O.

C, as an operating system implementation language, is trying to do something fundamentally different than Fortran.

You live by memory address, you die by memory address.

[PhilipRoman]

> For example, if you write to a memory address, and then read from the memory address in the "next instruction", you expect the change to be immediate

This would also be true for assembly, hardly a high level language

[lmm]

On modern CPUs assembly is a high level language (or rather, it's a language that doesn't have any of the advantages of traditional low-level languages, even if it also lacks the advantages of traditional high-level languages. Much like C)

[AnimalMuppet]

> you expect the change to be immediate, even though the code is actually running on a pipeline that could be dozens of instructions deep, with several layers of cache between the core and system memory.

I expect the hardware to handle cache coherency in that situation. What the compiler does should be irrelevant.

[dTal]

Right, but the point is that the hardware is still "meeting you halfway" to present the appearance of something which isn't actually happening. Those pointers in C aren't really "memory addresses" at all, they're keys in a key-value store managed by the hardware to preset the illusion of flat, contiguous memory, as mandated by the C programming model.

So maybe it's accurate to say that C is "more compatible" with real hardware, in the sense that its abstract machine is more isomorphic to what's really happening than Fortran's is. But it's not exactly "closer to hardware" in the way we might be tempted to think; it's more of a lingua franca that your processor happens to speak.

If you're still tempted to consider C "close to hardware", consider that you can compile the same code for a Z80 and a Threadripper. What hardware exactly are you controlling that's common to both?

[AnimalMuppet]

> as mandated by the C programming model.

As PhilipRoman said, this is also true of assembly (or any other programming language model[1]).

> If you're still tempted to consider C "close to hardware", consider that you can compile the same code for a Z80 and a Threadripper. What hardware exactly are you controlling that's common to both?

In both of them I can write to a memory-mapped I/O device, if it has one. I can write a custom memory allocator for a pool that I'm managing myself. I can't do either of those in Fortran or Javascript.

[1] Why does it have to be true of any other programming language model? Well, maybe I exaggerate slightly. But can you show me a (single threaded) programming language where "a = 1" does not mean that on the next line, a will be 1?

[kmstout]

> But can you show me a (single threaded) programming language where "a = 1" does not mean that on the next line, a will be 1?

MIPS I.

https://en.wikipedia.org/wiki/Delay_slot#Load_delay_slot

[gpderetta]

>But can you show me a (single threaded) programming language where "a = 1" does not mean that on the next line, a will be 1

Generally agree with your point, but just to play the devil's advocate, in a CPU with exposed pipeline and no interlocks, setting a register to a value doesn't guarantee that a following instruction reading from that register will see the last value written.

[teleforce]

With D language it can be the music, instruments, player and the conductor all at once [1].

Fun facts, Walter the original author of D language wrote his popular Empire game in Fortran [2]. Some of the ideas that make Fortran fast is incorporated into D language design and this makes D is as easy if not easier to optimize than Fortran [1].

[1]Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:

http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

[2]A Talk With Computer Gaming Pioneer Walter Bright About Empire:

https://madned.substack.com/p/a-talk-with-computer-gaming-pi...

[NikkiA]

Oddly, when people mention Empire, I think of Peter Langston's Empire rather than Walter's.

[coliveira]

Yes, you're correct. C was created to control a CPU, it is a low level language with a comfortable syntax. C abstracts the hardware. But Fortran has nothing to do with hardware, it is just a notation for computing matrix algorithms. Fortran can be thought as a primitive APL. You can do all kinds of optimizations in Fortran that you cannot do in C, because it doesn't care or know about the underlying hardware.

[mhh__]

That was maybe true for C in the seventies but there's practically no difference anymore e.g. C has an as if rule too.

[theodorethomas]

The point is, it shouldn't.

https://news.ycombinator.com/item?id=30022022 How ISO C became unusable for operating systems development