2 ms·
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 st
by jackhack 9y ago
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.
- moron4hire 9y agoI 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).
- jackhack 9y agoAgree 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.