The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf] • Hacker News Board

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#41

Post by seanmcdirmid » Mon, Oct 06, 2014, 1:14 AM UTC

glurgh wrote: post #26

seanmcdirmid wrote: post #21

Earlier quoted context omitted.

Everyone reads these papers from different perspectives, so it's quite easy to say someone missed something (fair or not). My criticism is that an analysis of OOP is incomplete if you avoid looking at...objects. It's like saying, we are going to ignore the objects themselves, and just focus on the technical features of the objects to see what the technical advantage of these features are. It is very reductionist...wh…

We probably (broadly) agree more than disagree. One reason FP/OOP comparisons are difficult is that FP is closely related to a mathematical formalism while OOP isn't and can't be. I think the tack he's taking is 'can we explain the popularity of OOP in terms of "technical" or really, "practical programming/software engineering" advantages'. It's a tricky needle eye to thread. The objection 'that approach can't lead t…

Ah, I never said he took this approach out of ignorance. I've talked about this with him before, and never found his arguments lacking.

It is nice that something is still going on in OOP.

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#42

Post by [deleted] » Mon, Oct 06, 2014, 1:15 AM UTC

jamii wrote: post #36

chipsy wrote: post #13

I agree with the idea that the abstractions provided are "inevitable." I disagree with the idea that the way we're using them is optimal. I've just spent time in my code reducing polymorphic classes into simpler type identifier + record combinations. The rationale I am going by is that every class I introduce proliferates new symbols: the class definition, the instances, the methods, the values, the references to yet…

Bitsquid recently had an interesting 3-part post on the design of the entity system for their game engine: http://bitsquid.blogspot.com/2014/08/building-data-oriented-... http://bitsquid.blogspot.com/2014/09/building-data-oriented-... http://bitsquid.blogspot.com/2014/10/building-data-oriented-... Data is stored in flat, homogeneous blobs and linked together by integer ids instead of pointers.

[deleted]

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#43

Post by seanmcdirmid » Mon, Oct 06, 2014, 7:07 AM UTC

jamii wrote: post #40

seanmcdirmid wrote: post #37

Earlier quoted context omitted.

Alot of work in glitch goes into solving this problem. In the new case, we are able to form stable (reproducible) IDs through a memoized lexical stream (re-lex will produce the same tokens if possible) and by using the call stack (so the id is a path with special ids for loop indices). For a declarative (rule based?) language, perhaps rule firing context could be used for a similar purpose; I'll try to look at that p…

For largely the same reason that relational databases need identity. The classic example is the users table. Everything about the user, from their username to their email address, can be changed. So you need some way to stably reference that user. In the timeless Tarpit/Edelweiss world, the current state of the program is a pure function of its inputs. That means that the id has to be deterministically derived from t…

Isn't that effectively mutation then? You have an ID with information related to that ID that changes, or what we would call mutable fields in the object world. Anyways, this is why I don't play with declarative programming models anymore: I would wind up hacking in necessary things like identity and mutation in very weird ways. This is why I decided instead to try applying declarative time semantics to an imperative programming model.

Your solution is quite similar to mine: all blocks that continue in after clauses underneath an event are indexed by the event instance (we memoize event instances so they have identifiers). One problem that we had to deal with is the discrete nature of an event handling context; it made sense to have an additional clause that continues after the event (to create an object like a new user) vs. code that executes discretely (like a physics step). The former gets indexed by the event instance, the latter is shared across all event instances (so you can't really create an object in anything other than a top-level block of event-after block).

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#44

Post by jamii » Mon, Oct 06, 2014, 7:59 PM UTC

seanmcdirmid wrote: post #43

jamii wrote: post #40

Earlier quoted context omitted.

For largely the same reason that relational databases need identity. The classic example is the users table. Everything about the user, from their username to their email address, can be changed. So you need some way to stably reference that user. In the timeless Tarpit/Edelweiss world, the current state of the program is a pure function of its inputs. That means that the id has to be deterministically derived from t…

Isn't that effectively mutation then? You have an ID with information related to that ID that changes, or what we would call mutable fields in the object world. Anyways, this is why I don't play with declarative programming models anymore: I would wind up hacking in necessary things like identity and mutation in very weird ways. This is why I decided instead to try applying declarative time semantics to an imperative…

I'm not sure where you got the idea that we are proposing a language where nothing ever changes :p

Both Bloom and Edelweiss are ideas about how to model time/change declaratively ie without having to specify control flow or incidental ordering. That doesn't seem to be too different to Glitch. Whether you think of imperative code pushing updates to data structures or declarative code pulling updates from stream is a matter of perspective. Either way, you still have to figure out how to order and combine those updates.

Bloom takes the approach that each fact is true at an explicit point in time, so rather than mutating in place you simple define the state at time T+1 in terms of the state at time T. Both states are simultaneously accessible so you don't have to worry about what order the changes happen in.

Edelweiss takes the approach discussed in Out Of The Tarpit where the true state is just the list of input events and everything else is an incrementally maintained view over these events. Edelweiss makes this practical by analysing datalog code to determine when an input event can no longer contribute to the state of the system. This is roughly analogous to GC, except that instead of relying on pointers to determine unreachability it uses static analysis. The appeal of this model is that you can always explain the state of system to the programmer by tracing backwards through the views.

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#45

Post by seanmcdirmid » Mon, Oct 06, 2014, 11:51 PM UTC

jamii wrote: post #44

seanmcdirmid wrote: post #43

Earlier quoted context omitted.

Isn't that effectively mutation then? You have an ID with information related to that ID that changes, or what we would call mutable fields in the object world. Anyways, this is why I don't play with declarative programming models anymore: I would wind up hacking in necessary things like identity and mutation in very weird ways. This is why I decided instead to try applying declarative time semantics to an imperative…

I'm not sure where you got the idea that we are proposing a language where nothing ever changes :p Both Bloom and Edelweiss are ideas about how to model time/change declaratively ie without having to specify control flow or incidental ordering. That doesn't seem to be too different to Glitch. Whether you think of imperative code pushing updates to data structures or declarative code pulling updates from stream is a m…

I don't think you are, and neither am I. What we both want is controlled change, we are just going about it from different directions.

I'm still trying to get a handle on Bloom and this discussion is useful, thanks! Glitch is based on the same GC analogy but does a pure dynamic analysis: input events generally never wash out of the system since they are often clock ticks that step a physics simulation :)