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

61–70 of 253 posts

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

#61

Post by jcelerier »

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.

The problem with this approach is that different domain experts will have different definitions of what "is" a frog. If you ask a theologist, a molecular biologist, and a zoologist to define a frog, you'll certainly get three different but valid answers.

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

#62

Post by exDM69 »

Ace17 wrote: post #15
exDM69 wrote: post #13

Earlier quoted context omitted.

But it is not an opinion. There is no universally accepted definition of OO let alone a formal, axiomatic definition, and that makes it ill-defined. If you disagree, point to a definition of OO that you think is "correct".

I suggest to look at Alan Kay's definition, since he's the one who invented the term "object oriented". http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

Well, Alan Kay's definition is just one definition and as evidenced by the rest of this thread, it's far from being universally accepted and definitely not the definition used in the mainstream "OO" languages.

Further, that email thread is far from being a formal definition. In that email there's a pointer to a ISO standard doc, but that's hardly authoritative either.

It seems like every language (and every programmer) has their own idea of OO, which is why I consider it quite apt to call it "ill-defined". That's not to say that OO programming itself is bad, more that the term "OO" is bad.

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

#63

Post by akvadrako »

jcelerier wrote: post #61
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. The problem with this approach is that different domain experts will have different definitions of what "is" a frog. If you ask a theologist, a molecular biologist, and a zoologist to define a frog, you'll certainly get three different but valid answers.

That's not a "problem" - that just means you have different frogs - each with a well defined criteria.

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

#64

Post by willtim »

mpweiher wrote: post #54
willtim wrote: post #14

Earlier quoted context omitted.

OOP does not offer true state encapsulation, it just hides it. Objects are always potentially stateful when reasoned about externally. This means that all objects in your system could potentially contribute to the global state space, resulting in a combinatorial explosion of state. This makes programs difficult to reason about and is not a good general approach. In contrast, functional programming makes state explici…

> not offer true state encapsulation, it just hides it. That's kind of the definition of encapsulation. > difficult to reason about This is repeated as a mantra without any backup. Most people find state trivial to "reason" about. What becomes more difficult are certain types of proofs that nobody actually does. > [FP] makes it easier to manage and control state No, not "easier". In fact, incredibly more difficult. J…

> That's kind of the definition of encapsulation.

State encapsulation, at least in FP, means that the state is not visible externally. For example a pure function that uses mutable state in its implementation. Such state does not contribute to the sytem global state.

> This is repeated as a mantra without any backup.

The more global mutable state your application has, the harder it is to reason about. That should be fairly obvious I think.

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

#65

Post by jcelerier »

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…

indeed, there has been a small essay on this: http://www.lispcast.com/object-oriented-vs-functional-duals

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

#66

Post by yetihehe »

MarkMc wrote: post #24
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.

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…

In functional programming you would store actions in lists with funs/closures inside those data. For example in erlang list of undo actions would look like this:

  Undo = [ { RemoveJpeg, JpegData} ]
where RemoveJpeg is a fun (like closure) and JpegData is what would be given as argument to this fun. The implementing undo looks like this:

  undo_action(Document,[UndoHead|UndoTail]) ->
    {UndoFun,UndoData} = UndoHead,
    UndoFun(Document,UndoData).
Isn't it simple? RemoveJpeg just returns modified document. undo_action knows only that every action should take two arguments and return modified document.

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

#67

Post by jwdunne »

jcelerier wrote: post #61
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. The problem with this approach is that different domain experts will have different definitions of what "is" a frog. If you ask a theologist, a molecular biologist, and a zoologist to define a frog, you'll certainly get three different but valid answers.

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 argument is that this is why OOP suffers: it makes the taxonomy inherent to the object and all best OO practice tries to work around that. "Composition over inheritance" anybody?

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

#68

Post by willtim »

jcelerier wrote: post #58
willtim wrote: post #52

Earlier quoted context omitted.

Functional programming languages do not capture mutable state in closures.

So LISP and Caml aren't functional programming language nowadays ? Because both allow you to modify what's in a closure.

There is no language definition or implementation called "LISP". Both Scheme and OCaml lexically capture variables by value, as if they have been passed in as arguments. This is not how it works in e.g. Python.

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

#69

Post by icc97 »

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…

One of the main points of design patterns is composition over inheritance. Composition is also a major part of functional programming.

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

#70

Post by jcelerier »

jwdunne wrote: post #67
jcelerier wrote: post #61

Earlier quoted context omitted.

> 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. The problem with this approach is that different domain experts will have different definitions of what "is" a frog. If you ask a theologist, a molecular biologist, and a zoologist to define a frog, you'll certainly get three different but valid answers.

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 boss says "okay, seems that our software interests molecular biologists too, but they need to have another 'molecular frog view' with properties Foobigate and Brozigate to study them properly at the molecular level. Of course the 'molecular frog view' has to be in sync with the 'pond frog view', also they want a simple readable save format.". Now, how do you set up your code so that Joe programmer that comes next week can be operational on the code in three days ?

Post reply on HN