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