4 ms·

Well... C teaches you how a PDP-11 worked, but modern computers aren't PDP-11s either. Most happen to expose a PDP-11-like structure via x86 assembly, but even

Well... C teaches you how a PDP-11 worked, but modern computers aren't PDP-11s either. Most happen to expose a PDP-11-like structure via x86 assembly, but even that abstraction is a bit of a lie relative to what's going on under-the-hood. C doesn't let you write "string x = y" because it doesn't have string as a primitive variable type; that's the whole and only reason. It's not quite correct to say that "the computer must allocate memory, copy memory, and eventually free memory" to do string assignment---it depends heavily on context and how a given language defines 'string' (are strings mutable in this language? If not, that statement may just be setting pointers to two immutable memory locations the same, and that immutability may be maintaned by type constructs in the language or by logical constraints in the underlying architecture like read-only TEXT memory pages---or both!---and so on). The old Apple Foundation NSString is an interesting example of how the question of string manipulation is a complicated one that doesn't even lend itself well to the "allocate, copy, free" abstraction you've described. Pop that thing open, and you discover there's a ton of weird and grungy work going on inside of it to make string comparison, merging and splitting of strings, copying strings, and mutating strings cheap. There are multiple representations of the string attached to the wrapper structure, and a host of logic that keeps them copy-on-X synchronized on an as-needed basis and selects the cheapest representation for a given operation.

haberman 8y ago
> C doesn't let you write "string x = y" because it doesn't have string as a primitive variable type; that's the whole and only reason. But why does C not have string as a primitive variable type? It's for exactly the reason you state: there are very different approaches a high-level language can take wrt. string ownership/mutability. These approaches might require GC, refcounting, allocation, O(n) copies, etc -- operations that do not trivially map to assembly language. C is close to the machine precisely because it declines to implement any high-level semantics like these.
- fixermark 8y ago
  I wouldn't call "lacks a feature" the same as "close to the machine" any more than I'd call "specifically refrains from defining whether 'a' or 'b' is first evaluated in an expression like 'a - b'" as "close to the machine." Machines lack statements and expressions entirely, but C has those; the reason that C refrains from being explicit on order of evaluation for (-) and other operators is that on some machines, evaluating b first, then a, then difference, lets you save a couple of assembly instructions at compile-time, and on some other machines, the reverse is true. So C's ambiguity lets the compiler generate code that is that much faster or terser on both machines (at the cost of, well, being Goddamn ambiguous and putting the mental burden of that ambiguity on the programmer ;) ). Perhaps it is more correct to say not that C is "closer to the machine," but that C "tries to position itself as somewhat equidistant from many machines and therefore has design quirks that are dictated by the hardware quirks of several dozen PDP-esque assembly architectures it's trying to span." Quite a few of C's quirks could go away entirely if someone came along, waved a magic wand, and re-wrote history to make K&R C a language targeted exclusively at compiling Intel-based x86 assembly computer achitectures, or even one specific CPU.
monocasa 8y ago
The C = PDP-11 meme doesn't really line up with reality. Those features that people normally point (ie. the auto increment/decrement) were taken from BCPL, which is older than the PDP-11.

haberman 8y ago

> C doesn't let you write "string x = y" because it doesn't have string as a primitive variable type; that's the whole and only reason. But why does C not have string as a primitive variable type? It's for exactly the reason you state: there are very different approaches a high-level language can take wrt. string ownership/mutability. These approaches might require GC, refcounting, allocation, O(n) copies, etc -- operations that do not trivially map to assembly language. C is close to the machine precisely because it declines to implement any high-level semantics like these.

fixermark 8y ago
I wouldn't call "lacks a feature" the same as "close to the machine" any more than I'd call "specifically refrains from defining whether 'a' or 'b' is first evaluated in an expression like 'a - b'" as "close to the machine." Machines lack statements and expressions entirely, but C has those; the reason that C refrains from being explicit on order of evaluation for (-) and other operators is that on some machines, evaluating b first, then a, then difference, lets you save a couple of assembly instructions at compile-time, and on some other machines, the reverse is true. So C's ambiguity lets the compiler generate code that is that much faster or terser on both machines (at the cost of, well, being Goddamn ambiguous and putting the mental burden of that ambiguity on the programmer ;) ). Perhaps it is more correct to say not that C is "closer to the machine," but that C "tries to position itself as somewhat equidistant from many machines and therefore has design quirks that are dictated by the hardware quirks of several dozen PDP-esque assembly architectures it's trying to span." Quite a few of C's quirks could go away entirely if someone came along, waved a magic wand, and re-wrote history to make K&R C a language targeted exclusively at compiling Intel-based x86 assembly computer achitectures, or even one specific CPU.

monocasa 8y ago

The C = PDP-11 meme doesn't really line up with reality. Those features that people normally point (ie. the auto increment/decrement) were taken from BCPL, which is older than the PDP-11.