6 ms·

I would really appreciate some examples of oop being "wrong" and the problem solved in a better way. I just don't see why its bad, it makes sense to me. Our lib

I would really appreciate some examples of oop being "wrong" and the problem solved in a better way. I just don't see why its bad, it makes sense to me. Our lib has classes and submodules with functions. A filetype benefits from a class that contains methods to manipulate said file but other common operation are better put in a function imho. Just saying "if you are really smart you'll see that oop is bad" just sounds so... Empty.

mywittyname 6y ago
I personally don't like inheritance as it is implemented in Java/C++. To me it feels like terrible default way to design a language so that methods can be shared between structured data types. It's certainly useful in a lot of cases, but I don't think it is in the majority of cases. Traits feel more natural to me. Instead of needing to make a subclass of a data structure to attach a foo method to it, you can define a collection of foo methods with the same name and pick the runtime implementation based on data structures passed to the method. I understand that this six of one, half dozen of the other, but I do prefer it this way. Granted, this is not something OOP does "wrong," and you can use generics to accomplish a similar thing, so it's not that big of a deal.
- wvenable 6y ago
  Inheritance is just traits combined interfaces. Interface is type, trait is the implementation. It just so happens that bringing the type along with the implementation is so common/useful that traits on their own aren't as common as inheritance.
oliwarner 6y ago
It's not empty, it's downright hypocritical. I fully accept that not everything benefits from being expressed in objects, which is why hybrid languages like Python are so excellent. But yes, even if some things don't map, keeping OOP around for things that do makes too much sense to ignore.
- dnautics 6y ago
  what's a thing that "does make sense?" The common one is "GUIs". But even React has basically taken UI and turned it functional (obviously not pure functional, but most FPs are not Haskell), by way of using distinctly non-OOP patterns to manage detached local state. There are of course plenty of other, less well known functional UI frameworks in their respective functional languages.
  - snidane 6y ago
    State management systems are what OOP is used. It used to be GUIs until React, Elm and such proved that FP style describing the end state is a better fit. "Simulations" can be done in both real time state management OOP style or FP or data centric style with explicit time. Operating systems are a good example for state management OOP. Linux is written in C with OOP techniques. FP with immutabilty of objects would likely not be a good fit because operating systems are expected to just run in thr background and to not waste resources (eg by copying full objects each microsecond). Anything where Erlang shines is another good fit for OOP because its actor model actually is the original vision of OOP - objects reacting to messages.
alquemist 6y ago
In small doses, OOP is invaluable, especially for defining modules and their interfaces. Alas, OOP advocates, especially in the old days, oversold it. Several major flaws: * "Everything is an object". This creates unnecessary confusion between data and modules and sometimes even functions. * "Everything is a message". This encourages splitting state between a myriad of objects, each hiding some tiny bit of mutable state that changes whenever it receives a message. Reasoning about such a state graph is impossible for any non-trivial application. * "Everything is an interface", which leads to tests tightly coupled to implementation due to mock over-usage. * "Everything is an inheritance hierarchy". Practice has proven that composition is better than inheritance.
- kazinator 6y ago
  No, no, no. Everything is a pointer-wide cell of bits, with a type tag. Now we're cooking with gas!
