4 ms·

I think they are both concepts with different traits or required features. These are my subjective definitions: OOP: - Everything is an object - Inheritance

by JepZ 10y ago

I think they are both concepts with different traits or required features. These are my subjective definitions: OOP: - Everything is an object - Inheritance (an object inherits all features of its class and super classes) - Polymorphism (one object can replace another if the required class is one of its own or its super classes) - Encapsulation (an object exposes only what it is meant to expose (black box)) FP: - Functions can be used as values (therefore it is possible to write higher order functions) - There is no state/variables, so that any function call with its input parameters define the result and can therefore be cached quite easily So in theory it should be possible to combine the two concepts, but in my opinion it doesn't make much sense as they have different strengths and weaknesses (e.g. introducing state to FP is a very bad idea...). Sadly many languages try to combine both concepts and implement both poorly and on the other hand there are too few people who actually understand the concepts and use them appropriately. As a rule of thumb: - Take OOP if you have to model the relationship and interaction between things (objects) - Take FP if you have to calculate something (like Excel formulas do)

MustardTiger 10y ago
>As a rule of thumb ... I've heard variations on that a lot, but have not found it to be true at all. I've tried 3 times over the years as I got better at programming to write a server for a little mmorpg in OO languages. Each time it turned into a buggy, unmaintainable mess. On my fourth try I was using ocaml because I thought a better type system could help. Again the OO version I wrote initially was buggy and terrible. But being ocaml, I could rewrite bits and pieces in a functional style and improve it gradually. I ended up with no OO code at all, and very little imperative code (which was only for performance reasons). This is the very definition of "you have to model the relationship and interaction between things (objects)", but OOP was terrible and FP is great.
grogs 10y ago
I think Scala is doing a decent job at bringing these concepts together. Scala ticks all the OOP points you made - even more than Java does (Java has special primitives for int/booleans etc, in Scala that's more hidden, really everything in an object). FP also likes Encapsulation as you decided it - pure functions, that don't do side effects (even logging) without it being explicit in the type signature. FP can model relationships/interactions OK. They just have new tools/techniques to do it. For example, instead of mutating things, you create a copy with the change. You then push the actual state/mutation to the edges of your system (e.g. the database), and thus hopefully make it easier to reason about. But it can be slower or hard to change things deep in an object graph. For slowness - we have persistent collections which re-use unchanged parts of the collection and implement performant "copying". For deep structures, Haskell & Scala have lenses. It's still an ongoing exploration, with people borrowing/discovering new techniques, but I think it's working quite well and I'm happy to keep exploring. In the other direction, I've been following Rust. I find it very interesting that it's got a very good type system, but still has mutation. Instead of avoiding mutation, they track ownership in the type system, and thus keep it easier to reason about. By doing this, they make the the performance/memory management easier to reason about, without making it too hard to reason about where effects are happening.

by JepZ 10y ago

MustardTiger 10y ago

>As a rule of thumb ... I've heard variations on that a lot, but have not found it to be true at all. I've tried 3 times over the years as I got better at programming to write a server for a little mmorpg in OO languages. Each time it turned into a buggy, unmaintainable mess. On my fourth try I was using ocaml because I thought a better type system could help. Again the OO version I wrote initially was buggy and terrible. But being ocaml, I could rewrite bits and pieces in a functional style and improve it gradually. I ended up with no OO code at all, and very little imperative code (which was only for performance reasons). This is the very definition of "you have to model the relationship and interaction between things (objects)", but OOP was terrible and FP is great.

grogs 10y ago

I think Scala is doing a decent job at bringing these concepts together. Scala ticks all the OOP points you made - even more than Java does (Java has special primitives for int/booleans etc, in Scala that's more hidden, really everything in an object). FP also likes Encapsulation as you decided it - pure functions, that don't do side effects (even logging) without it being explicit in the type signature. FP can model relationships/interactions OK. They just have new tools/techniques to do it. For example, instead of mutating things, you create a copy with the change. You then push the actual state/mutation to the edges of your system (e.g. the database), and thus hopefully make it easier to reason about. But it can be slower or hard to change things deep in an object graph. For slowness - we have persistent collections which re-use unchanged parts of the collection and implement performant "copying". For deep structures, Haskell & Scala have lenses. It's still an ongoing exploration, with people borrowing/discovering new techniques, but I think it's working quite well and I'm happy to keep exploring. In the other direction, I've been following Rust. I find it very interesting that it's got a very good type system, but still has mutation. Instead of avoiding mutation, they track ownership in the type system, and thus keep it easier to reason about. By doing this, they make the the performance/memory management easier to reason about, without making it too hard to reason about where effects are happening.