Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does OO really match the way we think (1997) [pdf]

leshatton.org

Post reply on HN
Print view View original

181–190 of 253 posts

Re: Does OO really match the way we think (1997) [pdf]

#181

Post by tzs »

wfunction wrote: post #71
mpweiher wrote: post #57

Earlier quoted context omitted.

It absolutely is. OOP languages formalized this pattern and made it easy to use.

No, it absolutely is not. OOP has lots of well-known unique characteristics such as inheritance, dynamic dispatch, polymorphism, encapsulation, etc... as well other less-frequently-noticed semantic differences like the fact that the message-passing follows a subroutine model (which may be more difficult to appreciate if that's the only thing you're used to). Yes, you can do OOP in C, but just making a struct and defi…

This thread brings to mind an old quote:

  What is object oriented programming? My guess is
  that object oriented programming will be in
  the 1980s what structured programming was in
  the 1970s. Everyone will be in favor of it.
  Every manufacturer will promote his products
  as supporting it. Every manager will pay lip
  service to it. Every programmer will practice
  it (differently). And no one will know just
  what it is.
Tim Rentsch, "Object Oriented Programming", SIGPLAN Notes, v17, n9 (1982).

Re: Does OO really match the way we think (1997) [pdf]

#182

Post by tome »

barking wrote: post #51

I found this anti-oop video very persuasive. https://youtu.be/QM1iUe6IofM He also had a couple of follow up ones. Basically he blames java for oop's popularity. He maintains that oop's combining of methods and data is actually a fault and not a benefit. That every good oop promises apart from inheritance (which is bad anyway) is more easily achieved in procedural programming. OOP promotes endless meaningless abstract…

I'm sad you've been downvoted. I loved this video.

Re: Does OO really match the way we think (1997) [pdf]

#183

Post by bitwize »

MikkoFinell wrote: post #156
dyarosla wrote: post #111

Earlier quoted context omitted.

I think you'd benefit from taking a look at Entity Component Systems. Generally used for games, this programming pattern assigns behaviour to entities based on the components that they have. Moreover, neither entities nor components on their own actually own any behaviour. Behaviour occurs by systems that operate on entities with the associated component "signature". For example, an entity with a position and a veloc…

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, an…

Components do not belong to a system. Any system can access any component. Think of RDBMS stored procedures that operate on all rows matching certain criteria; don't think OO style encapsulated "methods".

The system only operates on entities that have all the components they need. So there won't be one rendering system but several: one for entities that require movement, one for those which do not, etc.

Re: Does OO really match the way we think (1997) [pdf]

#184

Post by lgas »

MikkoFinell wrote: post #156
dyarosla wrote: post #111

Earlier quoted context omitted.

I think you'd benefit from taking a look at Entity Component Systems. Generally used for games, this programming pattern assigns behaviour to entities based on the components that they have. Moreover, neither entities nor components on their own actually own any behaviour. Behaviour occurs by systems that operate on entities with the associated component "signature". For example, an entity with a position and a veloc…

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, an…

Why does a component need to belong to a system? Why can't the component belong to itself and just be used by multiple systems?

Re: Does OO really match the way we think (1997) [pdf]

#185

Post by bitwize »

humanrebar wrote: post #148
macintux wrote: post #146

Earlier quoted context omitted.

Wait, learning curve? Relative to C++ or Java?

You can write something that passes acceptance tests in C++ without a lot of effort. It's things like removing all the bugs, memory leaks, and undefined behaviors that requires enormous expertise. There is certainly a lot of ground to cover before C++ mastery can be had, but simple OOP and procedural programs aren't that bad.

> You can write something that passes acceptance tests in C++ without a lot of effort.

True for freshman-year

    std::cout
programs maybe. People's heads asplode when they get into C++ with any sophistication because they need to grasp several things at once: classes, inheritance and polymorphism, pointers (smart or not), value vs. reference types, etc. Java, JavaScript, and even Lisp go a long way toward hiding those details from the programmer.

Re: Does OO really match the way we think (1997) [pdf]

#186

Post by willtim »

imtringued wrote: post #173
willtim wrote: post #19

Earlier quoted context omitted.

I've now expanded on that statement. In my experience, working using OOP in large multi-million line codebases, the state issues have proven very true.

