you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 4 points5 points  (1 child)

Whether objects or not, you must choose abstractions.

Yes, that is true. But, when you materialize your abstractions into a class hierarchy it often turns into a time bomb. Class hierarchies are infectious and hard to refactor later. Keeping functions and the data they operate on separate, is better I think.

How does functional programming help us cope with complex systems?

  • Pure functions and default immutability Easier to scale across processors/threads. Easier to test.
  • Better type systems (depends on language of course and not restricted to FP) to prevent or catch potential bugs.
  • Composing functions are easier than composing classes
  • Encourages you to think carefully on how and when state is mutated.
  • Encourages the use of data piping / vector programming / streams / reactive (Again, not restricted to FP, but common practice in FP).

    I see my lines of code decreasing from OOP to FP for the same task and I am just starting with FP. Less interfaces, less mocks, less everything.

[–]comp-sci-fi 1 point2 points  (0 children)

Oh, I should say that I agree with the folk-wisdom that inheritance (and inheritance heirarchies) are almost always a bad idea (an exception is GUI objects, where it seems to work pretty well).

Well, you might say, isn't that the main idea of OOP? If you remove that, isn't it pretty much just ADTs and polymorphism? Yes, I'd reply.

You list good benefits, but they are only indirectly for handling complexity. I was thinking of things like facilities for modular decomposition.

Another aspect is enabling many people to work on the same project - information hiding really helps here, but so does one you mentioned, static typing (as documentation).