
Functional programming in object oriented languages - jamesbritt
http://www.harukizaemon.com/2010/03/functional-programming-in-object-oriented-languages.html
======
j_baker
One important thing to point out: functional programming and object-oriented
programming aren't necessarily mutually exclusive. Scala, OCaml, and a lot of
Lisps have proven that. Whether it's a _good idea_ is another question
entirely, but the point is that it can be done.

~~~
Silhouette
> One important thing to point out: functional programming and object-oriented
> programming aren't necessarily mutually exclusive.

I'm not sure that's true.

The essence of functional programming is treating a program as evaluating a
function without carrying around state, a declarative approach that promotes
things like pure functions and referential transparency.

The essence of object-oriented programming is passing messages between objects
with identity, state and behaviour, an imperative approach and one that
fundamentally relies on late binding at run-time.

Aren't these styles mutually exclusive?

Of course, you can have tools _representative_ of both styles, such as higher
order functions and abstract data types, in the same language; the languages
you mentioned all do. But whatever merit the resulting hybrid programming
style may have, I'm not sure that style is properly called either functional
or object-oriented programming.

~~~
j_baker
"The essence of functional programming is treating a program as evaluating a
function without carrying around state"

Isn't a closure a function that carries around state? There's an old tale
about this:

"The venerable master Qc Na was walking with his student, Anton. Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
objects are a very good thing - is this true?" Qc Na looked pityingly at his
student and replied, "Foolish pupil - objects are merely a poor man's
closures."

Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures. He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small Scheme
interpreter with a closure-based object system. He learned much, and looked
forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying
"Master, I have diligently studied the matter, and now understand that objects
are truly a poor man's closures." Qc Na responded by hitting Anton with his
stick, saying "When will you learn? Closures are a poor man's object." At that
moment, Anton became enlightened."

[http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/m...](http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/msg03277.html)

~~~
Silhouette
> Isn't a closure a function that carries around state?

Well, that's the question, isn't it?

In our present context, to me "state" suggests something persistent and
independent, something that could be read and possibly written by multiple
paths.

Do you view creating a closure as customising an existing function with
specific data, or as defining a whole new function? I think of it as the
latter, and it just happens to be at run-time. The resulting function is still
pure, and any customisation based on particular data is an integral part of it
that isn't externally visible, which doesn't feel "stateful".

------
yason
There are so many facets in object-orientedness and you can ignore many of
them and still have something that's clearly object-oriented.

For example, object-oriented doesn't mean you have to store all your state in
objects and that objects must thus be mutable. You can, for example, return
new objects of the same kind with new, modified state.

------
moultano
I can't imagine this would work out well if he had to do his own memory
management.

~~~
zaphar
What would memory management have to do with it? That seems orthogonal to his
point.

~~~
btilly
If you have to do your own memory management the first thing people reach for
is reference counting. Reference counting means maintaining state and directly
contradicts immutable objects.

So immutable objects only really work if you've got some kind of garbage
collection available.

~~~
yason
Maintaining mutable metadata for objects doesn't preclude having immutable
objects. The object's value doesn't change when someone wants to inc/dec its
refcount.

~~~
btilly
The strategy discussed involved lots of creating new objects that were the
same as an old object but with one more piece of data. If you're using a
reference counting implementation then every one of those methods needs to
know about, and adjust, all of the reference counts that the object points to.
This kind of busy accounting work is error-prone, and does a lot to undo the
simplicity that you're trying to achieve with this methodology.

