Hacker News Reader

Comment by vbuwivbiu | Hacker News Reader

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.

View on HN

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.

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

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)

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.

Reply on news.ycombinator.com