Right. A closure can be thought of as an object with a single method.

Alternatively, the core of OOP is objects sending messages to other objects. There are a lot of different ways to do that. A micocontroller sending “begin <process>” to another microcontroller over SPI is OOP. At some point, the way C++ does things became the way to do OOP, and that was a narrow minded mistake.

I mean, I have an OOP background. I found FP as a result of my dissatisfaction with OOP. In fact, I used to teach OOP languages to new students and saw the same mistakes over and over again, mistakes that are simply not possible in FP. It’s a very similar story for everyone I work with, too. We all had jobs in various OOP languages before we managed to get jobs writing Haskell.

Oh, and I’m currently teaching Haskell to someone at work who has a CS degree and has only done OOP languages (and C), and while it’s different than what he’s used to, he’s still picking it up very quickly (working towards making him a junior engineer, which I think shouldn’t take too much longer). In fact, just the other day we pair programmed on a bug ticket I have and he was not only following along with the code, he spotted issues I hadn’t seen yet. Part of it is certainly that’s he smart (which is why I’m doing this in the first place), but part of it is also that, with a bit of familiarity, FP languages are incredibly easy to read and follow. The primary difference is that FP does everything explicitly, whereas OOP encourages a lot of implicit (and hidden) behavior. When you organize code around functions, there’s necessarily more explicit arguments and explicit return values, which makes it far, far easier to follow the flow of logic of code (and test!). Recently I was trying to read through our Kotlin codebase at work (for our Android app), and it was so much harder because so much is implicit.

If your experience with FP is as limited as you say, then, respectfully, you lack the requisite experience to compare the two. It’s an entire paradigm shift that requires you to completely change how you think if you’re accustomed to OOP, and really requires one to program in a language designed for it. The features that OOP languages have cribbed from FP languages are very surface-level and not at all representative of what it actually is (and I’d say they largely miss the point of FP).

I have been writing Haskell professionally for the last 5 years over the course of 2 jobs developing database-backed web services for web and mobile apps, and spent about ~5 years before that developing in OOP/imperative languages. I have a good deal of experience with both paradigms.

OOP is more useful as an abstraction than a programming paradigm.

It’s a very poor (and leaky) abstraction, and you can achieve much more powerful abstractions with FP languages (especially Haskell, which has a type system that is far more powerful than any OOP language is capable of). This is evidenced by the fact that a whole slee of design patterns exist to solve problems created by OOP itself. FP languages, on the other hand, have little need for design patterns, because useful patterns are easy to abstract over and turn into libraries.

Real, human, non-computer programming is object-oriented, and so people find it a natural way of organizing things.

I have no idea what this even means. Programming is taking input and producing output. That, at its core, is a function. Pure and simple. Many useful ideas are quite difficult to express as a noun, which is how you end up with a whole array of super awkwardly named classes that try to “noun-ify” verbs (think classes named like Serializer, Resolver, Initializer, and so on).

It makes more sense to say “for each dog, dog, dog.bark()” instead of “map( bark, dogs)”.

This entirely misses the point of FP. What data is actually being transformed here? It’s a nonsensical example.

A good use case for OOP is machine learning. Despite the industry’s best effort to use functional programming for it, Object oriented just makes more sense.

Not really sure what you’re talking about. No one uses functional programming for machine learning outside of research. To be clear, Python is not functional programming. The reasons for that having nothing to do with the paradigm and everything to do with social reasons and inertia. Python was already used by a lot of academics for some ecosystem reasons, and the ecosystem has grown since then. Had the history of things been different, functional programming absolutely would have excelled at it and would have been a much better fit, because machine learning is fundamentally a pipeline of transformations on data.

You want a set of parameters, unique to each function applied to the input. This allows you to use each function without referencing the parameters every single time. You can write “function(input)” instead of “function(input, parameters)”.

This is trivial to do in functional programming languages with a variety of methods. Commonly this is done with the Reader Monad, or even simply partial application of functions (also known as closures).

My first assignment as a professional programmer I balked at. I said it was “Unethical and immoral.” And when they told me I “had to do it” I said that I don’t and that they shouldn’t find someone else. My boss stepped in, chewed me out and told me to she would do it. Instead of putting her foot down there was just always another priority. It never got done in the ten years of the project.

The KPI approach.

I have seen and worked on many projects that use inheritance, polymorphism, interfaces, all the staples of OOP. It’s true that none of these use only OOP principles and applies them rigorously. Real world projects are almost? always a mix of many different paradigms, because the truth is no one paradigm matches all use cases - and every programmer is only familiar with a few anyway.

This is one of the ways I believe Java went wrong: the program entry point is naturally a function, not an object. Wrapping main in an object makes little sense. Similarly, having absolutely everything inherit “Object” is forcing OOP where it doesn’t belong.

But that doesn’t mean OOP isn’t used in the real world. It is.

While the concept has it’s uses as a tool, the fallacy that OOP advocates fall into is overusing it.

I’ve seen many people completely swear off of using scripts, which is absolutely ridiculous. While you may use some tools more than others, swearing off an entire code structure for no reason is ridiculous.

Say there’s a module of code you need to write that has hundres if not thousands of variables that come into play in combinations that would be extremely difficult to organize as functions. You’re then stuck with passing all those as inputs and outputs between functions.

Sure, you could organize all those variables as a giant array and pass them around as one big block, but at that point you’re just emulating the shared workspace that you get with scripts, and you’d just be better off working with scripts from the start.

The issue with OOP is that it completely ignores this reality and insists that nobody should ever need a script, and if they think they do then they just aren’t clever enough.

That’s because you haven’t unlearned it yet