Learn Programming with OCaml

To get a sense of how the computer runs your program you need to learn some modern assembly language, i.e. either Intel/AMD x86-64 or Arm Aarch64, or for something simpler one could start with IBM POWER.

The hardware machine model used by the C programming language is completely obsolete and very different from how modern CPUs work. Even for abstracting PDP-11 it had defects and omissions.

The fact that C is indeed more transparent than many other more abstract programming languages does not make it good enough for understanding how the CPU runs your program. Believing that the CPU works within the straitjacket of the C language is dangerous, because much more than half of the instructions of a modern CPU cannot be directly expressed in C (though a good optimizing compiler can sometimes infer when such instructions can be used), and the C language does not even have the data types that are used by many hardware instructions.

The relationship between the C language and how a computer runs a program is exactly the opposite of what the previous comment says.

For someone who knows how a CPU runs a program, it will be easier to understand how a C program is run than how a program in another language is run, because for the latter there may be very different runtime library implementations, whose behavior cannot be guessed by looking at a source program, without having supplementary documentation about the compiler or interpreter that is used.

On the other hand if someone knows only the C programming language, their mental image about how the program is executed is likely to be very wrong for any non-trivial program.

For learning an assembly language, the prior knowledge of C is more a handicap than something helpful, by creating bad habits, like using incorrect implicit conversions, inappropriate integer data types, not caring about interactions with the cache memory or memory access ordering, choosing between alternative expressions those that are more inefficient in hardware (e.g. in many modern CPUs accessing data through indices is more efficient than through pointers, but a lot of legacy C programs use pointers to access arrays, under the wrong assumption that this is more efficient), etc.

I agree with the top poster that languages from the ML family are a very good choice for a first-learned programming language.

For a programming language to be known before any assembly language, I believe that even Fortran is much more appropriate than C, because it is much less misleading about how a modern CPU works, and I say this despite the fact that for decades I have been writing programs in the C language, for embedded computers (but before learning the first assembly languages I had experience mostly in Fortran, and to a lesser extent in LISP and COBOL).

For a few years starting with 1990, I liked C very much, because with the Microsoft and Borland C compilers for IBM PC it was a great improvement over the Pascal, Fortran or Basic to which I had access previously, but today, 36 years later, I do not think that there exists any application for which learning or using C makes sense, despite the fact that we will remain stuck with it in many places for many more decades in the future.

Even the ancient Fortran remains more useful than C today, because for many computational applications most modern programming languages are crippled in comparison with it, by poor support for array operations, while C does not have any intrinsic advantage over alternative programming languages. A "C" done in the right way is "D", so it would be better for learning, though it still inherits from C some questionable features, which would not exist in a clean design.

C lacks just enough “modern language features”, by design, that students are forced to be vaguely aware of memory layout, memory management, ref vs copy, shallow copy vs deep copy, maybe even calling convention, etc.

It’s also popular enough that there is an abundance of high quality learning resources for beginners.

No other language threads that needle as well as C.

You really need to grok C and understand Lisp. Learning just these two well, will give you most of the foundation you're ever gonna need. Nearly every other PL is a bunch of accretions on top of one of these; sometimes those accretions are great improvements, and more often than you'd think - they are downgrades.

Lisp can teach you everything about what logically a program is, how computation itself can be expressed - code as data, recursion, and abstraction built from almost nothing, and C can teach you what a program physically is - memory, pointers, and how the machine actually runs it.

I have gone through over a dozen of different PLs, each time thinking that my skillset was improving but I still sucked at it, and just needed to learn yet another language to truly get better at programming. Turns out, I just needed to grok Lisp.

Don't be like me, don't waste your lives wandering around, following a map everyone's holding. Majority not only can be wrong, but as history teaches us - it is wrong most of the time. Instead, follow those few that are looking for shortcuts. They may not have most popular opinions, but they might be on the right path after all.

Computers haven't presented an accurate model of how computers actually work for decades. Compare the surface ISA of anything mainstream since the mid 90s versus all of the superscalar and out-of-order execution happening under the hood.

Deliberate efforts to surface this deeper layer back to the programmer-facing ISA (VLIW, notably Itanium) failed spectacularly outside of niche applications. C and its contenders can't simply hop over the CPU abstraction presented to them without having to map backward from some lower-level model to the surface ISA it's forced to target then having the rug pulled every few years due to microarchitectural changes. It has managed to evolve surprisingly gracefully over decades from tiny 16 and 18-bit machines, sometimes segmented, to 32 and 64 bit machines, and even accommodating SIMD reasonably gracefully via intrinsics (which is about the best we can do at present, as CPUs continue to diverge wildly in this area, though I'm begrudgingly impressed by what modern compilers can do via autovectorization to optimize simple loops).

Yes, I have much less complaints about the content of this paper, except for the PDP-11 meme aspect.