7 ms·

Since this is aimed at new developers, I would encourage anyone who falls into that category and is reading this to also look at alternate programming methodolo

by woah 12y ago

Since this is aimed at new developers, I would encourage anyone who falls into that category and is reading this to also look at alternate programming methodologies. The key component of OOP is the mixture of code and data into "objects". This can be very useful for physical simulations such as games, etc., since the real physical world is actually made of objects. However, many feel that applying OOP to software that is not for physical simulation has led to a huge amount of wasted effort over the previous decades. The problem is with code reuse. The only real form of code reuse that OOP addresses is direct object inheritance. If you want to reuse a piece of code, the way to do it is to make an object that is a 'subclass' of an object that has the code that you want to use. The actual relationship of these objects is often not that simple, and people often create baroque inheritance trees to force their logic into the OOP pattern. Worse, is that OOP is built into many languages, which leaves you no choice. An alternate pattern is functional programming, where a program is modeled as a series of data transformations, instead of a universe of interacting 'objects'. To write the code, one looks at what data will go into the software, and what data will need to come out. After all, if the right data is coming out of the program at the right times, it works. Instead of breaking code into objects, you write functions that process the data correctly, and assemble them into larger structures, often resembling pipelines. The nice thing is that a lot of these functions are very reusable across projects and within a project. Avoiding the messy mixture of code and data allows you to identify the common patterns in your code, and refactor and reuse more easily. EDIT: Here are a couple of libraries which have really facilitated functional programming for me in node.js - http://ramda.github.io/ramdocs/docs/ http://ramda.github.io/ramdocs/docs/ - https://github.com/dominictarr/pull-stream https://github.com/dominictarr/pull-stream

evanspa 12y ago
To build on what you're saying, one could argue that functional programming also is a way to model the world; that is, if you're model of the world is that of a series of snapshots of instants, as opposed to mutable stateful objects. Abelson from the SICP lectures argues this in this lecture: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/6a-streams-part-1/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...
zmb_ 12y ago
Like you say, the main benefit of OOP is that it matches the way we perceive reality. That can make it intuitive to design software. However, this often comes at the expense of performance since the hardware that executes your system bears no resemblance to the way we perceive reality. Take your physical simulations, for example. You may have a game scene with hundreds or thousands of entities. It's natural to try to model these as objects. In every frame you will then call a method on each object that applies a translation to its position. Very intuitive and simple. But unfortunately extremely inefficient for a computer to execute. You will likely pay a number of cache misses while jumping to each of your objects. And once you get there, the rest of the cache line where your coordinates are is full irrelevant stuff and therefore wasted (the other fields of your object). For performance, you would want to have all your entities' coordinates in continuous memory one after another, and then apply a function to translate them all at once. Pretty much the opposite design from where OOP naturally leads you.
- the_af 12y ago
  It's debatable whether OOP "matches the way we perceive reality". Many have come to believe this, but is it true? I don't perceive all of reality as a strict hierarchy of things constructed out of templates, with "is a" and "has a" relationships between them. I don't think the main problem with OOP is performance, either. The problem is that it's not always the right or the most natural design approach, regardless of any performance considerations.
  - bunderbunder 12y ago
    > It's debatable whether OOP "matches the way we perceive reality". Many have come to believe this, but is it true? No, it isn't true. But neither do we perceive all of reality as a collection entities that never change but are used to create new unchanging entities by a series of idempotent mappings from domains to codomains. But both abstractions are useful as ways to organize your thoughts, or as languages we can use to describe processes in an organized manner. Which one is more useful is often case specific - with the case covering not only the problem space but also the individual psychology of the person doing the work. Many find that neither is so useful that they would be comfortable using it to the exclusion of the other, which is why there are so many functional languages with object-oriented features such as Caml and why so many major object-oriented languages such as C++, C# and Java have been acquiring increasingly many functional features over the past decade.
