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

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

#201

Post by slackingoff2017 » Sat, Aug 12, 2017, 5:34 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…

>It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog.

This is known as structural typing and TypeScript does exactly this. Two objects with the same properties are the same.

This usually works well, but there are a few issues with this. Number one is related to optimization. The type system that results from using structural typing is unsound. This doesn't matter for typescript since it compiled down to JavaScript which has no types anyways, but for a typical VM executed language there's many optimizations the compiler can't do.

The second issue with structural typing is what I like to call the "mixin problem". If you get too flexible with composition it becomes close to having no type system at all.

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

#202

Post by Others » Sat, Aug 12, 2017, 5:43 PM UTC

slackingoff2017 wrote: post #201

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…

>It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog. This is known as structural typing and TypeScript does exactly this. Two objects with the same properties are the same. This usually works well, but there are a few issues with this. Number one is related to optimization. The type system that results from using structural typing is…

Is it true that all structural type systems are unsound? I was under the impression this is a typescript specific problem.

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

#203

Post by d0mine » Sat, Aug 12, 2017, 5: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…

Different languages encourage different OOP styles e.g., Go language encourages composition.

Though people may argue on the meaning of OOP https://groups.google.com/forum/#!msg/golang-nuts/bSXry29pNo...

Direct link: http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

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

#204

Post by skrebbel » Sat, Aug 12, 2017, 5:49 PM UTC

tome wrote: post #172

skrebbel wrote: post #59

Commenting more on this thread than the article: in my opinion, the idea that OO and functional are somehow at odds with each other is misguided. There is little about OO that doesn't mesh well with functional ideas, and vice versa. The core concept of most OO designs is that data is coupled with the methods that operate on that data. There is absolutely no reason why that can't work with immutable data and pure func…

> The core concept of most OO designs is that data is coupled with the methods that operate on that data. I've read this a lot, in this discussion and elsewhere, for years. But what does it mean? Does it mean data is syntactically coupled with state? Otherwise I don't get why pretty much any C program is an OO design by this definition.

Many C programs are OO by this particular definition :) I take the least ambitious definition of OO on purpose, because that definition is often the one that matters the most. I mean message passing yada yada, if you look at most OO software out in the wild, the key feature is the syntactical coupling between nouns and the verbs that operate on those nouns.

Extra bonus though, compared to eg C, is that in OO languages you don't need to spell out the type (plus polymorphism ofc). So String_trim(&myString) becomes myString->trim() and that's shorter and, most of the time, equally clear and less noisy.

I miss this most when coding Elixir.

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

#205

Post by brabel » Sat, Aug 12, 2017, 5:51 PM UTC

avodonosov wrote: post #189

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).

A `Door` is not an agent, so no, it can't open itself (unless it's a game and your doors have agency).

When you say a door can be opened, you are making the assumption that the door is installed in some sort of building. But then, the door is a component of that building, not just a stand-alone door. It can only be opened in that context.

So I would suggest something like this:

    class Door(Material, Size)
    class Room(List, Size)
    enum DoorState { Closed, Open, Locked }
    class RoomConnection(Room, Room, Optional, Size)

To open the door, you don't need a method in any of these "data" classes, you just need to update the door state given there's a door in a room connection you're interested in.

The room connection may or may not have a door, and that could change over time. If it does have a door, then the door must have a state (but not all doors have a state, only the ones that are in a Room Connection, possibly others).

Notice that to update the room connection, you don't need mutable state locally... you just need a way to provide a new RoomConnection to code where opening a door may be possible (normally, you're given a RoomConnection as an input, and you might give a new one, basic FP style but OOP can also operate in that way).

So, I don't think it's that hard if you know what you're doing.

I don't want to even comment on the suggestion to have a `Man.open(Door)` method :) that's really not good.

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

#206

Post by zaphar » Sat, Aug 12, 2017, 5:58 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…

