> This kind of sweeping unsupported assertion is actively harmful for FP evangelists. Anyone who isn't already a fanboy is most likely going to read that and say “clearly this person has no idea what they're talking about. [close tab]”.

That seems as much an unsupported assertion (i.e. opinion) as what I wrote.

I don't think it's useful to try to write a comprehensive essay with no ambiguity every time I comment, and I don't have the time. Doesn't mean I don't believe the things I say. :)

If you decide to close the tab because I said functional programming languages are much better at abstraction, that's too bad, but it's not exactly an unsupported assertion--and I'm not trying to sell you anything anyway.

If it helps, most of my FOSS stuff is written in Go, a language Haskell fans generally vehemently dislike for "ignoring 30 years of PL research." I actually like Go for a similar reason I like FP: It does away with a lot of the bad abstraction (classes) and emphasizes the good (interfaces.)

The difference is that you're dismissing the entire field of mainstream software development for the last couple of decades as “elementary school” level abstractions which “do a very poor job of solving more problems than they create”. A strong majority of working programmers are familiar with those concepts because they were taught those concepts in schools, by industry experts, and see them used by platform developers and vendors.

FP is not that pervasive and anyone trying to make the case that it's better across the board has to address that familiarity gap. Try to think about, say, the average Java or C# developer working on a large project. They aren't spending their day saying “OOP is terrible” and when you say something is better because it's “grounded in mathematical practice” that's really non-obvious to someone who's thinking the main way their life would improve would be if they could get the business stakeholder to make a decision and stick with it for more than 24 hours, stop using Oracle products, etc. Talking about avoiding shared state and side-effects, going beyond Java-level typing to make refactoring safer, etc. is a lot more useful since those probably are things they spend time on regularly.

I don't disagree that somebody who knows OOP but not FP needs a lot more information than I gave. Where we disagree is on the notion that I need to explain everything in detail when there are fountains of material out there. If anything, the purpose of my comments is to make you think, "Is it hyperbole, or is he on to something? Maybe I should look into this further."

I was an imperative programmer for a decade before I looked at functional languages, and it was because of glowing but unfamiliar praise that I looked deeply in the first place. Now I know that a lot of that praise was warranted. Everyone's different!

Also, as I noted in another comment, the "elementary school" comment was not meant to imply that it's simple--alas, one of my main gripes with OOP is that it isn't simple in the ways it needs to be--just that it's something you're almost certainly exposed to early on, so it quickly becomes what's familiar.

Just wanted to note that the "elementary school" comment in the original post rang true with me. When I was learning OOP, my first program was literally about animals (cows, chicken, sheep) making sounds. A cow says "Moo", a sheep says "Baa", a chicken says "Cluck-cluck", an Animal says "Error: this method shouldn't be executing" or something.

What he wrote is a comment in a forum, not an article. This is his opinion.

Yes. Note that I did not say it was wrong or that he shouldn't be allowed to hold it, only that the style in which it was expressed seemed unlikely to be effective for people who didn't already share that opinion.