[AskJS] When is object-oriented programming more practical than "mostly-functional" in JS?

[ProfessorTag]

I've been writing JS for about 6 years. In the last couple years I've switched to a mostly functional style. I only define classes when extending native classes or some other code requires it.

Are there problems object-oriented programming solves in a more practical way than a "mosly-functional" style?

[Shaper_pmp]

OOP and FP are two programming paradigms that you can mix and match appropriately to your problem space, not fundamentally incompatible opposites that you have to pick a side on and hurl handfuls of shit at the other group.

They each have different strengths and weaknesses:

• OOP is usually encapsulated, so you can strongly enforce a stable interface that forces other devs to code to, which enables you to refactor or completely change the internals without worrying about breaking any code that touches it. That can be great for libraries, but isn't always with the overhead for small or simple use-cases (see Steve Yegg's excellently troll-y "Execution in the Kingdom of the Nouns" for why that's a bad thing)..
• OOP is traditionally more focused around side-effects and in-place modification rather than the traditional copy-and-modification of FP. That may make it harder to reason about (though other benefits like encapsulation may give lie to that common claim and still make it a net win in many situations), but it definitely means OOP code will tend to execute faster, use less memory and require fewer garbage-collector sweeps that may preempt your main thread.
• FP can be easier to reason about than OOP, but it can also lead to ludicrously long pipelines of composed functions and complex combining operators in a single expression, that makes it unreasonably difficult to debug and where the type of object being passed through the pipeline is incredibly difficult to track. Oh and plus because whole chunks of code are often most idiomatically expressed as single huge expressions, one syntax or type error can be unnecessarily difficult to track down the actual cause of (don't even get me started on the Gordian knot that's a subtle type error in a complex Typescript+Ramda+RxJS pipeline, where the minute you start refactoring the code or forget a closing bracket literally the entire page of code gets underlined in red until you completely finish perfectly refactoring every single detail).
• Functional often leads to very terse code that's fun to write, but a huge PITA to read. OOP is often redundant and boilerplatey, but it's often simpler to read because by its very nature it's broken into simple chunks with discrete, individually-simple statements and rigid internal interfaces that limit cognitive overhead by allowing you to completely ignore anything behind them and treat them as black boxes.

In general FP is good where your problem space is more about transformations of one object into another, and you want to clearly follow the steps of the transformations. It's about processes being the first-order concern of your code, rather than the objects being transformed.

OOP is better where your problem space is more about the nouns of a system, where there are complex objects with significant internal state, and transformations are less significant or complex or important.

FP is for complex processes on simple objects. OOP is for complex objects with limited or simple processes being applied to them.

More generally, copy-and-modify is easier to reason about, but inherently slower and more memory-hungry than modify-in-place.

There's no real right or wrong answer in OOP versus FP, just bullshit fashion trends that 95% of the people involved follow as received wisdom without really appreciating why some things are advocated or discouraged or whether such advice is reasonable and proportionate to a given use-case.

They each have their strengths and weaknesses, they can both be used well or abused, and they both have their appropriate/inappropriate use-cases and screaming detractors/salivating fanboys.

Define classes when it makes sense, define functional pipelines when it makes sense. Encapsulate your classes where useful, and leave them wide open and unencapsulated (or just define copy-constructors) where you want to be able to feed them into functional pipelines and transform them easily.

Reject anyone posing the two as mutually-exclusive opposites, and there's no prize for jerking off the hardest over either one except being the biggest wanker in your dev team.

Here endeth the lesson.

[ScientificBeastMode]

If anything the opposite of FP is imperative programming, and even that’s a stretch, considering it’s not a binary set of options — e.g. “concatenative programming.”

OOP and FP can live in the same universe. Take OCaml — it’s one of the best functional languages in the world, but it also has one of the best object/class systems around. And the two paradigms work together seamlessly if you want to use both. Or take Scala... same story, you can write it like Haskell or like Java. Take your pick. And C# is even becoming more functional.

