Functions vs OOP

[William Gill]

During some recent research, and re-familiarization with Python, I came
across documentation that suggests that programming using functions, and
programming using objects were somehow opposing techniques.

It seems to me that they are complimentary. It makes sense to create
objects and have some functions that take those objects as arguments.
Are they suggesting that any function that takes an object as an
argument should always be a method of that object? Conversely I can see
creating functions that take raw input (e.g. strings) and return it in a
format compatible with an object's constructor, rather than have objects
accept any conceivable format for its constructor.

Am I missing something, or am I taking things too literally?

 

[Steven D'Aprano]

During some recent research, and re-familiarization with Python, I came
across documentation that suggests that programming using functions, and
programming using objects were somehow opposing techniques.

It seems to me that they are complimentary. It makes sense to create
objects and have some functions that take those objects as arguments.

Python is a mixed paradigm language, with object, functional and imperative
paradigms.

Are they suggesting that any function that takes an object as an
argument should always be a method of that object?
Yes.

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

[...]
Am I missing something, or am I taking things too literally?

No, it is the OO purists who are missing something.

 

[MRAB]

During some recent research, and re-familiarization with Python, I
came across documentation that suggests that programming using
functions, and programming using objects were somehow opposing
techniques.

It seems to me that they are complimentary.

I think you mean "complementary".

It makes sense to create objects and have some functions that take
those objects as arguments. Are they suggesting that any function
that takes an object as an argument should always be a method of that
object? Conversely I can see creating functions that take raw input
(e.g. strings) and return it in a format compatible with an object's
constructor, rather than have objects accept any conceivable format
for its constructor.

Am I missing something, or am I taking things too literally?

I think that it's all about "state".

In functional programming, there's no state; a function's result
depends solely on its arguments, so it will always return the same
result for the same given arguments.

In OOP, on the other hand, an object often has a state; a method may
return a different result each time it's called, even for the same
given arguments.

 

[Ian Kelly]

During some recent research, and re-familiarization with Python, I came
across documentation that suggests that programming using functions, and
programming using objects were somehow opposing techniques.

It seems to me that they are complimentary.  It makes sense to create
objects and have some functions that take those objects as arguments. Are
they suggesting that any function that takes an object as an argument should
always be a method of that object?  Conversely I can see creating functions
that take raw input (e.g. strings) and return it in a format compatible with
an object's constructor, rather than have objects accept any conceivable
format for its constructor.

Am I missing something, or am I taking things too literally?

I think you may be confusing "functional programming" and "programming
using functions". These are not the same thing.

Functional programming is about using functions in the *mathematical*
sense. A mathematical function maps one value (or tuple of values) to
another value. The mapped value never varies; if it did, it would be
a different function. So functional programming eschews the use of
functions where the results depend on any internal or external state
beyond the values of the passed-in arguments, such as the variable
state of the object the method is being called on.

Functional programming and OOP are not entirely opposed -- for
example, string methods in Python such as str.upper are perfectly
functional, since strings are immutable. Many functional languages
such as Common LISP also have powerful OOP facilities. Still,
functional programming does not fit well with the traditional OOP
model of objects passing messages to other objects, which generally
implies statefulness.

Cheers,
Ian

 

[Terry Reedy]

Ours, or someone else's?

Python is a mixed paradigm language, with object, functional and imperative
paradigms.

Or of the class of the object.

Yes.
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Since in Python, everything is an object, that would mean that every
function has to be a method, which would mean creating classes just to
have a class to attach functions to. How awful. (Oh, right, I believe I
just described Java.)

No, it is the OO purists who are missing something.

Yes, Python.

 

[William Gill]

I think you mean "complementary".

How polite of you to point out my spelling deficiency. I guess
shouldn't be watching football while typing (I'm sure the beer didn't
help either).

I think that it's all about "state".

In functional programming, there's no state; a function's result
depends solely on its arguments, so it will always return the same
result for the same given arguments.

In OOP, on the other hand, an object often has a state; a method may
return a different result each time it's called, even for the same
given arguments.

I think you mean "it [sic, a function] will "return the same result for
the same given values..."

x=1
y= myFn(x)

will return the same result as

y= myFn(1)

A method may use an attribute as an implicit argument, and that
attribute's value change, just like the value of x (above) may change.
It may or may not return anything (it may just modify an attribute).

The question wasn't about encapsulation, it was about programming
paradigms, and if they conflict.

As was pointed out elsewhere, I may have just confused "functional
programming" with "programming using functions".

 

[William Gill]

I think you may be confusing "functional programming" and "programming
using functions". These are not the same thing.

I think you may be right, Ian. It didn't make much sense

 

[William Gill]

Ours, or someone else's?
Python.


Since in Python, everything is an object, that would mean that every
function has to be a method, which would mean creating classes just to
have a class to attach functions to. How awful.

Exactly why I asked, but I realize the the mistake was mine. I think
they were talking about "functional programming" not "using functions in
an OO program."

 

[William Gill]

Can you show exactly where in the Python documentation you found the
passage which confused you?

