I'm guessing Zed first learned to program using for loops so they look "natural" and easier for beginners to learn than functional callbacks. That seems like a testable proposition, but I'm guessing it isn't so. There aren't too many situations in life outside programming and racing where people go around in circles to get something done. Furthermore, the choice of print in the example begs the question. Are you teaching that imperative programming is natural and functional programming is only for "advanced" students? What are you going to teach the beginner when the goal is calculate the sum of the squares of a list of numbers?
FWIW I learned on BASIC. "GOTO" looks natural to me. It's also much closer to the machine. Structured programming is a prettification of test-and-jump, and you have to be able to see through it, to use it well.
Functional programming, on the other hand, is a bit of a conceptual leap away from the metal. If you're mapping two functions over a stream of data how many loops is it? In a dumb language like Ruby, it will be as many as your map() calls. But in Haskell, it will fuse them into one loop doing two operations. And the thing with functional programming is, you're not supposed to care - except, you do have to. Generating an endless unresolved series of thunks in Haskell is a beginner mistake. But if you can't see through the functional list-flipping to the generation and consumption of callable heap objects in a test-and-jump cycle, you're going to be scratching your head.
My answer would be to teach both assembler and FP, and step up and down simultaneously. Start on Excel and move to Haskell, while also starting on 6502 or some such toy assembler, and moving to C, and meet in the middle at Scheme.
In a very real sense, imperative programming _is_ natural. Its much closer to how computers work. Whether this means that its an easier way to learn is up for debate. (For the record, I think it is easier for a majority of people, but that functional would be easier for a significant minority.) Your phrasing of that part just kind of bothered me.
I think we already teach beginners that you calculate the sum of the squares of a list of numbers with a for loop. Actually, its a fairly common type of problem when you're learning about for loops. Maybe I'm missing your point?
Natural != how the machine works. Few of us have the faintest clue about how the laws of thermodynamics apply to the internal combustion engine or how solid state physics leads to semiconductors leads to electronics leads to electronic injection. Yet we all drive cars as naturally as we walk.
I'd argue that your analogy strengthens my point. In their original form, cars involved people manipulating the mechanical parts as directly as possible (the steering wheel was completely tied to the front axle, the gas pedal, brake, starting crank all directly controlled a single aspect). And yet, we drive cars so naturally. I think using the word natural in this sense makes a lot of sense.
Ruby gets `each` specifically and blocks in general from Smalltalk, so I'd be willing to bet there is research showing whether it is easy or hard to pick up. I'd further wager that the answer is that it is no harder. Loops are more "natural" for the machine, and therefore anybody who understands the machine; that doesn't mean they're more natural for the student.
