4 ms·

Functional and Object Oriented Programming

40 points by wellpast 14y ago

WTPayne 14y ago
Well, everything that jmolly says is true, but decoupling data and functional behavior is only part of it. Indeed, OOP was designed specifically to couple data and behavior together, so some people (at least) think that this is a good thing. In my mind, the difficulty lies not with OOP per se, but in the thought-patterns and practices that have grown up around modern OOP programming, and the mental confusion that we have between the construction of models, the design of algorithms, and the creation of machines to help solve a particular problem. To a large extent, we lack the intellectual tools required to understand the problem; or, at least, the use and understanding of those tools is not widespread. Personally, I suspect that there is a significant difference between product-centric thinking (design the product, ignore all else), and product-line-centric (or capability-centric) thinking (design the machinery that will make it trivially easy to design the product). This, for me, is a more important distinction than OOP vs FP, or any other dichotomy that you might care to mention. I am not suggesting that I am right here, mind you: this is just the way that I feel; my gut instinct ... so perhaps some Socratic questioning might be in order here: Let me start. What problem, as software developers, are we actually trying to solve?
- wellpast 14y ago
  In most business cases, I would think the problem for us is to minimize the work required to solve the ongoing business needs. The other cases, I suppose, are art and play -- but there probably isn't much point in trying to optimize these activities.
