6 ms·
The problem for me in regards to OOP is the complexity related to the management of state. OOP encourages mutability and understanding the state of an object as
by j_m_b 8y ago
The problem for me in regards to OOP is the complexity related to the management of state. OOP encourages mutability and understanding the state of an object as its methods are called can be confusing when additional internal (and often times, private) methods are called. In functional programming, state is something acted upon by functions. It is as simple as f(x) = y. Reasoning in functional programming is much closer to the mathematics I've been trained in since grade school. In functional programming languages, mutability of an object is an explicit operation. It's easy to tell when state is being mutated visually from syntax. Mental overhead is greatly reduced when you can assume that your data structures are immutable.
- mjburgess 8y agoYes, but I/O is impure and sequentially dependent, unlike mathematics. Maybe the "impedance mismatch" between pure-fp and I/O is too great, with the IO monad being the "leaky abstraction" of the FP world. Then OO is not a bad solution to an irrelevant problem, but a pretty-good solution to a bad relevant problem. EDIT: To clarify: The "problem" is change. Imperative programming relates sequential device-change over time, to sequential programming lines. OO programming is a structured imperative programming. Pure FP langs model sequential change with (roughly,) lists of actions to-be-performed that are snaked through your program. (Also: maybe OO's failure has more to do with its limited static analysis, type systems, than its model of change?)
- Rumudiez 8y agoMathematics is sequentially dependent. Try 3/4==4/3 for a trivial example
- willtim 8y agoWhy is the IO monad a leaky abstraction? Any function that returns an IO computation in Haskell, is still a pure function.
- discreteevent 8y agoBackus: Well, because the fundamental paradigm did not include a way of dealing with real time. It was a way of saying how to transform this thing into that thing, but there was no element of time involved, and that was where it got hung up. Booch: That’s a problem you wrestled with for literally years. Backus: Yeah, and unsuccessfully. http://archive.computerhistory.org/resources/access/text/2013/05/102657970-05-01-acc.pdf http://archive.computerhistory.org/resources/access/text/201...
- mjburgess 8y agoThanks for the quote! Before I wrote that comment I was actually on the anti-OO side, and in writing it, I convinced myself that maybe the FP solution wasn't great. Good to see this wasn't a mistake!
- jononor 8y agoMost of your application logic should not have to care about I/O. That is a concern which should stay at the edges. This way it is easier to reason about the program, and test it.
- sisu2019 8y agoIn theory this sounds great but in reality every major application, game, operating system and even website is written in an OOP style. Why is that? People should first answer that question. Yeah, real existing software has flaws like every other thing in reality but at least it exists unlike a significant piece of fp style software. I like fp and I think it has a lot to teach but I think it's a bit presumptuous to advocate against a major paradigm that has actually proven itself with one that has failed to do so for decades. And if OOP is so horrible why do so many people write OOP style PHP and javascript where they really don't have to? Personally, I don't think OOP is bad per se, I just think the type systems of the main OOP languages are too limited and inflexible. Even so, you can accomplish amazing stuff in them. Just look at the Spring Framework and what it helps you do with so little code.
- Fellshard 8y agoA fair bit of that can be easily explained as cargo cult - a fair number of developers simply believe, because it's how they've been taught and what's been stated as fact over and over and over, that OOP is just 'how you write code'.
- discreteevent 8y agoOk but objects have been successful for a very long time. And this is in a field where there are more potential early adopters than most. Programmers like new stuff. I think they have been successful because in the end a lot of the world we deal with behaves like objects. Devices, processes, remote machines all accept messages and those messages have 'side effects' in that they change the future behaviour of that thing.
- Fellshard 8y agoMy current understanding (sure to change!) is this: Objects and messaging are best at the boundaries of system components. The internals end up being far simpler to state in functional terms, where the side effects can be pushed to the edges with far less inherent complexity. By assuming that objects are successful everywhere and always, it's really ignoring the regions where objects are more or less useful, painting over the picture with broad strokes. By learning multiple paradigms, you're learning broad principles that map well across all languages, as well as principles that are stronger or weaker in some paradigms than others. This enables you to be much more versatile when creating systems than devoting yourself to the 'One Way To Code' mentality.
- felipeccastro 8y ago“Mental overhead is greatly reduced when you can assume that your data structures are immutable”. I’ve been reading lots of articles claiming that but I still haven’t understand how that’s so. If you have fifty functions all acting on the same piece of state, why would returning new objects instead of mutating would greatly reduce mental overhead? Isn’t there still mental overhead in tracking which of the fifty functions made some transformation? Maybe this is something I would understand better with more practice in functional programming (which I don’t have yet), but if anyone could provide an example of this in practice I’d really appreciate.
- vbuwivbiu 8y agosimply this: when any function returns a result, you never need to worry about anything else in the universe changing too. It's a self-contained operation with totally predictable results and no side effects.
- felipeccastro 8y agoYeah but when you do need to mutate state, why returning a new object is any clearer than modifying an object and returning it? Especially when the new object you return is going to be used to update a state tree later. Isn’t this a side effect too, even if more indirect?
- dnautics 8y agoYou don't have to worry about state mutating in the body of your functions, so when tracing or debugging the action of the function you can be very single minded and deterministic. Its especially beneficial when you're doing multithreading work. I've debugged multithreading C++ and multithreaded elixir/erlang and fixing errors and identifying race conditions is night and day. We wrote a front end in highly disciplined functional JavaScript on react with a single source of truth object in the center. I haven't touched JavaScript in a decade, and I could debug parts and add features with 100% confidence that I wasn't messing anything up (needed the frontend in a pinch so we hadn't done unit testing yet-i know I know, it's fixed now) If you are curious, I recommend the video "boundaries" by Gary Bernhardt, of "wat" fame.
- dnautics 8y ago> OOP encourages mutability This is largely only true in the post-bjarne soustrop OOP era. The smalltalk or actor paradigms don't necessarily encourage state mutation.
- pjmlp 8y agoActually it was with C++ that I learned to control mutability via proper use of const and mutable, even before I got to learn Caml Light.