Hacker News Reader

Comment by j_m_b | Hacker News Reader

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.

View on HN

In 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.

A 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'.

Ok 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.

My 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.

Credit where it's due; that sounds like Gary Bernhardt's "functional core, imperative shell": https://www.destroyallsoftware.com/screencasts/catalog/funct...

Previous HN discussion: https://news.ycombinator.com/item?id=18043058

is it really cargo cult if it works though?

http://paulgraham.com/avg.html

fun read -- the last sentence included ! plenty to say about that article..

I get the sense that many commenters here, YNews in 2019, very much fit the description of a "Blub" programmer.. with the added twist that it is -giant-cloud-thing- platform and/or exciting web trends are my thing, to deepen the "Blub" point of view..

.. can't help but chuckle at the repeated and fairly clever jabs at ASM, considering it took M$FT ten years to make a windowing GUI that performed well enough on a PC, after the Mac OS was written in a lot of ASM.

But Lisp's object system is kind of famous. Where are the people beating the averages in pure fp languages? There should be a lot of really amazing software if fp is as good as it's made out to be and employed exclusively by elite non-blub programmers. There really isn't though, except maybe in finance where F# is doing quite well. And that's great but even F# is multi paradigm.

My home-grown accounting system, written in a language with great support for functional programming, is based on objects. accounts, transactions, transaction deltas, ledgers, are all objects. Starting from a blank slate, a file is loaded which defines the ledger entries. These definitions are processed one by one, using mutable updates to the object framework. What is left is then the state of the ledger with all those entries and that can be subject to various queries and reports.

>In 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.

Ok, try this on for size: OOP in general has one characteristic that makes it fantastic for large-team development, and that's extending over replacing. OOP makes it easy to never remove or change any existing code, and also "easy" to make changes or fixes by only adding more code. I wouldn't call it a good thing, but it does enable enormous numbers of people to all work on a codebase productively at the same time. I think this, more than anything else, is the power of OOP.

> And if OOP is so horrible why do so many people write OOP style PHP and javascript where they really don't have to?

Numbers. OOP supports big teams, so there are lots of OOP programmers in the wild. I genuinely think Javascript is sucking up to the Java developers of the world, and PHP is genuinely better for adopting OOP bits and pieces, but I'm not entirely sure why OOP devs and Java devs in particular seem to be immune to the industry mantra of "stay current and learn new things".

Yes, 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?)

Mathematics is sequentially dependent. Try 3/4==4/3 for a trivial example

3/4==4/3? Please explain.

Sequentially dependent in time.

Backus: 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/201...

Thanks 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!

Most 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.

Why is the IO monad a leaky abstraction? Any function that returns an IO computation in Haskell, is still a pure function.

“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.

simply 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.

Yeah 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?

You 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.

Additionally you break up the implementation into two smaller tasks. First one being how to transform object A to object B. And second being how to wire up everything to pass object B to other functions needing it. In OOP we essentially do the two at once. It can turn into quite an overhead in complex system.

But this is (largely) a property of the functions you write rather than the data structures. You can get virtually all of the benefit in the procedural world by just writing pure functions.

when you have immutable data structures by default you get the additional assurance that other places in the code that previously used an input to a function can continue to work with their data without needing to worry that it might have been changed by its use by a function elsewhere, since that function cannot modify the data, only return a new 'version' (through structural-sharing)

On the other hand, if the "everything else in the universe changes" model is established and understood, that can be an excellent way to streamline and decouple things.

I could see it working well with a React-style component model-- update the state, and anything derived from it automatically changes to match.

of course, if you prefer the 'anything could happen!' universe, have it at! And good luck to you

> 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.

Actually 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.

Reply on news.ycombinator.com