I'm not sure why you bring up C. A look on Wikipedia tells me FORTRAN II was made in 1958, then BASIC in 1964, and then C in 1969-1973. FORTRAN II looks like it was clearly in the same design family as BASIC, with line numbers, multiple GOTO variants, capitalized English words for syntax, and a necessity to munge obscure memory addresses to invoke advanced functionality. :)
Just like you, the first language I learned was BASIC--specifically Applesoft BASIC--and the second was C. I liked C better because its program code was more modular (no need to push around line numbers when combining programs or inserting code) and it had variables that were local to the current procedure call, which made recursion much more useful.
Then I learned JavaScript, and I no longer had to worry about choosing specific numbers for my array sizes or fumbling with pointer operators. Then I was formally taught Java, and that's when I finally felt capable of writing just about any program: Run time allocation was now easy even when the lifetimes didn't fit a recursion hierarchy (i.e. I couldn't stand malloc() before), and the notion of behavior as part of data made it easy to pursue higher-order designs.
---
"But it seems to me that a concrete concept is easier to understand than an abstract one. The hardware gives you a concrete frame of reference."
Although I briefly programmed in C and I've occasionally read machine code, I don't recall ever considering computation hardware to be a very good frame of reference. Mathematics is where I find confidence, and user experience is where I find tangible feedback.
C tells an elaborate story of a world where memory is mostly one-dimensional, mutable, and uniformly cheap to access, where this memory contains all execution state (even the stack), and where execution takes place in a sequence of discrete steps. In our present-day world of cloud and mobile computing (not to mention the future), where we use networks, caches, distributed code sandboxes, predictive branching, cryptography, etc., this metaphor of computation is a joke at spatially large scales and only an approximation at small scales.
I suspect C feels close to the hardware because (1) historically it's been much closer, (2) CPU-scale architecture design has continued to pander to it, and (3) its elaborate story provides programmers with a chance to discover escape hatch after escape hatch, until they're trained to believe that C closes no doors to them.
---
"a character is the same as an integer holding its ASCII code, a string is the same thing as an array of characters"
If the text you need to represent is always unformatted, canned English, then a sequence of ASCII codes might be the only representation you need. However, I hardly consider all text to fall into that category. I think text can be as hard as natural language and typography, which can be as hard as UI.
>> Then I learned JavaScript, and I no longer had to worry about choosing specific numbers for my array sizes or fumbling with pointer operators.
Javascript is easier in that way because it has garbage collection. Garbage collection makes programming easier. But you can't add garbage collection to every programming language. There are trade-offs when the language abstracts away details like memory management.
>> I suspect C feels close to the hardware because... CPU-scale architecture design has continued to pander to it
I think this gets to the issue of the Von Neumann architecture, and the fact that it isn't the only possible way to design a CPU. I'm not well educated on this subject... However, I don't think you can say that C is the reason for the Von Neumann architecture. I think it's the other way around.
>> "a pointer is the same thing as a memory address"
>> Eh? Who says it isn't? :)
I meant that pointers are the same as integers, integers that hold memory addresses. Which is what they are from the standpoint of the cpu.
