

Deprecating the Observer Pattern - calebmpeterson
http://infoscience.epfl.ch/record/148043/files/DeprecatingObserversTR2010.pdf

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

~~~
Dn_Ab
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

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

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

------
roel_v
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?

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

~~~
roel_v
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?

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

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

------
cskau
Seems overloaded. Found a possible alternative:

[http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.p...](http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf)

~~~
DanielRibeiro
Scribd link is fine for me:
[http://www.scribd.com/doc/64224686/Untitled?secret_password=...](http://www.scribd.com/doc/64224686/Untitled?secret_password=9q0dekkn0ruhohd8xt#full)

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

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

~~~
Dn_Ab
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

------
mark242
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?

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

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

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

