Does OO really match the way we think (1997) [pdf] • Hacker News Board

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

#111

Post by dyarosla » Sat, Aug 12, 2017, 1:46 PM UTC

jwdunne wrote: post #53

I think the big problem with OOP is that it's designed to simulate the real world but has the real world backwards. Real world objects are a composition of parts. The taxonomy of those objects, and its constituent parts, is am artificial construct independent of how those objects are composed. A frog is a frog because it fits some definition that experts agree on. The taxonomy comes afterwards - the composition just…

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 velocity component (position could hold x,y,z values and velocity vx,vy,vz values) could be operated on by a movementSystem (which adds behaviour to any entities that have both a position and velocity component, and updates position values based on velocity values.)

The nice thing about such a system is that the taxonomy as you call it gets defined when you instantiate the systems of your program. If you have entities with position and velocity components but dont want to use a movementsystem to operate on them, you simply dont instantiate the movementsystem. Pretty flexible, but not used excessively outside of video games.

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

#112

Post by OtterCoder » Sat, Aug 12, 2017, 1:47 PM UTC

jondubois wrote: post #98

theboywho wrote: post #92

I've noticed most HN comments transformed from being discussions about the _content_ of the article to comments discussing the _topic_ of the article being posted, not sure if this is healthy, but the risk is HN becoming an echo chamber where people discuss opinions, and the posts becoming just topic triggers. We'll see how it evolves.

That's true but the HN algorithm for deciding what articles make it to the front page has itself become very political. For example, the amount of articles about programming languages like Rust or Elixir is disproportionate compared to their actual relevance in the industry. HN has a very strong bias for functional programming. You almost never hear about Go or Node.js anymore except when there is a major release but…

I would agree with Pavlov. I would also say that Rust is a much more disruptive and interesting language from a technical perspective. Node is simply another iteration on quick prototyping languages, like Ruby before it. There's not a lot of new stuff to say about its design. Projects built in node show up in the feed all the time though.

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

#113

Post by pjmlp » Sat, Aug 12, 2017, 1:49 PM UTC

nonsince wrote: post #79

jcelerier wrote: post #33

Earlier quoted context omitted.

> Rust "feels" OO but isn't. If you write C#7 or Swift and avoid inheritance and prefer immutable types as long as possible - how OO is your code then? Both are 100% object-orientated (and in the case of Rust, also 100% FP is reachable I'd say. Not knowledgeable enough in C# to say). Do they have in-memory data structures with attached functions that do useful work with this object's state (not necessarily mutating i…

Rust is neither OO nor FP, it's procedural (like C and Fortran) but borrows concepts from OO and FP. OO requires data structures to support dynamic dispatch, and although you can have dynamic dispatch in Rust via trait objects your code is heavily gimped - no generics, you can only pass by reference, lifetimes have to be explicitly annotated, etc. It feels like OOP-emulating C code from back in the day. Likewise, if…

Contrary to mainstream knowledge there isn't one single truth of what OOP or FP actually are, rather multiple approaches of applying a set of abstract concepts.

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

#114

Post by [deleted] » Sat, Aug 12, 2017, 1:51 PM UTC

jcelerier wrote: post #70

jwdunne wrote: post #67

Earlier quoted context omitted.

That's just a problem of context. With the taxonomy separate, the objects can be different things in different contexts. With de facto OOP, you have no hope in hell because the taxonomy is hard coded to the structure of the object itself. My point is supported by what you say, in fairness. A taxonomy is artificial and separate to the actual object itself. It can and is different based on who defines the taxonomy. My…

> That's just a problem of context. With the taxonomy separate, the objects can be different things in different contexts. Except that you want to share properties between those different contexts, and this is where hell begins. For instance (for a more programming-related problem) say that you have a gui application with graphical objects that map to your frogs,say a frog pond simulation. Now months passes and the b…

[deleted]

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

#115

Post by pjmlp » Sat, Aug 12, 2017, 1:51 PM UTC

BoiledCabbage wrote: post #4

OOP did more to set back program design than anything else I can think of. It was incredibly wrong, has sent so many smart minds down a poor path. If for example functional has taken prominence in the 90s we'd be in a much better place now.

You mean the functional path from Lisp with CLOS and FLAVORS?

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

#116

Post by jwdunne » Sat, Aug 12, 2017, 1:52 PM UTC

filoeleven wrote: post #109

jwdunne wrote: post #76

Earlier quoted context omitted.

Yep, exactly! We now have a bunch if OOP languages that provide language features for inheritance making it easy but composition is an emergent property entirely based on existing language features - it's not a language feature itself. What I'm saying is flip it on its head. Build an OOP language where you have features to make composition easy and separate the taxonomy as a separate thing that shouldn't be tied dire…

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 envisioned a system where it's perfectly possible to work with purely anonymous taxonomies i.e your behaviours specify explicitly what its parameters have in terms of behaviour e.g if an object parsed a string, we could expect that the parameter has just the behaviours needed to do the work e.g length, substring, equality. Or we could just say it wants a string (which is just a separate alias that says an object has those things - like an interface except you don't have to declare you're implementing it).

