5 ms·

Look, there is nothing wrong with classes and OO in general. What is wrong is using OO when it is unnecessary and only adds layers of complexity.

by phzbOx 15y ago

gruseom 15y ago
What is wrong is using OO when it is unnecessary That's a platitude which everybody can and does say about everything. But I think one can make a case that there is something wrong with OO in general. The original arguments for OO were: it's better for managing complexity, and it creates programs that are easier to change. Both of these turned out not to be true in general. So we need to ask, when is OO a win? But for simpler problems it doesn't matter, because anything would work. So we need to ask: what are the hard problems that OO makes significantly easier? I don't think anyone has answered that. I suspect it's that OO is good when the problem involves some well-defined system that exists objectively outside the program - for example, a physical system. One can look at that outside thing and ask, "what are its components?" and represent each with a class. The objective reality takes care of the hardest part of OO, which is knowing what the classes should be. (Whereas most of the time that just takes our first hard problem - what should the system do? - and makes it even harder.) As you make mistakes and have to change your classes, you can interrogate the outside system to find out what the mistakes are, and the new classes are likely to be refinements of the old ones rather than wholly incompatible. This answer boils down to saying that OO's sweet spot is right where it originated: simulation. But that's something of a niche, not the general-purpose complexity-tackling paradigm it was sold as. (There's an interview on Youtube of Steve Jobs in 1995 or so saying that OO means programmers can build software out of pre-existing components and that this makes for at least one order of magnitude more productivity - that "at least" being a marvelous Jobsian touch.) The reason OO endures as a general-purpose paradigm is inertia. Several generations of programmers have been taught it as the way to program -- which it is not, except that thinking makes it so. How did it get to become so standard? Story of the software industry to date: software is hard, so we come up with a theory of how we would like it to work, do that, and filter out the conflicting evidence.
- rbarooah 15y ago
  Another reason it endures is the large collection of mature and easy to use libraries available. Of course this is something of a chicken and egg problem, but a very present one.
  - gruseom 15y ago
    Yes, but that's just the same inertia. If programmers no longer believed in those libraries, they'd soon write new ones. Otherwise our systems would all still be integrating with Fortran and COBOL. Some still do, of course - and the extent to which they still do is probably the true measure of the library argument.
    - Drbble 15y ago
      Maybe the reason programmers moved from cobol to OO is because they found OO better? Staying with Cobol was an option?
      - gruseom 15y ago
        It would have been if pre-existing software (libraries) were the dominant factor.
    - rbarooah 15y ago
      I'm not so convinced. There was a time when most people had grown up with procedural code. OO offered enough promise that people moved over to it and developed things like Cocoa or Java. If people aren't moving on, it's not simply because of 'intertia'. It's because the alternatives aren't offering enough benefit yet.
      - gruseom 15y ago
        I think that's nearly entirely untrue. Emotional attachment to what one already knows is the dominant factor - all the more dominant because, in our zeal to appear rational, we deny it. What will change the paradigm is the desire of a future generation to make its mark by throwing out how the previous generation did things. One can see this trying to happen with FP, though I doubt FP will reach mass appeal. When you do anything as intensely as writing software demands, your identity gets involved. When identity is involved, emotions are strong. The image of being a rational engineer is mostly a veneer on top of this process. Edit: 'intertia' - your making fun of an obvious typo rather illustrates the point.

Look, there is nothing wrong with classes and OO in general. What is wrong is using OO when it is unnecessary and only adds layers of complexity.

by phzbOx 15y ago

Look, there is nothing wrong with classes and OO in general. What is wrong is using OO when it is unnecessary and only adds layers of complexity.

gruseom 15y ago

What is wrong is using OO when it is unnecessary That's a platitude which everybody can and does say about everything. But I think one can make a case that there is something wrong with OO in general. The original arguments for OO were: it's better for managing complexity, and it creates programs that are easier to change. Both of these turned out not to be true in general. So we need to ask, when is OO a win? But for simpler problems it doesn't matter, because anything would work. So we need to ask: what are the hard problems that OO makes significantly easier? I don't think anyone has answered that. I suspect it's that OO is good when the problem involves some well-defined system that exists objectively outside the program - for example, a physical system. One can look at that outside thing and ask, "what are its components?" and represent each with a class. The objective reality takes care of the hardest part of OO, which is knowing what the classes should be. (Whereas most of the time that just takes our first hard problem - what should the system do? - and makes it even harder.) As you make mistakes and have to change your classes, you can interrogate the outside system to find out what the mistakes are, and the new classes are likely to be refinements of the old ones rather than wholly incompatible. This answer boils down to saying that OO's sweet spot is right where it originated: simulation. But that's something of a niche, not the general-purpose complexity-tackling paradigm it was sold as. (There's an interview on Youtube of Steve Jobs in 1995 or so saying that OO means programmers can build software out of pre-existing components and that this makes for at least one order of magnitude more productivity - that "at least" being a marvelous Jobsian touch.) The reason OO endures as a general-purpose paradigm is inertia. Several generations of programmers have been taught it as the way to program -- which it is not, except that thinking makes it so. How did it get to become so standard? Story of the software industry to date: software is hard, so we come up with a theory of how we would like it to work, do that, and filter out the conflicting evidence.

rbarooah 15y ago
Another reason it endures is the large collection of mature and easy to use libraries available. Of course this is something of a chicken and egg problem, but a very present one.
- gruseom 15y ago
  Yes, but that's just the same inertia. If programmers no longer believed in those libraries, they'd soon write new ones. Otherwise our systems would all still be integrating with Fortran and COBOL. Some still do, of course - and the extent to which they still do is probably the true measure of the library argument.
  - Drbble 15y ago
    Maybe the reason programmers moved from cobol to OO is because they found OO better? Staying with Cobol was an option?
    - gruseom 15y ago
      It would have been if pre-existing software (libraries) were the dominant factor.
  - rbarooah 15y ago
    I'm not so convinced. There was a time when most people had grown up with procedural code. OO offered enough promise that people moved over to it and developed things like Cocoa or Java. If people aren't moving on, it's not simply because of 'intertia'. It's because the alternatives aren't offering enough benefit yet.
    - gruseom 15y ago
      I think that's nearly entirely untrue. Emotional attachment to what one already knows is the dominant factor - all the more dominant because, in our zeal to appear rational, we deny it. What will change the paradigm is the desire of a future generation to make its mark by throwing out how the previous generation did things. One can see this trying to happen with FP, though I doubt FP will reach mass appeal. When you do anything as intensely as writing software demands, your identity gets involved. When identity is involved, emotions are strong. The image of being a rational engineer is mostly a veneer on top of this process. Edit: 'intertia' - your making fun of an obvious typo rather illustrates the point.