Deprecating the Observer Pattern | Hacker News Reader

Deprecating the Observer Pattern

infoscience.epfl.ch

I found this and given the usual interest in all things Scala and functional programming on HN, thought I'd share it.

tl;dr - functional reactive programming is a nice abstraction which addresses many of the flaws in the observer pattern, especially as it is often employed in UIs, and can be implemented quite nicely in Scala.

slight correction,this is about reactive programming not functional reactive programming. the latter deals primarily with continuous time objects. although the way you used it arguably should be the correct way

In Section 4 they introduce continuous time and FRP is the result of Section 5.

Yes! One thousand times yes!

Having first class EventSource objects is far superior. Would love to see the ideas from this paper make it into the mainstream of UI frameworks.

I don't quite understand the finer points of the article, so can somebody answer: is there a more fundamental suggestion in it than 'switch to signals' (which I for this purpose roughly define as 'type-safe generic callback abstractions')? If so, what is it?

That is Section 2, which describes how to make observers more composable and thus simpler to use.

The problem solved in Section 3 is to use some cleverness in your compiler/runtime to make it so you can write a state machine as straight line code but have it wait for signals to arrive and run in parallel with other code without having to think about it.

The Reactor described on the second column of page 4 enables this. Notice the difference with the previous column, and even more so with the first example. You are no longer tracking any state (starting/disposing moveObserver or adding/removing moveObservers) but just writing the code as if you can wait forever for the signals and then respond to them.

This looks really nice, but depends on some compiler features that most languages do not have (continuations and/or tail call optimisation) so it is unlikely to make it into other languages soon.

Section 4 describes time-varying instead of discrete signals, so that Section 5 can then describe how to unify time-varying and event-based signals into a framework, which is (the already invented but not widely used) functional reactive programming. The types make it much more exciting than the Scheme implementation though. Section 6 shows how this is/could be actually implemented.

Thank you. I re-read with this in mind, but I can't really follow the examples since I don't know Scala nor any other functional language. Is it correct to say that the paper is more about 'advanced' uses of signals (and only mentions observers in passing), and from section 3 on relies on the parallellisation features of the language and runtime to create an event-driven state machine?

I'm still not sure how they use 'reactive programming' and 'inversion of control' in relation to each other - it seems that what they call 'reactive programming' is 'inversion of control', no?

Reactive programming seems like an excellent model for game programming (I know Haskell uses Yampa for this). I am surprised there isn't a canonical Scala implementation that is easily available. From my searching on the web, it looks like there are a couple of frameworks, none of which are particularly active.

I recall reading that FRP might be included in scala 2.10

I recall someone mentioning that the Haskell implementations of FRP suffer from various performance problems. Anyone know if those issues are relevant here too?

Seems overloaded. Found a possible alternative:

http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.p...

Scribd link is fine for me: http://www.scribd.com/doc/64224686/Untitled?secret_password=...

For those that use C# or Javascript, there are the Reactive Extensions here:

http://msdn.microsoft.com/en-us/data/gg577609

F# has had this built in via the notion of first class events. im on my phone so I can't says more than its easy to underestimate how easy this style makes things

Implementing Actors, and by extension the Observer pattern, is just so ridiculously easy in Scala.

observers.foreach(o => o ! myEvent)

...and you're sending asynchronous events to each of the observers. With Akka, you can have those actors running basically anywhere and have the messages automatically routed to them. The obvious question is-- can this Reactor trait be applied via Akka to external machines?

They left an essential part out of the description: the scheduler. Is there a description written somewhere?

PDF is clunky, difficult, and dangerous. Why allow posts to it?

Because reading it in pdf is better than not being able to read it at all.

They call those papers.

Reply on news.ycombinator.com