[jamesblonde]

The move towards Interactive Applications has helped OO and scripting languages. There are still plenty of applications for functional programming in the most demanding of environments, for safety and high availability. However, most students are not good enough at math to learn functional programming concepts. Whether that's the teachers' fault or the students' fault or society's fault, I can't say. But if we paid programmers for safety critical systems much more than we pay for good front-end developers, you would see a much higher level of adoption of functional programming languages.

[adbmal]

> However, most students are not good enough at math to learn functional programming concepts.

When does this misconception disappear?

You don't need to be good at math to use functional programming. It's nice that there is a correspondence between math and FP, but it's mostly irrelevant when coding. You could as well say you need a FP background when learning math. Both statements are nonsense and usually spread by people who mostly read complicated blogposts instead of writing actual code using FP.

FP just offers a nice bunch of intuitive and predictable ways of processing information.

[Sean1708]

Take Lisp as a perfect example, I doubt you'd find very many people who think that you need to be strong at maths to learn Lisp. I wonder if this misconception came about because of Haskell's (unfounded) reputation of being a "scary abstract maths language".

[chriswarbo]

> However, most students are not good enough at math to learn functional programming concepts.

I don't agree with this. Many programming concepts outside functional programming can be very hard to grasp, yet we expect students to pick them up, and we expect front-end Web devs to use (some of) them every day.

Some examples off the top of my head:

- Pointers (e.g. the many incompatible meanings of "" in C).

- Classes and instances.

- Implicit state.

- Mutable global state!

- Concurrency (events, continuations, actors, etc.).

- Multithreading. Yes, it's a form of concurrency, but it also offers a unique combination of being a) the default go-to strategy for implementing concurrency, and b) so fundamentally hostile to any attempts at understanding.

- `x = x + 1`. This can be completely baffling when first encountered!

In this context, functional programming doesn't really require anything particularly difficult. Maybe recursion is hard to grasp, but that's not unique to FP; FP just uses it more often, making it harder to avoid. The only thing I can think of that's pretty much a requirement in FP, that we don't already require everyone to grasp, is first-class functions; and they're already pretty widespread in scripting languages.

What about monads? What about denotational semantics? What about cartesian closed categories? What about all that other complicated math stuff? None of it is needed to do FP*! Just grab a small Scheme interpreter, ignore "call/cc" or anything ending in "!", and start coding.

Let's look at, say, the accepted papers from the last OOPSLA (Object-Oriented Programming, Systems, Languages & Applications): http://2016.splashcon.org/track/splash-2016-oopsla#event-ove...

Looking through the titles, I don't know what an "enclave" is, or "conditional future synthesis", or "first-class effect reflection". I have no idea what a "non-linearizable concurrent object" is, or what constitutes a "dependent object type". Does that mean I'm not good enough at math to learn OOP? Not at all; I can just run `python` and start hacking.

[chriswarbo]

Oops, I meant the incompatible meanings of the asterisk in C; HN swallowed it as markup, and emphasised the rest of the comment.

[sobani]

Half the world runs on Excel, a functional programming environment. If your average manager is mathy enough to understand functional programming, the average programmer should be as well.