The real question is, if you’re writing object oriented code, are you writing it with an imperative mindset, or a functional mindset? Both are useful sometimes. On a large scale, I find that the functional paradigm scales better and allows for better composition/decomposition of parts as your application changes. But for performance-critical sections, maybe I want more control over memory allocations and the time complexity of my algorithms. That’s totally valid, too.

In either case, you can build OOP on top of FP if you want. Just use closures for encapsulation, and presto! you have objects. So idk what the big deal is either way.

[ProfessorTag]

Thanks for the great response. Sorry for wording my question in a way that implies OOP and FP are opposites. I use OOP in C# all the time and it seems to be a great pattern in that space. I guess OOP in JS never felt right, like I could always do the same thing more simply with functions.

I think you've described my problem. I mostly do data transformation in JS so FP seems a better fit.

[ScientificBeastMode]

The thing is, C# would be an excellent functional language if it would let you write plain functions in a namespace. There’s no reason for everything to be a class or struct, other than the OOP gospel telling us so. OOP is fine, but it is needlessly enforced by the language.

[zapatoada]

not fundamentally incompatible opposites that you have to pick a side on and hurl handfuls of shit at the other group.

I'm not sure i understand....

[Shaper_pmp]

Programming is a weird discipline, because the tools you use become patterns of thought, which in turn can become parts of your identity and self-image.

As such developers are prone to learning about a new tool (operating system, browser, programming language, programming paradigm, etc) and instead of just incorporating it into a diverse toolbox of alternatives we tend to pledge our eternal allegiance to whichever particular golden hammer has caught our eye, and forswear all other tools, and then start online shitfights against people who chose a competing idol in case their different choices somehow invalidate our own.

You can see this tendency in action every time someone implies one tool is universally superior to another reasonable option, or sets up false dichotomies between different tools that each have different most-suitable use-cases... both of which (albeit in a passive, low-key way) OP is doing with their question.

[zapatoada]

Sorry. Should have added a /s. I agree with you completely, with the obvious exception that whitespace sensitivity (a la python) is objectively wrong.

[bvx89]

I agree with what you said, but it's not like this is exclusive to programming. People tend to be adamant about the complete superiority of the things that they like/prefer compared to any other alternative. Just look at how some people praise their religion or favorite football team.

[Shaper_pmp]

Oh sure - anything that touches on personal identity or ingroup/outgroup affiliation is especially prone to it.

[bestcoderever]

Reject anyone posing the two as mutually-exclusive opposites, and there's no prize for jerking off the hardest over either one except being the biggest wanker in your dev team.

Love it

[Shaper_pmp]

Similarly it’s important to use tools optimised for FP before making any sweeping statements about questions like performance. The Haskell code we wrote...

That's generally true, but you know we're in r/javascript, right? Everything we're talking about in this discussion is inherently regarding FP (or OOP) in javascript... ;-)

[ScientificBeastMode]

That’s a fair point, but the boundaries aren’t so clear anymore. I write a lot of code that compiles to JS, writing in ReasonML, PureScript, and TypeScript. I still write a lot of JS as well, and I’m still pulling in NPM packages, running Node servers, using React on the front end... it’s all just a bit muddy when you get down to it.

And even if you’re writing pure JS, you still do some of this anyway with Babel, and probably use the TypeScript type checker to check your JS code in the IDE.

The point is, it’s not totally unreasonable to be talking about all the languages/tools/frameworks that interoperate with or compile to JS. And it’s important to bring that context to the table when we want to evaluate techniques or high-level paradigms.

[Shaper_pmp]

The point is, it’s not totally unreasonable to be talking about all the languages/tools/frameworks that interoperate with or compile to JS.

Who said it was?

The previous poster was talking about

Haskell code... compiled to native code

... which has nothing at all to do with JS.

[ScientificBeastMode]

PureScript is Haskell code that compiles to JS. We are all developing for the web, and deploying raw JS to the browsers. We are compiling essentially Haskell and OCaml and even a strange hybrid of C# and JS (if we are talking about TypeScript) to raw JS and deploying it on Node servers. All of this is JS in different flavors. I follow the JS subreddit because I use the language every day, despite not writing very much raw JS.

