5 ms·

When you maximize the number of pure methods, minimize mutable state, minimize inheritance and so on, you are doing OOP well. But when you write that style of

When you maximize the number of pure methods, minimize mutable state, minimize inheritance and so on, you are doing OOP well. But when you write that style of OOP, what's the advantage over a non-OOP language that is immutable by default, uses just functions, and provides constructor (in the FP sense) hiding to maintain invariants? To me, it seems that it only has disadvantages: team members can still write mutable, reference/pointer leaking horrors.

agumonkey 11y ago
I was about to comment that SQL normalization and functional programming (even in diluted form through closure friendlyjavascript) taught me OOP more than OOP itself. There are deep principles that overrule paradigms and they're rarely explained via OOP.
- arunix 11y ago
  What are those deep principles?
  - agumonkey 11y ago
    Factorization of logical dependencies (normalization) is a generic form of object modeling. Logical regression over function yields combinators. (like how one derives Y from factorial) Thinking in terms of properties instead of memory, unless you reach interface only OOP you don't do it (OOP in the Java/UML sense gives you rope to bike shed to no end, effectful constructors, is it composition, aggregation ... a never ending well) The notion of eta conversion, that I see as a generalized form of 'unnecessary wrapping' (if true then true else false and such) that is clean and well expressed in FP and full of bolts in Java (anonymous classes are too verbose, .Net had delegates for this I believe but it's named as yet another kind instead of an equivalence). Linked to reliance on temporaries instead of combinators a = f .. b = g a c = k c return c instead of simply (k . g . f) a (or a |> g |> ... for reading order ) ps: I encourage people to read books like Programming in Haskell from Graham Hutton (this book deals with average problems, not too sophisticated alienating ideas) to get a feel on how so many things can be re-expressed as composition.
alkonaut 11y ago
> But when you write that style of OOP, what's the advantage over a non-OOP language that is immutable by default I think there is no advantage to using an OOP language with mutability by default, over not doing so. (The only advantages are circumstantial -- the most common are probably that the existing code is OO, or that the existing devs are OO, or any devs we can find are OO, or the company is a shop that has always done OO, etc. ). I didn't say that all state should be immutable. Sometimes you actually must have mutable state (e.g. in a large scale game engine or scientific app where performance and cache is king, you likely do want to modify in place, which is hard to do with immutable abstractions over the data). The trick is to use as little mutable state as possible for the task at hand. I certainly hope most new statically typed languages will not use mutable by default. Rust is a good example. Rust does most of what OO and FP does well, but does it without actually being either FP or OO in the normal sense.
Patient0 11y ago
My experience of OO programming - by the end I found the following style worked best: -> always using pure abstract base classes -> constructed those implementations using factories (which in turn, were pure abstract base classes) -> almost always made my implementations immutable which after a while, I realised, was just functional programming with more boiler-plate.
- tracker1 11y ago
  Not mutable, but tethered state, I think OO/Objects/Classes work slightly better when used as a means of tethering state/presentation/events... not that they need to mutate... for example the React.Component via ES6-style classes doesn't bug me as much as some... but I use it sparingly, most of the rest is more functional.
lmm 11y ago
* Ad-hoc polymorphism is valuable, and objects represent a clear way to express it * Thin wrappers that slightly change functionality are often a business requirement, and "extends" inheritance provides an easy way to express them * Having data associated directly with the corresponding state can make exploratory programming easier (e.g. suppose I have a library for accessing the Facebook API, so I fetch my user info. In OO style it's immediately clear what I can do with my user info, because it's all methods on the object; in functional style it's less clear)
- alkonaut 11y ago
  > Thin wrappers that slightly change functionality are often a business requirement I doubt that a business requirement stipulates how something is implemented, but thin extensions are often an apparently convenient way of quickly getting the slightly different behavior of the business requirement. Whether or not it's a good idea just because it is quick and convenient I think isn't clear. From a business perspective this is one of the false benefits -- if the problem is apparently solved quickly, but the maintenance is harder afterwards, it may not be the best idea. I'd bet sum types + common pure functionality accomplishes the same thing with lower maintenance cost. > Having data associated directly with the corresponding state can make exploratory programming easier I agree that many functional languages have definite drawbacks in terms of exploratory and self documenting programming. "Methods" on types are to me a definite requirement also for an FP language because of autocomplete/documentation/ergonomics. To , me writing v2 = Vector.normalize(v1) is vastly inferior to v2 = v1.normalize(). This is syntactic sugar of course, but important sugar. Neither is "OO" though: associating methods as postfix can be done regardless.
  - lmm 11y ago
    > I'd bet sum types + common pure functionality accomplishes the same thing with lower maintenance cost. Not my experience - most functional languages make it much harder than it should be to say "this is exactly an X except that it prints differently". > I agree that many functional languages have definite drawbacks in terms of exploratory and self documenting programming. "Methods" on types are to me a definite requirement also for an FP language because of autocomplete/documentation/ergonomics. To , me writing v2 = Vector.normalize(v1) is vastly inferior to v2 = v1.normalize(). This is syntactic sugar of course, but important sugar. Neither is "OO" though: associating methods as postfix can be done regardless. Well, if a feature is present in all mainstream "OO" languages and not in any mainstream "functional" languages then I'll call it "OO". I'd be very interested to see a functional language with good support for this kind of thing though.

agumonkey 11y ago

I was about to comment that SQL normalization and functional programming (even in diluted form through closure friendlyjavascript) taught me OOP more than OOP itself. There are deep principles that overrule paradigms and they're rarely explained via OOP.

arunix 11y ago
What are those deep principles?
- agumonkey 11y ago
  Factorization of logical dependencies (normalization) is a generic form of object modeling. Logical regression over function yields combinators. (like how one derives Y from factorial) Thinking in terms of properties instead of memory, unless you reach interface only OOP you don't do it (OOP in the Java/UML sense gives you rope to bike shed to no end, effectful constructors, is it composition, aggregation ... a never ending well) The notion of eta conversion, that I see as a generalized form of 'unnecessary wrapping' (if true then true else false and such) that is clean and well expressed in FP and full of bolts in Java (anonymous classes are too verbose, .Net had delegates for this I believe but it's named as yet another kind instead of an equivalence). Linked to reliance on temporaries instead of combinators a = f .. b = g a c = k c return c instead of simply (k . g . f) a (or a |> g |> ... for reading order ) ps: I encourage people to read books like Programming in Haskell from Graham Hutton (this book deals with average problems, not too sophisticated alienating ideas) to get a feel on how so many things can be re-expressed as composition.

