Other than for teaching "an industry language" I don't immediately see much reason to teach C and Pascal - but I suppose the "modern" equivalent would be Python, Cython, C and assembler, followed by haskell/(oca)ml, Prolog and/or a lisp/scheme - with the benefit of showing C interop along the way.

On the constrained part of things, there's no pointer arithmetic, and in Standard Pascal, there's no "address of" operator at all - a pointer can only point at dynamically allocated memory block, not at global or local variable, or some memory location inside another block. Consequently, there's also no pointer arithmetic. This is sufficient to make linked lists and other similar data structures, but also makes the concept much more opaque compared to C (i.e. it's less obvious that it's really a numeric address).

On the syntax part, I think the big problem with C is that the moment you start dealing with pointers, the arcane rules for declarator precedence are in play. Pascal, OTOH, has a very regular type syntax, which in case of pointers is also easier to read - you just read ^ as "pointer to", and so ^integer is "pointer to integer". Same thing for dereferencing - again it's ^, but there you read ^ as "points to", and so a dereference like x^ becomes "what x points to". And there's also no confusion with any other operator, since ^ is reserved for pointers alone, and it has a fairly obvious mnemonic to it.

Sure, sixy seven lines of assembly handily beats arcane crap like:

   obj->ops.tbl[BLAH]->func(obj, &obj->x, arg);

Just use LEA (load effective address) and don't comment anything.

Let the reader figure out that no pointers are involved.

[edit: 99% sure is sarcastic]

Do I have to buy what you're on from some guy on the street or is it available as a prescription?

> As such, it lets you "feel" the bare metal, much more so than a scripting language like Python or Javascript.

C hasn't been bare metal since the PDP-11. There are like eight layers of abstraction between

  char *foo = "bar";

So the compiler is obviously one layer. Then there's the assembler and the linker. Does the C runtime count too?

You think you have a "string", but it's actually just an address to a (hopefully) nul-terminated chunk of "contiguous" virtual memory.

If you wanted to read the first byte of that array, it would first go through the OS's virtual memory system, so that's one rather large abstraction. (I'm lumping in the hardware's virtual memory support here, too)

Then when you actually access a piece of "real" memory, there are a number of caches between your data and the request to fetch it. And what about the DRAM itself? Can it access only a single byte of memory at a time, or is that too an abstraction?

Instruction decoding is one or two layers at least, since chances are the processor doesn't actually execute x86 opcodes directly.

And when you run out of software abstractions, how many levels of abstraction is there in the actual hardware?

I only have vague ideas of what actually happens at this level, and whenever I stop to think about it, it's pretty amazing our software stacks work at all...

I'm not sure what you mean by layers of abstraction (type checking? optimization?) but C code often does have a pretty straightforward translation to assembly.

Perhaps you had a bad experience and can clarify what you mean?