6 ms·

You conspicuously don't actually name any OO principles. If you did I'm sure we could find "OO" languages that don't conform to them. My personal definition of

by jerf 5y ago

You conspicuously don't actually name any OO principles. If you did I'm sure we could find "OO" languages that don't conform to them. My personal definition of OO has been backed down to directly connecting some concept of "method" to a data structure, and some form of polymorphism of those methods depending on what data structure you pass in to some function/method. You may note this is incredibly weak, but it does have the virtue of usefully distinguishing between two sets of languages, and that those two sets will have real differences in how you program them. Beyond that it's hard to create a definition of OO that has the second property; you may be able to split the world into "languages that implement OO visibility rules (private, protected, public) and those that don't", but you'll fail the second criterion, in that languages that just leave everything public aren't meaningfully different to program in than ones that implement the visibility rules. I could create several different sets of "OO principles", which wouldn't be mutually exclusive necessarily but certainly would be distinguishable. Especially the distinction between the silly principle that OO objects should somehow reflect real-world entities, which was the major failure in 1980s/1990s OO principles and has, mercifully, all but died in the modern era but most certainly was at one point an "OO principle", and any of the several sets of OO principles I could name that actually function in the real world.

mytailorisrich 5y ago
Well, this is HN so I did not want to sound condescending by stating the obvious. OO Programming 101, OO principles: encapsulation, abstraction, inheritance, polymorphism, SOLID. Whatever a specific language adheres to and how is beside the point.
- jhgb 5y ago
  That must be some kind of "new OOP", since the "old OOP" is messaging, local retention, and protection and hiding of state-process, and extreme late-binding of all things. At least according to Alan Kay, who wrote this verbatim. To wit, encapsulation and abstraction existed outside of OOP (for example, Modula had it before), inheritance is not a necessary feature for OOP (Self doesn't have it), and the O in SOLID doesn't apply to Smalltalk and Self.
  - mytailorisrich 5y ago
    That's standard OOP as it stands today (versus the 60s when Alan Kay coined the term). Alan Kay considers that inheritance and polymorphism are not essential, fine. He does consider encapsulation essential, though. Specific languages have their own take, fine. The point being is that there are well-known OO principles. Claiming otherwise is either disingenuous or ignorant.
    - jhgb 5y ago
      > versus the 60s when Alan Kay coined the term It was in the 70s, and his description that I quoted is from the 2000s. > Alan Kay considers that inheritance and polymorphism are not essential, fine. Polymorphism is a logical outcome of his requirements. So in a purely logical sense it is essential, although I imagine that saying that might be a little bit like saying that CO2 is essential for a campfire (as in that you can't get a campfire without emitting CO2, even though that is strictly a matter of consequences). > He does consider encapsulation essential, though. Yes, because biological cells are encapsulated. > there are well-known OO principles. Claiming otherwise is either disingenuous or ignorant. There surely are some "well-known principles" but whether the "known" in that phrase has the same meaning as in "knowledge" (justified true belief at a first approximation) seems debatable.
- bccdee 5y ago
  Those aren't exclusive to OO, though. C, for all its faults, has encapsulation at a module level: any functions you don't define in your header file aren't exported and are thus private. Go and rust do the same thing. Abstraction is even more common. Functions are abstractions. And any language with typeclasses (like haskell) or function overriding (like Julia) uses a form of polymorphism Really, the only essentially object-oriented things here are inheritance and (by extension) inheritance-based polymorphism.
  - rsj_hn 5y ago
    > C, for all its faults, has encapsulation at a module level: No language that supports memory access for the entire address space of the currently running program can ever support something like encapsulation: you can pass pointers to objects and functions outside the currently running module, or you could somehow derive this info from outside the module and so access functions and objects that were not declared in header files. Thus the language cannot give you the isolation guarantees that memory managed languages can. What it can do, is put up some roadblocks or barriers that require effort to cross. But there is a big difference between correctness guarantees and roadblocks. There really is a qualitative change when you are working in a memory managed language as that allows the language to assign fine grained control over which memory addresses are available to which data structures, which is something that you cannot do with C.
    - corty 5y ago
      Well then, C++ doesn't have encapsulation, therefore C++ isn't OO. Hell, even Java isn't OO if you allow JNI.
      - rsj_hn 5y ago
        I don't want to get into a debate defining what language is OO and what is not. My point was rebutting the notion that C has private data structures by pointing out only languages in which memory is managed by the runtime (e.g. VM) can offer isolation guarantees. Attempts to switch the topic to OS level memory protections are not really what we're talking about here, as the OS doesn't provide language level protections. So yes, if your code leaves the VM then you lose those VM protections.
- jerf 5y ago
  The tree under your reply proves my point. There is no one set of OO principles. This thread identifies at least two, the original Kay principles and what I wasn't sure you were going to name, which is what I'd call the outdated 1990s ideas of OO. Then there's today's idea, which is probably pretty close to what I said in my post and is exemplified by duck-typed dynamic languages and a lot of modern languages like Go and Rust. That's at least three, and that's staying fairly broad; if we start quibbling about arcane details the count only goes up.
  - mytailorisrich 5y ago
    > what I wasn't sure you were going to name, which is what I'd call the outdated 1990s ideas of OO. I'm sorry but this is getting surreal. I named the standard OO principles and concepts which are very much valid and alive today, though of course how they are applied (or if they are applied at all) varies from language to language. Claiming otherwise is absurd. If anything this whole article and thread show that too many people are confused by the concepts of OO principles (if they know what that means at all), programming languages (that may or may not implement some of these principles), design practices/patterns (how to come up with a model of objects): these are all different things. Certainly selecting objects that reflect real-life entities is not an OO principle, for instance, but rather a design practice (good or bad, it depends). In my team we do C exclusively and follow OO principles as much as practical. Any software engineer worth their salt has a good idea of what that means.

by jerf 5y ago

mytailorisrich 5y ago

Well, this is HN so I did not want to sound condescending by stating the obvious. OO Programming 101, OO principles: encapsulation, abstraction, inheritance, polymorphism, SOLID. Whatever a specific language adheres to and how is beside the point.

jhgb 5y ago
That must be some kind of "new OOP", since the "old OOP" is messaging, local retention, and protection and hiding of state-process, and extreme late-binding of all things. At least according to Alan Kay, who wrote this verbatim. To wit, encapsulation and abstraction existed outside of OOP (for example, Modula had it before), inheritance is not a necessary feature for OOP (Self doesn't have it), and the O in SOLID doesn't apply to Smalltalk and Self.
- mytailorisrich 5y ago
  That's standard OOP as it stands today (versus the 60s when Alan Kay coined the term). Alan Kay considers that inheritance and polymorphism are not essential, fine. He does consider encapsulation essential, though. Specific languages have their own take, fine. The point being is that there are well-known OO principles. Claiming otherwise is either disingenuous or ignorant.
  - jhgb 5y ago
    > versus the 60s when Alan Kay coined the term It was in the 70s, and his description that I quoted is from the 2000s. > Alan Kay considers that inheritance and polymorphism are not essential, fine. Polymorphism is a logical outcome of his requirements. So in a purely logical sense it is essential, although I imagine that saying that might be a little bit like saying that CO2 is essential for a campfire (as in that you can't get a campfire without emitting CO2, even though that is strictly a matter of consequences). > He does consider encapsulation essential, though. Yes, because biological cells are encapsulated. > there are well-known OO principles. Claiming otherwise is either disingenuous or ignorant. There surely are some "well-known principles" but whether the "known" in that phrase has the same meaning as in "knowledge" (justified true belief at a first approximation) seems debatable.
bccdee 5y ago
Those aren't exclusive to OO, though. C, for all its faults, has encapsulation at a module level: any functions you don't define in your header file aren't exported and are thus private. Go and rust do the same thing. Abstraction is even more common. Functions are abstractions. And any language with typeclasses (like haskell) or function overriding (like Julia) uses a form of polymorphism Really, the only essentially object-oriented things here are inheritance and (by extension) inheritance-based polymorphism.
- rsj_hn 5y ago
  > C, for all its faults, has encapsulation at a module level: No language that supports memory access for the entire address space of the currently running program can ever support something like encapsulation: you can pass pointers to objects and functions outside the currently running module, or you could somehow derive this info from outside the module and so access functions and objects that were not declared in header files. Thus the language cannot give you the isolation guarantees that memory managed languages can. What it can do, is put up some roadblocks or barriers that require effort to cross. But there is a big difference between correctness guarantees and roadblocks. There really is a qualitative change when you are working in a memory managed language as that allows the language to assign fine grained control over which memory addresses are available to which data structures, which is something that you cannot do with C.
  - corty 5y ago
    Well then, C++ doesn't have encapsulation, therefore C++ isn't OO. Hell, even Java isn't OO if you allow JNI.
    - rsj_hn 5y ago
      I don't want to get into a debate defining what language is OO and what is not. My point was rebutting the notion that C has private data structures by pointing out only languages in which memory is managed by the runtime (e.g. VM) can offer isolation guarantees. Attempts to switch the topic to OS level memory protections are not really what we're talking about here, as the OS doesn't provide language level protections. So yes, if your code leaves the VM then you lose those VM protections.
jerf 5y ago
The tree under your reply proves my point. There is no one set of OO principles. This thread identifies at least two, the original Kay principles and what I wasn't sure you were going to name, which is what I'd call the outdated 1990s ideas of OO. Then there's today's idea, which is probably pretty close to what I said in my post and is exemplified by duck-typed dynamic languages and a lot of modern languages like Go and Rust. That's at least three, and that's staying fairly broad; if we start quibbling about arcane details the count only goes up.
- mytailorisrich 5y ago
  > what I wasn't sure you were going to name, which is what I'd call the outdated 1990s ideas of OO. I'm sorry but this is getting surreal. I named the standard OO principles and concepts which are very much valid and alive today, though of course how they are applied (or if they are applied at all) varies from language to language. Claiming otherwise is absurd. If anything this whole article and thread show that too many people are confused by the concepts of OO principles (if they know what that means at all), programming languages (that may or may not implement some of these principles), design practices/patterns (how to come up with a model of objects): these are all different things. Certainly selecting objects that reflect real-life entities is not an OO principle, for instance, but rather a design practice (good or bad, it depends). In my team we do C exclusively and follow OO principles as much as practical. Any software engineer worth their salt has a good idea of what that means.