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

131–140 of 253 posts

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

#131

Post by willtim »

tempodox wrote: post #126
willtim wrote: post #68

Earlier quoted context omitted.

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.

There is an ANSI standard for Common Lisp, though. And ML and OCaml have a “reference” type that was built for the explicit purpose of having mutable contents.

The ML/OCaml reference type is an opt-in feature with its own type and explicit syntax, it is not the default used pervasively everywhere. That's the key difference that makes ML programs easier to reason about.

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

#132

Post by yen223 »

maxxxxx wrote: post #121
yen223 wrote: post #119

Earlier quoted context omitted.

Store a list of actions, and represent your state as a sum of said actions. That way, no matter what the action is, "undoing" an action is literally just popping it off the list. actions = [append("The"), append(" quick"), append(" brown"), append(" fox")] state = reduce(actions, some_combiner) // This might give you a string "The quick brown fox" If you pop the last element `append(" fox")` of the actions and rebuil…

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 constraints in mind, OO-style code brings nothing to the table.

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

#133

Post by throwaway413 »

krapp wrote: post #110
SwellJoe wrote: post #101

Earlier quoted context omitted.

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…

> but it can't force people to actually read the articles before responding They could hash the title for a minimum time, or until at least three comments are posted. That would at least force people to click the link to find out what's there, and filter out commenters too lazy to do even that.

Or just force the user to click the link before the comment box is enabled for that posting.

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

#134

Post by smichel17 »

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…

I wonder if there are other mitigation techniques that would be effective. For example, hiding all comments for the first N hours of a post's life, then showing all comments at once. This way, the incentive is towards writing the best comment you can, quickly _enough_.

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

#135

Post by sds2 »

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

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

#136

Post by dyarosla »

jwdunne wrote: post #122
dyarosla wrote: post #111

Earlier quoted context omitted.

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…

Thank you - I think this was probably the inspiration or seed for what I was thinking :) I was amazed when I saw the ECS architecture when I filled my toe into game development. I remember wanting to apply it to other areas outside of game development. It's interesting though that a paradigm that intends to help simulate the real world has been eschewed for speed and maintainability in favour of something like ECS in…

Yeah it's an interesting pattern and even when implemented in an OOP language ignores most OOP ideas in favour of what is really more akin to data-driven design.

There's some great insight into how the pattern evolves in non-game projects here:

https://softwareengineering.stackexchange.com/a/306983/27143...

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

#137

Post by mgkimsal »

throwaway413 wrote: post #133
krapp wrote: post #110

Earlier quoted context omitted.

> but it can't force people to actually read the articles before responding They could hash the title for a minimum time, or until at least three comments are posted. That would at least force people to click the link to find out what's there, and filter out commenters too lazy to do even that.

Or just force the user to click the link before the comment box is enabled for that posting.

then waiting X minutes before enabling the comment box too, to avoid just clicking and posting?

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

#138

Post by willtim »

tempodox wrote: post #124
willtim wrote: post #52

Earlier quoted context omitted.

Functional programming languages do not capture mutable state in closures.

> Functional programming languages do not capture mutable state in closures. Yes, they can. In ML, you can build a function that returns a set of closures that manipulate or use shared mutable state. I'm quite sure you can do something equivalent in Haskell, too. As always, “it depends” whether you would actually want to do that.

The reference type in ML/OCaml is an opt-in feature, a container with it's own special type. In Haskell, you can also capture IORefs or similar, but any reads/writes to them are effectful and captured in the types. The point is that Python does this all the time as the default. Any captured variable could potentially change under your feet. It is rarely useful and most beginners do not expect it, hence it is commonly considered a "gotcha".

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

#139

Post by seanmcdirmid »

ettoretorti wrote: post #84
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…

There's more to the everyday definition object oriented than having functions operating on in-memory data structures. Two other features that are commonly included are subtyping through inheritance and encapsulation. If we stick to your definition C functions operating on structs qualify as OO, and I don't think many would agree with that.

My first exposure to OOP was in C using structures to hold function pointers as a pattern. You can do OO in C without C being OO. There is a huge semantic difference between doing OO and a language at supports OO, the article is referring to the former rather than the latter.

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

#140

Post by brudgers »

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.

Is a discussion of the discussion healthier?
Post reply on HN