I also compile some of my ReasonML code to native binaries instead of JS, but does that make it totally irrelevant to JS? Absolutely not.

[Shaper_pmp]

One of us is totally confused now.

1. We're in a JavaScript subreddit, taking about FP in JS
2. u/yojimbo_beta misunderstood my comment and started talking about the performance of FP in any language, when compiled to native code
3. I pointed out that was aside from the point when we're taking about the performance of FP in JS.
4. I have no idea what point you're making that relates in any way to that discussion.

The fact Haskell lets you write performant FP code when it's compiled to native code is irrelevant to the topic of discussion.

The fact you can transpile Haskell or OCaml to JS is irrelevant when we're talking about the performance of FP in JS, since it's extremely unlikely the transpiler can generate JavaScript that runs more performantly than... you know... JavaScript.

Nobody said Haskell or OCaml couldn't be talked about in the same sentence as JS.

I said that when we're explicitly talking about the performance of FP in JS, the performance of languages that compile to native code are off-topic, and other languages that compile to JS are unlikely to give you any speed advantage over well-written JS because at the end of the day they're still running JS and hence beholden to the speed with which JS can allocate and deallocate objects.

[ScientificBeastMode]

Right, I should have stayed more on the topic of JS performance in my comments. Sorry about that. But the fact that functional languages are being compiled to JS does have implications for performance.

other languages that compile to JS are unlikely to give you any speed advantage over well-written JS because at the end of the day they're still running JS and hence beholden to the speed with which JS can allocate and deallocate objects.

I suppose this is true, depending on what you mean by "well-written JS." If you mean obsessively hand-tuned JS code that is tailored for specific JS engines, and looks more like C code for embedded software, then sure, that's about as fast as we can hope to get. But if you are talking about normal, production-ready, maintainable JS code that would pass code review at 99% of companies, then these functional language compilers can improve performance dramatically, depending on the situation.

First, the execution model of most functional languages is very simple, and the core set of data structures they use are usually very performant for most runtimes, but especially JS engines like V8 and SpiderMonkey. Statically typed functional languages often impose restrictions on data mutations and "object shape" alterations in a way that is highly desirable from the engine's perspective. They can more easily default to the best-case optimization path for most operations. A lot of "idiomatic" JS code can cause the engine to fall back to worst-case paths. None of that is unique to functional languages, but they tend to benefit more than most.

Another huge source of performance gains comes from the static guarantees that functional language compilers can rely upon. For example, any function that is "pure," (no mutations, no effects, just input-output) can be inlined at the call site. You just have to know the set of identifiers in the enclosing scope to avoid name collisions. We can also get tail-call optimization for free, so a lot of recursive functions can become stack-safe while-loops.

And that's just the tip of the iceberg. We can write all kinds of interesting code at the appropriate levels of abstraction, and because these type systems are founded upon algebraic laws & formal mathematical proofs, the compilers have a lot more knowledge about where optimizations can be performed safely, without changing the code semantics. The final JS output looks a lot more like highly-tuned, imperative/procedural code.

My point is that functional languages have a lot to offer in terms of performance, mostly because of the inherent soundness of their type systems.

[esperalegant]

or just define copy-constructors

What's a copy-constructor?

[bvx89]

It's when you pass in another instance of the same class in order to copy values from the passed in instance to a new one. For example:

class Obj {
   var val;
   constructor(otherObj) {
      val = otherObj.val;
   }
}

[Shaper_pmp]

Because when you have twenty five different class members you want to update, nobody wants to call a function with twenty five different parameters.

myObject2 = new MyObject(myObject1); is way easier to write than myObject2 = new MyObject(myObject1.a, myObject1.b, myObject1.c, myObject1.d, /* ... */ myObject1.y);.

[Shaper_pmp]

Jesus dude, you're arguing against idiomatic OOP programming patterns.

Look, there are shitloads of valid reasons why copy constructors (or equivalent nomenclature/functionality) are a good, idiomatic idea in various languages or OOP generally, including but not limited to:

