Hacker News Reader

Hacker News

Comment by mpweiher | Hacker News Reader

Parent Full thread

mpweiher

Hmm...

"Event Driven Services

1. Receive and React (or not) to facts

2. Publish new facts (immutable events)

3. Invert the control flow"

How is this different from "objects receive (or ignore) messages, send new messages, invert the control flow"?

Except of course for the new and shiny.

"Mutable State Needs to be Contained (within the service)"

-> (mutable) state is contained within objects

"Use the Event Stream as the Consensus Fabric"

-> TeaTime, David Reed's Multi Version Concurrency Control

etc.

Have we really not understood OO at all so that we have to reinvent it all the time? Or maybe this should be seen as a validation of those principles, because we keep coming back to them even when we don't know it.

View on HN

> Have we really not understood OO at all so that we have to reinvent it all the time?

We haven't. I think the popular OO languages shows this. In both Java and .Net the focus is on classes, not on messages passed between objects. But class hierarchies are not essential for message passing. Classes are mainly a way of decomposing an application into manageable logical parts of interacting chunks. Looking at how many language features center around classes and class hierarchies (interfaces, abstract classes, generics, inheritance etc) as opposed to how many facilitates different forms of interactions between objects (you basically have method calls and arguably async/await) it seems clear to me that these languages are more "class oriented" than object oriented...

I think it is more a matter of people not understanding their tools.

React UI? Smalltalk already had Observer and event messages.

java.util.Observable exists since version 1.0.

Interfaces are lousily based on Objective-C categories, and the first edition of "Component Software: Beyond Object-Oriented Programming" using Component Pascal, COM, Java was published in 1997.

The second edition added C# examples.

Which are concepts that now everyone is discussing as Entity–Component System.

Our field would be much better if there was less pop culture and more book/paper reading.

EDIT: forgot to add the publishing date

I think everybody's talking about messages, but you can choose to encode messages as direct method-calls versus indirect data-objects, e.g.:

watchers[0].customerNameChanged(this, old_name, new_name);

emit_for_whomever(new CustomerNameChanged(this,old_name, new_name));

The second version actually has more classes being defined and objects being created. However, it comes with quite a few benefits in terms of documentation, duplication, persistence, deferring, batching, etc.

Can you expand on how messages ideally get passed around between objects? Is there a good example in python (if not Java or others is fine)? Thanks

> Have we really not understood OO at all

The problem is that whenever we think OO, visions of Alan Kay and Smalltalk float into our heads and suddenly Everything Is An Object. Numbers "know" how to add themselves to other numbers, strings "know" how to print themselves to standard output...

...insanity ensues. We wake up, write a blog post about how OO failed and discard it all, only to repeat the cycle when we notice that some of the sane things we're doing look entirely as if we were doing OO.

This is a highly insightful comment. Thanks! I find the TeaTime stuff fascinating, but is know they only a handful of people have ever heard of it. Do you have any pointers for reference?

Reply on news.ycombinator.com