4 ms·

Object Orientation is a design philosophy, not a concrete process or mechanism. Its major principle is encapsulation; things outside of me don't need to know a

Object Orientation is a design philosophy, not a concrete process or mechanism. Its major principle is encapsulation; things outside of me don't need to know about my internal workings, just my external appearance. This leads to abstraction; if I externally appear just like that other guy, things outside of me can pretend we're the same even if we have different internal workings. Beyond those concepts, we begin to get into implementation. Classes, inheritance, and polymorphism are implementation. You can apply OO principles without them. They just happen to be the traditional face of OO. That may be why you're struggling to find a definition that makes sense. Too often we use the implementation to discuss the philosophy. Don't get hung up on a definition. It's like trying to define love, art, or pornography. Keep asking and arguing about it though. That's a good way to learn it.

loup-vaillant 16y ago
OK, but if I admit your principles as OO, then a functional language with modules and parametric polymorphism is OO (Haskell and Ocaml come to mind). Your definition seems reasonable, but following it means that giving any language reasonable facilities for low coupling and code reuse makes it OO. I'm fine with that, but such a broad term can't be useful in technical discussions.
- terrywilcox 16y ago
  I think you'll find that the basic principles of good design are shared between most design philosophies. Reducing coupling and increasing cohesion spring to mind. Stop thinking in terms of whether a language claims to be object oriented and start thinking in terms of how you'd apply object oriented principles to the language. The language is merely a tool, sometimes with support for a specific implementation of object orientation. How you use that tool is up to you.
  - loup-vaillant 16y ago
    I did start with the techniques, then checked if the languages supported them. My ideas are a lot clearer than you seem to think. Thanks to you and the others, I now have resolved my confusion: "OO" doesn't technically mean anything significant, but nevertheless carries a strong emotional load (positive or negative, depending on the reader). That tends to end useful discussion and to encourage religious flame-wars. I now consider "OO" taboo, along with sentences like "just a tool". I now believe that most programmers did fall in the trap I spoke of in my original post, but this trap appears to be less obvious than I thought. Now about what implements what: Coupling reduction is implemented by encapsulation. There's no other way. Any technique that reduces coupling is a form of encapsulation. Any language that supports coupling reduction supports encapsulation. Encapsulation is supported by 3 features: functions, modules, and classes. Let's not talk about functions, whose presence don't differentiate. So, to support encapsulation (and therefore coupling reduction), a language needs either modules or classes. Code reuse is achieved with functions and abstraction as you defined it. I don't know any other way, short of writing a DSL or using a whole program. As before, let's not talk about functions themselves. Therefore, any language that supports code reuse supports abstraction. Abstraction means I can interact the same way with two "things" if they are of the same type. Well, I think that by "guy", you meant "something with embedded behaviour", and not just dead data, like integers or arrays. Such a thing is necessarily a closure. Closures can be achieved by 3 mechanisms: subtype polymorphism (interfaces, mixins…), duck typing, and first class functions (which are isomorphic to duck typed mono-method objects). I said "parametric polymorphism" earlier, but it isn't actually needed. So, to supports abstraction (and therefore code reuse), a language must have either subtype polymorphism or first class functions. Now Back to OO. To support OO, a language must support encapsulation and abstraction. I've established that it's the same as saying that it must support coupling reduction and code reuse. And intuitively, a language that doesn't support either of them isn't worth using. Therefore any modern language should support OO. Now, supporting OO is not the same as being OO. To be OO in my book, a language must actually strongly encourage the frequent use of encapsulation and abstraction. As it happens, most modern languages do. Almost all have either modules or classes. And when they do, they strongly encourage you to use them systematically, if they do not flatly mandate it like Java. Likewise, almost all have either subtype polymorphism, duck typing, or first class functions. And when they do, they strongly encourage their frequent use. Which means that almost every modern language strongly encourages the frequent use of all the necessary OO features. In other words, almost every modern language is OO. C++ and Java are OO because of their classes and subtype polymorphism. Ocaml and Haskell are OO because of their module system and their first class functions. You probably didn't intend to qualify those last two as OO (I don't, and they don't claim to be), but they fit your definition nevertheless.
    - terrywilcox 16y ago
      I don't qualify any languages as OO, their creators do. You can do OO in any language, with varying degrees of difficulty and success. The language merely tries to provide mechanisms for encouraging object oriented design (or not). You appear to need some strict boundaries between different classes of languages. Those boundaries rarely exist. Languages and the people that define them are influenced by what they've already learned. There's nothing to stop language designers from trying to combine elements from various different types of languages, nor should there be. Languages evolve. Philosophies evolve. Terminology evolves. Expecting to find a rigid definition within so much change is naive. Your definition will be obsolete before you get it written down. As for religious flame wars, whatever. Ideas don't cause flame wars, people do. The tone of your post is certainly slanted toward starting one, so I'm leaving before it happens. I hope I've been of some assistance and I hope you find what you're looking for. I fear you'll be disappointed. Personally, I prefer a more pragmatic than academic approach to software development.
      - loup-vaillant 16y ago
        First and foremost: you have been of assistance. In http://news.ycombinator.com/item?id=1808634 http://news.ycombinator.com/item?id=1808634 I've already said what I mean when I qualify some language as OO. Now your acceptance or rejection of this definition is not important. What is important is that Ocaml and Haskell both strongly encourage the use of OO as you defined it, that they greatly facilitate it, and that they even make it the standard way of writing programs. I insist because that's definitely not what one would say at first, especially starting from the reasonable looking definition of OO you provided. I don't need strict boundaries between languages, I see them. Some languages have automatic currying, some do not. Some have duck typing, some have type inference… and so on. A single difference in two languages' core features can make them quite different. Of course, if you measure languages along a single given axis (like the OO/not OO axis), the boundaries appear much smoother. By the way, I don't see how the fact that language designers are influenced by the languages they learned support (or refute) the assertion that the boundaries between languages aren't strict. > Languages evolve. Philosophies evolve. Terminology evolves. Expecting to find a rigid definition within so much change is naive. Your definition will be obsolete before you get it written down. Beware. That, is very close to a semantic stop sign http://wiki.lesswrong.com/wiki/Semantic_stopsign http://wiki.lesswrong.com/wiki/Semantic_stopsign While true, (Languages, philosophies and terminology do evolve), it is suggesting that it makes any conversation whatsoever impossible. If you don't want to discuss further, just say so (saying "I'm leaving before [a flame war] happens" was perfectly fine). Now, if you do think that the meaning of the term "OO" evolve so fast that it's not worth writing down, then you'll agree that the term "OO" itself shouldn't be used at all.. I didn't say that Ideas cause flame wars. I said that using some terms,which aren't the ideas themselves, can cause flame wars. (I said «"OO"», not «OO».) One reason the term "OO" can cause flame wars is because it triggers cached thoughts http://wiki.lesswrong.com/wiki/Cached_thought http://wiki.lesswrong.com/wiki/Cached_thought which are difficult to de-construct without a clear, agreed upon definition. And I certainly don't want to start a flame war with you. You didn't attacked me personally, nor used any dark arts http://wiki.lesswrong.com/wiki/Dark_arts http://wiki.lesswrong.com/wiki/Dark_arts Many people can't say so.