Sorry, no. I tried to locate the exact reference again, and couldn't
remember where I read it (short term memory problems).

 

[Terry Reedy]

Exactly why I asked, but I realize the the mistake was mine. I think
they were talking about "functional programming" not "using functions in
an OO program."

It is possible that our doc was less than crystal clear. We are
constantly improving it where we can see fixable faults. If you run
across whatever it was and it still seems a bit muddy, post something again.

 

[William Gill]

It is possible that our doc was less than crystal clear. We are
constantly improving it where we can see fixable faults. If you run
across whatever it was and it still seems a bit muddy, post something
again.

Will do.

Thanks.

 

[tinnews]

I think you may be confusing "functional programming" and "programming
using functions". These are not the same thing.

Functional programming is about using functions in the *mathematical*
sense. A mathematical function maps one value (or tuple of values) to
another value. The mapped value never varies; if it did, it would be
a different function. So functional programming eschews the use of
functions where the results depend on any internal or external state
beyond the values of the passed-in arguments, such as the variable
state of the object the method is being called on.

I think there may be another issue here. If someone says "functional
programming" to me then I would generally assume that they *do* mean
"programming using functions". While your distinction of the two may
be strictly correct I don't think it's the generally accepted meaning.

 

[Steven D'Aprano]

I think there may be another issue here. If someone says "functional
programming" to me then I would generally assume that they *do* mean
"programming using functions".

Strictly speaking you are correct, "functional programming" does
mean "programming using functions", the usual name for which is "procedural
programming". But it means more than that: functions in the sense of
mathematical functions, not merely sub-routines.

http://en.wikipedia.org/wiki/Functional_programming

Merely using functions is not the same as functional programming.

While your distinction of the two may
be strictly correct I don't think it's the generally accepted meaning.

On the contrary, "functional programming" specifically refers to languages
derived from, based on, or at least inspired by, the ideas of Alonzo
Church's lambda calculus. It should be understood as somewhat in opposition
to the idea of imperative programming, where the programmer gives
instructions for changing program state.

http://en.wikipedia.org/wiki/Programming_paradigm

In practice, there are degrees of purity: strictly speaking, a purely
functional language would be impractical, because it would have no I/O and
therefore not be very useful. But generally, functional programming
implies:

- all coding is done using functions
- functions are first-class data values
- higher-order functions are used (functions which take functions as
arguments)
- no global variables
- all data is immutable (cannot be modified)
- functions should always return the same result each time they are called
with the same arguments (so-called "referential transparency")
- computations should be performed lazily as needed
- no side-effects other than those caused by hardware limitations (e.g.
there is only a finite amount of memory available), usually with an
exemption made for I/O
- use of recursion instead of imperative features such as iteration (for
loops, while loops, etc.)


Pure functional programming languages enforce those conventions as design
features, rather than just leaving it up to the coder to apply them as a
convention. Impure functional languages, such as Python, don't enforce all
(or even any) of those conditions, although they may provide certain
functional features.

 

[rusi]

During some recent research, and re-familiarization with Python, I came
across documentation that suggests that programming using functions, and
programming using objects were somehow opposing techniques.

Staying with (for the moment) the suggestion that OO-P and F-P are
complementary, I believe it is worthwhile to distinguish syntactic OO-
P vs F-P from semantic OO-P vs F-P.

Syntactically: f(x) is functional x.f() is object oriented.
Semantically if f's return value depends only on x ie does not depend
on state it is functional (in the math sense) -- the jargon is that f
is referentially transparent.

Referential opaqueness is usually such a source of problems that it
turns out good to contain the problem somewhat -- hence the wish for
encapsulation.

One can find in the python library itself all 4 combinations:
syntactically and semantically OO : sort
syntactically and semantically FP: sorted
syntactically OO semantically FP: join

 

[Terry Reedy]

I think there may be another issue here. If someone says "functional
programming" to me then I would generally assume that they *do* mean
"programming using functions". While your distinction of the two may
be strictly correct I don't think it's the generally accepted meaning.

The distintion drawn by Ian *is* generally accepted in computer science. See
https://secure.wikimedia.org/wikipedia/en/wiki/Functional_programming
For instance, programming is C is imperative programming with functions
but it generally is not 'functional programming' in the sense referred
to by Ian and the Wikipedia article. Given that our docs are written by
people who do understand the technical distinction, you are probably
wrong to assume otherwise.

However, as I said to William, it is possible that our docs could be
improved so as to not depend on all readers having prior knowledge of
the intended meaning of 'functional programming'. As the use of Python
has expanded, so has the variety of backgrounds of Python programmers.

 

[William Gill]

The distintion drawn by Ian *is* generally accepted in computer science.
See
https://secure.wikimedia.org/wikipedia/en/wiki/Functional_programming
For instance, programming is C is imperative programming with functions
but it generally is not 'functional programming' in the sense referred
to by Ian and the Wikipedia article. Given that our docs are written by
people who do understand the technical distinction, you are probably
wrong to assume otherwise.

However, as I said to William, it is possible that our docs could be
improved so as to not depend on all readers having prior knowledge of
the intended meaning of 'functional programming'. As the use of Python
has expanded, so has the variety of backgrounds of Python programmers.

Since I am the one who opened this can of worms, and since I believe I
have relocated the document that I misinterpreted, I feel compelled to
jump in here.

The source of my error is "Functional Programming HOWTO
(/python-3.1.3-docs-html/howto/functional.html)"

Having arrived at this page indirectly (searching for and skimming other
information regarding functions and methods) I was only half paying
attention. As a result I made the same mistake Chris did.

As a point of reference, I would not call myself a programmer, and any
formal exposure was many, many years ago. I am familiar with the
concepts of procedural, declarative, and object-oriented programming,
but not functional. At least not in this context.

Having done a little more digging I now understand the difference.
"Functional programming" is the proper terminology, and had I come
across it from another direction, or with a more deliberate focus I
probably wouldn't have made the initial mistake.

If you read the material with even a nominal understanding of the
functional paradigm (functional relationships in a mathematical sense,
not functions in the procedural sense), it is clear. If you read it
without consciously recognizing this difference, the material does
nothing to alert you to the initial error.

 

[Steven D'Aprano]

The source of my error is "Functional Programming HOWTO
(/python-3.1.3-docs-html/howto/functional.html)"

For those who don't have access to William's local file system, I expect
he's looking at this:

http://docs.python.org/release/3.1.3/howto/functional.html

or the most recent version:

http://docs.python.org/dev/howto/functional.html


[...]

If you read the material with even a nominal understanding of the
functional paradigm (functional relationships in a mathematical sense,
not functions in the procedural sense), it is clear. If you read it
without consciously recognizing this difference, the material does
nothing to alert you to the initial error.

What about the entire "Introduction" section, which starts with this
statement?

"This section explains the basic concept of functional programming"

If you would like to suggest improvements, please do so.

 

[William Gill]

For those who don't have access to William's local file system, I expect
he's looking at this:

http://docs.python.org/release/3.1.3/howto/functional.html

or the most recent version:

http://docs.python.org/dev/howto/functional.html

I didn't expect anyone to access my file system so I trimmed the path,
but left enough for an industrious soul like yourself to figure it out.
You did, so it seems I was correct, or do you think "functional.html"
would have been sufficient? ;-)

[...]

If you read the material with even a nominal understanding of the
functional paradigm (functional relationships in a mathematical sense,
not functions in the procedural sense), it is clear. If you read it
without consciously recognizing this difference, the material does
nothing to alert you to the initial error.

What about the entire "Introduction" section, which starts with this
statement?

"This section explains the basic concept of functional programming"

Which clears up the misunderstanding, how? Unless the target audience
is people who already understands "the basic concept of functional
programming." That seems like a circular reference.

The article is introducing a concept. To assume any familiarity with
that concept as a basis, is not an introduction.

As previously stated; I was already familiar with the concepts of
procedural, declarative, and object-oriented programming, but not
functional programming. Nothing I read (I'll be honest; scanned) did
anything to contradict my incorrect point of reference.

If you would like to suggest improvements, please do so.

How about a caveat stating something like "NOTE: functional as in
mathematical functions, not to be confused with functions/procedures."

 

[Chris Angelico]

http://docs.python.org/dev/howto/functional.html

What about the entire "Introduction" section, which starts with this
statement?

"This section explains the basic concept of functional programming"

If you would like to suggest improvements, please do so.

Well, it does invite you to skip that whole section

Since you asked, though, the copyeditor in me does want to suggest one
small tweak:

Second paragraph after the bullet list ends "Avoiding side effects
means not using data structures that get updated as a program runs;
every function’s output must only depend on its input." - I'd word it
as "must depend only on". Pretty immaterial, but the formal style
prefers correctness.

Somewhat more significant: Under "Modularity", may be of value to add
a paragraph about parallelism.

With functional code, it's easy for an interpreter to ascertain which
functions depend on each other (because one's return value is
another's input). Independent functions can be run in parallel without
affecting the result; the interpreter can therefore divide a complex
task across multiple CPUs without any work from the programmer.

Like I said, it's just "since you asked". The above paragraph is
hereby given out as public domain, use it (edit it, whatever) under
whatever license the Python docs require.

ChrisA

 

[William Gill]

Staying with (for the moment) the suggestion that OO-P and F-P are
complementary, I believe it is worthwhile to distinguish syntactic OO-
P vs F-P from semantic OO-P vs F-P.

Syntactically: f(x) is functional x.f() is object oriented.
Semantically if f's return value depends only on x ie does not depend
on state it is functional (in the math sense) -- the jargon is that f
is referentially transparent.

Not to split hairs, but syntactically f(x) is a function in many
programming paradigms.

As I understand it functional programming places specific requirements
on functions, i.e.referential transparency. So f(x) may or may not be
"functional".

x.f() is also a function, but it is a member of the object x, is
referred to as a 'method' of x, and uses the syntactical "dot" notation
object"dot"function for identification.