Every time I see a discussion online on 'what functional programming is' it drives me so crazy because everyone (speaking against it) talks so confidently as if they know exactly what FP is, only to then take some small application of functional programming (or worse, the sorts of things you only see in a toy FP 101 example) and then extrapolate it to the entire paradigm (while missing the real point altogether), which then becomes an easy strawman to take down. And hell, I can't be sure but I swear I keep seeing an argument that, underneath the surface, desugared from its reasonable-ish sounding language, seems to be almost saying "functional programming = haskell, haskell = math, math = pythagorean theorems and shit? Pythagorean theorem = no for programming". Each time I see this I try more and more to myself write on exactly what I believe it to be (offline, to eventually present), and refine this writing to be clear, and it can just be very difficult to translate intuition into words, and to really capture an entire paradigm like that (all whilst I feel like I have to be careful, because FP and OOP are the kinds of topics where people easily become tribal and us-versus-them, or where they are expecting evangelism, and where I have to be careful not to imply anything that sounds to good to be true, despite the fact that I have many things to say that are too good to be true).

What’s the real point they are missing?

I mean, if someone equates functional programming with Haskell, then they are missing out on the tightly controlled mutability that Clojure has, and I believe that the ML family of languages has, and perhaps tying the kinds of sophisticated type systems that other languages besides Clojure have.

Erlang is the only language I know of off the top of my head that you could say has a strong immutable data leaning that doesn't also have the extensive type system.

I'm currently writing something to elaborate more on what I was saying, but in doing so I was trying to find the thread that originally made me think of this, and I believe this is one of the comments that spurred it, as an example ""The reason FP has not caught on is because it is too abstract from how the underlying machine code and operating systems work. It changes programming from instructing a computer to carry out a particular set of instructions to a higher-level mathematical problem, which is much less groun/ded, and harder to systematically approach.""

I've never found FP to be inherently more mathematical, although I want to think on any edge cases there. Haskell of course is mathematical, and I want to be careful about making generalizations on where its mathematical and why, but I attribute a lot of that to both its academic background, and the extreme microscopic abstractive-precision of its type system (a type system that could exist in an imperative form in an imperative language I might add). Haskell utilizes monoids for programs, for instance, which is usually a concept from abstract algebra, but functional programming doesn't need monoids and you're not limited to implementing them just in functional languages

I mean, programming is a human endeavor, so it does require the right kind of thinking and training to take advantage of a programming language, and I doubt that there is any one programming language which everyone will find to their liking.

But unless you want to write machine code or assembly, the whole point of higher level languages is to enable a person to ignore some details about the underlying physical hardware, in order to get your job done by saying less, and/or worrying about fewer details of the underlying machine.

High level code that makes extensive use of higher-order functions can be difficult for most people to understand the first time they see it (and perhaps forever, for particular people that don't exert the necessary effort to become accustomed to it).

Yeah, if someone immediately jumps from "FP" to "Haskell" then they're bound to think "FP" = "Monads" and that's going to put a lot of people off (even tho' monads are, in general, pretty common things that just happen to have a formalism attached to them, such as list comprehensions, or operations that have an identity such as + or * etc).

That's why Evan was so insistent that the Elm community not use the m-word when describing things: he wanted Elm to be accessible to the "average JavaScript" programmer.

And Erlang and Clojure are good examples of how you can write production code without needing to worry about the formalism of monads etc.

> It changes programming from instructing a computer to carry out a particular set of instructions So SQL must also be bad. As any other declarative language.

And then there's the basic problem that "what is functional programming?" has as many answers as there are people to ask the question of... 😐

(but that's also really true of OOP too -- it's just that more people seem to agree on more of the common parts of all those answers 🙂 )

yea ahahah that's one problem I was worried about running into in even starting to write this ; the moment I begin arguing 'what FP is' I have to be careful not to define things in a way that captures the jist but technically fails to some higher level, more rigorous definition someone might throw back at me, or have the boundaries of my definition clumsily step on the toes of another in the contested, less well defined frontier of its definition, which is what I’m always uncomfortable over where I don't have a 100% clearly defined agreed upon definition in my mind

It has been amazing as it is to see the difference in how Elm is perceived, as while I haven’t used it, it always looked like Haskell lite to me, while somehow seeming to even be considered easy or approachable, seeming to lack a lot of that Haskell baggage (although don't quote me on that, I'm drawing that conclusion from only a few anecdotes)

The core of Haskell is pretty easy to learn, to be honest. But it's hard to find Haskell tutorials/learning material that doesn't immediately dive off into the weeds of either the (very powerful) type system, or monads, or even just type classes... and you can get a long way without any of those.

Elm is living proof that you can make those trade offs and still have a powerful language that is easy to learn.

(it helps that Elm is very opinionated so there is pretty much always a "right way" to do things)

(tired of writing documentation https://github.com/clojure-expectations/clojure-test/blob/master/doc/getting-started.md so I'm off for the night -- but this is an interesting discussion @zdot101 -- I look forward to reading whatever you end up writing!)

😄 thank you! (I'm going to sleep too so who knows if I'll write more ahaha) I am terrible at wording my thoughts (if you'll notice, even the last two tiny responses I wrote took 8 and 12 minutes to write respectively) and I've come to realize recently that part of it is that its a self reinforcing cycle; because it takes so much effort for me, I don't do it, don't get the practice, and it remains hard. Like many things, just a little bit of extra initial difficulty becomes a lifetime of major difficulty. So right now I'm trying to finally refine some of my thoughts and hopefully put them out there (especially in cases like this, where I feel there are misconceptions about FP -- but this is particularly hard, because one has to both find clear ways to transmit a huge amount of intuition, summarized in a series of, say, blog posts, and convince people who have already made up their minds on these things)