tunesmith 12y ago
This criticism against OO programming is more of a criticism against junior-level OO programming. A lot of beginning OO programmers go crazy with complicated object models that aren't necessary. Composition is often a better way to go than inheritance. http://en.wikipedia.org/wiki/Composition_over_inheritance http://en.wikipedia.org/wiki/Composition_over_inheritance
hcarvalhoalves 12y ago
> This can be very useful for physical simulations such as games, etc., since the real physical world is actually made of objects. Actually, OOP breaks down for this case (simulation) too.
ww520 12y ago
> The only real form of code reuse that OOP addresses is direct object inheritance. That is incorrect and it's misinformation about OOP. The most important mechanism for code reuse is a function or method, and it's the essential part of OOP. You put code into a function/method that can be used repeatedly. Function exists in most languages and is not the exclusive domain of functional programming.
rebootthesystem 12y ago
I've always had a different view about OO vs Functional. OO is beneficial to the programmer. Functional provides benefits in performance, footprint and memory utilization. You can solve any problem with either approach. Microprocessors don't care. I've written genetic evolver code in machine language (don't ask) as well as C, C++, Python and objective C. The OO languages make it easy for the programmer, while the Functional approach requires more thought, planning and perhaps attention to detail. I tend to prefer The functional approach, probably because I did tons of real work using this model before OO came into my world. However, I certainly appreciate how much easier some things can be in OO. What I object to is this idea that everything today has to be an object, this is wasteful and slow. Of course, I am biased. When you learned programming starting with machine language, then Forth and then C before touching C++ your view of how to solve problems computationally is bound to be quite different than that of someone who started life with, say, Java.
Arnor 12y ago
>The only real form of code reuse that OOP addresses is direct object inheritance. Composition is far more useful and effective means of code reuse in OOP.
- Dewie 12y ago
  Yet composition in the OOP sense seems like it can be easily achieved in any other paradigm - so OOP does not seem to address composition in any distinct way.
  - stormbrew 12y ago
    I disagree. I think the criticisms in the GGP post are largely targeted at a very particular form of OOP (which is granted probably the most popular form): That popularized by C++ and later doubled down on by Java. Inheritance heavy, overly mingling interface and structure, etc. The Smalltalk/Ruby/arguably Erlang form of OO does not really treat composition and inheritance as things at odds -- the way the object you're talking to has achieved its composition (where inheritance is a specialized form of composition) is basically irrelevant to you as the caller does address this, and quite well imo.
    - jghn 12y ago
      I agree with you but it is worth noting that many people I've come across will claim that the other forms of OO aren't really OO. For instance the OO system that we see in CLOS, Dylan, R's S4, etc. I vehemently disagree with them but my point is that for many people OO is by definition the one "popularized by C++ and later doubled down on by Java"
      - Someone 12y ago
        Indeed. For many people, the question "what is OO programming?" has an answer that mentions the word "class" a few times before it mentions the word "object". That's why I call that subset of OO "class-oriented programming", instead.
pjmlp 12y ago
> The only real form of code reuse that OOP addresses is direct object inheritance. This is not true. COM, Smaltalk, Eiffel, BETA, SELF, CLOS offer different OOP models than the average Java and C# programmers are aware of. You can have code reuse via composition, delegation, sub-typing, genericity, mixins. OOP is nothing more than modules in steroids for those of us that started with languages like Modula-2 and Turbo Pascal, doing Abstract Data Types[1][2] programming. [1] - http://cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.pdf http://cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.p... [2] - http://www.amazon.com/Data-Structures-Abstract-Types-Modula-2/dp/0534073026 http://www.amazon.com/Data-Structures-Abstract-Types-Modula-...
- lmm 12y ago
  "OOP" means different things to different people. I think we can all agree that beginners should be encouraged to look beyond the C++/Java/Python object models and consider alternatives to direct inheritance, which is the core point here.
  - pjmlp 12y ago
    That I agree, yes.
mathattack 12y ago
Your reaction was very similar to mind. I thought, "What benefit here is not available via functional programming?"
syntaxgoonoo 12y ago
I think a lot of developer don't really understand OOP, and as a result they mess it up. In many ways functional programming is more straight forward, easier to get your head around it, but you can still mess it up just as much. I feel your statement above is a little naive. You should read some Martin Fowler. Be less reactive and more informed. Find balance. Software systems, regardless of methodology, need good experienced designers There is no silver bullet.
- bunderbunder 12y ago
  I wouldn't just blame developers; I feel like the OOP languages most of us have been stuck with deserve some scorn as well. The major functional languages all come from academic backgrounds, and it shows. They're very principled, and a lot of thought is put into designing languages that are clean and actively encourage you to write clean code. The major object-oriented languages, by contrast, tend to come out of non-academic environments. Their design was often compromised by pragmatic concerns (C++, Java), or by their being hobby languages being designed by folks for whom Barbara Liskov maybe isn't a household name. I don't want to hate on these languages too much - C++ and Java and Python and Ruby make the world turn, after all, and I suspect that's partially because they let you get away with so much. But they are what they are.
