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

141–150 of 253 posts

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

#141

Post by maxxxxx »

yen223 wrote: post #132
maxxxxx wrote: post #121

Earlier quoted context omitted.

Makes sense. But i don't see how this is related to OO vs FP then. Putting all your actions into a list is easy. Replaying is easy. The main problem is caching the state which can become tricky no matter OO or FP.

You're right in that nothing about this is specific to OO or FP. However, under this model, you really don't want your actions in the actions list to change after the fact. That means those actions in the list really shouldn't be modeled as "objects" with object-like mutable internal state and all. In fact, you'd probably need them to be as lightweight as possible, which means no sticking methods on them. With those…

I think this unfortunately goes into the same direction a lot of political discussions tend to go. Two rigid philosophies and one has to win. In the real world either one can work if applied correctly. And both can learn from each other.

FP brings a lot of interesting concepts to the table that are useful. But I doubt that people that screw up OOP will screw up less with FP

In the end competent and disciplined (in my view the number one attribute of a good dev) people will produce good software with any paradigm. Clueless people will cause problems no matter what the tool is.

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

#142

Post by logicallee »

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.

But I came here to read commentators' statements on the subject. I only clicked the paper due to your comment. The paper makes the claim, early, "[OOP's] central premise appears to be that it matches the way we think about the world."

This is the same as the title, and enough for us to discuss. I want to hear what people here have to say about the subject. That's a lot more interesting than what this 1997 paper has to say on the subject. (Of course, people can comment about that as well.)

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

#143

Post by seanmcdirmid »

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…

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.

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

#144

Post by mbrock »

willtim wrote: post #105
maxxxxx wrote: post #88

Earlier quoted context omitted.

"In this way, OOP would benefit from composition-first, taxonomy after. An object is a thing because of what it has (and this includes behaviour too), not because of what it is or descended from." A lot of working programmers have figured this out already. Most experienced programmers I know don't use much inheritance.

Unfortunately OOP languages typically lack sum types, the mathematical dual of product types (objects with just fields). This means subtyping and inheritance is often needed to encode sum types.

In functional languages it's easy to run into difficulties with extending a sum type without changing the defining module.

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

#145

Post by mbrock »

mjfisher wrote: post #22

In reaction to some of the comments popping up re. OOP and functional programming: I've come across quite a bit anti-OO sentiment in my career now, and not nearly as much anti-functional sentiment. I suspect that the prevalence of OOP has something to do with it - you're more likely to have been exposed to bad OO code than any other type simply because there's more of it. People often seem to draw an artificial disti…

A few years ago, most programming forums I visited considered OO the normal good way, and FP arcane, slow, and basically useless. This opinion seems to have turned. Basically Haskell was too cool to ignore so everyone played with it on the weekends, while Clojure, React, and Erlang promoted functional patterns for pragmatic system development...

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

#146

Post by macintux »

sds2 wrote: post #135
alkonaut wrote: post #28

OO solves some problems and creates others. One must remember that the competing paradigm isn't functional programming but imperative procedural programming. Very large code bases in C, Fortran, Cobol aren't all that nice either. It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Many of OO's flaws are being addressed and are even missing from new languages. Rust "feels" OO…

> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...

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

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

#147

Post by [deleted] »

sds2 wrote: post #135
alkonaut wrote: post #28

OO solves some problems and creates others. One must remember that the competing paradigm isn't functional programming but imperative procedural programming. Very large code bases in C, Fortran, Cobol aren't all that nice either. It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Many of OO's flaws are being addressed and are even missing from new languages. Rust "feels" OO…

> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...

[deleted]

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

#148

Post by humanrebar »

macintux wrote: post #146
sds2 wrote: post #135

Earlier quoted context omitted.

> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...

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.

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

#149

Post by mbrock »

willtim wrote: post #94
empthought wrote: post #90

Earlier quoted context omitted.

Python has had closures exactly the same as Scheme and OCaml since the year 2000. What it lacks is a multiline anonymous function syntax. See PEP 227: https://www.python.org/dev/peps/pep-0227/

No they are not exactly the same. From the link you posted: "all uses of the name within the block are treated as references to the current block" The Python folks call them "late binding closures" and they are frequently discussed as "gotchas". Essentially lexically scoped variables are captured as references to mutable state. Java did not make this mistake, perhaps because they had Guy Steele (of Scheme fame) on th…

Wait, isn't that exactly how lexical scoping in Scheme works?

That's how you implement "objects" using lambdas. You make closures that mutate their closed-over bindings.

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

#150

Post by empthought »

willtim wrote: post #94
empthought wrote: post #90

Earlier quoted context omitted.

Python has had closures exactly the same as Scheme and OCaml since the year 2000. What it lacks is a multiline anonymous function syntax. See PEP 227: https://www.python.org/dev/peps/pep-0227/

No they are not exactly the same. From the link you posted: "all uses of the name within the block are treated as references to the current block" The Python folks call them "late binding closures" and they are frequently discussed as "gotchas". Essentially lexically scoped variables are captured as references to mutable state. Java did not make this mistake, perhaps because they had Guy Steele (of Scheme fame) on th…

> It is a questionable default that ultimately just destroys ones ability to reason about programs.

If that destroys one's ability to reason about programs, then one never really had the ability to reason about one's programs in the first place.

It's not like nested block scopes are some boon to program comprehensibility anyway.

Post reply on HN