ehosca 14y ago
i've being dalliancing in haughtiness for years.
aiscott 14y ago
This is coming from the point of view of someone who doesn't dwell in the world of programming to any significant degree. I don't always understand or use the jargon correctly. I was really put off by the contrast between declarative programming and imperative programming. Honestly I didn't understand the declarative example at all. It seemed to me that all the author did was move functionality into some functions and then not bother showing the implementation of those functions. I work in hardware design, so my perspective is bound to be pretty different, and maybe that is where I am having trouble. We have declarative tools, and what they consist of is stating a bunch of things that need to be true about something. It's not at all what this supposedly declarative example looked like. I could see no difference between the imperative and declarative examples except for refactoring some functionality into functions that then were glossed over in the imperative example. Can someone clarify for me where I am mistaken?
michaelochurch 14y ago
The original vision behind OOP wasn't at odds with functional programming. In fact, it looks more like modern FP than modern OOP, with its FactoryFactories and POJOs and cargo cult bullshit that are more an artifact of a failed attempt to commoditize programming talent (one which hijacked OOP) than anything else. Pure functional programming is great. Alan Kay would agree. However, the world is stateful. The original inspiration for OOP was the cell, which encapsulates complex physical machinery (state and behavior) behind a simpler chemical or electrical interface. The idea wasn't that complexity is a good thing (it's not) but that, when it becomes inevitable, it needs to be sequestered so that it's only visible to the few who need to fuss with the object's internals, not to the many who need to interact with it at an API level only. An "object" is a complex entity whose interface is designed for simplicity. An example of this would be a SQL database. Query optimization is complex, but the interface is much simpler. You don't micromanage which indexes it uses and when; you just specify the query you want to run and trust the software to figure it out. In spite of its age, SQL is the most successful DSL ever invented, and for a number of reasons, but it's relative simplicity and flexibility are high among them. An added benefit of the simpler interface is that implementations can be swapped out without rewriting the entire interface. Where OOP broke horribly was when someone got the (wrong) idea that every program needed to be "object-oriented", and OOP went from a set of tools solving specific problems (e.g. GUIs) very well to a general-purpose programming paradigm, which became worse because it was so poorly understood. It evolved from a stance of "use objects when complexity requires it" to "use objects as the fundamental unit of programming", which is bad because complexity and uncertainty aren't inherently good, but undesirable all else being equal. Scheme is a better first substrate for programming than Java, because the fundamental building block of programming should be the referentially transparent function. Only when this is reasonably well understood should people be exposed to mutable state.
- espeed 14y ago
  Pure functional programming is great. Alan Kay would agree. Alan Kay does agree: "the greatest single programming language ever designed" - Alan Kay, on Lisp (http://paulgraham.com/quotes.html http://paulgraham.com/quotes.html).
marknutter 14y ago
Is learning Haskell even practical yet? I have a great interest in becoming a more productive programmer, but not as much in learning a language just for the fun of it. What kind of stuff is Haskell best suited for building?
- espeed 14y ago
  Clojure is functional and practical -- you get access to all of Java's libraries without the performance hits from languages not originally designed for the JVM, like Jython and JRuby.
wyred 14y ago
DrinkingAge.isAbove(person.getAge()) Sounds like the type of code Yoda would write if he codes.
richcollins 14y ago
OO idioms and practices encourage coupling. For example, in Java, if you want behavior you are forced to create a class. In OO instruction classes are often introduced as containers of state. So it’s no surprise that in OO systems you typically find data and behavior mashed together. Replace class with arguments and you have the same "coupling" As soon as I get the creative idea of asking if my Cat is of drinking age, I can’t reuse this behavior Yes you can, you just delegate the behavior to an object whose job it is to determine things about ages. It isn't much different than having a suite of related functions designed to operate on things with ages. We'll designed software doesn't look much different if you do it in a functional or OO language. The main difference you do see is that much of the code for dealing with state disappears in an OO language as the language itself implements it. In a functional language you have to build your own OO like system to make the stateful parts easy.

40 points by wellpast 14y ago

Well, everything that jmolly says is true, but decoupling data and functional behavior is only part of it. Indeed, OOP was designed specifically to couple data and behavior together, so some people (at least) think that this is a good thing. In my mind, the difficulty lies not with OOP per se, but in the thought-patterns and practices that have grown up around modern OOP programming, and the mental confusion that we have between the construction of models, the design of algorithms, and the creation of machines to help solve a particular problem. To a large extent, we lack the intellectual tools required to understand the problem; or, at least, the use and understanding of those tools is not widespread. Personally, I suspect that there is a significant difference between product-centric thinking (design the product, ignore all else), and product-line-centric (or capability-centric) thinking (design the machinery that will make it trivially easy to design the product). This, for me, is a more important distinction than OOP vs FP, or any other dichotomy that you might care to mention. I am not suggesting that I am right here, mind you: this is just the way that I feel; my gut instinct ... so perhaps some Socratic questioning might be in order here: Let me start. What problem, as software developers, are we actually trying to solve?

wellpast 14y ago
In most business cases, I would think the problem for us is to minimize the work required to solve the ongoing business needs. The other cases, I suppose, are art and play -- but there probably isn't much point in trying to optimize these activities.

ehosca 14y ago

i've being dalliancing in haughtiness for years.

aiscott 14y ago

This is coming from the point of view of someone who doesn't dwell in the world of programming to any significant degree. I don't always understand or use the jargon correctly. I was really put off by the contrast between declarative programming and imperative programming. Honestly I didn't understand the declarative example at all. It seemed to me that all the author did was move functionality into some functions and then not bother showing the implementation of those functions. I work in hardware design, so my perspective is bound to be pretty different, and maybe that is where I am having trouble. We have declarative tools, and what they consist of is stating a bunch of things that need to be true about something. It's not at all what this supposedly declarative example looked like. I could see no difference between the imperative and declarative examples except for refactoring some functionality into functions that then were glossed over in the imperative example. Can someone clarify for me where I am mistaken?

michaelochurch 14y ago

The original vision behind OOP wasn't at odds with functional programming. In fact, it looks more like modern FP than modern OOP, with its FactoryFactories and POJOs and cargo cult bullshit that are more an artifact of a failed attempt to commoditize programming talent (one which hijacked OOP) than anything else. Pure functional programming is great. Alan Kay would agree. However, the world is stateful. The original inspiration for OOP was the cell, which encapsulates complex physical machinery (state and behavior) behind a simpler chemical or electrical interface. The idea wasn't that complexity is a good thing (it's not) but that, when it becomes inevitable, it needs to be sequestered so that it's only visible to the few who need to fuss with the object's internals, not to the many who need to interact with it at an API level only. An "object" is a complex entity whose interface is designed for simplicity. An example of this would be a SQL database. Query optimization is complex, but the interface is much simpler. You don't micromanage which indexes it uses and when; you just specify the query you want to run and trust the software to figure it out. In spite of its age, SQL is the most successful DSL ever invented, and for a number of reasons, but it's relative simplicity and flexibility are high among them. An added benefit of the simpler interface is that implementations can be swapped out without rewriting the entire interface. Where OOP broke horribly was when someone got the (wrong) idea that every program needed to be "object-oriented", and OOP went from a set of tools solving specific problems (e.g. GUIs) very well to a general-purpose programming paradigm, which became worse because it was so poorly understood. It evolved from a stance of "use objects when complexity requires it" to "use objects as the fundamental unit of programming", which is bad because complexity and uncertainty aren't inherently good, but undesirable all else being equal. Scheme is a better first substrate for programming than Java, because the fundamental building block of programming should be the referentially transparent function. Only when this is reasonably well understood should people be exposed to mutable state.

espeed 14y ago
Pure functional programming is great. Alan Kay would agree. Alan Kay does agree: "the greatest single programming language ever designed" - Alan Kay, on Lisp (http://paulgraham.com/quotes.html http://paulgraham.com/quotes.html).

marknutter 14y ago

Is learning Haskell even practical yet? I have a great interest in becoming a more productive programmer, but not as much in learning a language just for the fun of it. What kind of stuff is Haskell best suited for building?

espeed 14y ago
Clojure is functional and practical -- you get access to all of Java's libraries without the performance hits from languages not originally designed for the JVM, like Jython and JRuby.

wyred 14y ago

DrinkingAge.isAbove(person.getAge()) Sounds like the type of code Yoda would write if he codes.

richcollins 14y ago

OO idioms and practices encourage coupling. For example, in Java, if you want behavior you are forced to create a class. In OO instruction classes are often introduced as containers of state. So it’s no surprise that in OO systems you typically find data and behavior mashed together. Replace class with arguments and you have the same "coupling" As soon as I get the creative idea of asking if my Cat is of drinking age, I can’t reuse this behavior Yes you can, you just delegate the behavior to an object whose job it is to determine things about ages. It isn't much different than having a suite of related functions designed to operate on things with ages. We'll designed software doesn't look much different if you do it in a functional or OO language. The main difference you do see is that much of the code for dealing with state disappears in an OO language as the language itself implements it. In a functional language you have to build your own OO like system to make the stateful parts easy.