alkonaut 11y ago

> But when you write that style of OOP, what's the advantage over a non-OOP language that is immutable by default I think there is no advantage to using an OOP language with mutability by default, over not doing so. (The only advantages are circumstantial -- the most common are probably that the existing code is OO, or that the existing devs are OO, or any devs we can find are OO, or the company is a shop that has always done OO, etc. ). I didn't say that all state should be immutable. Sometimes you actually must have mutable state (e.g. in a large scale game engine or scientific app where performance and cache is king, you likely do want to modify in place, which is hard to do with immutable abstractions over the data). The trick is to use as little mutable state as possible for the task at hand. I certainly hope most new statically typed languages will not use mutable by default. Rust is a good example. Rust does most of what OO and FP does well, but does it without actually being either FP or OO in the normal sense.

Patient0 11y ago

My experience of OO programming - by the end I found the following style worked best: -> always using pure abstract base classes -> constructed those implementations using factories (which in turn, were pure abstract base classes) -> almost always made my implementations immutable which after a while, I realised, was just functional programming with more boiler-plate.

tracker1 11y ago
Not mutable, but tethered state, I think OO/Objects/Classes work slightly better when used as a means of tethering state/presentation/events... not that they need to mutate... for example the React.Component via ES6-style classes doesn't bug me as much as some... but I use it sparingly, most of the rest is more functional.

lmm 11y ago

* Ad-hoc polymorphism is valuable, and objects represent a clear way to express it * Thin wrappers that slightly change functionality are often a business requirement, and "extends" inheritance provides an easy way to express them * Having data associated directly with the corresponding state can make exploratory programming easier (e.g. suppose I have a library for accessing the Facebook API, so I fetch my user info. In OO style it's immediately clear what I can do with my user info, because it's all methods on the object; in functional style it's less clear)

alkonaut 11y ago
> Thin wrappers that slightly change functionality are often a business requirement I doubt that a business requirement stipulates how something is implemented, but thin extensions are often an apparently convenient way of quickly getting the slightly different behavior of the business requirement. Whether or not it's a good idea just because it is quick and convenient I think isn't clear. From a business perspective this is one of the false benefits -- if the problem is apparently solved quickly, but the maintenance is harder afterwards, it may not be the best idea. I'd bet sum types + common pure functionality accomplishes the same thing with lower maintenance cost. > Having data associated directly with the corresponding state can make exploratory programming easier I agree that many functional languages have definite drawbacks in terms of exploratory and self documenting programming. "Methods" on types are to me a definite requirement also for an FP language because of autocomplete/documentation/ergonomics. To , me writing v2 = Vector.normalize(v1) is vastly inferior to v2 = v1.normalize(). This is syntactic sugar of course, but important sugar. Neither is "OO" though: associating methods as postfix can be done regardless.
- lmm 11y ago
  > I'd bet sum types + common pure functionality accomplishes the same thing with lower maintenance cost. Not my experience - most functional languages make it much harder than it should be to say "this is exactly an X except that it prints differently". > I agree that many functional languages have definite drawbacks in terms of exploratory and self documenting programming. "Methods" on types are to me a definite requirement also for an FP language because of autocomplete/documentation/ergonomics. To , me writing v2 = Vector.normalize(v1) is vastly inferior to v2 = v1.normalize(). This is syntactic sugar of course, but important sugar. Neither is "OO" though: associating methods as postfix can be done regardless. Well, if a feature is present in all mainstream "OO" languages and not in any mainstream "functional" languages then I'll call it "OO". I'd be very interested to see a functional language with good support for this kind of thing though.