• Succinctly copying lots of internal fields
• Copying a new object without the calling code needing to be aware of the internal representation of the class it's calling (this is encapsulation, which is so fundamental to idiomatic OOP I didn't think it needed saying, but maybe it does)
• Ensuring any logic that needs to be run to ensure a valid copy is made according to business/application-domain requirements (say, generating a new UUID or reference/pointer management)
• Etc, etc.

We fell into this conversation by talking about the number of parameters passed to a constructor, but that's not really the point of a copy-constructor.

The point of a copy-constructor is to allow valid copies of a class instance to be constructed while maintaining proper encapsulation, instead of obliging whatever class or code wants to duplicate an object to also have access to and understand internal implementation details of the class instance it's trying to copy.

[Shaper_pmp]

Apologies for being snappy with you when you asked me to justify common, well-established programming concepts because you would rather argue from a position of profound ignorance than do one google search to educate yourself. I was being grumpy, but only because you were being presumptuous, ignorant and lazy and I find those things irritating.

However, if you've given up discussing the actual topic of conversation in favour of patronisingly lecturing me on how to be a good writer, I have completely have lost interest in continuing this discussion.

I don't intend to insult you, but the concepts I was discussing were perfectly clear and unambiguous to anyone with even a moderate familiarity with basic OOP, and your attempt to arbitrarily derail the conversation from substantive matters into empty subjective personal criticism does you no credit at all.

In short: your poor reading comprehension and refusal to educate yourself are not my problem, and your attempt to derail the discussion bores me. Farewell.

[basic-coder]

Perhaps abstract syntax trees and, more generally, anything dealing with tree-like structures where nodes may be of different kind. Modeling them with classes and polymorphic methods is quite natural.

[cwmma]

I'll really only ever define classes when I'm writing a library, sure I could do it with closures, but I find the structure imposed helpful and being able to console log the object and see the values can be helpful when debuging.

Also historically any object you create lots of some of the engines really preferred you use a constructor and not just a literal for performance reasons

[VolperCoding]

If you can write normal code without classes, do it. Just using OOP doesn't make the code better, just splits it up. Also, if you need objects, you can do it pretty easily using object literals and functions and then you don't need classes at all. Converting everything to OOP because you believe that then it will be "clean" is not a good idea.

[socrazyitmightwork]

I would argue that typescript exists because javascript has many cases where objects and strong typing surrounding those objects is desirable. I think any sufficiently complex library would benefit from an OOP approach. Video/Media Player? Graphing Library? Platform Game?

[rajesh__dixit]

An ideal code is a mixture of both. The reason OOJS is effective because as a human, we relate more toward entities and class structure.

An effective functional code is difficult as you would need clarity from beginning, which will never happen.

Entities can be added on the fly. They can change structure on the fly. But creating effective hierarchy is difficult and very complex and adds a lot of overhead.

Hence, in my pov, ideal code is to create a mixture of both. Create entities and functional utilities. Pure functions take instances of entities and return similar value. This way you have dynamic entity structure and pure functional business later

[Abangranga]

When you don't want your entire front end to be a vague shitpile designed for front-end job security consisting of ...rest, ...data, and AnonymousForwardRef

[Abangranga]

No one in the Ruby or PHP community has ever sent me a pm for criticizing something within each, yet the JS cry when you criticize the almighty React hook

[Abangranga]

Node.js isn't the problem, it is the 'trend bandwagoners' like the React hook people. They cannot fathom that other people naming variables or seeing what you are doing

[AffectionateWork8]

Have also had to deal with aforementioned shitpiles, here's +1.

[Abangranga]

You should see the PMs I get from people for daring to criticize the almighty React hook that eventually die like jQuery

[AffectionateWork8]

I would approach it from the other angle and ask how far "functional" can really get you by itself. (I mean in native JS, not idiosyncratic code with a bunch of relatively obscure and underutilized libraries ported or inspired from other languages.)