leafboi 6y ago
https://news.ycombinator.com/item?id=24358711 https://news.ycombinator.com/item?id=24358711 OOP only provides illusions of reuse-ability. In reality every component created in OOP takes extra steps and extra glue code to make compose-able. In programming you want to build small primitives that you can compose to form larger higher order primitives. This allows you to reuse lower level components to form new programs. OOP does not allow you to do this easily.
- wolco 6y ago
  Too many small primitives lead to grouping. An object can be a collection of primitives.
  - leafboi 6y ago
    And isn't a collection of primitives a grouping in itself? An object is a grouping of primitives. So according to your logic OOP should have the same problem. The real issue isn't grouping. The true nature of abstractions is the formation of higher level abstractions from "groupings" of lower level primitives. So "grouping" is fundamental to abstraction and therefore fundamental to programming. The problem with OOP is that the groupings are forced. I cannot reuse a method outside of the context of the object because the method is tied to mutable state. For example: Try to write a function addOneTimesTwo from the composition of the three primitives below (in python): def addOne(number): return number + 1 def timesTwo(number): return number * 2 def compose(f, g): return lambda x: f(g(x)) Answer: addOneTimesTwo = compose(timesTwo, addOne) You will note, compose is a universal functional operator. The definition for compose above is the most primitive way to compose functions in FP. Try to do the same with OOP: class AdditionObject: def __init__(self, number): self.number = number def addOne(self): self.number += 1 class MultiplicationObject: def __init__(self, a, b): self.a = a self.b = b def mult(self): return self.a * self.b Certainly do-able with OOP. But I cannot extract the methods away from the state. In order to use the banana (method) I need the gorilla holding it and the entire forest it lives in (Object) to come with it. It can be done, but generally you need a lot more glue code to make it work especially given the fact that people can get more creative with OOP. As you can see the MultiplicationObject is an example of this creativity. It was written with a different interface then the AdditionObject. Basically if you know haskell even similar issues to the above can be dealt with in terms of haskell. You can certainly define a composition operator for even the most complex types. The issue with OOP is that EVERYTHING is a complex type. A standard Object already has enough complexity to necessitate custom composition operators so you're basically writing custom glue code everywhere. Either you're writing complex glue code or your bending all your code to fit into a framework. Nothing is truly modular.
dnautics 6y ago
> oop being "wrong" ORMs that overload getters and setters as DB transactions: It creates a harmful illusion that the data inside the object are equally as authoritative as the data in the source of truth (as in database).
- dpc_pw 6y ago
  My take on ORMs (and OOP) is that they create a harmful illusion that data is just a bunch of "objects" that can be used in some abstract "reusable" way without care for the concrete form it have to be stored (relations, indices, collections/tables) to support efficient computation. See https://twitter.com/dpc_pw/status/1240719977071575040 https://twitter.com/dpc_pw/status/1240719977071575040 for how this works in practice.
  - imtringued 6y ago
    If you ask Gavin King or other creators of ORMS their complaints is that they lower the barrier of entry so much that even people who know nothing about databases end up using them. A lot of people seem to have the impression that the ORM is supposed to solve all their problems when an ORM is more of a convenience thing. You have to know the limitations of your database and design your database structure based on those limitations first. Your domain objects (objects representing data in the database) are supposed to match the design of your database, not the other way around. People like to call this a leaky abstraction but I think it's far more boring. Know your tools (both the ORM and the database). It will be worth it. Don't hesitate to use raw SQL if the ORM doesn't play along.

mywittyname 6y ago

I personally don't like inheritance as it is implemented in Java/C++. To me it feels like terrible default way to design a language so that methods can be shared between structured data types. It's certainly useful in a lot of cases, but I don't think it is in the majority of cases. Traits feel more natural to me. Instead of needing to make a subclass of a data structure to attach a foo method to it, you can define a collection of foo methods with the same name and pick the runtime implementation based on data structures passed to the method. I understand that this six of one, half dozen of the other, but I do prefer it this way. Granted, this is not something OOP does "wrong," and you can use generics to accomplish a similar thing, so it's not that big of a deal.

wvenable 6y ago
Inheritance is just traits combined interfaces. Interface is type, trait is the implementation. It just so happens that bringing the type along with the implementation is so common/useful that traits on their own aren't as common as inheritance.

oliwarner 6y ago

It's not empty, it's downright hypocritical. I fully accept that not everything benefits from being expressed in objects, which is why hybrid languages like Python are so excellent. But yes, even if some things don't map, keeping OOP around for things that do makes too much sense to ignore.

dnautics 6y ago
what's a thing that "does make sense?" The common one is "GUIs". But even React has basically taken UI and turned it functional (obviously not pure functional, but most FPs are not Haskell), by way of using distinctly non-OOP patterns to manage detached local state. There are of course plenty of other, less well known functional UI frameworks in their respective functional languages.
- snidane 6y ago
  State management systems are what OOP is used. It used to be GUIs until React, Elm and such proved that FP style describing the end state is a better fit. "Simulations" can be done in both real time state management OOP style or FP or data centric style with explicit time. Operating systems are a good example for state management OOP. Linux is written in C with OOP techniques. FP with immutabilty of objects would likely not be a good fit because operating systems are expected to just run in thr background and to not waste resources (eg by copying full objects each microsecond). Anything where Erlang shines is another good fit for OOP because its actor model actually is the original vision of OOP - objects reacting to messages.

