5 ms·

OO code, on the other hand, is rarely reused. This is true in situations where OO is done wrong. OO is supposed to help us implement types, and you can do thi

by Xurinos 16y ago

OO code, on the other hand, is rarely reused. This is true in situations where OO is done wrong. OO is supposed to help us implement types, and you can do this portably. You can write bad functions, too, that have too much dependency on things specific to your framework. This is not a matter of FP vs OOP but of writing portable code, which neither approach forces you to do. FP vs OOP is not a real conflict anyway. The two are compatible.

kls 16y ago
I have yet to be convinced that any other development philosophy other than OO is superior when it comes to the UI. I will concede that OO offers little advantage when writing services, accessing databases, and integrating systems. But for the UI having self encapsulated widgets that can be extended to add distinct functionality is far superior to procedural, functional or declarative. Having a select box that can be extended to create a filtering select box with only the functionality for filtering needed is a no brainer. As well having the UI elements functionality represented by a distinct object helps isolate that code and functionality away from the larger system, with a defined interface so that it can be reused as needed without external dependencies. OO manages the hierarchy of code and its bisection in a manner that is far more comprehensible when it comes to UI, AI and game development. The rest is just preference.
- Xurinos 16y ago
  What exactly are people talking about when they are discussing these differences? You mentioned "procedural" and "declarative"; how is that something wherein OO can be in opposition? In other words, how are you programming your class methods, and how are you programming the things that call those methods in a way that is not "procedural, functional, or declarative"? OOP is not a philosophy. It is a way to glue data together. OOP is not separate from "procedural, functional, or declarative" programming, so it cannot possibly be "superior". I object to this becoming a religion or a we vs them. Here is an example for clarity: x = new(Complex); set_real_part(x, 4); set_imag_part(x, 10); imag_part = get_imag_part(x); Did I program that with OOP? How can you tell? Is it just syntax (because we can rearrange syntax)? x = new(Complex); x->set_real_part(4); x->set_imag_part(10); imag_part = x->get_imag_part(); And back to my hint: x = new(Complex); x = x->set_real_part(4); x = x->set_imag_part(10); imag_part = x->get_imag_part(); x could be a function.
  - kls 16y ago
    OOP is not a philosophy philosophy: any personal belief about how to live or how to deal with a situation; "self-indulgence was his only philosophy"; "my father's philosophy of child-rearing was to let mother do it" It's not a science, it is a philosophical view point on how code should be arranged. So for me philosophy best fits the definition of the abstract concept that is a though process enshrined in code in particular adherence to a philosophically composed structure. I think philosophy fits the bill quite well. I think you miss the point, functions and data existing outside of the class do not encapsulate the code base, so for you example, what if I write a widget for the UI and I want to give that widget to my friend, but not my project. In you example, I have to package up the functions, which may or may not reside with other functions, then you have to package up the data and again many or may not. Further the API does not float with the widget, so my friend has to design non conflicting entry points in his system to ensure that those functions are now available to the data for manipulation. You are introducing external dependancies to a concept that by all intents and purposes can stand alone. OO promote reusability, because it boxes everything you need into a class and that is why when specifically applied to the UI where there is a lot of inherent reusability of items that deviate slightly it provides great application. External dependancies are the nemesis of isolated components and your example shows why. You are looking outside the object at how it is used by the system. You are looking at how you call and use that class not how it relates to the overall system and keeps itself from becoming intertwined with it, all of the is dealt with inside the class not outside because it is inherent to OO. Inheritance is a whole other aspect of why it is superior in this context and again it has to do with limiting external dependancies. Being able to extend a code base and suppress existing functionality while adding new novel functionality allow one to build on an existing item while still allowing the existing items to stand independent of that relationship. This allows my friend the ability to build upon my code base while leaving my code base intact. Therefore when I update my code base so long as I do not modify the existing contracts he can take upgrade in whole with no issue and no modification to his existing system. Now I know all this can be done with functional languages, the point is that it is simpler with OO and that is the crux of the issue.
    - contextfree 16y ago
jcromartie 16y ago
I have yet to see OO objects live on from one internal project to another. It's always the same cycle: design domain model objects; let them grow/bloat for the purposes of the project; end up redesigning them the "right" way for the next project.
- Xurinos 16y ago
  Assuming we are talking about classes, I am glad someone released Path::Class for perl, among many other class packages. This is a social problem, not a problem with the technology.
  - billswift 16y ago
    Except to the extent that the technology exacerbates the social problem. Or even just enables the social problem to continue.
- Goladus 16y ago
  There are objects that persist and are reusable, although often you might not think of them that way. In python, for example, there are a number of useful and reusable objects. The 'function' object, the 'module' object, the 'str' object, etc..
Goladus 16y ago
I would say it's not just a matter of writing portable code, but writing portable, generic, useful code. Code can be portable but not useful. I think object-oriented code is slightly more prone to being portable-but-not-useful because it tends to be designed around real-world models for a particular problem, while functional programming tends to prefer generic abstract models like lists, hashes, graphs, and sets. Also, code can be useful but not obviously so. A method like org_chart.peruse, for example, might be a solidly generic and portable tree-traversing method that you'd never think to use elsewhere.
raganwald 16y ago
> This is true in situations where OO is done wrong. Beware the No True Scotsman fallacy: http://en.wikipedia.org/wiki/No_true_Scotsman http://en.wikipedia.org/wiki/No_true_Scotsman
fleitz 16y ago
Yes, they are compatible but you end up writing a lot of let Write f buffer start len = f.Write(buffer,start,len) so that you can pass functions independently of the object.