joshcanhelp 12y ago
Best description of functional programming I've ever heard, thank you
Impossible 12y ago
Game developers have been big on data oriented design (http://www.asawicki.info/news_1422_data-oriented_design_-_links_and_thoughts.html http://www.asawicki.info/news_1422_data-oriented_design_-_li...) in recent years. It's funny, because data-oriented design examples tend to look like the original ("bad"?) array of values example in the blog post. Most of articles on DOD focus on performance, which seems of least concern to most software engineers, but I think it helps with understanding how your data is transformed and results in easier to understand code. I don't see how OOP is any more applicable to games than it is to other software. In a typical business or social CRUD app you can represent things in the same way you could in an OOP game. "Hero" becomes "User", "Monster" becomes "Friend", "Inventory" becomes "Account", etc. Otherwise I strongly agree with you. I think all software should be written in a more functional or data-oriented style. The biggest reason I'd write OOP code now is that many game designers and programmers, and most popular game engines and frameworks, prefer OOP.
jowiar 12y ago
> The only real form of code reuse that OOP addresses is direct object inheritance. Not really, or at least, not with a well designed system. Give me a system with small, composable objects. I can reuse code by creating a new object for one of the components of the system, or by writing an object that knows how to talk to a previously existing objects. Sandi Metz' POODR [1] should be required reading for anyone who is writing object oriented code. Functional programming is also worth learning as well, and Martin Odersky's Coursera [2] shows how Scala can be used for code that is both object oriented and functional. [1]: http://www.poodr.com http://www.poodr.com [2]: https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun
epper 12y ago
> [...] The problem is with code reuse. The only real form of code reuse that OOP addresses is direct object inheritance. [...] Inheritance is a form of code reuse in OOP. Composition is another one which is often preferred since it does not have the issues you mention here. Note that just a couple of days ago this was posted on HN: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... It's the definition that basically the inventor of Object Oriented Programming gave of OOP itself. One of the nice things he says is that he left out inheritance on purpose because he "didn't like it" the way it was done and wanted to "understand it better". Regardless, I think your advice of learning other programming paradigms is great.
Kiro 12y ago
> To write the code, one looks at what data will go into the software, and what data will need to come out. What if your program has no output? The applications I write seldom has. Instead they save down stuff or send it away here and there during the lifespan of the program. When they're done they just exit without any output. FP seems to be focused on one input going through transformations ending up in one output. (I'm not a good programmer and barely know how to do OOP, much less FP.)
- dragonwriter 12y ago
  > What if your program has no output? The applications I write seldom has. Instead they save down stuff or send it away here and there during the lifespan of the program. What is saved and what is sent are outputs. > FP seems to be focused on one input going through transformations ending up in one output. That's not entirely untrue, but that one can be a set of simpler values, a processes can be values, too.
- 4ydx 12y ago
  Functional programming is nothing more than applying the rigour of math to programming.

by woah 12y ago

evanspa 12y ago

To build on what you're saying, one could argue that functional programming also is a way to model the world; that is, if you're model of the world is that of a series of snapshots of instants, as opposed to mutable stateful objects. Abelson from the SICP lectures argues this in this lecture: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/6a-streams-part-1/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...

zmb_ 12y ago

Like you say, the main benefit of OOP is that it matches the way we perceive reality. That can make it intuitive to design software. However, this often comes at the expense of performance since the hardware that executes your system bears no resemblance to the way we perceive reality. Take your physical simulations, for example. You may have a game scene with hundreds or thousands of entities. It's natural to try to model these as objects. In every frame you will then call a method on each object that applies a translation to its position. Very intuitive and simple. But unfortunately extremely inefficient for a computer to execute. You will likely pay a number of cache misses while jumping to each of your objects. And once you get there, the rest of the cache line where your coordinates are is full irrelevant stuff and therefore wasted (the other fields of your object). For performance, you would want to have all your entities' coordinates in continuous memory one after another, and then apply a function to translate them all at once. Pretty much the opposite design from where OOP naturally leads you.

