5 ms·
> OOP won against functional because OOP is easier to understand and leads to more maintainable code. You say that as if it's the truth. It's not at all clear
by wtetzner 6y ago
> OOP won against functional because OOP is easier to understand and leads to more maintainable code.
You say that as if it's the truth. It's not at all clear to me that's the reason OOP "won".
> These days people are taking a second look at functional because functional avoids state, which makes it easier to write concurrent code with no locks.
I think that's only a small part of the reason for the interest in functional programming.
- Weebs 6y agoAfter picking up functional programming < 2 years ago and using it constantly at work, I definitely have to say I disagree with GP that OOP is easier to understand. I think there's a lot of value in the concepts of OO's message passing, and exposing an interface that encapsulates some internals. It's a tool I regularly use in FP even with immutable types Imperative OO to me though is plain difficult to do correctly, and shouldn't be the primary way that your encouraged to write code. It's much more difficult to track dependencies and who touches what in an imperative class, and you end up digging around the file before you can even know what you have to keep in your head. With FP, you generally have pure functions that take in some state and dependencies, and produce a new state. Everything you need to know related to how that function behaves is explicitly given to you, and it's trivial to test the code. You can do this in imperative OO too, but you're nudged in that direction by default. I do think there are cases when imperative code and imperative OO make a problem easier to represent/understand and faster to execute, but I like to keep those sections small and easy to fit in your head, delegating most of the logic to functions. The imperative OO is mostly some glue to bring the business logic to life.
- narwally 6y agoOO: 'state is hard, let's make it easier by encapsulating it with only the procedures that need to manipulate it' FP: 'state is hard, let's not do it unless we absolutely have to'
- munificent 6y agoModern multi-paradigm language: "State is hard. Let's avoid it when we can and encapsulate it in procedures when we can't."
- Weebs 6y agoI think for FP it should be added, that the state is explicit and has a clear owner. Eventually someone has to replace the old value with the new value in the call chain What's really interesting is Rust arrived at a similar destination, I assume as a natural byproduct of pushing for memory+thread safety. State isn't discouraged, but you get explicit owner(s) of data who lend it out to others who are readonly by default, and explicit when they will modify the reference you gave them.
- narwally 6y agoYeah, maybe it's more like "state is hard, so only Paul can do it. If you want to Paul to change some state for you, then you're gonna need to fill out this form."
- neutronicus 6y agoI don't think that OO code is easier to understand. I do, though, I think, find OO projects easier to understand. There's an opinionated convention about what code to save in which file (one file for interface of a class, one for implementation). Sometimes I think it's this, more than anything to do with language semantics, that actually drives OO adoption. When you sit down with an empty folder and a text editor, it's really easy to know where the files go.
- narwally 6y agoI'd say OOP 'won' because Java offered garbage collection and a C style syntax. The fact that it was also OOP was incidental.
- euiq 6y agoRight—garbage collection makes most software engineering significantly easier.
- munificent 6y agoOOP first boomed with C++ before Java came around, and Java got GC from function languages. If GC was the distinguishing factor, OOP would have never gotten off the ground.
- pjmlp 6y agoHaving been there when it all took off, it always feels so wrong to read "C++ code written Java style", when it was C++ that actually created that style.