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

151–160 of 253 posts

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

#151

Post by brudgers »

logicallee wrote: post #142
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 t…

If writing is thinking (and googling "writing is thinking" quote produces plenty of hits), then object oriented code reflects the way we think because we write it...I mean thinking in terms of object orientation is pretty a given in order to right object orientated code. That's a different proposition than object oriented programming reflects the primary way humans think or the only way humans think.

Without diving deep into the uncanny valleys of existential philosophy surrounding trying to be both observer and observed, there is a big leap from I am thinking in objects right now to Everyone always thinks in objects [or something approaching it].

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

#152

Post by empthought »

mbrock wrote: post #149
willtim wrote: post #94

Earlier quoted context omitted.

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.

The question is if you mutate the variable, create a closure, mutate the variable, create a closure, and so on -- do those closures -- when executed -- each use the value that the variable had at the time the individual closure was created, or do they all use the latest value that the variable had? Scheme (and other academic languages) do the first, Python (and other scripting languages) do the second.

But the problem with program comprehensibility comes from doing these gymnastics with block scope and anonymous functions in the first place. The right thing to do is to give things proper names and interfaces.

In other words, both what Scheme does and what Python does are bad for reasoning about programs, precisely because the semantics of what should be done in this scenario are implicit and unable to be discerned solely by reading the code. Since either behavior is non-obvious, and understanding the program relies on this implicit behavior, the practice of mutating a variable while repeatedly creating closures over it should be avoided.

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

#154

Post by scroot »

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?

I think a lot of the "standard" objects in Smalltalk-80 are very elegant. In particular, have a look at the implementations of Boolean, True, and False (it has been posted to HN before). Clever.

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

#155

Post by icebraining »

jcelerier wrote: post #56
willtim wrote: post #39

Earlier quoted context omitted.

The fundamental feature that makes such an example easy is first-class functions. You are simply using objects to encode this and not making any use of their identify and mutable state.

> 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…

You can do that optimization in FP languages if you have unique types, ie, types that can only have one reference to them. You use the list as if it's immutable, by creating a new list with the new command and the rest of the previous list. But since the compiler can prove that the old list is no longer referenced, it can reuse it and simply make the update in-place.

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

#156

Post by MikkoFinell »

dyarosla wrote: post #111
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 veloc…

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, and this same issue permeates all aspects of the architecture.

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

#157

Post by squeeeeeeeeeee »

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…

> you're more likely to have been exposed to bad OO code than any other type simply because there's more of it

That's certainly true, but as someone who routinely has to go in and bugfix/maintain classes contaning thousands of lines of code (sometimes in themselves, more often collectively in their inheritance hierarchies), the simple presence of extensively used member variables often is a massive cognitive load. I'm not claiming that I'm some rockstar programmer who knows better, but from my experience working with other programmers, member variables might as well be called global variables.

tl;dr: Mutation, mutation everywhere.

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

#158

Post by tome »

jcelerier wrote: post #33
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…

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

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

#159

Post by logicallee »

brudgers wrote: post #151
logicallee wrote: post #142

Earlier quoted context omitted.

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 t…

If writing is thinking (and googling "writing is thinking" quote produces plenty of hits), then object oriented code reflects the way we think because we write it...I mean thinking in terms of object orientation is pretty a given in order to right object orientated code. That's a different proposition than object oriented programming reflects the primary way humans think or the only way humans think. Without diving d…

By that standard it is impossible for any type system not to match the way we think: for example a programming language could be abstracted in terms of food, recipes, and breakfast, lunch, and dinner, and express literally everything that way.

Although by your standard our code would then match the way we think, clearly this is not a useful takeaway.

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

#160

Post by Pica_soO »

SwellJoe wrote: post #101
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.

Actually reading the whole article takes time, while reading the title and posting a knee-jerk reaction takes only a moment. One of the curses of a hotness-oriented system like HN is that earlier comments receive the bulk of the upvotes and responses, so it becomes less interesting to comment as time goes on. There are lots of little rules in place to minimize the damage of this (like no memes, jokes, pics, etc.; HN…

one could make a sort of article captcha..
Post reply on HN