> It takes me a few seconds to rewrite foldl from rote understanding: foldl f z (x:xs) = foldl f (f x) xs, because it takes a function, a 'zero', a list of head

> It takes me a few seconds to rewrite foldl from rote understanding: foldl f z (x:xs) = foldl f (f x) xs, because it takes a function, a 'zero', a list of head and tail, and calls itself again with the same function, a zero 'going up' (so accumulating) and a list 'going down' (being exhausted). So as you see this is an almost a visual way to understand it, which is natural to those that already are familiar with these abstractions, but is meaningless to those who don't. I think this type of explanation falls into what the parent post is talking about. That is a technical accurate but very dry way to describe a construct that simply calls the function it's given for every element in a collection and returns the accumulation of the results. Granted you can dive into all sorts of discussions about what that _really_ means and what power it gives you, but save that for much later, it isn't introductory material. An analogy to how functional programming often is taught would be if I tried to teach a new programming language by going over the BNF grammar first without context instead of starting with how the language is actually used in practice. It may be more 'technically correct' but it's a terribly ineffective way to learn for most people, even those who know and understand BNF. People are often more interested in what they can do or create with this new thing, not the nitty gritty details of how it works mathematically even if they intend to get into the details later.