If it's so beneficial then those people can prove it by building something exceptional. I worked with Haskell and Scala for almost a decade and libraries were full of bugs and performance problems. A lot of bugs just hadn't been reported because so few people were using them. FP certainly has its strengths but so far there's very little evidence that it produces better software in the long term.
For example, I'm a biochemist with 12 years of education, and I can't seem to be able to convince anyone that vaccines are safer than no vaccines.
Humans just don't like new things or changing their mind, and that's a very generalizable fact, even among very smart groups of intelligent engineers.
Imagine trying to get people to accept vaccines, but in a world where we have other types of medicine that usually works well enough for all the things you've developed vaccines for, and the only argument you're allowed to make is "it's obviously better, look at how amazingly liquid the stuff in this syringe is".
You'll still get some resistance, but in our current world, pure FP is much more of a niche thing than pro-vaccine stances. There's a reason for that.
I suspect you aren't that knowledgeable about either.
> For one, vaccine people can actually explain why vaccines are good.
Unless you have a very particular background, I'm suspicious that you can actually follow the frontier of that argument. More likely, you're getting the ELI5 explanation.
> FP people seem to mostly just repeat variations on "it's easier to reason about" and showing trivial functions that are generally not easier to reason about.
Well-designed FP languages reify coherent low-complexity formal semantics. When FP advocates say "reason about", they mean in a (semi-)formal sense. No popular imperative language has any kind of denotational semantics, so good luck reasoning about the compositional behavior of C++ libraries, unless your definition of "reason about" is "think about informally".
People who actually understand complex things are able to provide ELI5 level explanations for people who haven't the background for more rigor. You're presenting a false representation of the OP's comment anyway: it never suggested the explanation for why vaccines are good required "frontier" level discourse.
> Well-designed FP languages reify coherent low-complexity formal semantics.
This is such a great example of what so many of us have noted about FP evangelists. It's so divorced from writing software as to be gibberish.
Yes, in theory.
In practice, people come to your explanation pre-conditioned with a lot of (often politicized) misinformation, Dunning-Kruger type overconfidence in their own ability, very little curiosity or openness to new ideas, and exhibit the attention span of a 26th percentile squirrel.
People tend to listen very little and are more skeptical of others than they are of their own understanding: instead of searching for ways in which their mental models need adjusting, they try to poke holes in your explanations. This undermines both "ELI5" approaches (because what you gain in simplicity you lose in nuance and correctness) and more pedantic approaches (which require more prerequisite knowledge, experience, and patience).
If you disagree with me because that is not your experience, just consider that you probably surround yourself with above-average intelligence people.
Until someone bucks the trend and does it.
But for that you need someone with actual intelligence and empathy; a Feynman of that sphere so to speak.
In every gatekeeper community this is the order of things until someone finally destroys the gates to the knowledge and the monopoly of the priesthood. Until then, it's basically "blame the victim" for their own lack of understanding (e.g. "people listen very little", "people are more skeptical of others", "they try to poke holes in your explanations", "They'll repeat whatever objections they've seen or heard somewhere", etc).
Hopefully people who read QED don't go around thinking that they know all they need to know to make an informed judgement about lagrangian QM.
And regardless of where we place the blame, at the end of the day:
> In life, there are a lot of obvious things that are very difficult to teach.
Only if the software you're writing is A) aggressively simplified, so as to be amenable to informal analysis, or B) garbage.
If you're only interested in writing garbage, or perhaps you don't even notice that's what you're doing, then the appeal of FP is significantly reduced.
Have you used other software? 99% of it is dogshit.
> libraries were full of bugs and performance problems
This is a really wild claim to me. IDK about Scala, but libraries in Haskell, Ocaml, and Elixir are all vastly better than libraries in C++, Java, Python, despite a smaller userbase.
Case in point for the problem with FP communication. When you speak in smug absolutes, it comes off as religion.
I'm pretty big into the FP world. I love Purescript. I dig Idris and exploring dependent types. I spend a lot of time at work teaching "functional" thinking. And yet, I still find most "hard core" FP evangelists insufferable for smugly explaining things as "obviously beneficial." ugh.
That is a lots that sucks about pure FP. It's not all upsides. The FP community can do a lot better at "evangelizing" by talking like engineers rather than sales people.
> talking like engineers rather than sales people.
They do talk like this - go to any Haskell conference and it's 90% engineering papers - much better than e.g. a JS conference. It's just that most people don't even know what PL engineering even looks like, let alone how to interpret it.
cmon fuckin guy
Seems easy to me.
If it's obviously benefitial, show me:
- Performance benchmarks showing how much faster the compiled code runs
- Case studies demonstrating faster development and/or fewer time spent debugging
- Studies showing consistently better maintainability
If it is lacking this data, it comes across as religious fervor.
The only semi-objective metric you've proposed is compiled code performance, which is a fairly small component of most people's utility function, especially when the difference disappears in all but numerical-computation-centric applications.