the_af 12y ago
It's debatable whether OOP "matches the way we perceive reality". Many have come to believe this, but is it true? I don't perceive all of reality as a strict hierarchy of things constructed out of templates, with "is a" and "has a" relationships between them. I don't think the main problem with OOP is performance, either. The problem is that it's not always the right or the most natural design approach, regardless of any performance considerations.
- bunderbunder 12y ago
  > It's debatable whether OOP "matches the way we perceive reality". Many have come to believe this, but is it true? No, it isn't true. But neither do we perceive all of reality as a collection entities that never change but are used to create new unchanging entities by a series of idempotent mappings from domains to codomains. But both abstractions are useful as ways to organize your thoughts, or as languages we can use to describe processes in an organized manner. Which one is more useful is often case specific - with the case covering not only the problem space but also the individual psychology of the person doing the work. Many find that neither is so useful that they would be comfortable using it to the exclusion of the other, which is why there are so many functional languages with object-oriented features such as Caml and why so many major object-oriented languages such as C++, C# and Java have been acquiring increasingly many functional features over the past decade.

tunesmith 12y ago

This criticism against OO programming is more of a criticism against junior-level OO programming. A lot of beginning OO programmers go crazy with complicated object models that aren't necessary. Composition is often a better way to go than inheritance. http://en.wikipedia.org/wiki/Composition_over_inheritance http://en.wikipedia.org/wiki/Composition_over_inheritance

hcarvalhoalves 12y ago

> This can be very useful for physical simulations such as games, etc., since the real physical world is actually made of objects. Actually, OOP breaks down for this case (simulation) too.

ww520 12y ago

> The only real form of code reuse that OOP addresses is direct object inheritance. That is incorrect and it's misinformation about OOP. The most important mechanism for code reuse is a function or method, and it's the essential part of OOP. You put code into a function/method that can be used repeatedly. Function exists in most languages and is not the exclusive domain of functional programming.

rebootthesystem 12y ago

I've always had a different view about OO vs Functional. OO is beneficial to the programmer. Functional provides benefits in performance, footprint and memory utilization. You can solve any problem with either approach. Microprocessors don't care. I've written genetic evolver code in machine language (don't ask) as well as C, C++, Python and objective C. The OO languages make it easy for the programmer, while the Functional approach requires more thought, planning and perhaps attention to detail. I tend to prefer The functional approach, probably because I did tons of real work using this model before OO came into my world. However, I certainly appreciate how much easier some things can be in OO. What I object to is this idea that everything today has to be an object, this is wasteful and slow. Of course, I am biased. When you learned programming starting with machine language, then Forth and then C before touching C++ your view of how to solve problems computationally is bound to be quite different than that of someone who started life with, say, Java.

Arnor 12y ago

>The only real form of code reuse that OOP addresses is direct object inheritance. Composition is far more useful and effective means of code reuse in OOP.

Dewie 12y ago
Yet composition in the OOP sense seems like it can be easily achieved in any other paradigm - so OOP does not seem to address composition in any distinct way.
- stormbrew 12y ago
  I disagree. I think the criticisms in the GGP post are largely targeted at a very particular form of OOP (which is granted probably the most popular form): That popularized by C++ and later doubled down on by Java. Inheritance heavy, overly mingling interface and structure, etc. The Smalltalk/Ruby/arguably Erlang form of OO does not really treat composition and inheritance as things at odds -- the way the object you're talking to has achieved its composition (where inheritance is a specialized form of composition) is basically irrelevant to you as the caller does address this, and quite well imo.
  - jghn 12y ago
    I agree with you but it is worth noting that many people I've come across will claim that the other forms of OO aren't really OO. For instance the OO system that we see in CLOS, Dylan, R's S4, etc. I vehemently disagree with them but my point is that for many people OO is by definition the one "popularized by C++ and later doubled down on by Java"
    - Someone 12y ago
      Indeed. For many people, the question "what is OO programming?" has an answer that mentions the word "class" a few times before it mentions the word "object". That's why I call that subset of OO "class-oriented programming", instead.

pjmlp 12y ago

> The only real form of code reuse that OOP addresses is direct object inheritance. This is not true. COM, Smaltalk, Eiffel, BETA, SELF, CLOS offer different OOP models than the average Java and C# programmers are aware of. You can have code reuse via composition, delegation, sub-typing, genericity, mixins. OOP is nothing more than modules in steroids for those of us that started with languages like Modula-2 and Turbo Pascal, doing Abstract Data Types[1][2] programming. [1] - http://cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.pdf http://cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.p... [2] - http://www.amazon.com/Data-Structures-Abstract-Types-Modula-2/dp/0534073026 http://www.amazon.com/Data-Structures-Abstract-Types-Modula-...

