> FP is much simpler to learn, so much better suited for newcomers.
I can't see how this is the case. Assignment is just one tiny piece of learning how to program, and is almost never a pain point after a small amount of instruction.
Imperative programming is easier to learn because you simply write out the steps that you want the computer to take, and the computer takes them. FP requires much much more abstract thinking that is often difficult for newcomers to grasp.
The main exception that I see is when someone who has a very deep mathematics education. Graduate level math folks seem to more easily grasp FP concepts from my experience. Almost everyone else seems to grasp imperative programming easier.
My sense (guess) is that you, like most people, learned programming from the outset using the procedural/imperative style. After this way of thinking and approaching problems became firmly ingrained, you then experienced FP as more abstract or difficult to wrap your brain around. But I don't think this reflects on anything innate to FP. FP is, at its core, far FAR simpler than procedural/imperative/whatever-you-want-to-call-it programming. It requires high school math, if that. Equational reasoning, substitution, etc. The basic concepts get you extremely far and are, in their essence, incredibly simple and straightforward and far less foreign to a newcomer than any of the complicated stuff most people are introduced to programming with. That's one guess. The other is that you don't have a great sense of what FP actually is and most of how you think about it comes from HN conversations or blog posts about parser combinators and monads, etc. To that I would say two things: 1) those concepts AREN'T actually that complicated, they are built upon some very basic concepts, but a firm grasp of them is required. They are taking a few basic concepts and exploiting their usefulness to the nth degree and 2) some of the stuff you see or read that is, I'll admit partially, or can be quite complicated does not represent what FP is at its core and is instead a few nerds who really really enjoy pushing the limits of FP and its style of reasoning. I don't mean this derogatorily, it's great that people are doing that. But a deep knowledge of those more advanced concepts isn't essential to FP which, I argue, is incredibly simple and, indeed, far simpler than the other dominant style of programming. None of this is to say that I think a newcomer who is job-minded should start with FP. Perhaps they shouldn't. I'm only addressing what I think might be a misperception of what FP is or how complicated or abstract it is.
>My sense (guess) is that you, like most people, learned programming from the outset using the procedural/imperative style.
>FP is, at its core, far FAR simpler than procedural/imperative/whatever-you-want-to-call-it programming. It requires high school math, if that.
These two factors do not go together in my opinion. Most people who learn imperative programming have studied mathenatics for a dozen years beforehand, but somehow learning imperative programming for a year "ruins" their ability to understand FP permanently? This sounds like an excuse to explain why people have poor performance when they learn FP.
From my experience people do have poor preformance with FP. Back in uni we had a class for FP. If there's anything the majority of students took away from that class, it's that they're never going to touch Haskell again. Because the average performance was that poor.
> but somehow learning imperative programming for a year "ruins" their ability to understand FP permanently?
No, it ruins their willingness to learn FP. Novices know they're learning a new subject and set their expectations appropriately. Experienced imperative programmers think they're learning another minor variation on C and get frustrated when it turns out many of their existing mental models don't transfer.
You didn't, of course, but playing devil's advocate and abusing terminology in the usual way, you have to understand a monad a little bit to know what to make of the type signature.
In practice I expect the comment you replied to is hyperbole and/or confused.
The fact that you cannot interact with the real world without wrapping side effects is sufficient justification that OOP is easier to teach, IMO.
I'm a strong proponent of FP and agree (though I recognize I may be biased) that it's easy to learn with the right teacher, but that's a big caveat that isn't universalizable IMO
> The fact that you cannot interact with the real world without wrapping side effects
That has nothing to do with FP.
That's mostly a Haskell (and the-like) thing.
"Hello world" looks in for example in OCaml like this: `print_string "Hello world!\n"`. You can interact with the outside world just fine without any "side-effect wrapping".
You don't need to know more than high school math to learn Functional Programming. This myth really needs to stop.
All functional programing languages, have ergonomics in their syntax and semantics. around referential transparency and immutable data structures, there's nothing in there about Monads or Functors or Hindley–Milner type systems.
Languages like Haskell do benefit from having that kind of experience, however, langs like,
OCaml, Erlang, Elixir, Gleam, Racket, Clojure, Standard ML.... and the list goes on, doesn't require that kind of education.
(Antidotally, I find FP langs much easier to reason about and I have a background in the humanities. I just don't buy the advanced math argument.)
I don't know why you think I said high level mathematics knowledge is required to learn FP. I simply said that in my experience, those who found FP easier to learn than imperative programming tend to be those who have a background in high level mathematics. Not everyone follows this pattern, of course.
Remember, we're simply comparing FP to imperative programming. I'm simply not convinced that FP is easier to learn than imperative programming for the vast majority of newcomers, and that's what I'm arguing here.
Keeping track of all that state in one’s head is hard.
I think because of the limitations of FP it’s much easier for new programmers to reason about programs and honestly, learn to program.
New developers don’t have to micromanage the computer, the way that the would with an imperative lang.
For example, SQL isn’t FP, but think about the number of business analysts whose lives would be more difficult if the had to write imperative programs to fetch data from some sort of data store.
I think what in comes down to is simple vs easy. Imperative programming in the very very beginning is easy, buts not simple.
Because there’s all this implicit state in your program, as the program grows it becomes very very complex. It’s no longer simple.
There’s this really great talk about this idea by rich hickey, the creator of clojure, that dives into this in detail.
That really depends on when the person took high school mathematics, and the extent to which function abstractions were emphasized. That was not a core part of the curriculum when I was in school, but it is now.
> Assignment is just one tiny piece of learning how to program, and is almost never a pain point after a small amount of instruction.
The issue isn't assignment. You have also assignment even in the most pure FP languages.
The issue is mutation!
> Imperative programming is easier to learn because you simply write out the steps that you want the computer to take, and the computer takes them.
No, that's not easy given every step can change the whole world around and you need to track all the changes in your head.
That becomes very hard to follow even after only a few steps. (That's why imperative programs are always so buggy.)
FP code, which usually eschews mutation, is much simpler to follow as you can look at any "step" in isolation. No hidden "change the world" side-effects everywhere.
> FP requires much much more abstract thinking that is often difficult for newcomers to grasp.
No it doesn't. At least as long as you don't go nuts like e. g. Haskell.
At the core FP is basically the same trivial concept taught to children in elementary school: If you have some expression you can mechanically substitute following occurrences which the value assigned to that expression. That's all.
> The main exception that I see is when someone who has a very deep mathematics education.
Like every child that attended math classes for many years. In school people are trained for a very long time in exactly the way of reasoning you need to write FP code.
On the other hand you need to teach those people imperative programming form the ground up, including mayor mental shifts around all kinds of concepts they were taught previously. Only after this kind of brainwashing people start "to get" imperative programing…
> Almost everyone else seems to grasp imperative programming easier.
Just go out and talk to some programming instructors… Everybody will tell you the same.
Only people whos brains are already burned by imperative programming think it's easier. For everybody else it's the opposite. Which is perfectly logical as the FP way of thinking is what they practiced for many many years before, in math in school.
Even on the top answer on one of your own links: "In spite of what this all sounds like, I'm not suggesting that functional programming is necessarily easier"
My experience is that of a TA and a tutor. Granted, it's hard to find people who aren't tainted by imperative programming thinking these days, unless you're starting on the true ground floor, which I admittedly rarely do.
>> Imperative programming is easier to learn because you simply write out the steps that you want the computer to take, and the computer takes them.
> No, that's not easy given every step can change the whole world around and you need to track all the changes in your head.
Learning and using are 2 separate things.
FP is supposedly easier to use in the long run but it’s definitely harder to pick up.
Imperative is the opposite since it’s analogous to writing out a list of things you want the computer to do - a concept even the uneducated can understand.
I can't see how this is the case. Assignment is just one tiny piece of learning how to program, and is almost never a pain point after a small amount of instruction.
Imperative programming is easier to learn because you simply write out the steps that you want the computer to take, and the computer takes them. FP requires much much more abstract thinking that is often difficult for newcomers to grasp.
The main exception that I see is when someone who has a very deep mathematics education. Graduate level math folks seem to more easily grasp FP concepts from my experience. Almost everyone else seems to grasp imperative programming easier.