I don't agree with his premise even though I might share some of the same experiences. I have switched to FP. I think I was using some bad instructional material or a bad mental model for OO that basically made objects just imperative programming containers. And I always found that it became increasingly harder to maintain over time. I wish I had discovered better ways of doing OO back then. For example, I've since seen a lot of good stuff from Sandi Metz. In any case, OO is a paradigm that has gotten the job done for a long time. I think if you stay at it long enough, you can figure out how to avoid most of the footguns and write good software with it. But I found FP before I got to the equilibrium point, and now prefer it.
In my opinion, one of the biggest downsides of FP right now is that most instructional materials insist on bringing abstract math into it. It is not needed. And in fact, I avoid putting my own logic in terms of math categories. Because then I am requiring all future readers to be able to think in terms of abstract math to read the code. Which is a non-trivial burden to take on, definitely not friendly to new devs. The way we do FP is probably simpler than OO. I have an article about that approach here.
I think both OO and FP have potentially harmful approaches. In the end, they are just tools to get jobs done. It is all in how you use them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't agree with his premise even though I might share some of the same experiences. I have switched to FP. I think I was using some bad instructional material or a bad mental model for OO that basically made objects just imperative programming containers. And I always found that it became increasingly harder to maintain over time. I wish I had discovered better ways of doing OO back then. For example, I've since seen a lot of good stuff from Sandi Metz. In any case, OO is a paradigm that has gotten the job done for a long time. I think if you stay at it long enough, you can figure out how to avoid most of the footguns and write good software with it. But I found FP before I got to the equilibrium point, and now prefer it.
In my opinion, one of the biggest downsides of FP right now is that most instructional materials insist on bringing abstract math into it. It is not needed. And in fact, I avoid putting my own logic in terms of math categories. Because then I am requiring all future readers to be able to think in terms of abstract math to read the code. Which is a non-trivial burden to take on, definitely not friendly to new devs. The way we do FP is probably simpler than OO. I have an article about that approach here.
I think both OO and FP have potentially harmful approaches. In the end, they are just tools to get jobs done. It is all in how you use them.