From: Francis Cianfrocca <garbagecat10@...>
Date: 2007-08-18T01:44:25+09:00
Subject: Re: wishing of reactive programming in ruby

------=_Part_130743_16284844.1187369068531
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 8/17/07, benjohn@fysh.org <benjohn@fysh.org> wrote:
>
> >
> >
> > On Aug 17, 7:34 am, ashishwave <ashishw...@gmail.com> wrote:
> >> ruby integrates power of functional programming from lisp , purest OO
> >> from smalltalk, prototype oriented power from self etc etc into one
> >> single language
> >>
> >> i just was wondering that whether the heavy developers/users of
> >> reactive languages like kanaputs or reactive-C etc will ever get
> >> reactive features in ruby.
> >>
> >> in kanaputs, If the variable 'c' is defined as  c = a + b; and if the
> >> reactivity of 'c' is set (c.reactive = true;), then each time the
> >> value of 'a' or 'b' changes then the value of 'c' is updated as the
> >> result of the addition
> >
> > That's interesting --a form of rational programming (like Prolog).
> >
> > But I think it is far outside the scope of Ruby's design.
>
> I'm about to go home. Damn.
>
> I've been very interested in reactive programming for about 10 years,
> although I've never heard of it reffered to as such. The Empirical
> Modelling group at Warwick University did a lot of work on it in a
> language called EDEN. They called it Definative Programming (think
> reactive is a much better name, as it happens).
>
> It's entirely possible to build a library in an imperative language that
> will provide reactive programming capabilities. I've previsouly used a
> similar idea for a GUI application in C++, and it made implementation of
> pretty complex change propagation very easy.
>
> My recent thinking is that reactive programming shares a great deal with
> software transactional memory, and could share a lot of infrastructure.
>
> Something the Empirical Modelling group at Warwick found was that
> Reactive Programming is also very useful for making systems that are
> composable. They could often take a few models they'd built, and easily
> combine them, make a few other changes, and come up with a new useful
> model. This is curious because composability is also a strong advantage
> of STM.
>
> My personal opinion is that reactive programming is _the_ pattern for
> building any kind of interactive software (ie - something that doesn't
> just process a batch of data, but reacts to user initiated changes to
> its state, or changes from an external system). As an approach, it's got
> a lot of overlap with:
>
>   Model View Controller pattern and Observer, etc,
>   Spreadsheet change propagation,
>   Database Triggers and propagation.
>
> Basically, you just don't need to think about the complexity that's
> caused by propagating changes through a program. It really is pretty
> dramatically cool :-)
>
> Cheers,
>   Benjohn
>
>
>
>

I'm well aware and very respectful of the respect that many informed people
have for STM, but in my experience it's challenging to implement and
maintain in the real world.

I've always been a partisan of loosely-coupled systems that use idempotent
messaging. I'm still hopeful that such a thing will come to Ruby. (This in
fact was precisely the reason that the EventMachine library was developed,
and it's still on the roadmap.)

I'm not a mathematician so I can't prove this, but I have a hunch that all
of these approaches are equivalent in some deep sense, and the practical
considerations should drive the choice. (The exception of course is
distributed object models.)

------=_Part_130743_16284844.1187369068531--