4 ms·

The OOP community fascinates me. It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea, yet the classic OOP languages go out of their wa

The OOP community fascinates me. It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea, yet the classic OOP languages go out of their way to support this kind of programming. Meanwhile the alternative approaches require you to jump through a bunch of hoops or apply convoluted "design patterns". Writing good, modern "OOP" you are often fighting the OOP language! Things are getting somewhat better (e.g. Java Record types) but perhaps it is time to admit these languages just aren't a good fit?

fabian2k 4y ago
The only real difference is that inheritance as explicit language support while composition is something you can easily implement with common language features. It's not really more difficult to use composition than inheritance. As an example, if I want to use composition in C# using ASP.NET, I simply inject the class I want to use into my new class using the built-in DI. This is as simple as extending the class.
- substation13 4y ago
  Some features are plain missing (or must be implemented in a convoluted manner): - Discriminated unions - Immutable data types (records) - Free functions (or modules of free functions) - Software transactional memory (STM), atoms - Ad-hoc polymorphism (traits) - Custom operators (used sparingly for building DSLs) - List comprehensions Instead we get anti-features like automatic properties, implementation inheritance, events, object initializers, etc...
  - tester756 4y ago
    >(records) there are >- List comprehensions Enumerable.Range? >- Custom operators (used sparingly for building DSLs) Could you please show what kind of DSL you'd want to write?
    - substation13 4y ago
      >(records) Agreed, although this a recent addition in Java and a step away from old school OOP >- List comprehensions Enumerable.Range is not equivalent to list comprehensions. For example, in F# you can build a list using a comprehension containing more or less any code you like. It's incredibly powerful for things like building HTML. >- Custom operators (used sparingly for building DSLs) These are used in many places, but to give one example https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jones/contracts.pdf https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...
lmm 4y ago
It suits cases (e.g. modelling business logic) where you have that kind of edge case. Until recently non-OO languages had very little support for delegation, and so while inheritance bundles delegation with some other things it really shouldn't be bundled with, it was often the least-bad option. In particular this made it a natural fit for GUI, where you very often want "this widget is almost like this one, except...", and so it was able to ride the coattails of that. Add on the fact that people somehow seem to think Alan Kay has some insights (even if they can never tell you what they are), and Bob's your uncle.
- substation13 4y ago
  > non-OO languages had very little support for delegation, What do you mean by "delegation" here?
  - lmm 4y ago
    I mean something like "this value contains this kind of value and implements the same interface as it by forwarding methods to the corresponding methods on that". E.g. https://kotlinlang.org/docs/delegation.html https://kotlinlang.org/docs/delegation.html . (i.e. imagine doing something similar to inheritance but having the "parent" object be explicitly a field of your child object rather than just mushed together with it).
    - substation13 4y ago
      Ah I see. What you say is not quite true though, ad-hoc polymorphism (traits) provides the same functionality for non-OOP languages. > Until recently non-OO languages had very little support for delegation
      - lmm 4y ago
        > ad-hoc polymorphism (traits) provides the same functionality for non-OOP languages. No they don't. Show me how you'd do that in e.g. Haskell. And note that Rust has `delegate` as a macro even though it has a trait system.
tgv 4y ago
> It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea It's not a bad base for UI programming. There is quite a lot of functionality that is suited to the OOP paradigm.
everyone 4y ago
It's really not. For example C# has no guiding principles imo. It's just a hodgepodge of any and all popular language features all lumped together. Java was popular at its inception so it stole lots of Java, as new things have become popular they are added (eg. anonymous functions) As a dev you just use whatever features u like and can safely ignore the majority of them. Its very non-prescriptive unlike some languages where you must do a thing only one way. Eg. Inheritance is pretty much terrible, I just never use it. Same way I try to not write bad code and instead write good code. Also sure you need to put functions in classes, but thats fine, classes are just buckets for code. In any language you need to put your functions somewhere eg. in a text file.

fabian2k 4y ago

The only real difference is that inheritance as explicit language support while composition is something you can easily implement with common language features. It's not really more difficult to use composition than inheritance. As an example, if I want to use composition in C# using ASP.NET, I simply inject the class I want to use into my new class using the built-in DI. This is as simple as extending the class.

substation13 4y ago
Some features are plain missing (or must be implemented in a convoluted manner): - Discriminated unions - Immutable data types (records) - Free functions (or modules of free functions) - Software transactional memory (STM), atoms - Ad-hoc polymorphism (traits) - Custom operators (used sparingly for building DSLs) - List comprehensions Instead we get anti-features like automatic properties, implementation inheritance, events, object initializers, etc...
- tester756 4y ago
  >(records) there are >- List comprehensions Enumerable.Range? >- Custom operators (used sparingly for building DSLs) Could you please show what kind of DSL you'd want to write?
  - substation13 4y ago
    >(records) Agreed, although this a recent addition in Java and a step away from old school OOP >- List comprehensions Enumerable.Range is not equivalent to list comprehensions. For example, in F# you can build a list using a comprehension containing more or less any code you like. It's incredibly powerful for things like building HTML. >- Custom operators (used sparingly for building DSLs) These are used in many places, but to give one example https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jones/contracts.pdf https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...

lmm 4y ago

It suits cases (e.g. modelling business logic) where you have that kind of edge case. Until recently non-OO languages had very little support for delegation, and so while inheritance bundles delegation with some other things it really shouldn't be bundled with, it was often the least-bad option. In particular this made it a natural fit for GUI, where you very often want "this widget is almost like this one, except...", and so it was able to ride the coattails of that. Add on the fact that people somehow seem to think Alan Kay has some insights (even if they can never tell you what they are), and Bob's your uncle.

substation13 4y ago
> non-OO languages had very little support for delegation, What do you mean by "delegation" here?
- lmm 4y ago
  I mean something like "this value contains this kind of value and implements the same interface as it by forwarding methods to the corresponding methods on that". E.g. https://kotlinlang.org/docs/delegation.html https://kotlinlang.org/docs/delegation.html . (i.e. imagine doing something similar to inheritance but having the "parent" object be explicitly a field of your child object rather than just mushed together with it).
  - substation13 4y ago
    Ah I see. What you say is not quite true though, ad-hoc polymorphism (traits) provides the same functionality for non-OOP languages. > Until recently non-OO languages had very little support for delegation
    - lmm 4y ago
      > ad-hoc polymorphism (traits) provides the same functionality for non-OOP languages. No they don't. Show me how you'd do that in e.g. Haskell. And note that Rust has `delegate` as a macro even though it has a trait system.

tgv 4y ago

> It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea It's not a bad base for UI programming. There is quite a lot of functionality that is suited to the OOP paradigm.

everyone 4y ago

It's really not. For example C# has no guiding principles imo. It's just a hodgepodge of any and all popular language features all lumped together. Java was popular at its inception so it stole lots of Java, as new things have become popular they are added (eg. anonymous functions) As a dev you just use whatever features u like and can safely ignore the majority of them. Its very non-prescriptive unlike some languages where you must do a thing only one way. Eg. Inheritance is pretty much terrible, I just never use it. Same way I try to not write bad code and instead write good code. Also sure you need to put functions in classes, but thats fine, classes are just buckets for code. In any language you need to put your functions somewhere eg. in a text file.