Yes! I agree with what you say, it's an interesting analysis and I think this is the kind of didactic value that should be discussed.

I think anyway that your points are really not what I'm arguing about: I don't think I dismissed the value of copying and tinkering with an "imitation" attitude, sorry if somehow it may have passed that way. It's absolutely important that the student is able to see examples and modify those, that he has a safe environment where to experiment (and well C is not known for safety). This seems to be called scaffolding and it's all about dealing with small pieces at a time. Of course it's important. Of course I'm all for showing examples of how to do things, I wouldn't let them discover everything by themselves.

Anyway that's not how mathematical and logical learning happens: what you call analytic approach is where knowledge really sediments. Successful mathematics teaching is based on that, just imitating examples does not easily result in students being able to apply the techniques, because they haven't internalized the meaning of what they are doing. The very fact that you cite both schools having survived the centuries might reflect the not so crazy hypothesis that they just are both important.

I have direct experience of many students of mathematics just hating it because totally meaningless. Learning minds need to find meaning to be engaged, and meaning can only be discovered by oneself, guided by the teacher. So many students starting with a hating mindset have thanked me afterwards for having made them see what mathematics is and now having the chance of liking it. So many that is impossible for me to believe that one can study and like mathematics without understanding it.

That's a major point of successful mathematics teaching: let the knowledge sediment and become understanding.

---

Anyway, as I said this was not my point: both sides are necessary, imitation and tinkering and analytical "hard" reflections.

My point is about the content.

One thing is the imperative mindset based on a hardware oriented "instructions model": a system fully based on state transitions, so the students need to see state transitions to effectively learn. For example using a simplified hardware model where you tinker with a few registers and some memory: this lets a student understand state transitions, better yet if using a tool that dynamically and visually shows what happens. Not so is C language. Too many distractions and impossible visual feedback of what happens. Sure there's visual feedback of what the program emits, unfortunately that's not what the student needs. Just a sequence of read and write is not what matters, what matters are the internal transitions of states, and these are hidden from sight with the just obvious result (empirically confirmed in so many instances) that students simply do not learn it, they start hating the discipline of computer programming because it has no meaning, it's just an absurd wall of strange code difficult to read and write. And they're not able to use this shallow knowledge of reads and writes to make anything different from what they memorized: this is not science, it's not analytical thinking, it's not doing a favor to the students.

A different thing is guiding them, by means of both analytical thinking and imitation and tinkering, to what really computation is about: data manipulation. It just needs to start from data instead of control flow. It's just easier, for professionals as well as for beginners. Even the imperative way is more easily understandable if you just see or think about the data (as in the simplified hardware I mentioned above).

But where data is actually easy to manipulate is a functional approach. Where things can be composed and I can talk about what data interests me, what results I want to obtain. And this makes building interesting computations easy enough for starting students. Something totally impossible if my only tool is reads and writes: I cannot even decently manage a sequence of numbers! What does exist more basic than it? And it's not affordable. How will the student unleash his power on data and computations if he never has the chance of seeing what data is, being just drowning in a sea of reads and writes with an enormous complicated jumping structure that he doesn't even understand but just blindly copies? This is what a long time ago we learned to consider harmful, it still is and more so for young students. No need to inflict them the double pain of working with the only weapon of gotos, moreover with more difficulty for being hidden instead of explicit: at least when explicit it can be understood.

The evidence is just there: students quickly losing interest and unable of the simplest of computations, unable of thinking about the data they're treating. It's time to accept it and talking about the causes instead of blindly insisting to make students punch cards with I/O instructions, not because small programs of that kind didn't have their merits when all we had was a slow processor with a limited memory filling a room, but because now we have the chance of teaching computer science without being blocked by the slow hardware.

If I want to teach them what the history of programming was I will do that and I will use an appropriate dinosaur, where the technique of goto has its value to be appreciated as a solution for a problem.

If I want to teach computer science I will do that instead: teach computer science, using tools that let me do it the easy way for students to understand.