loup-vaillant 16y ago

OK, but if I admit your principles as OO, then a functional language with modules and parametric polymorphism is OO (Haskell and Ocaml come to mind). Your definition seems reasonable, but following it means that giving any language reasonable facilities for low coupling and code reuse makes it OO. I'm fine with that, but such a broad term can't be useful in technical discussions.

terrywilcox 16y ago
I think you'll find that the basic principles of good design are shared between most design philosophies. Reducing coupling and increasing cohesion spring to mind. Stop thinking in terms of whether a language claims to be object oriented and start thinking in terms of how you'd apply object oriented principles to the language. The language is merely a tool, sometimes with support for a specific implementation of object orientation. How you use that tool is up to you.
- loup-vaillant 16y ago
  I did start with the techniques, then checked if the languages supported them. My ideas are a lot clearer than you seem to think. Thanks to you and the others, I now have resolved my confusion: "OO" doesn't technically mean anything significant, but nevertheless carries a strong emotional load (positive or negative, depending on the reader). That tends to end useful discussion and to encourage religious flame-wars. I now consider "OO" taboo, along with sentences like "just a tool". I now believe that most programmers did fall in the trap I spoke of in my original post, but this trap appears to be less obvious than I thought. Now about what implements what: Coupling reduction is implemented by encapsulation. There's no other way. Any technique that reduces coupling is a form of encapsulation. Any language that supports coupling reduction supports encapsulation. Encapsulation is supported by 3 features: functions, modules, and classes. Let's not talk about functions, whose presence don't differentiate. So, to support encapsulation (and therefore coupling reduction), a language needs either modules or classes. Code reuse is achieved with functions and abstraction as you defined it. I don't know any other way, short of writing a DSL or using a whole program. As before, let's not talk about functions themselves. Therefore, any language that supports code reuse supports abstraction. Abstraction means I can interact the same way with two "things" if they are of the same type. Well, I think that by "guy", you meant "something with embedded behaviour", and not just dead data, like integers or arrays. Such a thing is necessarily a closure. Closures can be achieved by 3 mechanisms: subtype polymorphism (interfaces, mixins…), duck typing, and first class functions (which are isomorphic to duck typed mono-method objects). I said "parametric polymorphism" earlier, but it isn't actually needed. So, to supports abstraction (and therefore code reuse), a language must have either subtype polymorphism or first class functions. Now Back to OO. To support OO, a language must support encapsulation and abstraction. I've established that it's the same as saying that it must support coupling reduction and code reuse. And intuitively, a language that doesn't support either of them isn't worth using. Therefore any modern language should support OO. Now, supporting OO is not the same as being OO. To be OO in my book, a language must actually strongly encourage the frequent use of encapsulation and abstraction. As it happens, most modern languages do. Almost all have either modules or classes. And when they do, they strongly encourage you to use them systematically, if they do not flatly mandate it like Java. Likewise, almost all have either subtype polymorphism, duck typing, or first class functions. And when they do, they strongly encourage their frequent use. Which means that almost every modern language strongly encourages the frequent use of all the necessary OO features. In other words, almost every modern language is OO. C++ and Java are OO because of their classes and subtype polymorphism. Ocaml and Haskell are OO because of their module system and their first class functions. You probably didn't intend to qualify those last two as OO (I don't, and they don't claim to be), but they fit your definition nevertheless.
  - terrywilcox 16y ago
    I don't qualify any languages as OO, their creators do. You can do OO in any language, with varying degrees of difficulty and success. The language merely tries to provide mechanisms for encouraging object oriented design (or not). You appear to need some strict boundaries between different classes of languages. Those boundaries rarely exist. Languages and the people that define them are influenced by what they've already learned. There's nothing to stop language designers from trying to combine elements from various different types of languages, nor should there be. Languages evolve. Philosophies evolve. Terminology evolves. Expecting to find a rigid definition within so much change is naive. Your definition will be obsolete before you get it written down. As for religious flame wars, whatever. Ideas don't cause flame wars, people do. The tone of your post is certainly slanted toward starting one, so I'm leaving before it happens. I hope I've been of some assistance and I hope you find what you're looking for. I fear you'll be disappointed. Personally, I prefer a more pragmatic than academic approach to software development.
    - loup-vaillant 16y ago
      First and foremost: you have been of assistance. In http://news.ycombinator.com/item?id=1808634 http://news.ycombinator.com/item?id=1808634 I've already said what I mean when I qualify some language as OO. Now your acceptance or rejection of this definition is not important. What is important is that Ocaml and Haskell both strongly encourage the use of OO as you defined it, that they greatly facilitate it, and that they even make it the standard way of writing programs. I insist because that's definitely not what one would say at first, especially starting from the reasonable looking definition of OO you provided. I don't need strict boundaries between languages, I see them. Some languages have automatic currying, some do not. Some have duck typing, some have type inference… and so on. A single difference in two languages' core features can make them quite different. Of course, if you measure languages along a single given axis (like the OO/not OO axis), the boundaries appear much smoother. By the way, I don't see how the fact that language designers are influenced by the languages they learned support (or refute) the assertion that the boundaries between languages aren't strict. > Languages evolve. Philosophies evolve. Terminology evolves. Expecting to find a rigid definition within so much change is naive. Your definition will be obsolete before you get it written down. Beware. That, is very close to a semantic stop sign http://wiki.lesswrong.com/wiki/Semantic_stopsign http://wiki.lesswrong.com/wiki/Semantic_stopsign While true, (Languages, philosophies and terminology do evolve), it is suggesting that it makes any conversation whatsoever impossible. If you don't want to discuss further, just say so (saying "I'm leaving before [a flame war] happens" was perfectly fine). Now, if you do think that the meaning of the term "OO" evolve so fast that it's not worth writing down, then you'll agree that the term "OO" itself shouldn't be used at all.. I didn't say that Ideas cause flame wars. I said that using some terms,which aren't the ideas themselves, can cause flame wars. (I said «"OO"», not «OO».) One reason the term "OO" can cause flame wars is because it triggers cached thoughts http://wiki.lesswrong.com/wiki/Cached_thought http://wiki.lesswrong.com/wiki/Cached_thought which are difficult to de-construct without a clear, agreed upon definition. And I certainly don't want to start a flame war with you. You didn't attacked me personally, nor used any dark arts http://wiki.lesswrong.com/wiki/Dark_arts http://wiki.lesswrong.com/wiki/Dark_arts Many people can't say so.