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".
