"Okay, we're going to start with a simplified version of this concept first. Keep in mind that the reality is somewhat more difficult to grasp, but grasping thi

"Okay, we're going to start with a simplified version of this concept first. Keep in mind that the reality is somewhat more difficult to grasp, but grasping this simplified and idealized version will help you to eventually grasp the real deal." No problem with that. But out of order explanations are unforgivable. I did get better in math when I figured this out and learned to find the meaning of the symbols first. But believe it or not, sometimes this wasn't easy. Sometimes I would encounter some esoteric mathematical notation and have to spend quite a bit of time digging through books or searching the net to even find a place where anyone bothered to explain what it meant. By "what it meant" I mean what it meant conceptually. A bunch of jiu-jitsu of symbol manipulation is completely worthless without a conceptual understanding of what that manipulation is actually doing. My first aha here was with calculus. After struggling really badly in high school and then college, someone finally told me that a derivative was a rate of change. After that, I completely got it and had no further problems with derivatives, integrals, or differential equations. It all made perfect sense. I also completely understood why calculus was invented, and its historical importance. The book did say a derivative was "rise over run," which I suppose is a maximally-obtuse way of saying "rate of change," but it never clicked. How in the world do these people perpetuate their discipline? But back to functional programming. I taught myself to program when I was four years old. It was BASIC on the Commodore VIC-20. In retrospect I think it was easy for me even as a 4-year-old because everything was explained in terms of "this statement does X," and then the more complex variant of "this statement makes the next statement conditional on..." I got that because that's how things work. Things work by, umm, doing stuff with stuff. I think this is why procedural languages are so much easier to grasp. Procedural languages are explained in terms of what they do with stuff, which is how people think because that's how things happen in the real world. Functional languages on the other hand tend to be introduced in this obtuse, theoretical, mathy way, with symbols and expressions thrown out before their function or conceptual meaning is adequately explained. Introduce FP like this: language, semantics, and meaning first, then concepts, then immediately dive into doing things with it. Try that and I think FP will get more popular.