I'm not sure where this meme on HN that Rust isn't OO comes from but it's based on a definition of OO that is almost never applied by day to day programmers and it's disagreed with by a fair number of language theory people.

Rust has encapsulation, message passing in the smalltalk/OO sense, and polymorphism. It does this through objects with attached methods, and traits. In every way that actually matters to a working programmer Rust is OO.

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

#207

Post by jcelerier » Sat, Aug 12, 2017, 6:05 PM UTC

tome wrote: post #166

jcelerier wrote: post #56

Earlier quoted context omitted.

> You are simply using objects to encode this and not making any use of their identify and mutable state. Most software with undo-redo will show you some metadata related to the action (for instance "Undo 'Drag stuff'", "Redo 'Set text in bold'"...) so you have to have a way to associate metadata with the "undo / redo" functions; the class is a good tool for this. Also, a common optimization is to alter the head of t…

> If command objects are immutable, every time the mouse moves, you have to pop the head of your stack and push a new command instead (which may be a waste of resources) Have you profiled that?! :)

yes, actually, it used to eat 30% of the CPU on a software I worked on because of malloc-fest when moving the mouse quickly across the screen and dragging multiple objects.

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

#208

Post by jwdunne » Sat, Aug 12, 2017, 6:06 PM UTC

dragonwriter wrote: post #200

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 the big problem with OOP is that it's designed to simulate the real world I actually think that it's more designed to reflect (one particular idea of) the way humans construct mental models of the real world. > Real world objects are a composition of parts At the lowest level, sure, but if our aren't modelling quantum physics, the “parts” are abitrary artificial divisions (or aggregations), not part of the…

Food for thought. Your comment shows a wide range of knowledge and covers things I haven't thought about.

I was reading about the history of Simula and how the majority of OOP features originated there. It was built as a simulation language, hence the name. I took from that it was designed to simulate the real world - I guess based on the below that's akin to simulation of mental models.

I did briefly think about the quantum mechanics rabbit hole. You make a good point. I'll think about this more. People can tell what a radio is because they have a general idea of what a radio does - has a speaker, volume, aerial. This is what led my thinking.

I'll think more about this.

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

#209

Post by jcelerier » Sat, Aug 12, 2017, 6:16 PM UTC

tome wrote: post #158

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…

> Do they have in-memory data structures with attached functions What do you mean by "attached function"?

I meant that a semantic value in the code (a variable for instance) "carries" functions with it, as methods.

e.g. in a C API:

    struct foo {
      // dispatch
      void (*do_stuff)(int);
      int (*get_stuff)(const char*, void* context);
    };

    // attached functions
    void foo_do_operation1(foo*);
    int foo_do_operation2(foo*, int);

or C++ which allow to conflate both forms but restricts the first with inheritance

    struct foo {
        virtual void do_stuff() = 0;
        virtual int get_stuff(std::string, a_better_type_than_void_ptr&) = 0;
        void do_operation1();
        int do_operation2(int);
    };

or JS where everything can change whether you want it or not

    var v = new Object;
    v.do_stuff = function() { ... }
    v.get_stuff = function(str, something) { ... }
    v.do_operation1 = function() { /* v is available in the closure */ } 
    etc...

or OCaml modules:

    module foo = 
      struct
        let do_operation1 = ...
        let do_operation2 x = ...
    end

in every case, some state is mentioned first, and then some code is bound to this state; then, the language (except in C where it is only a convention... even though some people can get fairly "creative" with macros) provides a way to call the code with a given variable of type `foo`.

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

#210

Post by jcelerier » Sat, Aug 12, 2017, 6:18 PM UTC

seanmcdirmid wrote: post #143

wfunction wrote: post #71

Earlier quoted context omitted.

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…

OOP is all about the nouns while FP/procedural is all about the verbs. That's it really: are you modeling your system in terms of objects (nouns) or behavior (verbs)? It is super easy to tell just by looking at the names in your code. Semantic features only play supporting roles, they don't define the paradigm.

that's a nice definition