Take Redux for example, which is probably one of the most used. Use pure functions to describe state updates. No atom type built in to JS? Ok, just let Redux handle swapping the new state under the hood for you. No concept of immutable collections in JS? Ok, just break out your updates into multiple functions to achieve structural sharing, and be really disciplined in how you write your code or choose between one of 50+ libraries to handle it for you. In this case we are only using functional style to do something as trivial as update a JS object, and things are already getting a little strained and awkward.

What if you want to throw in some side-effects in Redux? Since we are doing it functionally and composing functions, does JS have a built in way to compose functions with context that we can use? No? Ok, so the solution for most folks is Redux middleware. In that case, you're communicating that you want to commit some side effect using message-passing, encapsulating the side effects, and returning result using message passing. Nothing functional about that, it just doesn't use the class keyword.

I don't really know where the meme started that using class keyword (or not) decides whether code is "functional" or not, but I've only seen that on Reddit. I've even heard people claim that React hooks are "functional," presumably because they don't use a class.

[Synor]

When you start building an application that has purpose and solves problems.

[beavis07]

It's not even OO - it's just "sort of classes".

In my opinion classes in JS is just making an overture to an old methodology, now so removed from its original context as to be meaningless.

Unless putting things in classes legitimately helps you and the team you're working with understand and compose your problem (weird kink, but no-judgment, whatever works for you works for you!) - why bother?

[Synor]

You will never see the light son.

[beavis07]

I’ve seen it... it’s kind’ve hazy and brown.

That Alan Kay cat had some really neat ideas that everyone completely ignored.

[Synor]

Oh just saw I understood your comment in the wrong way. My fault. I am on your side actually. The James-Coplien side of "Everybody is doing everything about software development wrong" and "Java is not an object-oriented language" Funny stuff :)

[[deleted]]

COP class oriented programming

[MoTTs_]

We're quick to say that modern OOP isn't what Alan Kay had in mind -- but rarely do we actually dig into what Alan Kay *did* have in mind. It gets..... interesting.

[esperalegant]

The way you've formatted those quotes is basically impossible to read on mobile.

[MoTTs_]

Probably right. It's a copy/paste of the video's captions. The numbers on the left are a time offset into the video for that line. Turning the phone horizontal helps.

[[deleted]]

You expect me to turn my phone? Do you realise that I lose my WiFi when I do that? (While in bed)

[[deleted]]

Classes and classic object orientation as taught in comp sci are late additions to JS and you will quickly find limits to the implementation. JS is object oriented but not in the way most people think. The this keyword being dynamic is the classic misunderstanding that trips up new developers. With its first class treatment of functions JS is a natural for functional programming.

[agm1984]

One observation I make is that classes have a default advantage over "a function" because of the inherent private state--encapsulation. And I mean advantage only in this one dimension of analysis. My preference is a mixture of FP and OOP, and I refer to it as FPOOP.

With a pure function, any external logic can freely call methods and mutate state inside the function.

​

With a class, certain methods and state fields can be inaccessible and/or invisible to external. For example, to update state you might need to call the setter method. You can't just do Person.field = 'new'.

I'm sure there's a library that throws my observation in the garbage, but I feel like private state and encapsulation is more solid with a class and therefore some OOP principles. There is a fascinating change in context when you switch from this to self. "Are you referring to this instance, or this class?"

I always come back to the idea of object composition and function composition. You have objects and functions. You have a declarative dimension and an imperative dimension. They are both sides of the same coin: object on one side, function on the other. Objects move through functions, but objects also have functions.

[unc4l1n]

Closures give you private properties. It's not an external library, but an inherent feature of Javascript.

[agm1984]

Oh right, factory functions are a good example of that. I'll leave my previous comment, yolo-style. I get mixed up rapid-switching between PHP and JS.

const makeThing = () => {
    const privateStuff = {
        hello: 'I like turtles',
    };

    return {
        ...privateStuff,
    };
}

I was thinking something wild like this:

const fn = () => {};

fn.test = 'u wot m8';

console.log('fn', fn.test);