lmm 12y ago
"OOP" means different things to different people. I think we can all agree that beginners should be encouraged to look beyond the C++/Java/Python object models and consider alternatives to direct inheritance, which is the core point here.
- pjmlp 12y ago
  That I agree, yes.

mathattack 12y ago

Your reaction was very similar to mind. I thought, "What benefit here is not available via functional programming?"

syntaxgoonoo 12y ago

I think a lot of developer don't really understand OOP, and as a result they mess it up. In many ways functional programming is more straight forward, easier to get your head around it, but you can still mess it up just as much. I feel your statement above is a little naive. You should read some Martin Fowler. Be less reactive and more informed. Find balance. Software systems, regardless of methodology, need good experienced designers There is no silver bullet.

bunderbunder 12y ago
I wouldn't just blame developers; I feel like the OOP languages most of us have been stuck with deserve some scorn as well. The major functional languages all come from academic backgrounds, and it shows. They're very principled, and a lot of thought is put into designing languages that are clean and actively encourage you to write clean code. The major object-oriented languages, by contrast, tend to come out of non-academic environments. Their design was often compromised by pragmatic concerns (C++, Java), or by their being hobby languages being designed by folks for whom Barbara Liskov maybe isn't a household name. I don't want to hate on these languages too much - C++ and Java and Python and Ruby make the world turn, after all, and I suspect that's partially because they let you get away with so much. But they are what they are.

joshcanhelp 12y ago

Best description of functional programming I've ever heard, thank you

Impossible 12y ago

Game developers have been big on data oriented design (http://www.asawicki.info/news_1422_data-oriented_design_-_links_and_thoughts.html http://www.asawicki.info/news_1422_data-oriented_design_-_li...) in recent years. It's funny, because data-oriented design examples tend to look like the original ("bad"?) array of values example in the blog post. Most of articles on DOD focus on performance, which seems of least concern to most software engineers, but I think it helps with understanding how your data is transformed and results in easier to understand code. I don't see how OOP is any more applicable to games than it is to other software. In a typical business or social CRUD app you can represent things in the same way you could in an OOP game. "Hero" becomes "User", "Monster" becomes "Friend", "Inventory" becomes "Account", etc. Otherwise I strongly agree with you. I think all software should be written in a more functional or data-oriented style. The biggest reason I'd write OOP code now is that many game designers and programmers, and most popular game engines and frameworks, prefer OOP.

jowiar 12y ago

> The only real form of code reuse that OOP addresses is direct object inheritance. Not really, or at least, not with a well designed system. Give me a system with small, composable objects. I can reuse code by creating a new object for one of the components of the system, or by writing an object that knows how to talk to a previously existing objects. Sandi Metz' POODR [1] should be required reading for anyone who is writing object oriented code. Functional programming is also worth learning as well, and Martin Odersky's Coursera [2] shows how Scala can be used for code that is both object oriented and functional. [1]: http://www.poodr.com http://www.poodr.com [2]: https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun

epper 12y ago

> [...] The problem is with code reuse. The only real form of code reuse that OOP addresses is direct object inheritance. [...] Inheritance is a form of code reuse in OOP. Composition is another one which is often preferred since it does not have the issues you mention here. Note that just a couple of days ago this was posted on HN: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... It's the definition that basically the inventor of Object Oriented Programming gave of OOP itself. One of the nice things he says is that he left out inheritance on purpose because he "didn't like it" the way it was done and wanted to "understand it better". Regardless, I think your advice of learning other programming paradigms is great.

Kiro 12y ago

> To write the code, one looks at what data will go into the software, and what data will need to come out. What if your program has no output? The applications I write seldom has. Instead they save down stuff or send it away here and there during the lifespan of the program. When they're done they just exit without any output. FP seems to be focused on one input going through transformations ending up in one output. (I'm not a good programmer and barely know how to do OOP, much less FP.)

dragonwriter 12y ago
> What if your program has no output? The applications I write seldom has. Instead they save down stuff or send it away here and there during the lifespan of the program. What is saved and what is sent are outputs. > FP seems to be focused on one input going through transformations ending up in one output. That's not entirely untrue, but that one can be a set of simpler values, a processes can be values, too.
4ydx 12y ago
Functional programming is nothing more than applying the rigour of math to programming.