[submeta]

When I started programming in Pascal in the early 90s, my procedures/functions and my data were decoupled, spread all over the place. Then I started learning (Turbo)Pascal with OOP. It was godsend. All of a sudden I could structure my code in a way I wasn’t able to do before.

Now thirty years later I know how to structure my (Python) code without OO: Via modules. I hardly use OO anymore. And I am drawn to FP more and more. But I see cases where OO is useful.

I don‘t think it‘s either/or. We should be glad we have all sorts of paradigms to go back to.

[sodapopcan]

I'm a recent FP convert after 15ish years of OO. I don't hate OO now or anything, but maybe a little? It adds so much more to think about for what I now consider to be no benefit, at least for the types of systems I've worked on in my career. A big thing I've realized is that everything I've worked on has modelled things that are already abstract. For example, I'm working on a scheduling app right now. In real life, a schedule is an abstract concept realized on paper. Our app certainly doesn't have a Paper class. That may seem knit-picky to some people but it's true: the whole "model the real world" breaks down there. My apps also always have way more behaviour than they do things. FP is much easier to model a lot of behaviour around a generally fixed set of things than OO is.

This is not to say there aren't good use-cases for OO (video games come to mind) but for my day-to-tasks, I've found FP much simpler (and immutability is a god-send... it's like, "Hey, you know that foot gun you've been carrying around? You don't need that anymore!"). I would encourage any OO zealots to give FP a honest try.

[ajuc]

> It adds so much more to think about for what I now consider to be no benefit

That's my problem with OO too. It encourages people to add unnecessary mutable state to programs and then they have to think about it interacting with everything else and with itself.

When you realize most systems are actually pretty simple once you look at the fundamental data and how it changes and ignore all the architecture built around it - it's a very freeing experience.

> This is not to say there aren't good use-cases for OO (video games come to mind)

Gamedev is currently moving away from traditional OO towards Entity Component System - which is basically a in-memory relational database for your data + imperative code put into classes that are basically modules :)

[mavelikara]

> For example, I'm working on a scheduling app right now. In real life, a schedule is an abstract concept realized on paper. Our app certainly doesn't have a Paper class.

I am hoping that your application has a function for UnscheduledWorld -> ScheduledWorld.

> I would encourage any OO zealots to give FP a honest try.

Why assume that people who like OO more than FP do so only because they haven't tried FP? Isn't it possible that you are in the honeymoon stage with FP, and as you gain more experience with it (like you have with OO), "the scales will fall off your eyes" as P G Wodehouse would have put it?

[odipar]

I've come full cycle:

0) Procedural

1) OO

2) FP

3) Really started to dislike mutability

4) Developed various FP frameworks

5) Back to pure (immutable!) OO and messages!

[submeta]

What made you transition from 4) to 5) ?

[odipar]

Managing state in (standard) FP doesn't compose that well.

Lenses look like a solution to transition 'deep' immutable state, but I find them cumbersome: YMMV.

Object Orientation has excellent composability with regards to state and with minimum fuss.

The step I took is to eradicate mutable OO state, and replace it with a pure OO substrate.