I always find it funny to see calls to “unlearn oop”. It’s a tool, useful in some contexts and not useful in others. At some point industry treated it like a silver bullet, and now people are reacting to it by checks notes treating the hot new paradigm as a silver bullet.
learn oop, learn fp, learn logic programming, learn whatever you want. Also, learn when not to use them.
It’s a tool, useful in some contexts and not useful in others.
In my opinion this is a thought terminating cliche in programming and the IT industry in general. It can be, and is, said in response to any sentiment about any thing.
Now, saying what sort of context you think something should or should not be used in, and what qualities of that thing make it desirable/undesirable in that context, could lead to fruitful discussion. But just “use the right tool for the right job” doesn’t contribute anything.
In my opinion this is a thought terminating cliche in programming and the IT industry in general. It can be, and is, said in response to any sentiment about any thing.
Sure, I agree it can be. But it doesn’t make it less true that “it depends” is often the answer. As I see it, my job is often to think “what applies in this case”. Including thinking about things like:
what matches the mental model the company has about this
what’s the shape of the problem
what type of abstractions do we already use
what aspect do I want to make available, how is this expected to change?
etc
Now, saying what sort of context you think something should or should not be used in, and what qualities of that thing make it desirable/undesirable in that context, could lead to fruitful discussion. But just “use the right tool for the right job” doesn’t contribute anything.
Sure. I lean towards object oriented design when things represent a simple well known object with a stable set of “nouns and verbs” that are unlikely to change. In my case this tends to be around UI elements or the data layer very basic things, where I don’t care too much about “data transformation”, but want to encapsulate an action (eg. I think being toggleable is intrinsic to a switch, so switch.toggle feels like a stable api and I can design an object like this that others can understand without having to care about the internals)
Some design patterns that come from the oop tradition (not exclusive to oop, but very much part of the toolkit) that I find exceptionally useful. For example, the strategy pattern is something I’ve used often when building things like data exporter and importer tools. I can structure my logic in this way, move all the specific logic to the leaves.
I can’t be exhaustive, but for me oop is all about encapsulation, and so I use it when it calls for that. I think it also makes APIs easy to test.
——
Functional programming I absolutely love. Whenever I’m transforming data, i think in functional terms. Composable functions, immutable data. It’s just a lot easier, and for me it makes it easier to test processes and operations. I tend to lean to this this in a business logic layer. If I can describe operations in a way that we talk about them in the company, and make those units of transformation testable, then bigger processes become safer and auditable.
Another thing from functional programming languages that I love is things like algebraic data types. It just pains me to use a language without sum types now.
——
A while back I used “aspect oriented programming”. That didn’t catch on, but moving some things like logging, event tracking, etc. to aspects makes sense to me. If a language supports function annotations, I /will/ try to move those sorts of aspects to a function annotation.
——
I spent a while doing prolog, and that language is just something else. I wish I had an easy to embed prolog that I could use for constraints on data. This one I don’t “get to mix and match” because multi purpose languages don’t include aspects of it. But thinking in terms of reversing operations (eg. Given this result, what set of constraints produce it) is still a tool that helps me understand how to shape a problem.
——
There’s a lot of nuance to this, more than can fit in a comment, and definitely nuance that doesn’t apply to imaginary problems or problems/sotuations that we don’t share. Also, you and others will probably think about it differently. to me that’s kind of the point, both thinking in terms of a diverse toolkit, and having a team with diversity of thought.
I’ve been working as first a Python and then a Java dev for the last 15 years and I can count the amount of times when I’ve seen actual OOP on one hand.
I mean, we write “class” at the beginning of our modules and at the beginning of our structs, and we write “interface” at the beginning of our header files, but none of that is actually OOP.
If you use Spring Boot, you are essentially doing C (not even C++) in Java.
You have data-only classes without methods (at best there’s a conversion method or something shallow like that) that work identical to C structs. You have service interfaces, which serve the same purpose as C header files. And then you have data-less collections of functions (service/controller classes), which work like .c files.
Nowhere in this whole process are you actually using OOP techniques.
FP has been around a long time, and yes, it is outright better than OOP. Sorry. I write Haskell professionally, and never have I ever felt like something would be easier done in an OOP language. Quite the opposite.
Unrestricted mutation makes programming really hard, and OOP and mutability go hand-in-hand. If you try to make immutable objects, then you’re just doing FP with worse ergonomics.
These are two sides of the same coin, and both of them miss the point. You should be dealing with scale, and you should use a language that allows you to concisely describe how to compute large amounts of data easily. The best part is that once you start writing APL, you’ll feel like a wizard.
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.
FP & OOP both have their use cases. Generally, I think people use OOP for stateful programming, and FP for stateless programming. Of course, OOP is excessive in a lot of cases, and so is FP.
OOP is more useful as an abstraction than a programming paradigm. Real, human, non-computer programming is object-oriented, and so people find it a natural way of organizing things. It makes more sense to say “for each dog, dog, dog.bark()” instead of “map( bark, dogs)”.
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. 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)”. Then, if you are using a clever library, it will use pointers to the parameters within the functions to update during the optimization step. It hides how the parameters influence the result, but machine learning is a black box anyway.
In my limited use of FP, I’ve found it useful for manipulating basic data structures in bulk. If I need to normalize a large number of arrays, it’s easy to go “map(normalize, arrays)” and call it a day. The FP specific functions such as scan and reduce are incredibly useful since OOP typically requires you to set up a loop and manually keep track of the intermediate results. I will admit though, that my only real use of FP is python list comprehension and APL, so take whatever I say about FP with a grain of salt.
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).
Imo the main issue with oop is that it’s very easy for people to make bad designs. Generally the feeling I get is that if you work on a well designed codebase, then you’ll come to like whatever the main paradigm of that codebase is, and if you work on a poorly design codebase you’ll come to dislike the paradigm.
I always find it funny to see calls to “unlearn oop”. It’s a tool, useful in some contexts and not useful in others. At some point industry treated it like a silver bullet, and now people are reacting to it by checks notes treating the hot new paradigm as a silver bullet.
learn oop, learn fp, learn logic programming, learn whatever you want. Also, learn when not to use them.
In my opinion this is a thought terminating cliche in programming and the IT industry in general. It can be, and is, said in response to any sentiment about any thing.
Now, saying what sort of context you think something should or should not be used in, and what qualities of that thing make it desirable/undesirable in that context, could lead to fruitful discussion. But just “use the right tool for the right job” doesn’t contribute anything.
Sure, I agree it can be. But it doesn’t make it less true that “it depends” is often the answer. As I see it, my job is often to think “what applies in this case”. Including thinking about things like:
Sure. I lean towards object oriented design when things represent a simple well known object with a stable set of “nouns and verbs” that are unlikely to change. In my case this tends to be around UI elements or the data layer very basic things, where I don’t care too much about “data transformation”, but want to encapsulate an action (eg. I think being toggleable is intrinsic to a switch, so switch.toggle feels like a stable api and I can design an object like this that others can understand without having to care about the internals)
Some design patterns that come from the oop tradition (not exclusive to oop, but very much part of the toolkit) that I find exceptionally useful. For example, the strategy pattern is something I’ve used often when building things like data exporter and importer tools. I can structure my logic in this way, move all the specific logic to the leaves.
I can’t be exhaustive, but for me oop is all about encapsulation, and so I use it when it calls for that. I think it also makes APIs easy to test.
——
Functional programming I absolutely love. Whenever I’m transforming data, i think in functional terms. Composable functions, immutable data. It’s just a lot easier, and for me it makes it easier to test processes and operations. I tend to lean to this this in a business logic layer. If I can describe operations in a way that we talk about them in the company, and make those units of transformation testable, then bigger processes become safer and auditable.
Another thing from functional programming languages that I love is things like algebraic data types. It just pains me to use a language without sum types now.
——
A while back I used “aspect oriented programming”. That didn’t catch on, but moving some things like logging, event tracking, etc. to aspects makes sense to me. If a language supports function annotations, I /will/ try to move those sorts of aspects to a function annotation.
——
I spent a while doing prolog, and that language is just something else. I wish I had an easy to embed prolog that I could use for constraints on data. This one I don’t “get to mix and match” because multi purpose languages don’t include aspects of it. But thinking in terms of reversing operations (eg. Given this result, what set of constraints produce it) is still a tool that helps me understand how to shape a problem.
——
There’s a lot of nuance to this, more than can fit in a comment, and definitely nuance that doesn’t apply to imaginary problems or problems/sotuations that we don’t share. Also, you and others will probably think about it differently. to me that’s kind of the point, both thinking in terms of a diverse toolkit, and having a team with diversity of thought.
I’ve been working as first a Python and then a Java dev for the last 15 years and I can count the amount of times when I’ve seen actual OOP on one hand.
I mean, we write “class” at the beginning of our modules and at the beginning of our structs, and we write “interface” at the beginning of our header files, but none of that is actually OOP.
If you use Spring Boot, you are essentially doing C (not even C++) in Java.
You have data-only classes without methods (at best there’s a conversion method or something shallow like that) that work identical to C structs. You have service interfaces, which serve the same purpose as C header files. And then you have data-less collections of functions (service/controller classes), which work like .c files.
Nowhere in this whole process are you actually using OOP techniques.
FP has been around a long time, and yes, it is outright better than OOP. Sorry. I write Haskell professionally, and never have I ever felt like something would be easier done in an OOP language. Quite the opposite.
Unrestricted mutation makes programming really hard, and OOP and mutability go hand-in-hand. If you try to make immutable objects, then you’re just doing FP with worse ergonomics.
An object is a poor man’s closure.
A closure is a poor man’s object.
These are two sides of the same coin, and both of them miss the point. You should be dealing with scale, and you should use a language that allows you to concisely describe how to compute large amounts of data easily. The best part is that once you start writing APL, you’ll feel like a wizard.
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 would humbly suggest FP may seem especially natural to you precisely because that’s what you use all day.
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.
Please Grok tell me why was I so invested in this discussion, even if I’m not quite sure what OOP is?
FP & OOP both have their use cases. Generally, I think people use OOP for stateful programming, and FP for stateless programming. Of course, OOP is excessive in a lot of cases, and so is FP.
OOP is more useful as an abstraction than a programming paradigm. Real, human, non-computer programming is object-oriented, and so people find it a natural way of organizing things. It makes more sense to say “for each dog, dog, dog.bark()” instead of “map( bark, dogs)”.
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. 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)”. Then, if you are using a clever library, it will use pointers to the parameters within the functions to update during the optimization step. It hides how the parameters influence the result, but machine learning is a black box anyway.
In my limited use of FP, I’ve found it useful for manipulating basic data structures in bulk. If I need to normalize a large number of arrays, it’s easy to go “map(normalize, arrays)” and call it a day. The FP specific functions such as scan and reduce are incredibly useful since OOP typically requires you to set up a loop and manually keep track of the intermediate results. I will admit though, that my only real use of FP is python list comprehension and APL, so take whatever I say about FP with a grain of salt.
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.
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.
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).This entirely misses the point of FP. What data is actually being transformed here? It’s a nonsensical example.
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.
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).
Imo the main issue with oop is that it’s very easy for people to make bad designs. Generally the feeling I get is that if you work on a well designed codebase, then you’ll come to like whatever the main paradigm of that codebase is, and if you work on a poorly design codebase you’ll come to dislike the paradigm.