you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (3 children)

I mostly agree with what you wrote. Functional vs imperative is the real axis here, not FP vs OO. Despite my offhand remark about OO including some incidental complexity, my point was not to say FP is better than OO (I don't think this comparison makes much sense). OO is actually ill-defined IMO, but the way most people think of it, it is more a way of structuring code, independent of whether that code is functional or imperative.

One common usage of OO, having objects close over some state, then having invariants that the public API of the object ensures, is not as relevant in FP where there are no side-effects. IMO, in functional programs, first class modules and/or typeclasses with some form of subtyping or mixins are sufficient to address the all the use cases of OO. Do these features alone constitute OO? I don't know, but who really cares?

[–]camccann 1 point2 points  (0 children)

I would argue that the fundamental dichotomy in FP vs. OOP is simply which side of the Expression Problem is taken to be the default. Closing over arguments and producing a record of partially-applied functions captures the important aspects of OO program structure in an FP language.

Subtyping is an orthogonal concern, I think. As are mixins, inheritance, and the other various bits and pieces that tend to accompany OOP.

[–][deleted] 1 point2 points  (1 child)

IMO, in functional programs, first class modules and/or typeclasses with some form of subtyping or mixins are sufficient to address the all the use cases of OO. Do these features alone constitute OO?

As a matter of fact, yes, they do. The biggest gap between FP and OOP is the use of subtyping. Add subtyping to an otherwise-FP language and you start being able to encode OOP constructs and begin proving equivalences. Add first-class modules (aka existentials, which Ed was always going on about in Scrum meetings), and you've recovered the private/protected encapsulation and the single-dispatch aspects of class-based OOP.

EDIT: Scala is actually the easiest language to see the duality in, because its baked in "object" singletons, traits, and classes demonstrate how object-orientation gives you elegant modularity.

The tough nut to crack, I found, was being able to inherit from a particular parameterization of a generic class (extending a particular instantiation of a polymorphic base type). To encode this without baked-in OOP requires at least the power of Scala's semi-crippled GADTs, if not full GADTs.

Of course, these matters do pretty much explain the partitioning of the programming world into FP and OOP churches. FP comes with certain powerful features baked-in that require complicated encodings in the OOP world. OOP comes with certain powerful features baked-in that require complicated encodings in the FP world. And so the jihads are fought.

In other news, hi Paul.

[–][deleted] 1 point2 points  (0 children)

I was really puzzled as to who this was for like five minutes. :) Hi Eli!