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

11–20 of 253 posts

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

#11

Post by ktRolster »

willtim wrote: post #10
seanmcdirmid wrote: post #8

Earlier quoted context omitted.

Ya. Lots of people think OO equals C++ and Java, but that is like evaluating FP on the basis of Haskell alone.

Agree that Java and C++ are poor examples. However, OOP fundamentally results in a combinatorial explosion of state, which makes programs difficult to reason about. This can be useful in some niche applications but does not make a good general approach. The best part of OOP is arguably its support for first-class modules, but this feature could in theory be added to a functional language. EDIT: the reason why there i…

OOP fundamentally results in a combinatorial explosion of state

I'd be interested in knowing what theory you are basing this on. In practice, I have never seen this combinatorial explosion of state, but maybe that's just me.

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

#12

Post by gnaritas »

willtim wrote: post #10
seanmcdirmid wrote: post #8

Earlier quoted context omitted.

Ya. Lots of people think OO equals C++ and Java, but that is like evaluating FP on the basis of Haskell alone.

Agree that Java and C++ are poor examples. However, OOP fundamentally results in a combinatorial explosion of state, which makes programs difficult to reason about. This can be useful in some niche applications but does not make a good general approach. The best part of OOP is arguably its support for first-class modules, but this feature could in theory be added to a functional language. EDIT: the reason why there i…

> However, OOP fundamentally results in a combinatorial explosion of state

Eh, no it doesn't. I think you need to expand on that statement because it isn't remotely true in my experience.

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

#13

Post by exDM69 »

eksemplar wrote: post #5

> Studying the copious literature of OO, the central features which define an OO system seem a little ill-defined. I didn't know opinion pieces could be disguised as academia. Of course the article has some interesting points about human memory, but that's why we have things like single responsibilities.

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

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

#14

Post by willtim »

robertkrahn01 wrote: post #7
kccqzy wrote: post #3

C++'s implementation of OO isn't that good to begin with, mainly due to compatibility concerns. Perhaps we should look for a better OO language for comparison, say Smalltalk.

Indeed! And not every language that claims to be OO actually follows the basic ideas [1,2]. So, Smalltalk, as e.g Squeak [3] or Pharo [4] is a good place to start looking and learning but also Erlang [5] and Clojure [6]. State is necessary not "evil" but needs to be managed well. And most OO-languages have, apart from the assignment operation, no abstractions for. [1] http://wiki.c2.com/?AlanKayOnMessaging [2] http:/…

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 explicit. This makes it easier to manage and control state.

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

#15

Post by Ace17 »

exDM69 wrote: post #13
eksemplar wrote: post #5

> Studying the copious literature of OO, the central features which define an OO system seem a little ill-defined. I didn't know opinion pieces could be disguised as academia. Of course the article has some interesting points about human memory, but that's why we have things like single responsibilities.

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

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

#16

Post by willtim »

ktRolster wrote: post #11
willtim wrote: post #10

Earlier quoted context omitted.

Agree that Java and C++ are poor examples. However, OOP fundamentally results in a combinatorial explosion of state, which makes programs difficult to reason about. This can be useful in some niche applications but does not make a good general approach. The best part of OOP is arguably its support for first-class modules, but this feature could in theory be added to a functional language. EDIT: the reason why there i…

OOP fundamentally results in a combinatorial explosion of state I'd be interested in knowing what theory you are basing this on. In practice, I have never seen this combinatorial explosion of state, but maybe that's just me.

Every object in OOP is potentially stateful, some are made stateless and immutable but most are not, you need to read the docs. If I build a composite object Z from objects X and Y, the set of possible states Z has is a product of the set of possible states X and Y have. No complicated theory, just basic mathematics. I spent many years building OOP systems before moving on to FP. I strongly disagree with the claim that it is easy to manage state in OOP!

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

#17

Post by Ace17 »

willtim wrote: post #10
seanmcdirmid wrote: post #8

Earlier quoted context omitted.

Ya. Lots of people think OO equals C++ and Java, but that is like evaluating FP on the basis of Haskell alone.

Agree that Java and C++ are poor examples. However, OOP fundamentally results in a combinatorial explosion of state, which makes programs difficult to reason about. This can be useful in some niche applications but does not make a good general approach. The best part of OOP is arguably its support for first-class modules, but this feature could in theory be added to a functional language. EDIT: the reason why there i…

The combinatorial explosion of state is only problematic if some parts of your program can actually "see" the global state resulting from the combinations, and thus, depend on some specific combinations in an undesirable way. In this case, you might have a design issue.

This is exactly one of the problems encapsulation and abstraction aim to solve, and has nothing to do with OO: you could also create a combinatoric explosion of possible behaviours by dynamically composing pure functions.

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

#18

Post by B4TMAN »

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 been learning OO design and I would like to see what functional programming has to offer. Where do I begin?

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

#19

Post by willtim »

gnaritas wrote: post #12
willtim wrote: post #10

Earlier quoted context omitted.

Agree that Java and C++ are poor examples. However, OOP fundamentally results in a combinatorial explosion of state, which makes programs difficult to reason about. This can be useful in some niche applications but does not make a good general approach. The best part of OOP is arguably its support for first-class modules, but this feature could in theory be added to a functional language. EDIT: the reason why there i…

> However, OOP fundamentally results in a combinatorial explosion of state Eh, no it doesn't. I think you need to expand on that statement because it isn't remotely true in my experience.

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.
Post reply on HN