[js8]

Can you explain what you mean by OOP? I personally think FP is a misnomer, it (as an architectural style) should be more properly called "algebra-oriented" programming (where algebra means general algebra and category theory). You basically design API based on some properties (equations) between objects.

If that's what you end up with, it's fine, but I don't think it should be called OOP, since this is not how OOP was understood in almost any OOP language (in particular, interfaces won't let you express equational relationships).

[vinceguidry]

What I mean by OOP is representing domain concepts as objects with state. The objects merge interfaces (methods) with state. The objects and their relationships are the primary focus and the code is structured around them.

FP takes a data-first approach, making program flow the primary focus. State is, as much as possible, turned into data and otherwise squeezed out of the picture.

FP programmers go to lengths to eliminate state that I would consider excessive, only to recreate that state later when they have to start reasoning about the whole system.

As a diehard Rubyist, I find Ruby's semantics to be perfectly suited for any task of abstraction you want to throw at it. Just throw the errant code into a module. Turn it into a class when you start to need state.

I'll take an example from my current side project. I'm integrating the Pocket API into my app. I don't have time to rigorously implement a Pocket API consumer, but what I can do is implement the one API call that I need right now.

Instead of taking the time to do everything right the first time, I can simply make a single file with a module and call methods off of that module. As I implement more calls, I'll have a better idea of what kinds of state I'm managing, so I can refactor the code appropriately when the time is due.

It starts off procedural, code that just does things one after the other. It might acquire functional flavors as I work out the data pipeline. But eventually it will turn into proper objects with classes that can be passed around to whatever needs them. Things that would look like major architectural changes from the data pipeline point of view, are simple when you think about them as objects. Just implement the required interface and pass the instances to who needs them.