Okay, so FP is more difficult to learn. Assume for the sake of this argument that FP has a tangible benefit over other paradigms, that manifest themselves at scale. You're tasked with educating students in this paradigm, but they complain that it is more difficult than the techniques that they are used to.
I don't know, because I'm not qualified for it. I had to pass a course on FP, but frankly, I wouldn't be able to do anything with it in practice, let alone teach it. My only personal experiences with it were negative. If it had been Haskell that was the entry level programming course, then I probably would never have learned to program.
Okay, so given this answer here's what I would do:
1) I wouldn't make it the entry level course. It's clearly a paradigm that's used by a minority of people, so it doesn't make sense to start educating students with it.
2) I mandate that all students take it, maybe in their 3rd year. We're going to mandate it because there are tangible benefits (which we've assumed for the sake of this argument). They're going to find it harder and more confusing because its's different to what they're used to. A lot of them may not like it and won't see immediate benefits. Some may even come to dislike it. Frankly, I don't care, some will pick it up and learn about it further. And when the students that disliked it inevitably run it into the future, they sufficiently prepared to deal with it.
We're back to square 1: forcing it down student's throats. If you still think that we shouldn't be forcing students to learn FP in schools, I think you have a problem not with FP but with structured curriculums.
Spark is the quintessential Google-scale FP project - it was even born out of the MapReduce paper by Google!
And there's plenty of other large-scale projects that are arguably in an FP style specifically to deal with the problems associated with scaling them: the Agda/Isabelle proof checkers, the seL4 kernel, the Chisel/FIIRTL project, Erlang/OTP, the Facebook Anti-Spam system (built on Haxl), Jane Street's massive investment into OCaml, Twitter's investment into Scala.
Not all scale problems are distributed problems. Some distributed problems are tackled by FP, and some aren't. Ultimately, these large-scale projects pop up at similar rates to the usage of the language themselves. It's intellectually dishonest to say that FP can't be used to tackle large scale problems, and the problems that occur at scale, because its repeatedly validated that it can.
It is also intellectually dishonest to strawman an argument.
I didn’t say it is impossible to do X with FP - I said it is not necessary to do X in FP.
You can convince yourself of that by looking for larger-scale non-FP counter-examples to the ones you've cherry-picked.
Every single large scale problem is a distributed problem simply because human societies are multi-agent distributed systems and programming languages are human-computer interfaces.
The issues at scale are systemic and arise from the design trade-offs made when your system's requirements bumps against the limits of computation. No language/paradigm can work around those.
The best a language can do is abstract-away the complexities behind a problem - solve it once (in the language/paradigm's preferred way) and give the human an interface/concept to work with.
Okay, I got really confused by this whole mandatory thing. I never said FP should be mandatory at scale. I said it had a moderate benefit at scale. You respond with "well actually, it's not mandatory at Google-scale" so I assumed that you were trying to refute the fact that FP has benefit at scale.
You also followed this up with
> The kind of problems that emerge at scale are not the kind of problems FP tackles.
I cherry picked these examples to demonstrate that you're completely talking out of your ass here.
> I didn’t say it is impossible to do X with FP - I said it is not necessary to do X in FP. You can convince yourself of that by looking for larger-scale non-FP counter-examples to the ones you've cherry-picked.
I never said it wasn't possible to tackle these problems without FP.
You need to get rid or the assumption that "if X is better than Y at task Z, everyone will use X rather than Y for task Z". You've used that line of logic to attempt to invalidate FP's capabilities. It simply does not make sense.
You give them difficult real-world problems where FP is helpful.
But university computer science seems to be specialized from mathematics instead of generalized from engineering, so CS professors most of the time have no idea about real world problems. At least here in Germany, where the problem seems especially bad.
What do you do?