Re: Functions vs OOP
On 9/4/2011 9:13 AM, rusi wrote: On Sep 3, 9:15 pm, William Gillnore...@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. 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 objectdotfunction for identification. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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) ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
William Gill wrote: 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 objectdotfunction for identification. Functional programming is not about writing a programm with functions (google it for more info). This may cause some confusion. Your original post was about functions vs methods, which are identical except some syntax detail. FYI, in python x.f() is equivalent to f(x). In an OOP world one will prefer the x.f() form. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
On 9/5/2011 1:45 PM, William Gill wrote: On 9/4/2011 9:13 AM, rusi wrote: On Sep 3, 9:15 pm, William Gillnore...@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. 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. In Python, it may be a parameterized procedure. Some languages separate functions and procedures (also called subroutines). Python does not. (Or you could say that it makes procedures into functions with side-effects by returning None by default). 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 objectdotfunction for identification. 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 Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
On 9/5/2011 3:04 PM, Jean-Michel Pichavant wrote: William Gill wrote: 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 objectdotfunction for identification. Functional programming is not about writing a programm with functions snip. This may cause some confusion. It can, and it did. That was the impression I (incorrectly) got from the documentation. Which didn't make sense to me. (google it for more info). I can, and I did. That, and the answers I got in this ng are how I corrected my misconception. Your original post was about functions vs methods, which are identical except some syntax detail. FYI, in python x.f() is equivalent to f(x). In an OOP world one will prefer the x.f() form. No, my original post was about how (based on the aforementioned misconception) the documentation seemed to suggest that OOP should never have free standing functions, only methods. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
Ian Kelly ian.g.ke...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
Progranming with functions vs Progranming with objects sounds like C vs. C++ more than functional programming vs. OO programming On 4 September 2011 04:18, William Gill noreply@domain.invalid wrote: 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. -- http://mail.python.org/**mailman/listinfo/python-listhttp://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
tinn...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
On Sep 3, 9:15 pm, William Gill nore...@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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
On 9/4/2011 4:13 AM, tinn...@isbd.co.uk wrote: Ian Kellyian.g.ke...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
On 9/4/2011 2:32 PM, Terry Reedy wrote: On 9/4/2011 4:13 AM, tinn...@isbd.co.uk wrote: Ian Kellyian.g.ke...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
On Mon, Sep 5, 2011 at 9:41 AM, Steven D'Aprano steve+comp.lang.pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
On 9/3/2011 5:39 PM, Ben Finney wrote: William Gillnoreply@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). -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Functions vs OOP
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. -- http://mail.python.org/mailman/listinfo/python-list