alquemist 6y ago

In small doses, OOP is invaluable, especially for defining modules and their interfaces. Alas, OOP advocates, especially in the old days, oversold it. Several major flaws: * "Everything is an object". This creates unnecessary confusion between data and modules and sometimes even functions. * "Everything is a message". This encourages splitting state between a myriad of objects, each hiding some tiny bit of mutable state that changes whenever it receives a message. Reasoning about such a state graph is impossible for any non-trivial application. * "Everything is an interface", which leads to tests tightly coupled to implementation due to mock over-usage. * "Everything is an inheritance hierarchy". Practice has proven that composition is better than inheritance.

kazinator 6y ago
No, no, no. Everything is a pointer-wide cell of bits, with a type tag. Now we're cooking with gas!

leafboi 6y ago

https://news.ycombinator.com/item?id=24358711 https://news.ycombinator.com/item?id=24358711 OOP only provides illusions of reuse-ability. In reality every component created in OOP takes extra steps and extra glue code to make compose-able. In programming you want to build small primitives that you can compose to form larger higher order primitives. This allows you to reuse lower level components to form new programs. OOP does not allow you to do this easily.

wolco 6y ago
Too many small primitives lead to grouping. An object can be a collection of primitives.
- leafboi 6y ago
  And isn't a collection of primitives a grouping in itself? An object is a grouping of primitives. So according to your logic OOP should have the same problem. The real issue isn't grouping. The true nature of abstractions is the formation of higher level abstractions from "groupings" of lower level primitives. So "grouping" is fundamental to abstraction and therefore fundamental to programming. The problem with OOP is that the groupings are forced. I cannot reuse a method outside of the context of the object because the method is tied to mutable state. For example: Try to write a function addOneTimesTwo from the composition of the three primitives below (in python): def addOne(number): return number + 1 def timesTwo(number): return number * 2 def compose(f, g): return lambda x: f(g(x)) Answer: addOneTimesTwo = compose(timesTwo, addOne) You will note, compose is a universal functional operator. The definition for compose above is the most primitive way to compose functions in FP. Try to do the same with OOP: class AdditionObject: def __init__(self, number): self.number = number def addOne(self): self.number += 1 class MultiplicationObject: def __init__(self, a, b): self.a = a self.b = b def mult(self): return self.a * self.b Certainly do-able with OOP. But I cannot extract the methods away from the state. In order to use the banana (method) I need the gorilla holding it and the entire forest it lives in (Object) to come with it. It can be done, but generally you need a lot more glue code to make it work especially given the fact that people can get more creative with OOP. As you can see the MultiplicationObject is an example of this creativity. It was written with a different interface then the AdditionObject. Basically if you know haskell even similar issues to the above can be dealt with in terms of haskell. You can certainly define a composition operator for even the most complex types. The issue with OOP is that EVERYTHING is a complex type. A standard Object already has enough complexity to necessitate custom composition operators so you're basically writing custom glue code everywhere. Either you're writing complex glue code or your bending all your code to fit into a framework. Nothing is truly modular.

dnautics 6y ago

> oop being "wrong" ORMs that overload getters and setters as DB transactions: It creates a harmful illusion that the data inside the object are equally as authoritative as the data in the source of truth (as in database).

dpc_pw 6y ago
My take on ORMs (and OOP) is that they create a harmful illusion that data is just a bunch of "objects" that can be used in some abstract "reusable" way without care for the concrete form it have to be stored (relations, indices, collections/tables) to support efficient computation. See https://twitter.com/dpc_pw/status/1240719977071575040 https://twitter.com/dpc_pw/status/1240719977071575040 for how this works in practice.
- imtringued 6y ago
  If you ask Gavin King or other creators of ORMS their complaints is that they lower the barrier of entry so much that even people who know nothing about databases end up using them. A lot of people seem to have the impression that the ORM is supposed to solve all their problems when an ORM is more of a convenience thing. You have to know the limitations of your database and design your database structure based on those limitations first. Your domain objects (objects representing data in the database) are supposed to match the design of your database, not the other way around. People like to call this a leaky abstraction but I think it's far more boring. Know your tools (both the ORM and the database). It will be worth it. Don't hesitate to use raw SQL if the ORM doesn't play along.