7 ms·

> What happens once something reaches the top is that you start to have people with lots of experience in it that are becoming more and more aware of some of th

> What happens once something reaches the top is that you start to have people with lots of experience in it that are becoming more and more aware of some of the small warts. And they start to heavily complain about them. I think it's lazy to dismiss the OOP as hate from experts who are complaining. I think a lot of criticism for OOP comes from experts who used to program in OOP, often with decades of experience, and have moved on to other paradigms, and are proudly proclaiming "I will never go back". If you want a really good (non-individual) example, take React, yes, the framework as a whole, which has quietly migrated away from OOP to promoting FP style as best practice; and hell, this is inside of a programming language that while proclaiming to be multi-paradigm, was very much created with Object Orientation in mind (yes, I am aware that it was supposed to be a lisp at one point, but almost everything in the language is Object object). I think there's good evidence that this isn't just a run of the mill "grass is greener" grousing by experts. Here's a challenge. Can you name a contemporary expert or a platform that started or spent a good chunk of time as FP and ran back towards OOP (I would say since 1990 or so, as it is a thing that FPs had very poor performance before that era)?

wolco 6y ago
I can't think of an OOP framework that went functional. I can't think of a time where we killed a project or rewrote a project to make it more functional. Or where OOP bite us. React went functional for a reason. Does everyone share that reason?
CraigJPerry 6y ago
>> I think there's good evidence that this isn't just a run of the mill "grass is greener" grousing by experts. I’m not sure. For example, frameworks are often nicer in OO than FP. Of course some wag will suggest you shouldn’t use frameworks, only libraries, but that misses the point. Plugins strike me as another use case that works better in OO than FP. I’m certainly not saying you can’t have a plugin architecture in FP though, it just won’t be as nice to use, that’s all. I expect in a few years the OO revival will be strong. “Look, we can neatly model fundamental concepts such as timers again!” >> Can you name Does es5 to es6 count? es5 was in theory already OO but the predominant usage appeared to be more heavily influenced by FP. I could be wrong on that but books like javascript the good parts were popular.
- dnautics 6y ago
  (going with the definition that frameworks are "your code gets called into by the community code" where libraries are "you call into the community code", please correct me if I'm wrong) There are some very nice FP frameworks, for example Phoenix LiveView, or phoenix in general. Elixir has lots of mini-frameworks (like the Enum and Access protocols). They're a joy to work with and pretty easy to understand. I'm not really sure what constitutes a plugin, but I've written what I would consider "plugins" for the BEAM vm (loaded at runtime, with an exposed API behaviour called into by the system), and they're pretty smooth and easy to handle. Arguably all of the BEAM OTP (std lib) and the patterns that packages expose for building persistent services are FP frameworks. If I may be permitted to make a more apples-to-apples comparison between the Erlang BEAM framework, to the BeOS C++ framework (both highly concurrent message-passing, actor frameworks). While I loved programming for BeOS, IMO doing everything functionally is far far smoother an experience than doing everything with objects. Both I enjoyed far more than programming the Dalvik (android) Java framework (though that was circa 2009). Anyways having experience in all four quadrants, I don't think it's as simple as ("frameworks/plugins -> OOP; libraries -> FP).
- esperent 6y ago
  Can anyone explain to me what the difference between a framework and a library is? I've looked it up several times but it always seems cloudy at best, and it seems like some things that are referred to as frameworks are pretty similar to some other things referred to as libraries.
  - phyrex 6y ago
    My favourite explanation is that a framework calls your code, whereas for a library, your code calls the library functions. Does that make sense?
  - leafboi 6y ago
    Basically like when you call something like: Math.abs(-5) That's a library call. A framework is like django or rails. You have to structure your code to fit within django's paradigm, while a library is just utilities you can use in your own code...
TwoBit 6y ago
I hear "I tried FP and learned a lot but it wasn't practical" all the time. Far more than the inverse.
- dnautics 6y ago
  There's probably a sampling bias, because of the attitude that one should learn Haskell "to be a better programmer". The FP universe is far broader than the pure FPs. Need I remind: Twitter went from RoR to Scala, ostensibly for practical (performance) purposes, though with hindsight they could have figured out how to scale RoR. So it's hard to argue that nobody has gone the other way strictly for "practical" reasons. It's also hard to argue that Whatsapp hasn't been wildly successful at scaling to a billion users on a miniscule engineering team in spite of "impracticality of FP".
  - sangnoir 6y ago
    > So it's hard to argue that nobody has gone the other way strictly for "practical" reasons. You've made explicit another confounding factor: a language is more than its syntax - you have to consider the entire ecosystem and constraints being operated under - including tooling and libraries
- patrickthebold 6y ago
  I think there are some subtleties hidden in the word 'practical'. There are differences between: My company has 200 Java engineers, and a dozen systems written in Java; it's not practical to migrate everything to <FP language>. Spring Boot solves so many things out of the box that I'd have to implement myself in <FP language>, which isn't practical. FP has a lot of features but it's not practical to maintain a large complex codebase using those features.
azangru 6y ago
> If you want a really good (non-individual) example, take React React is probably not a good example, because it didn't really expose its users to the horrors of OOP. There wasn't much inheritance and subclassing going on in the userland; you didn't really see SecondaryButton component inherit from the Button component and override its "render" or "onClick" method. True, there were some such codebases, but it was extremely rare. So no, I don't think React users have ever experienced the full extent of OOP, where you have to hunt through your codebase up the hierarchy chain for the bit of code that is misbehaving.
- JMTQp8lwXL 6y ago
  I can tell you the one time I ever worked on a subclassed React component (large codebase too-- so it was a unique situation), it was not a joy.
  - jamil7 6y ago
    Yikes I had a colleague years ago who was doing this, caused all kinds of fun bugs.
didibus 6y ago
> I think it's lazy to dismiss the OOP as hate from experts who are complaining I'm sorry if this is what you understood. The hate is from people hearing the complaints of experts. The experts generally have great understanding of the pros and cons, and are aware of the weaknesses, which they will openly talk about and sometimes that will make it sound worse, almost hyperbolic to others. Even I'm faulty of doing this, I might say this just sucks, or it's total rubbish, but really I mean it's pretty good and there's a lot of good ideas and parts, just needs some refinement and a few modifications because there are still problems with it, and I just faced one such wart so I'm frustrated and writing a big blog post to complain about it. And this is the source of the misunderstanding. Overreaction and hyperboles from experts, taken at face value to those who are learning about it. To your other points, I think it's interesting you bring up React since its biggest competitors: Vue, Svelte and Angular are all OO based and seem to be doing well. > Can you name a contemporary expert or a platform that started or spent a good chunk of time as FP and ran back towards OOP Hum, I think most did. OCaml added an object system to ML. CommonLisp added an object system to lisp. Haskell added TypeClasses. Scala is an attempt at an Haskell like language with a full object system. F# and Kotlin both have object systems as well. One could argue actors are a purer form of OO. And so on. See, my point is that experts only ever complained about certain aspects of current iteration of so called OO programming languages. And as you can see, alternate languages they'd reach for or newer languages after them (or even newer version of those languages) all tried to address those shortcomings, but did not throw the baby out with the bathwater. There is convergence of ideas, and most of those languages have many if not most of the OO staple feature set, while having taken a few out or added some other inspired often by FP, but sometimes by other paradigms too.
- johnisgood 6y ago
  I like OCaml's and Common Lisp's OOP. I hate Java's OOP.
  - didibus 6y ago
    Yup, and what happens when you take one entity that has qualities you dislike and generalize it to all entities of the same color? You get people hearing that OOP sucks, and they start to have fears and hatred towards it, thinking that all OO and every single idea and concept related to it is bad. This is called stereotyping, and it's not productive to bring into a technical conversation. Even inside FP it exists, ever saw a Scheme programer and a Haskell programmer debate? They'd go on forever about whose the one true Functional Programmer.

wolco 6y ago

I can't think of an OOP framework that went functional. I can't think of a time where we killed a project or rewrote a project to make it more functional. Or where OOP bite us. React went functional for a reason. Does everyone share that reason?

CraigJPerry 6y ago

>> I think there's good evidence that this isn't just a run of the mill "grass is greener" grousing by experts. I’m not sure. For example, frameworks are often nicer in OO than FP. Of course some wag will suggest you shouldn’t use frameworks, only libraries, but that misses the point. Plugins strike me as another use case that works better in OO than FP. I’m certainly not saying you can’t have a plugin architecture in FP though, it just won’t be as nice to use, that’s all. I expect in a few years the OO revival will be strong. “Look, we can neatly model fundamental concepts such as timers again!” >> Can you name Does es5 to es6 count? es5 was in theory already OO but the predominant usage appeared to be more heavily influenced by FP. I could be wrong on that but books like javascript the good parts were popular.

dnautics 6y ago
(going with the definition that frameworks are "your code gets called into by the community code" where libraries are "you call into the community code", please correct me if I'm wrong) There are some very nice FP frameworks, for example Phoenix LiveView, or phoenix in general. Elixir has lots of mini-frameworks (like the Enum and Access protocols). They're a joy to work with and pretty easy to understand. I'm not really sure what constitutes a plugin, but I've written what I would consider "plugins" for the BEAM vm (loaded at runtime, with an exposed API behaviour called into by the system), and they're pretty smooth and easy to handle. Arguably all of the BEAM OTP (std lib) and the patterns that packages expose for building persistent services are FP frameworks. If I may be permitted to make a more apples-to-apples comparison between the Erlang BEAM framework, to the BeOS C++ framework (both highly concurrent message-passing, actor frameworks). While I loved programming for BeOS, IMO doing everything functionally is far far smoother an experience than doing everything with objects. Both I enjoyed far more than programming the Dalvik (android) Java framework (though that was circa 2009). Anyways having experience in all four quadrants, I don't think it's as simple as ("frameworks/plugins -> OOP; libraries -> FP).
esperent 6y ago
Can anyone explain to me what the difference between a framework and a library is? I've looked it up several times but it always seems cloudy at best, and it seems like some things that are referred to as frameworks are pretty similar to some other things referred to as libraries.
- phyrex 6y ago
  My favourite explanation is that a framework calls your code, whereas for a library, your code calls the library functions. Does that make sense?
- leafboi 6y ago
  Basically like when you call something like: Math.abs(-5) That's a library call. A framework is like django or rails. You have to structure your code to fit within django's paradigm, while a library is just utilities you can use in your own code...

TwoBit 6y ago

I hear "I tried FP and learned a lot but it wasn't practical" all the time. Far more than the inverse.

dnautics 6y ago
There's probably a sampling bias, because of the attitude that one should learn Haskell "to be a better programmer". The FP universe is far broader than the pure FPs. Need I remind: Twitter went from RoR to Scala, ostensibly for practical (performance) purposes, though with hindsight they could have figured out how to scale RoR. So it's hard to argue that nobody has gone the other way strictly for "practical" reasons. It's also hard to argue that Whatsapp hasn't been wildly successful at scaling to a billion users on a miniscule engineering team in spite of "impracticality of FP".
- sangnoir 6y ago
  > So it's hard to argue that nobody has gone the other way strictly for "practical" reasons. You've made explicit another confounding factor: a language is more than its syntax - you have to consider the entire ecosystem and constraints being operated under - including tooling and libraries
patrickthebold 6y ago
I think there are some subtleties hidden in the word 'practical'. There are differences between: My company has 200 Java engineers, and a dozen systems written in Java; it's not practical to migrate everything to <FP language>. Spring Boot solves so many things out of the box that I'd have to implement myself in <FP language>, which isn't practical. FP has a lot of features but it's not practical to maintain a large complex codebase using those features.

azangru 6y ago

> If you want a really good (non-individual) example, take React React is probably not a good example, because it didn't really expose its users to the horrors of OOP. There wasn't much inheritance and subclassing going on in the userland; you didn't really see SecondaryButton component inherit from the Button component and override its "render" or "onClick" method. True, there were some such codebases, but it was extremely rare. So no, I don't think React users have ever experienced the full extent of OOP, where you have to hunt through your codebase up the hierarchy chain for the bit of code that is misbehaving.

JMTQp8lwXL 6y ago
I can tell you the one time I ever worked on a subclassed React component (large codebase too-- so it was a unique situation), it was not a joy.
- jamil7 6y ago
  Yikes I had a colleague years ago who was doing this, caused all kinds of fun bugs.

didibus 6y ago

> I think it's lazy to dismiss the OOP as hate from experts who are complaining I'm sorry if this is what you understood. The hate is from people hearing the complaints of experts. The experts generally have great understanding of the pros and cons, and are aware of the weaknesses, which they will openly talk about and sometimes that will make it sound worse, almost hyperbolic to others. Even I'm faulty of doing this, I might say this just sucks, or it's total rubbish, but really I mean it's pretty good and there's a lot of good ideas and parts, just needs some refinement and a few modifications because there are still problems with it, and I just faced one such wart so I'm frustrated and writing a big blog post to complain about it. And this is the source of the misunderstanding. Overreaction and hyperboles from experts, taken at face value to those who are learning about it. To your other points, I think it's interesting you bring up React since its biggest competitors: Vue, Svelte and Angular are all OO based and seem to be doing well. > Can you name a contemporary expert or a platform that started or spent a good chunk of time as FP and ran back towards OOP Hum, I think most did. OCaml added an object system to ML. CommonLisp added an object system to lisp. Haskell added TypeClasses. Scala is an attempt at an Haskell like language with a full object system. F# and Kotlin both have object systems as well. One could argue actors are a purer form of OO. And so on. See, my point is that experts only ever complained about certain aspects of current iteration of so called OO programming languages. And as you can see, alternate languages they'd reach for or newer languages after them (or even newer version of those languages) all tried to address those shortcomings, but did not throw the baby out with the bathwater. There is convergence of ideas, and most of those languages have many if not most of the OO staple feature set, while having taken a few out or added some other inspired often by FP, but sometimes by other paradigms too.

johnisgood 6y ago
I like OCaml's and Common Lisp's OOP. I hate Java's OOP.
- didibus 6y ago
  Yup, and what happens when you take one entity that has qualities you dislike and generalize it to all entities of the same color? You get people hearing that OOP sucks, and they start to have fears and hatred towards it, thinking that all OO and every single idea and concept related to it is bad. This is called stereotyping, and it's not productive to bring into a technical conversation. Even inside FP it exists, ever saw a Scheme programer and a Haskell programmer debate? They'd go on forever about whose the one true Functional Programmer.