The reason he says it's not popular is because the vast majority of people think imperatively when dealing with a problem that involves state and time. They might think functionally when trying to express an immutable law or when categorising the qualities of a horse or whatever. But when doing something that involves changing the state of the world in time and space (which is a significant part of many programs) they think imperatively. And even C will support enough of the functional stuff to do the rest (see Numerical Recipes, for example)
Those can be written in any style we like. For example, in languages like JavaScript and Ruby, if we wish to compose classes out of smaller components, we can imperatively modify classes, or we can write functions that take existing classes and return new classes consisting of the originals composed with whatever additions we desire.
What I am trying to say is that while imperative may feel more natural for problems involving state and time, we often perceive that problems require state and time even when they don’t.
---
I can fully accept the argument that people don’t like FP because they perceive that their problems need imperative solutions. But that is not the exact same argument as “people don’t like FP because their problems involve space and time."
I like "solving puzzles" but I don't like solving them under pressure. I also don't like deciphering someone else's puzzle when I am in a hurry and when I'm unlikely to never need this piece of code again. So even for people who like puzzles it's often the case that they just need to get something working fast that's reasonably correct.
The fact that life is short and that the world changes so rapidly is what makes worse better.
No. Shit. Sherlock.
I’d say the same thing about human languages. Can you imagine me criticizing Japanese because when I try to translate the English in my head to Japanese on a word-for-word basis, it’s a lot of hard work and the result is terrible?
The point of learning a different language is not to learn how to translate what is in your head into whatever the language demands, it is to change what is in your head. Alan Perlis put it best:
What I would say, is that if you know language X and want to compare it to language Y, you need to keep working at Y until it affects the way you think about programming. If it doesn’t, you can then say that it failed to improve you as a programmer. If it does, you can then give a thorough review of how your new perspective has improved you, and whether it is worth the effort.I’m not saying FP is better or worse, but I am saying that “It’s terrible for writing the imperative programs in my head” is not a good argument.