My first language was C, back in the early 90s -- from nothing but the K&R book -- and I did learn pointers before I learned my next language (like truly grok them, have the ability to visualize the concept viscerally). When people in interviews ask me to tell them about the most technically challenging thing I've ever done, I tell them about learning pointers in C as a teenager. Taking everything in its context, nothing else in technology has gone that far in pushing my intellect.

I agree, it's extremely difficult to go from zero to "understands pointers". I think it's a hurdle that a lot of people have failed to clear and have quit programming to go into other, less-lucrative fields. I don't think it has to be that way, and I don't think there is any virtue in it, either.

I was a C64 kid. Basic had peek/poke to read/write memory addresses directly. I still remember 53280 and 53281 as bytes to flip to change screen colors. So it came to me naturally when I saw assembler and Pascal pointers later on. It just depends on how you grew up.

I agree - you can present a topic before the student is ready and confuse. That happens quite often, in fact. But it's not the fault of the language. And the student must have that background to be prepared.

C was the "universal assembly language." In its day, it was unimaginable that one would learn to program a computer without an understanding of the hardware underneath, or computer architecture in general.

>>a systemic aversion to copying data But this isn't an issue with the C language or pointers, per se; an "aversion" to unnecessarily moving data is the very essence of optimization. [As part of choosing the right algorithm to begin with, of course.] As Michael Abrash wrote: "the fastest code is the code that never runs." So eliminating work (such as moving bits across a bus) is key.

I never claimed it was the fault of the language. It's the fault of advocates pushing it as a viable first language. My point on premature optimization was precisely because of that: optimization should not be a concern for raw beginners, and C programmers as a culture value optimization in all things, even to the point of error (fast code is not necessarily secure code).

Agree with you there & appreciate the clarification.

I would only add that many of those who obsess with optimization and "clever" programming, have never had to go back and maintain that code. I've looked at far too many modules and said "what was this idiot thinking?" before realizing it was my own work from years' prior.

With a bit of that perspective I now write code favoring clarity over cleverness/performance. And if it is unavoidable to write something dense, I document the hell out of it.

But you're right, there is a definitely a culture of writing impenetrable code full of clever & cute little tricks of the sort that come back and bite the author later. Prevalent in the C world, and I see it also in equal measure in Perl.

If you don't understand when you're working on a mutable version of a data structure vs a copy, you can't get very far. So at least that part of 'understanding pointers' is crucial in any language?

I don't know what companies you've worked at, but you can clearly get pretty far without having that sort of mastery over a particular language. I'm not saying it's good to stay in that state of ignorance, but it's definitely a thing, and I think the more gentle introduction to learning the topics that dynamic languages provide makes it more likely people will stick with programming at all, rather than quitting and changing their major to History or something.

>>but you can clearly get pretty far without having that sort of mastery over a particular language.

Completely agree. If this weren't true, the fizzbuzz test wouldn't exist.

The 90s were filled with businessmen creating Access databases that wouldn't scale, and Visual Basic's drag-and-drop capabilities created a cottage industry for controls consumed by non-programmers.

That's both good and bad. Bad for the obvious reasons (lots of crap software) but good in that for the most part people were able to build what they needed to solve problems and move on.

The trick is to benchmark that "crap software", not against the architectural marvel you would build, but against the Byzantine Excel spreadsheet (or worse, binder of paper forms) that would have been used otherwise.

Nowhere is "worse is better" more true than line-of-business software.

I'd agree, and even in Python, we end up talking about how some variables store "memory addresses," to explain the sometimes confusing behavior of variables bound to mutable objects. What's less essential is understanding all the ways that (C's) pointers can bite you: pointer arithmetic that results in invalid addresses, use after free, dereferencing uninitialized pointers, returning a pointer to a local variable from a function, and so on.