wishing of reactive programming in ruby
in [Ruby]
|
From: ashishwave on 17 Aug 2007 10:30 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 bye :-) Ashish ashishwave(a)yahoo.com.
From: Trans on 17 Aug 2007 12:17 On Aug 17, 7:34 am, ashishwave <ashishw...(a)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. T.
From: benjohn on 17 Aug 2007 12:35 > > > On Aug 17, 7:34 am, ashishwave <ashishw...(a)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
From: Dan Zwell on 17 Aug 2007 12:44 ashishwave wrote: > 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 > > > bye :-) > Ashish > ashishwave(a)yahoo.com. > I haven't used reactive languages, but can't this be emulated by using methods and instance variables? To emulate: c = a+b; c.reactive = true use: def c; @a+@b; end Then you could pretend c was a variable. To reset the value, just redefine c(). It would be simpler if all variables were methods, not instance variables. If you wanted, you could write a wrapper for that, so that set_reactive("c", "a + b") or set_reactive("c=a+b") would wrab a call to class_eval or instance_eval that defined the method as "def c; a() + b(); end". If you did this, however, you could never set a, b, or c by simple assignment. A big problem might be parsing the input. I could elaborate on some suggestions. (I wrote code that converts standard arithmatic notation to reverse polish notation, which is very easy to evaluate. You could also do a simpler scheme like not allowing more than one operation.) Let me know if you are interested. And let me know if I'm not grasping reactive programming correctly--I've never used it. Dan
From: James Edward Gray II on 17 Aug 2007 13:16
On Aug 17, 2007, at 11:44 AM, Francis Cianfrocca wrote: > 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. Are you aware of the Omnibus Concurrency Library? http://rubyforge.org/projects/concurrent/ > (This in fact was precisely the reason that the EventMachine > library was developed, and it's still on the roadmap.) To someone like me who has been looking at Erlang recently, this is very interesting. Can you share and of your plans for how EventMachine might evolve into this? I'm just curious. James Edward Gray II |