How can you know that without comparing the same programs with a FP version? What if those codebases would become messy even with FP simply because the problem they are trying to solve is difficult? Also in what way does OOP prevent you from writing the code in a FP-style? It doesn't because the concepts FP and OOP are orthogonal.

It is much harder to do functional programming in an OOP language, as one is often fighting the syntax, semantics and various defaults. For example all variables are typically by default mutable, null in every type, libraries and frameworks with pervasive mutable state etc.

Granted it has been getting easier as OOP languages have been slowly getting more and more functional features. But it really is easier to favour immutability and composition in a functional-first language.

Re: Does OO really match the way we think (1997) [pdf]

#187

Post by ryanbrunner »

jwdunne wrote: post #116
filoeleven wrote: post #109

Earlier quoted context omitted.

Would you say that Scala is close to hitting that target? I've only taken a cursory look at it, but its traits appear to satisfy composition and its type system looks pretty close to being a decoupled taxonomy. I'm not sure what a full implementation of a separate taxonomy would look like. Duck typing with an algebraic type system that is only applied when you ask for it?

I haven't looked at Scala closely. I'll take a look - thanks for the tip :) This is something I'm thinking about a lot. I've been wanting to sit down and sketch out what it would look like in terms of syntax / structure. Difficult with 3 kids, wife and a full time job. I think behaviours should be able to specify taxonomy, which in effect is a name for saying "I only accept objects that do this and have that". I envi…

I don't think what you're saying is really much at odds with many OOP languages. Unless I'm missing something, Ruby's mixins and duck-typing (care about what messages an object responds to rather than it's type) comes awfully close to what you're looking for.

Granted, something like duck-typing is more of a practice or pattern than something that's terribly well supported by the language (it's up to you to put safeguards that the object being passed to you does what you want it to do), but it's certainly possible and describes most well-written Ruby code.

Re: Does OO really match the way we think (1997) [pdf]

#188

Post by [deleted] »

MikkoFinell wrote: post #156
dyarosla wrote: post #111

Earlier quoted context omitted.

I think you'd benefit from taking a look at Entity Component Systems. Generally used for games, this programming pattern assigns behaviour to entities based on the components that they have. Moreover, neither entities nor components on their own actually own any behaviour. Behaviour occurs by systems that operate on entities with the associated component "signature". For example, an entity with a position and a veloc…

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, an…

[deleted]

Re: Does OO really match the way we think (1997) [pdf]

#189

Post by avodonosov »

How to model a door.

    class Door {
      void open() {...}
      void close() {...}
    }

    door.open().
But can a door open itself? Maybe

    Man petya = ...
    petya.open(door);
But can a door be opened if it's not installed? So walls should also come into play when we think about door and its methods.

It's difficult to model the world with OOP (at least in its current state).

Re: Does OO really match the way we think (1997) [pdf]

#190

Post by dyarosla »

MikkoFinell wrote: post #156
dyarosla wrote: post #111

Earlier quoted context omitted.

I think you'd benefit from taking a look at Entity Component Systems. Generally used for games, this programming pattern assigns behaviour to entities based on the components that they have. Moreover, neither entities nor components on their own actually own any behaviour. Behaviour occurs by systems that operate on entities with the associated component "signature". For example, an entity with a position and a veloc…

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, an…

I suggest you read more into component signatures and how systems decide which components to operate on.

Specifically, systems do not own components. Nor do they operate on full entities. Nor is there any coupling.

If you have entities that need to be rendered, you would give them a render component. A render system would render all render components that exist (thus 'rendering the entities' for whom those render components belong to)

If you have entities with positions but not render components, the render system would not operate on those entities.

Similarly if an entity has a render component but no, say, velocity component, it would not be registered to a movementSystem.

Systems that need to propagate data between components would have component signatures that include those components for which they need the data of. So a positionRender system would have an aspect of [PositionComp, RenderComp] and would be the only system to copy over data from one to the other.

There will always have to be a place that decides what object has which components. This should be as close as possible to the 'aggregate root' (a term from DI), and generally in ECS at the point of instantiation of the entity. I believe this question is prompted by a fundamental misunderstanding of ECS.

Post reply on HN