Tell Above, and Ask Below: Hybridizing OO and Functional Design

I don't understand what "object/functional hybrid languages" means. Smalltalk-80 had functional features, built in to the core. So much so that there was no "if statement"; instead, you would pass a message to a boolean object with two functions, one for the iftrue case, and one for the iffalse case.

Interestingly, my immediate reaction was "well that's backwards" when I read this sentence: "Object-orientation is better for the higher levels of a system, and functional programming is better for the lower levels."

Then I realized that his argument makes lots of sense, so I reframed my thoughts on this.

My recent experience with Clojure has taught me that OO is very well suited for the few low level key abstractions, like Clojure's various reference types. Object orientation is great at maintaining an invariant, which is a key complexity management mechanism for dealing with mutation.

In a distributed system, you can view each node as a low-level mutable component of a bigger system. It's not the top of the entire system, it's the bottom of the communication and coordination system.

I guess that languages such as Smalltalk, Common Lisp and Python are all OO-functional rather than pure-OO or pure-functional. It works quite well in practice - whenever you have some simply-structured mutable state that's being worked on a lot (and where the intermediary states are not really interesting), then OO is going to float your boat. If you have complex-structured data that undergoes transformations into many different shapes (summing, projecting, mapping, extracting), then you want to use functional idioms. (I say "functional idioms" because, e.g., list comprehensions are a functional idiom but not conceptually tied to functional languages if you really think about it).

First of all I don't care how a library is written - what I care is only its interface. Functional is more black box - if the abstraction suits you then it is great. OO is more manipulable, adaptable - you can override methods, set state etc. I also suspect that imperative programming is more natural (think cooking recipes and other instructions how to make something). In many cases the optimal solution is to provide two APIs - a functional, simple one, that covers most of the cases - and an OO one for the cases when people need to adapt the solution (this is often related to providing good defaults: http://perlalchemy.blogspot.com/2012/04/breaking-problems-do...).

It is very nice if all you need is a simple function - and in that case sure you should use a library with functional API - but what if your needs are more complex? This is why I don't buy the "functional programming at the low level" idea.

The thing I would like to see is a way to mark a function as pure in imperative languages which would be checked by the compiler. That check would enforce that all variables are local and that no system function is called - but it could still call imperative code and also OO code that uses state manipulation - the only restriction would be that all that state is local (that is it is on the stack of the outer function that we mark as 'pure').

Kay's mob must agree. Their current research language, COLA, handles Smalltalk messages with Scheme methods. I haven't seen much code, but the screenshots are impressive.

"Object oriented" programming tends to conflate a lot of simultaneous ideas. You can use objects to represent a kind of declaratory style that meshes extremely well with FP, or to represent different implementations of a common interface (ditto), or you can have the kind of uber-stateful, side-effect-ridden file.open, file.read, file.close patterns that really clash with it.

Functional at lower levels, message-based and asynchronous at higher levels - isn't that Erlang, with Actors as Objects?