I think there is value in being able to see an object you want to be part of a taxonomy fits the bill - this would be more like interfaces. Maybe it's better left to static analysis (stop! you're trying to pass an object that doesn't have behaviour X to behaviour Y that expects it).

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

#117

Post by pjmlp » Sat, Aug 12, 2017, 1:52 PM UTC

Tehnix wrote: post #42

MarkMc wrote: post #24

Earlier quoted context omitted.

I have the polar opposite view. I love OOP because it provides a way to elegantly solve so many problems. To take a concrete example, consider the undo-redo mechanism in a text editor. It seems natural to create a list of objects with each object representing the action that can be undone or redone, and a pointer to the most recent action object. Undoing executes the 'undo' method and moves the pointer to the previou…

Heh, check out time-travel debugging and be amazed at how simple a much more powerful “undo” can be made when purity is involved (in FP langs, e.g. Elm or Haskell). Seriously though, design wise there was not much you said that was specific to OO. Take for example: - all actions are a data type - the history is a list of actions (in LIFO style for the purpose of simplicity here) - undo pops the list and puts undo in…

Already present in Smalltalk, Lisp and Mesa/Cedar development environments at Xerox PARC, no need for FP advocating for it.

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

#118

Post by krylon » Sat, Aug 12, 2017, 1:53 PM UTC

yen223 wrote: post #108

A common sentiment expressed in threads like this is that people can write bad code in any language, therefore language doesn't matter. While that may be true, I don't think judging a language by the worse parts is a useful exercise. I'd rather judge a language by its best parts. To that end, can someone point to me an example of object-oriented code that they feel is elegant?

At work, I am currently working a program that needs to read XML messages from a message queue, and depending on the type of message extract several pieces of data from it and write them to a specific list in a SharePoint server.

I wrote an abstract base class that contains all of the boiler plate code for dealing with SharePoint, and then one subclass for each type of message I need to deal with; those subclasses only need to override a few methods to deal with the fields from the XML message and with the specific SharePoint list they need to write to.

It is not great (the task is just too dull for that), but I am happy with the approach I have chosen because I can add support for new message types fairly easily.

That being said, I do not think OOP is the answer to all (programming) questions, nor is it the worst idea ever. Some programs can be expressed in terms of objects and inheritance very easily, just as some can be expressed in functional terms very easily.

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

#119

Post by yen223 » Sat, Aug 12, 2017, 1:53 PM UTC

maxxxxx wrote: post #86

Tehnix wrote: post #42

Earlier quoted context omitted.

Heh, check out time-travel debugging and be amazed at how simple a much more powerful “undo” can be made when purity is involved (in FP langs, e.g. Elm or Haskell). Seriously though, design wise there was not much you said that was specific to OO. Take for example: - all actions are a data type - the history is a list of actions (in LIFO style for the purpose of simplicity here) - undo pops the list and puts undo in…

Isn't the real difficulty of undo the implementation of the undo method for each action? T The action list seems easy.

Store a list of actions, and represent your state as a sum of said actions. That way, no matter what the action is, "undoing" an action is literally just popping it off the list.

  actions = [append("The"), append(" quick"), append(" brown"), append(" fox")]
  state = reduce(actions, some_combiner) // This might give you a string "The quick brown fox"

If you pop the last element `append(" fox")` of the actions and rebuild the state, you can easily see that the new state "The quick brown" is simply the old state without the last action, i.e. an "undo".

If rebuilding the state is expensive, it is not hard to devise caches around state management under this model.

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

#120

Post by dyarosla » Sat, Aug 12, 2017, 1:54 PM UTC

jwdunne wrote: post #75

jcelerier wrote: post #70

Earlier quoted context omitted.

> That's just a problem of context. With the taxonomy separate, the objects can be different things in different contexts. Except that you want to share properties between those different contexts, and this is where hell begins. For instance (for a more programming-related problem) say that you have a gui application with graphical objects that map to your frogs,say a frog pond simulation. Now months passes and the b…

I love how much this comment makes me think. Thank you! To be honest, this sounds like a hell hole no matter what you did. It's a complex program that services two domains. I would say that in the real world, a frog studied in a pond and frog studied at a molecular level share the same properties. A frog is a complex object that has many parts. Naturally for a pond view, you provide the properties needed for that, th…

As I mentioned above, an Entity Component System would have no issue solving this. You'd add the molecular frog components (foobigate and brozigate) to wherever you create frog entities and then you'd also create and add a system that synchronizes between the entities that have pond frog components and these new components. None of the original code would change minus the instantiation function for a frog entity. Similarly simple change goes for the save format.