
Tell Above, and Ask Below: Hybridizing OO and Functional Design - johndcook
http://michaelfeathers.typepad.com/michael_feathers_blog/2012/03/tell-above-and-ask-below-hybridizing-oo-and-functional-design.html
======
billsix
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.

~~~
ajanuary
Isn't passing messages to boolean an OO concept, not a functional one?

Haskell98 defines if-then-else as a syntactic construct.

------
snprbob86
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.

~~~
dustingetz
> Object orientation is great at maintaining an invariant

i don't follow, can you say more?

~~~
snprbob86
<http://en.wikipedia.org/wiki/Class_invariant>

------
sqrt17
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).

------
zby
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...](http://perlalchemy.blogspot.com/2012/04/breaking-problems-down-and-
defaults.html)).

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').

------
thisrod
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.

------
fiatmoney
"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.

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

