Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #12703 > unrolled thread

Functions vs OOP

Back to article view | Back to comp.lang.python

Contents

  Functions vs OOP William Gill <noreply@domain.invalid> - 2011-09-03 12:15 -0400
    Re: Functions vs OOP Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-09-04 02:25 +1000
      Re: Functions vs OOP Terry Reedy <tjreedy@udel.edu> - 2011-09-03 15:15 -0400
        Re: Functions vs OOP William Gill <noreply@domain.invalid> - 2011-09-03 17:34 -0400
          Re: Functions vs OOP Ben Finney <ben+python@benfinney.id.au> - 2011-09-04 07:39 +1000
            Re: Functions vs OOP William Gill <nospam@domain.invalid> - 2011-09-03 17:58 -0400
          Re: Functions vs OOP Terry Reedy <tjreedy@udel.edu> - 2011-09-03 21:51 -0400
            Re: Functions vs OOP William Gill <noreply@domain.invalid> - 2011-09-03 22:18 -0400
      Re: Functions vs OOP William Gill <nospam@domain.invalid> - 2011-09-05 14:58 -0400
    Re: Functions vs OOP MRAB <python@mrabarnett.plus.com> - 2011-09-03 17:29 +0100
      Re: Functions vs OOP William Gill <noreply@domain.invalid> - 2011-09-03 17:09 -0400
    Re: Functions vs OOP Ian Kelly <ian.g.kelly@gmail.com> - 2011-09-03 12:50 -0600
      Re: Functions vs OOP William Gill <noreply@domain.invalid> - 2011-09-03 17:13 -0400
      Re: Functions vs OOP tinnews@isbd.co.uk - 2011-09-04 09:13 +0100
        Re: Functions vs OOP Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-09-04 21:18 +1000
        Re: Functions vs OOP Terry Reedy <tjreedy@udel.edu> - 2011-09-04 14:32 -0400
          Re: Functions vs OOP William Gill <nospam@domain.invalid> - 2011-09-04 15:43 -0400
            Re: Functions vs OOP Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-09-05 09:41 +1000
              Re: Functions vs OOP William Gill <nospam@domain.invalid> - 2011-09-04 20:46 -0400
              Re: Functions vs OOP Chris Angelico <rosuav@gmail.com> - 2011-09-05 10:59 +1000
    Re: Functions vs OOP rusi <rustompmody@gmail.com> - 2011-09-04 06:13 -0700
      Re: Functions vs OOP William Gill <noreply@domain.invalid> - 2011-09-05 13:45 -0400
        Re: Functions vs OOP Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-09-05 21:04 +0200
          Re: Functions vs OOP William Gill <nospam@domain.invalid> - 2011-09-05 20:30 -0400
        Re: Functions vs OOP Terry Reedy <tjreedy@udel.edu> - 2011-09-05 18:55 -0400

Page 1 of 2  [1] 2  Next page →

#12703 — Functions vs OOP

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?

[toc] | [next] | [standalone]

#12704

William Gill wrote:

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



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#12717

On 9/3/2011 12:25 PM, Steven D'Aprano wrote:
> William Gill wrote:
>
>> During some recent research, and re-familiarization with Python, I came
>> across documentation

Ours, or someone else's?

>> 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?

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

>> Am I missing something, or am I taking things too literally?
>
> No, it is the OO purists who are missing something.

Yes, Python.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#12722

On 9/3/2011 3:15 PM, Terry Reedy wrote:
>> William Gill wrote:
>>
>>> During some recent research, and re-familiarization with Python, I came
>>> across documentation
>
> 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."

[toc] | [prev] | [next] | [standalone]

#12723

William Gill <noreply@domain.invalid> writes:

> On 9/3/2011 3:15 PM, Terry Reedy wrote:
> >> William Gill wrote:
> >>
> >>> During some recent research, and re-familiarization with Python, I
> >>> came across documentation
> >
> > Ours, or someone else's?
>
> Python.

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

-- 
 \           “If you're a cowboy and you're dragging a guy behind your |
  `\      horse, I bet it would really make you mad if you looked back |
_o__)                and the guy was reading a magazine.” —Jack Handey |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#12724

On 9/3/2011 5:39 PM, Ben Finney wrote:
> William Gill<noreply@domain.invalid>  writes:
>
>> On 9/3/2011 3:15 PM, Terry Reedy wrote:
>>>> William Gill wrote:
>>>>
>>>>> During some recent research, and re-familiarization with Python, I
>>>>> came across documentation
>>>
>>> Ours, or someone else's?
>>
>> Python.
>
> 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).

[toc] | [prev] | [next] | [standalone]

#12730

On 9/3/2011 5:34 PM, William Gill wrote:
> On 9/3/2011 3:15 PM, Terry Reedy wrote:
>>> William Gill wrote:
>>>
>>>> During some recent research, and re-familiarization with Python, I came
>>>> across documentation
>>
>> 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."

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.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#12732

On 9/3/2011 9:51 PM, Terry Reedy wrote:
>
> 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.

[toc] | [prev] | [next] | [standalone]

#12787

On 9/3/2011 12:25 PM, Steven D'Aprano wrote:
> William Gill wrote:
>
>> Are they suggesting that any function that takes an object as an
>> argument should always be a method of that object?
>
> Yes.

I can think of times when a special application, such as a converter, 
would take an object as an argument, but the somewhat unique nature of 
the application wouldn't justify changing the class to make the behavior 
into a method.

I could extend the underlying class to include the new behavior 
(method), but that would mean existing instances of the base class would 
need conversion to the new class, requiring yet another method.

Seems to me, that would be POOP (Puristic Object Oriented Programming) ;-)

[toc] | [prev] | [next] | [standalone]

#12706

On 03/09/2011 17:15, William Gill wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#12720

On 9/3/2011 12:29 PM, MRAB wrote:
> 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".

[toc] | [prev] | [next] | [standalone]

#12714

On Sat, Sep 3, 2011 at 10:15 AM, William Gill <noreply@domain.invalid> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#12721

On 9/3/2011 2:50 PM, Ian Kelly wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#12735

Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sat, Sep 3, 2011 at 10:15 AM, William Gill <noreply@domain.invalid> wrote:
> > 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.
> 
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.

-- 
Chris Green

[toc] | [prev] | [next] | [standalone]

#12738

tinnews@isbd.co.uk wrote:

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



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#12745

On 9/4/2011 4:13 AM, tinnews@isbd.co.uk wrote:
> Ian Kelly<ian.g.kelly@gmail.com>  wrote:

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

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.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#12749

On 9/4/2011 2:32 PM, Terry Reedy wrote:
> On 9/4/2011 4:13 AM, tinnews@isbd.co.uk wrote:
>> Ian Kelly<ian.g.kelly@gmail.com> wrote:
>
>>> 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.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#12754

William Gill wrote:

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




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#12755

On 9/4/2011 7:41 PM, Steven D'Aprano wrote:
> William Gill wrote:
>
>> 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

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

[toc] | [prev] | [next] | [standalone]

#12756

On Mon, Sep 5, 2011 at 9:41 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web