by Xurinos 16y ago

kls 16y ago

I have yet to be convinced that any other development philosophy other than OO is superior when it comes to the UI. I will concede that OO offers little advantage when writing services, accessing databases, and integrating systems. But for the UI having self encapsulated widgets that can be extended to add distinct functionality is far superior to procedural, functional or declarative. Having a select box that can be extended to create a filtering select box with only the functionality for filtering needed is a no brainer. As well having the UI elements functionality represented by a distinct object helps isolate that code and functionality away from the larger system, with a defined interface so that it can be reused as needed without external dependencies. OO manages the hierarchy of code and its bisection in a manner that is far more comprehensible when it comes to UI, AI and game development. The rest is just preference.

Xurinos 16y ago
What exactly are people talking about when they are discussing these differences? You mentioned "procedural" and "declarative"; how is that something wherein OO can be in opposition? In other words, how are you programming your class methods, and how are you programming the things that call those methods in a way that is not "procedural, functional, or declarative"? OOP is not a philosophy. It is a way to glue data together. OOP is not separate from "procedural, functional, or declarative" programming, so it cannot possibly be "superior". I object to this becoming a religion or a we vs them. Here is an example for clarity: x = new(Complex); set_real_part(x, 4); set_imag_part(x, 10); imag_part = get_imag_part(x); Did I program that with OOP? How can you tell? Is it just syntax (because we can rearrange syntax)? x = new(Complex); x->set_real_part(4); x->set_imag_part(10); imag_part = x->get_imag_part(); And back to my hint: x = new(Complex); x = x->set_real_part(4); x = x->set_imag_part(10); imag_part = x->get_imag_part(); x could be a function.
- kls 16y ago
  OOP is not a philosophy philosophy: any personal belief about how to live or how to deal with a situation; "self-indulgence was his only philosophy"; "my father's philosophy of child-rearing was to let mother do it" It's not a science, it is a philosophical view point on how code should be arranged. So for me philosophy best fits the definition of the abstract concept that is a though process enshrined in code in particular adherence to a philosophically composed structure. I think philosophy fits the bill quite well. I think you miss the point, functions and data existing outside of the class do not encapsulate the code base, so for you example, what if I write a widget for the UI and I want to give that widget to my friend, but not my project. In you example, I have to package up the functions, which may or may not reside with other functions, then you have to package up the data and again many or may not. Further the API does not float with the widget, so my friend has to design non conflicting entry points in his system to ensure that those functions are now available to the data for manipulation. You are introducing external dependancies to a concept that by all intents and purposes can stand alone. OO promote reusability, because it boxes everything you need into a class and that is why when specifically applied to the UI where there is a lot of inherent reusability of items that deviate slightly it provides great application. External dependancies are the nemesis of isolated components and your example shows why. You are looking outside the object at how it is used by the system. You are looking at how you call and use that class not how it relates to the overall system and keeps itself from becoming intertwined with it, all of the is dealt with inside the class not outside because it is inherent to OO. Inheritance is a whole other aspect of why it is superior in this context and again it has to do with limiting external dependancies. Being able to extend a code base and suppress existing functionality while adding new novel functionality allow one to build on an existing item while still allowing the existing items to stand independent of that relationship. This allows my friend the ability to build upon my code base while leaving my code base intact. Therefore when I update my code base so long as I do not modify the existing contracts he can take upgrade in whole with no issue and no modification to his existing system. Now I know all this can be done with functional languages, the point is that it is simpler with OO and that is the crux of the issue.
  - contextfree 16y ago

jcromartie 16y ago

I have yet to see OO objects live on from one internal project to another. It's always the same cycle: design domain model objects; let them grow/bloat for the purposes of the project; end up redesigning them the "right" way for the next project.

Xurinos 16y ago
Assuming we are talking about classes, I am glad someone released Path::Class for perl, among many other class packages. This is a social problem, not a problem with the technology.
- billswift 16y ago
  Except to the extent that the technology exacerbates the social problem. Or even just enables the social problem to continue.
Goladus 16y ago
There are objects that persist and are reusable, although often you might not think of them that way. In python, for example, there are a number of useful and reusable objects. The 'function' object, the 'module' object, the 'str' object, etc..

Goladus 16y ago

I would say it's not just a matter of writing portable code, but writing portable, generic, useful code. Code can be portable but not useful. I think object-oriented code is slightly more prone to being portable-but-not-useful because it tends to be designed around real-world models for a particular problem, while functional programming tends to prefer generic abstract models like lists, hashes, graphs, and sets. Also, code can be useful but not obviously so. A method like org_chart.peruse, for example, might be a solidly generic and portable tree-traversing method that you'd never think to use elsewhere.

raganwald 16y ago

> This is true in situations where OO is done wrong. Beware the No True Scotsman fallacy: http://en.wikipedia.org/wiki/No_true_Scotsman http://en.wikipedia.org/wiki/No_true_Scotsman

fleitz 16y ago

Yes, they are compatible but you end up writing a lot of let Write f buffer start len = f.Write(buffer,start,len) so that you can pass functions independently of the object.