>But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part.
Ironically, it actually indicates a severe ideological bias on your part, not theirs.
The rest of your post seems like it is entirely platitudes intended to say nothing. No, people don't think in terms of objects, that is why the leaky metaphor used to teach OOP traditionally causes so much confusion, and makes OOP harder to learn than FP. Thinking in terms of FP is not thinking in terms of "formulas", and it appears you are basing all the rest of your assumptions on top of that one faulty assumption. People intuitively understand "I make a thing that transforms other things" much easier than they understand "I make my things know how to transform themselves, or maybe other things, or maybe both, but sometimes neither and I make different things to do the transforming instead, but those things are wrapped inside an "object" that doesn't represent anything for no discernable reason".
I'm not sure I understand, do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both. And I didn't even mean they have to do most of their programming in an OOPL. For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm!
I definitely meant to say something, I think the platitude remark is uncalled for. People don't talk in terms of transformations, they talk in terms of instructions, recipes, responsibilities, parts and pieces, and lots of encapsulated processes. Again, check out chapter 3 of the SCIP, which you already probably know about if you are teaching programming from an FP perspective.
>do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both.
No? How would you get to that interpretation when I didn't even say anything about this theoretical person, but rather about you?
>For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm!
Unless you are doing programming language research, yes you can. Almost everyone already does, it is just that the only paradigm in question is imperative, rather than functional. That's not a significant barrier for the vast majority of roles, especially not PhD students.
>People don't talk in terms of transformations, they talk in terms of instructions,
That's the same thing. People think "beat the egg". Beating is a transformation, egg is a thing. People do not think "send the egg a message requesting it to change itself to the beaten state", which is why the OOP metaphor fails so badly. Functional programming directly maps to the normal way people think, as does traditional imperative programming. OOP does not.
> Unless you are doing programming language research, yes you can.
Yes, I do, but no, its still a problem. With my colleagues, they are even more strict about OOP experience. I'm sort of unusual in that I appreciate FP experience, or I actually demand it, as part of finding well rounded candidates (very difficult in China, to be sure).
You don't "transform" the egg chemically from an unbeaten to a beaten state. Instead, you beat it, and that well-known transformation happens as a side effect. Also, after you've beaten the egg, you don't have an unbeaten egg to reuse elsewhere in another operation. Finally, someone has to beat the egg, either yourself or your assistant, or a machine designed specifically for beating eggs. In this way, FP does not map to the way normal people think.
I'm now unable to tell if your post is serious or satire. The strawmen are so glaring and absurd that I have a hard time believing you are seriously attempting to use them to make an argument. Chemistry, seriously?
Totally serious. You picked beating, which is THE classic side effect operation, and you had no idea what was going on? If so, just refresh your memory on what beating the egg actually does (spoiler: people don't beat eggs because they are angry at them):
Well that is genuinely impressive then. Please explain to me how the fact that no chemical reaction occurs when beating an egg is in any way relevant, or even related to the discussion, or anything I said. I didn't say beating an egg caused a chemical reaction, and at no point would anyone who has even the loosest grip on reality consider that to be relevant at all.
Had you just suggested that beating eggs is a side effect, and thus not purely functional you would have gotten a response. But when you go so far off the rails that the only reasonable explanations are that you are trolling or insane you shouldn't expect people to take you seriously enough to bother responding.
Yes, beating an egg changes the state of the egg from unbeaten to beaten. Yes, this is a difference, however it is not a difficult to understand difference. I explain it all the time, that's why I used it as an example. "With functional programming, instead of the egg_beater function changing the egg, it takes in the unbeaten egg, and returns to you a beaten egg. If you gave the unbeaten egg a name, you can still use it.". That is easy to understand, which is why people respond with "oh, ok" instead of confusion. This concept has to be understood when teaching OOP too, as generally methods that just change state return "this" so you can chain method calls: egg->beat()->fry(). So proposing that it is some unfathomable difficulty with learning FP is ridiculous.
Ironically, it actually indicates a severe ideological bias on your part, not theirs.
The rest of your post seems like it is entirely platitudes intended to say nothing. No, people don't think in terms of objects, that is why the leaky metaphor used to teach OOP traditionally causes so much confusion, and makes OOP harder to learn than FP. Thinking in terms of FP is not thinking in terms of "formulas", and it appears you are basing all the rest of your assumptions on top of that one faulty assumption. People intuitively understand "I make a thing that transforms other things" much easier than they understand "I make my things know how to transform themselves, or maybe other things, or maybe both, but sometimes neither and I make different things to do the transforming instead, but those things are wrapped inside an "object" that doesn't represent anything for no discernable reason".