From a practical perspective, one should probably learn procedural/OOP first, it's the de-facto industry standard, and thus better for one's early career. Whether functional is "better" in the longer term, I won't get into here, only to say I have skepticism.
Imho it's exactly the other way around: Imperative programming is an implementation detail and nothing you should care at first.
If you want to learn proper abstractions you should start with something FP-ish.
This also avoids to get your head messed up with the imperative kind of "reasoning".
Besides this: FP is much simpler to learn, so much better suited for newcomers. One just needs to follow up on what every child learns since first grade in school, namely the substitution model found in math. On the other hand imperative thinking makes absolutely no sense when looked at it intuitively. It looks more like complete nonsense: `x = x + 1` isn't true for any `x`… So imperative programming is at it's core contrary to logical reasoning. I would try to avoid it as long as possible.
> 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.
The way I see it, I live in a world that has state. I spend all my waking hours manipulating the state around me. From this perspective, imperative programming is as natural and intuitive as anything can be. You do things, and the world changes.
Abstractions are good, but you should first understand the concrete ideas behind them. Otherwise you may end up doing pure symbolic manipulation without any intuition to guide you.
> It looks more like complete nonsense: `x = x + 1` isn't true for any `x`
It does seem you were complaining about the syntax of assignment.
In the other comments it was clearer that your main complaint is that it's hard to compose mutations to reach a desired state. I agree! You should've led with that!
The syntax is of course also confusing. If you show the above line to a 6. grade child they will tell you that that line makes no sense, obviously.
That's why this example is so good! For someone without exposition to (imperative) programming it's completely nuts. But after some "brainwashing" people don't even recognize how weird the example is actually. My hope is always this makes people think (at least after explanation) a little bit whether they maybe just internalized some actually unintuitive stuff and now think that's the "normal" way to look at things, even it's actually not if you come in just with the knowledge from school.
Not everybody remember that but most people have for example major issues in grasping a loop with a counting variable in the beginning. It's just not so easy to "do the computation" in your head and track the state of your variable. Variables as such are already confusing to most people. Beginners often use them like constants and declare new ones when they actually need to assign a new value. I've see this pattern quite often! If you ask why it was done this way the answer is often "because re-assignment is confusing"…
Your complaint is that the '=' is used in a different domain than programming with a different use. Rightly or wrongly people will adjust to different notations very easily, homonyms in natural languages rarely cause problems because of the context. Same here, this is C/C++ not formal logic.
Once somebody is told 'this is mutation' and it sinks in, it's not a problem.
You make the bigger claim that FP is easier to understand, and I don't buy it. If you want to put forward that, back it up with some evidence. Personally I believe that it depends on the person. I did a brief introduction to FP to a couple of mathematicians and they got it immediately, but then they were extremely bright and had minds naturally suited to handling abstractions. (edit: which I am not and have not, respectively)
And one of them was not allergic to learning C either, and he got a few lessons in that too.
I worked with one person who simply couldn't understand the concept of passing a function around like any other piece of data.
It frustrates me when people (like you) insist that one programming paradigms is The Truth because, the truth is, you need all of them and you need to apply them at the right time – 00, FP, logic, and yes, procedural. If you can't do that, if you're too hung up on one-way then it speaks of inexperience. As a programmer you're there to deliver a solution, not a technology, and I've been involved in the mess when someone far too inexperienced pushed for the tech rather than the saleable product.
Final note, the inventor of Scala is Martin Odersky and I was watching one of his videos on YouTube where he very much surprised me by saying something about allowing Scala to be imperative for when imperative solutions were the more concise answer. And in the end, all computers are state machines.
So please, loosen up your presumptions; the world is a messy place and you need to allow for that.
I think this reply needs a longer answer than I can give at the moment; it's morning here and I've got to work, I'll reply in a few hours hopefully with something constructive.
>One just needs to follow up on what every child learns since first grade in school, namely the substitution model found in math.
Considering how much people struggle with learning math I'm not sure that this is a good way of going about things. I don't think functional programming classes have much more success either.
>Objectively they have. I've linked already some evidence in the other reply in this thread.
I don't see it. Maybe we (our class) were taught wrong, but back in uni I would rate the usefulness of our FP class as one of the worst. I got the sense that most of the students (that passed the class) weren't able to use what they studied in the class. If they took away anything from that class, it would be that they shouldn't touch Haskell again.
FP is useful, but I would argue that imperative is easier to learn, because keeping track of state is easy when you're learning. You're dealing with small programs that you wrote yourself. Keeping their entire state in your mind is not difficult.
Also, I think there's a joke somewhere in here about learning Java ruining the 'state' of your brain for learning FP.
Creating connections in the curriculum between math and other subjects is a good way to help students better understand both math and other subjects. I don’t have literature to cite on this though.
Also a good way to turn off students who have no interest in math from subjects they have interest in. I would have never become a SWE if I actually attempted a CS degree.
> FP is much simpler to learn, so much better suited for newcomers
I'm going to have to disagree with you like most other replies.
You need basic math knowledge to do FP - at least know what a function is.
Imperative programming is just writing out a list of instructions for the computer to follow and everyone understands the concept of write out a list of instructions. No math needed.
My position is that for university students, you should start with FP. You have them for 4 years anyway, they'll have plenty of time to learn imperative programming. But FP both distills essential CS concepts, putting them front-and-center, and it puts your freshman on a more even playing field between those with existing programming experience and those who don't.
If by FP we mean Monads recurrence and no single drop of state, then yes.
If by FP we mean "Let's write our functions as pure (and leave IO as a magic box for time being)", then this is undeniably more straightforward then getting head deep into side effects that procedures can create, not to mention the entangled web of dependencies in OOP, and other messy stuff it promotes
There are jobs for pretty much all established technologies. And if there aren't currently, there could be in the future. I primarily work on procedural & OO projects, but I disagree with your position. I've seen job postings for all sorts of things; Things that interest me, things that don't, things that are hot, things that are old hat, things that have an air of prestige, things that look like a coffee stain on your resume...
Well if you're learning computer science, what does it matter what is industry standard? Computer science doesn't really have very much to do with the programming industry.
Because when we're talking about CS education, it's usually in preparation for a software engineering career. Whether that should be the case is another story, but that's the reality.
I think the reality is that computer science is only tangentially useful preparations for a career as a software engineer.
There's some courses that are inarguably fundamental, some which "separate the good from the bad," but there's also many which are simply not practical, besides the fact that they teach you how to learn.
It's a flawed analogy but I'd liken it to mechanics vs automotive/manufacturing engineers. There's a good bit of overlap, but lots that isn't shared. And software engineering as an industry doesn't always do a good job differentiating between the two
Burn computer science. Like unironically it's so grown into an awful patchwork of dogmas. It sells itself as a software engineers degree, but if it's not really then it's effectively an incidental scam.
"De-facto industry standard" is heavily a function of what slice of the industry you're looking at.
It feels like the dominant style of programming in the companies I've worked at (YC startups and FAANG) is "functionalish" procedural, with a sprinkling of objects-qua-objects to interface with libraries and frameworks (Eg, react class components or rails ActiveRecord models).
Note I'm distinguishing between objects-qua-objects (data coupled tightly to methods that operate on them) from structs-implemented-via-objects (eg, ruby's `Struct` or Java "beans") or modules-implemented-via-objects (like a class with a bunch of static methods used as a namespace). I only see the first one as "object-oriented".
