Lambda the Ultimate

I think this is interesting claim, especially for LtU readers, because if we accept it, the distinction we often draw between OOP and FP would cease to exist; both use encapsulation as a core part of their "paradigm".

The one remaining difference would be the degree to which statefulness is required or assumed.

I think one of the things that this paper reminds us of is that the OO hype existed primarily in relation to the "spaghetti" programming that was the norm not that long ago.

This might allow us to sharpen the usual OO vs FP discussion: they are both "encapsulation oriented" programming, but OO tries to encapsulate state changes via a coalgebraic model, and FP tries to encapsulate successive layers of stateless structures via an algebraic model.

I think this is where we have been getting anyway (thanks to Frank and Bart Jacobs), but perhaps nuking the terms "OO" and "FP" might help us to avoid misunderstandings arising from red-herrings like inheritence, polymorphism, etc.

AEOP (Algebraic Encapsulation Oriented Programming) and CEOP (Coalgebraic Encapsulation Oriented Programming) anyone? ;-)

(Better names and acronyms would be much appreciated if anyone has any ideas. ;-) )

I guess you mean polymorphism in the usual OO sense (messages/generic functions). Could you elaborate on this point, because I don't think I follow?

"Polymorphism" is usualy trotted out as a defining characteristic of OOP.

What this term means exactly seems to vary depending on who you talk to.

Regardless of the specific definition, an equivalent property can (and usually does) exist in a given FPL, so I'm claiming it is a red-herring for distinguishing between OO and FP.

If you strip away the details of inheritence (a new, more specific entity can be used where an old more general entity was already), it is equally unhelpful as a distinguishing feature between OO and FP.

I'm re-reading the latest version of Friedmans's OO Style paper, and I think he effectively makes the case that OO Style is possible in any language that has both first-class closures and statefulness.

By bialgebraic, do you mean combining algebraic and co-algebraic models?

Wouldn't that just be an impure FPL? ;-)

I think that the reason the bialgebraic approach hasn't caught on yet is the difficulty of programming using existential types in functional languages. ML offers pretty good support for parametric polymorphism, but its support for existential quantification is much more limited. Haskell lets you simulate existentials using higher-rank polymorphism, but maybe that's too exotic for most people? It seems like people just use runST and don't think about it any further. (Frank, or other serious Haskell users, please comment.)

I'm re-reading the latest version of Friedmans's OO Style paper, and I think he effectively makes the case that OO Style is possible in any language that has both first-class closures and statefulness.

I tend to believe that inheritance is unmanagable for anything other than toy projects. Therefore Friedmans analysis is not exactly my cup of tea. Otherwise, I think it's a great job of showing that objects are just gobs of recursion :-)

Wouldn't that just be an impure FPL? ;-) No, it would be 100% pure BAPL ;-)

<troll> Calling co-algebraic aspects "impure" is not very politically correct, and somehow implies they are inferior to algebraic. Even the word "co-algebraic" is a derivative of "algebraic". This cannot be tolerated. Emancipate objects! </troll>

There's Martin Erwig's paper "Categorical Programming with Abstract Data Types", which talks about using the bialgebraic approach. This is a great paper, although a bit tough for me... I will need to re-read it some day, IIRC it was related to "Theorems for Free"? In the sense that programs are uniquely determined by their types? It's very sad we are not taught such ideas in schools :-(

But this post is becoming an off-topic, suitable at best for "Education" category...