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

121–130 of 253 posts

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

#121

Post by maxxxxx »

yen223 wrote: post #119
maxxxxx wrote: post #86

Earlier quoted context omitted.

Isn't the real difficulty of undo the implementation of the undo method for each action? T The action list seems easy.

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.

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

#122

Post by jwdunne »

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…

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 game development, which is all about simulation.

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

#123

Post by sukruh »

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?

The discrete event simulator and the circuit simulation using it in Odersky's book[1] had caught my attention as neat.

[1] http://www.artima.com/pins1ed/stateful-objects.html

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

#124

Post by tempodox »

willtim wrote: post #52
jcelerier wrote: post #32

Earlier quoted context omitted.

State doesn't magically disappear in FP. It just isn't given a name but it's still here, in your closures.

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.

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

#125

Post by jwdunne »

dyarosla wrote: post #120
jwdunne wrote: post #75

Earlier quoted context omitted.

I love how much this comment makes me think. Thank you! To be honest, this sounds like a hell hole no matter what you did. It's a complex program that services two domains. I would say that in the real world, a frog studied in a pond and frog studied at a molecular level share the same properties. A frog is a complex object that has many parts. Naturally for a pond view, you provide the properties needed for that, th…

As I mentioned above, an Entity Component System would have no issue solving this. You'd add the molecular frog components (foobigate and brozigate) to wherever you create frog entities and then you'd also create and add a system that synchronizes between the entities that have pond frog components and these new components. None of the original code would change minus the instantiation function for a frog entity. Sim…

I guess what I'm calling for is a language that directly supports ECS :) it's currently a pattern that works well and any good pattern should be one a language feature.

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

#126

Post by tempodox »

willtim wrote: post #68
jcelerier wrote: post #58

Earlier quoted context omitted.

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.

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.

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

#127

Post by pjmlp »

yetihehe wrote: post #66
MarkMc wrote: post #24

Earlier quoted context omitted.

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

In Smalltalk:

    RemoveJpeg
As possible implementation of undo could be

    undoAction: document with: undoList
    undoList do: [:aBlock| 
       aBlock value: document].

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

#128

Post by thegeomaster »

cousin_it wrote: post #55

No comment about OO in general, but I think Java/C# is a damn fine language design, avoiding many problems of newer paradigms. Here's an example: 1) Java: starts out with one opaque string type, because that's what OO methodology says. Changes the internals when needed. All clients continue to work forever. 2) Haskell: starts out with strings as exposed linked lists of characters, because functional methodology says…

The String and &str thing is a common criticism of Rust, but I feel it's a bit shallow when said without context. Maybe it's just me, but it makes sense when you consider Rust's ownership semantics (which are a new idea in language design, so you can't really look at how other languages solved issues arising from them).

Basically, when you have the notion of ownership/lifetime in a language, you have to make a distinction between an owned and a borrowed thing. When you pass an owned thing to a function, you give up your ownership of it, and can't use it anymore. When you pass a borrowed thing, you keep the ownership, and the compiler tries to prove that, based on ownership info it has, it lives long enough for the operation to be safe. Just as String and &str are owned-borrowed counterparts, you also have e.g. Vector and &[u8] (the former is an owned vector, the latter is a read-only, borrowed view into that vector) and many more examples of this dichotomy.

I don't see how this could have been solved in Rust without having those two types.

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

#129

Post by boramalper »

pjmlp wrote: post #113
nonsince wrote: post #79

Earlier quoted context omitted.

Rust is neither OO nor FP, it's procedural (like C and Fortran) but borrows concepts from OO and FP. OO requires data structures to support dynamic dispatch, and although you can have dynamic dispatch in Rust via trait objects your code is heavily gimped - no generics, you can only pass by reference, lifetimes have to be explicitly annotated, etc. It feels like OOP-emulating C code from back in the day. Likewise, if…

Contrary to mainstream knowledge there isn't one single truth of what OOP or FP actually are, rather multiple approaches of applying a set of abstract concepts.

This, a million times. Any (meta) discussion on OOP without giving a precise definition of it is futile, for the devil lies precisely in those details that are omitted from the discussion.

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

#130

Post by pjmlp »

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.

Apparently we went through some magic event that only Haskell is entitled to be the one and only functional programming language.
Post reply on HN