[originally published Jan 28, 2011]
Again we have yet another (software development) term which is very “En Vogue”. And this does not bother me a bit. I stopped being distracted by marketing long time ago.
What bothers me is when these tactics start polluting into the world of software design and development where I live too. Let me give you an very long explanation. Or leave now :)
Microsoft Developers relations department has new “paradigm” to sell. As ever, few “buzz words” are used to package the sell into the right-sized quasi academic wrap-up. What is “Reactive Programming” for Microsoft people hired to keep relations with (Steve Ballmers top priority) developers , warm and fuzzy … in a nutshell?
At least to me, it seems some bright and young developer, inside Microsoft, has one day discovered the Observer/Observable pattern. Everybody around her cubicle, got very excited. And then somehow .NET library called “Rx”, was promptly released. And this “Rx” library is now being sold to Windows Phone 7 and SilverLight developers, with the help of second buzz-word: “Observer, Design pattern”. And in that part of MSFT unverse there are a LOT of MVP evangelists and their blogs. And there is very large following indeed. Here is one explanation from one of them clever blogger ones:
The premise of Reactive Programming is the Observer pattern. This involves a subject and an observer that observes the subject.
And this is where my annoyance starts. When someone is trying to sell me “green bananas”. How and why did we came to “Reactive Programming” as the premise of the Observer pattern is beyond me? And this is the core of this article: My objection to misleading obfuscation around one indeed very simple and useful design pattern and programming idiom.
What exactly is misleading here? Well misleading is leaving out the whole history of OO patterns in general. And Observer pattern in particular. Because this is all left out from the selling pitch, general public is led to believe this is somehow a great invention of Microsoft’s uber-developers. Nobody ever said that, true, but nobody ever said anything to the contrary also. Not a single sentence mentions a seminal work on design patterns “Design patterns : elements of reusable object-oriented software”. Which I think is unforgivable obfuscation. I am sure someone will promptly prove to the contrary with a link to some obscure MVP blog. But why digging for such a necessary information which should be part of each and every general text on “Reactive Programming”?
Then (it seems to me) somebody else in Microsoft decided that “Rx.NET” is “original and awesome”, and is also ideal to be used to promote even more love that is emanating from Microsoft to all developers. As a consequence .NET evangelists are deployed to preach about “Rx.NET”, as yet another proof of the “love” of the Big Kahuna towards “it’s” good developers, who are developing by using Big Kahuna’s tools and technologies, too.
These days we indeed have a lot of (at least to me) annoying blogs full of “reactive programming” and this beautiful “silver bullet” design pattern Observer/Observable. All sounding very much like Observer pattern was invented by clever Microsoft-ees (no,no … not in early 1980’s) and like nobody ever before made any implementation worth mentioning. Pretty much the same “truth economy” approach as with MVC .NET upheaval. MVC pattern is invented in 1970’s (and used in first SmallTalk implementations). But regardless of that it is skilfully (re)packaged and made into the .NET “panacea” in 2010, for good little developers, slurping it up from evangelists and uber-developers. Who naturally are all working inside Microsoft. Because it is best for all of them, I guess.
The result is that we can enjoy pearls of wisdom and enlightened discoveries, form hundreds of blogs.msdn.com pages like this “pearl” for example:
As we should know, the model of the web is largely asynchronous in that we shouldn’t block for potentially long running operations. For example, we could have a large and potentially expensive collection to iterate through and process, which is in turn a blocking call. What if we could instead turn from these pull collections to a push model?
(Wysocki)
Wow ?! This guy has hit the nail on it’s head! I can see it now clearly ! Thank You, thank You … ! I must not ever again “iterate” over large collection during page load for example! How brilliant is this!
JavaScript : function call arguments as expressions
Never mind that actually almost nobody ever does this in the JavaScript DOM community. We are all doing this properly for at least last 10 years. Even before the term “AJAX” was invented. With very simple but effective, functional programming constructs based on window.setTimeout() or window.setInterval() , DOM functions. Which are in the DOM , since the day one of the DOM. And yes it is very rare to find a javascript code behind any browser page which does not start from (at least) inside window.onload, event handler function. I do not know about you, but I have never seen anything like this:
|
1 2 3 4 5 6 7 8 |
//hypothetical bad example var very_large_array = new Array(0xFFFF) ; for ( var j = 0 ; j < very_large_array.length; j++) do_something_complex( very_large_array[j] ) ; // window.onload = function () { alert("Wow this page has taken long to start?!") ; } |
What also annoy’s me to no end, is that now we have the .NET “C# brigade” telling us how to do things properly in JavaScript. How? Microsoft has released this rather naive JavaScript implementation, done by C# programmers. And over-engineered beyond belief. Namely “Reactive Extensions for JavaScript” aka RxJS. Believe me: this is not how JavaScript is to be used to make a library or anything else by anybody who understands JavaScript. I looked into the code. It is casual beginners JavaScript. I watched interview with that bright boy author. It is not his fault and name is irrelevant, and he already left Microsoft anyway. But why asking C# developer to write a JavaScript library, in the first place? I know there are at least few very good JavaScript programmer “inside” MSFT right now, who could make this into proper and modern JavaScript, inside one day. Bertrand Le Roy, is just one of them, that springs to mind. (oops, he left too )
Never mind that the whole DOM design and implementation is based on one hierarchical structure which is observable by the script code observing dozens of events emanating from the DOM document tree. Unfortunately (until MSFT came late to the scene) nobody thought it would be “awesome” to give a new name to this old and proven paradigm.
|
1 2 3 4 5 6 |
// Darn! Why did I not thought of some catchy phrase for this idiom // that I am using since 1997 (approximately) // I did not invented this, but never mind ... who would remember. window.onload = function () { alert("Voila: 'Reactive Programming' ?!") ; } |
Yes, same as you, I am wondering too, who the hell has this much enthusiasm and energy to spend it all in the wrong direction? And the very good example of “One Wrong Direction” would be Rx.NET (C#) transcoding into the RxJS. C# to JavaScript straight. That single fact on it’s own, reveals deep misunderstanding of JavaScript. And deep misunderstanding of C# too. Which OK , might not be that deep, but perhaps a simple consequence of working for MSFT.
Yesterday (somehow) I stumbled upon Jesse Liberty’s article (mainly on Windows Phone 7 + Silverlight) where he got very hot and excited on something that is called “Reactive Programming”. And yes, naturally, Jesse reveals to his fateful flock, there is .NET library for it called “Rx”. And yes, you guessed it, it is very easy to use Jesse says, especially from C#, because C# has all this brilliant features, like “lambdas”. Lambdas are invented in early 1960’s .. but never mind … let’s not disappoint just to disappoint. Although I have to say I enjoy exactly that, and I can’t explain why? And always when crushing some C# champions beliefs.
Where was I? Ok. I am still wondering what the excitement is all about when the core .NET “achievement” of this “programming paradigm” is quite easy and natural to understand and use, and to implement in any good functional language? This kind of design and programming is in regular use all the time in that “functional universe” too. Which I am sure must appear like “dark matter” universe to Jesse. I mean, I understand perfectly well why is it hard in C#, and thus looks very strange when a simple functional language solution is presented.
Let me show You some code now if I may. But in which language, in order to prove the point? The point being that it is very simple to implement “Reactive Programming” mechanisms in functional languages. Microsoft itself has released and (even more strangely ?), is actually promoting it’s own very good functional language: F#. But alas, I can not claim I am proficient in F#/ So, I will sadly revert back to JavaScript, if nobody minds too much?
Promoted as the good design and supported with unquestionable foundations in OO patterns, namely Observer/Observable, is the idea that every collection (yet another unnecessary abstraction) can be “observed”. That is: become “observable” by one or more “observers”. In the C# case “methods”. Nothing to dis-approve of, besides the MSFT sneeky “packaging” which makes it all sound like it was invented in there.
The further claim is that the immediate goody coming from that idea is that Observable can be seen as a place from where event’s are flying to observers. Thus one has a structure and workers working on that structure. All apparently working together, but in an asynchronous manner. This is all true. But please do understand, this is all already seen 30+ years ago; and is in widespread use in functional languages community since then. To you and me this is clearly Python or Erlang territory from early 1990’s. (Erlang: 1980’s)
But, OK then, I have promised I will be gentle with the C# generation. Enough of “rubbing it in”. Show us the code, now! Even if it is in the JavaScript!
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
// Our "reactive programming" solution (function(){ function dispatcher( fun ) { return function(v,i,a ){ // dbj.later does deferred fun() calling dbj.later(function() { fun(v,i,a ) ; }) ; } } // give every array instance a dispatch() function Array.prototype.dispatch = function ( cb ) { // use ES5 Array forEach() f Array.prototype.forEach.call(this,dispatcher(cb)); } }()); // test // callback function has to conform to ES5 // callbacks footprint. it has to receive three arguments // value, index of that value and the host array function callback(v,i,a) { a.pop() ; // try confusing us by shortening the array alert( // format is a simple string extension replacing every {0..99} // in a string, with its arguments "[{0}][{1}] = {2}nInput = {3}".format(a,i,v,arr) ) ; } var arr = [1,2,3]; arr.dispatch(callback); |
What? That’s it !? Well .. Yes, 90% of it at least. I warned you: it is simple when not thinking C#. But, hey wait a minute “pardner” ! How can above minuscule peace of scripting language be a solution in providing “reactive programming” idioms? Well, it simply can and it simply is.
Beside showing us the power of functional programming, this little piece provides us with the ability to asynchronously operate on a single structure (array) by one or more callbacks. Jesse (and others) says :
The three key points to “walk away with” are:
- Reactive Programming is a Push model rather than an “ask for” model
- Reactive Programming follows the Observer Pattern
- Reactive Programming shows its true value with asynchronous event handling
Here I have presented a JavaScript solution addressing all the points above.
- Push model : callbacks (C# delegates) are called and information is “Pushed” to them.
- The Observer Pattern : array is observable and callbacks are observers
- Asynchronous event handling: callback are called in async manner. Events are information they are called with.
Sorry but we have “callbacks” in here as the only “fancy” term. No “observers”. And no “collections” either. Only arrays and objects, which are btw more or less the same in JavaScript. And proven as enough to do anything. With a little help of a “function” object, of course. In this solution instead of using “asObservable()” as in Rx .NET library
|
1 2 |
// This is C# using Rx.NET var observable = some_collection.asObservable() ; |
Instead, I have implemented a function on the Array.prototype that sort-of-a “does it all”. It simply allows every JavaScript array to dispatch asynchronous calls to callbacks. There is no need for a compiled C# mumbo-jumbo in the back that will auto-magically call the observers when things are added to, or removed from “observable collection” … Simply prepare the callback and give it to Array’s dispatch() function. As a result callback will be called asynchronously for each member of the array given. As shown in the example above.
But what about the objects, sharp C# zealot might ask? Here is the (somewhat naive ) addition for objects:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// this is a big no-no ! Never extend Object.property // we do this just for illustration of JavaScript abilities Object.prototype.dispatch = function (cb) { // dbj.foreEach() applies callback to every property of the given object // if 4-th argument exist only 'own' non-inherited properties are used dbj.forEach(this,cb,null,1) ; } // this is preferential way Object.dispatch = function (obj, cb) { // dbj.foreEach() applies callback to every property of the given object // if 4-th argument exist only 'own' non-inherited properties are used dbj.forEach(obj,cb,null,1) ; } |
Just add the above inside the closure and enjoy.
|
1 2 3 4 5 6 7 |
function callback(v,i,a) { alert( "[{0}][{1}] = {2}".format(a,i,v) ) ; } var obj ={"a":2, "b":3 , "c":4 }; obj.dispatch(callback); // or use the preferred solution Object.dispatch( obj, callback ) ; |
Instant “Reactive programming” for active javascripter’s. Although it has to be said that in the JavaScript universe it is a big No-No to extend Object.prototype with anything. JavaScript purists would either implement Object.dispatch( obj, callback ) or would mandate object literals with property called “length” so that they can be also made into “observable” arrays. But that is way out of scope of this article, I am sure.
The point I am making here is that “Reactive Programming” terminology is not necessary in the JavaScript/DOM world. Folks in that world do everything that is covered in there, for at least, last 10+ years. And, equally importantly, they do it it in a much simpler but equally effective way.
Just say No to “RxJS” :)
31 thoughts on “JavaScript: Just say No to “Reactive Programming””
Thats the worst example of BS and arrogance that I ever read online.
Brilliant – I could care less what you said about Reactive programming, but I love the way you talk about the C# programmers (who are the modern-day version of Apple users with their arrogance and “we’re better than everyone else” crap). I would almost venture to say that C# programmers are just VB programmers (var, object, dynamic, …) who use curly braces and semi-colons. But at least VB programmers are humble about their language’s humbleness.
MSFT never said they “invented” any of these technologies. They just built them into their products and gave them to people – I don’t see whats wrong about that….It’s up to us to judge if we want to use them or not…No one is forcing you here.
The advances in unit testing alone that these frameworks have given the development community have been worth it.
If you read about Rx for .NET, you would know it’s written on top of PFX, which gives us a LOT more processing power in this multi core world, I don’t see you mention that anywhere…..
If you can’t take the time to study whats good about the technologies and the benefits they actually bring then more fool you.
Where did I say MSFT said they “invented” these “technologies” ? My “rage” was targeted to MSFT marketing Rx which to 95% of young and learning flock looks like MSFT invented these concepts. I still have not found a single MVP blog which clearly explains the history of Observer pattern? Or (even better) comparison to functional languages “reactive” solutions.
As far as technology is concerned, yes I know about PFX. So what? Herein lies the key weakness in the C# universe: over-engineering. Why PXF? Why Rx?
Using Python or Erlang one does not need additional abstractions to be able to do, elegant multi core solutions or similar “achievements” which are in C# world usually treated as “awesome”.
Rx contains nice and innovative ideas invented by people at MS Research, in particular Erik Meijer. If you believe Rx is a simple rediscovery of the subject/observer pattern, you’re in for a surprise, if you spend some time actually learning a bit about it.
Thanks Jarle,
Rx has great value for C# programmers because it hides the complexity of using C# in: asynchronous, observer/observable, and similar scenarios.
Why Eric has not used F# to “invent”? C# is perhaps over-engineered to the point of “getting in the way” vs “moving out of the way” so that one can produce effective and elegant but yet simple solutions, like one can do in F#, JavaScript, Python, etc. I am sure Eric, knows that … yet he has chosen C# ?
Rx also has great value for F# programmers, not only for C#/VB.
You quote “Jesse (and others)” about the main 3 points to walk away with wrt Rx. I disagree about these being the most important aspects of Rx, for me the main point of Rx (and much of good programming technology in general) is compositionality, which IMO is the beauty of Rx and its sole reason for existance. (No, your Javascript examples don’t measure up to this).
BTW: Rx didn’t start out with someone at Microsoft “discovering” the Observer/Observable pattern, like you hint at. It probably is more accurate to say it started out with someone at Microsoft discovering that Observable is the mathematical dual of Iterator, which was, AFAIK, a new discovery. (The GOF book don’t even mention that they are related.)
@Jarle, my post is focused on MSFT and MVP’s way of selling RxJS and selling C# with Rx. That selling strategy makes flock believe many things which are not true. Like for example you believe that Iterator abstraction is a “good thing”, which also made You believe that mathematical duality of the Iterator proves that Rx is a serious achievement. i do not know why have You singled Iterators out? Perhaps Rx “research” contains lot of that word? Iterator as a concept is superseded and proven as limiting. And yes, please do not argue with me why is it so.
Why F# and Rx are not match made in heaven? Well Rx has value for C# programmers because it is difficult to “do Rx” in class based languages and even more difficult to work in over-engineered class based language, like C#.
“3 point to walk away with” : talk to Jesse (and others) about that. I just copied these 3 points from Jesse’s blog. My JavaScript example solves all these 3 points. In a way which renders C# almost laughable. And RxJS.
Hope this helps.
I was referring to GoF (the Design Patterns book) style iterators, not STL-style iterators. The only relevance I can see regarding your STL-link is that one of the major reasons STL-style iterators are superseded is because they don’t compose well.
If you learn the core ideas of Rx you will see the beauty and relevance of the duality between iterators and observables.
I know that you just copied the 3 points from Jesse’s blog. Still my point remains that these 3 points don’t contain the crucial feature of Rx, which is compositionality. And which is where your Javascript examples fails.
BTW: F# and Rx is a nice match.
Hope this helps. :)
I tried to read it all and am almost successful, but am not able to figure out anything meaningful.
All Jesse is claiming that C# now support Rx which can be used in certain scenarios. A lot of people are using C# and it has many pros/cons over other language. Because some 60s language had implemented the concept doesn’t makes it irrelevant for C# or WP7 developers.
Beginning each post with a history lesson would be pretty stupid.
@anon,
I do care about MSFT and MVP’s being very clear as to who (might have) invented the Observer/Observable concept and when approximately. Otherwise I would not want to intrude into Your reality.
@Jarle
I am glad you are enjoying C#, “compositionality” of Rx and Rx and F# togetherness. Your tarot for today: “…You will travel far, and meet many interesting people…” ;)
Yikes. This was actually painful to read. Not because it had no substance but because it was the pot calling the kettle black. You talk like God’s gift to programming while saying C# developers are arrogant.
I think the ‘over engineered’ C# language actually makes things much easier to read. Case in point:
Observable.FromEvent(Search, "KeyUp" ).Throttle( TimeSpan.FromSeconds( .5 ) );
*From Jesse’s blog
With one line, I can attach to my search button’s Key Up event and handle it after the user has stopped typing for half a second. Easy to read. Easy to edit.
Different flavors though. I’m happy you like to use your pure languages.
@Jared … You have feelings which is a good thing. But You also have feelings for programming language, which is not that good, I am afraid.
Also one practical note: You forgot to mention to which other language You are comparing C# ?
Dusan,
1) I acknowledge your hatred of marketing ploys. They make me sick, too. MS is a huge culprit when it comes to acting as though they “invented” something (take for example the way they acted as though they invented tabbed browsing, when Firefox was busy taking over the browser market a few years ago).
2) A big problem with your rant is that you don’t acknowledge where RP actually comes from. It would have helped your point if you had. It seems no-one who replied here had a clue, either. RP was originally founded as FRP (functional reactive programming) in Conal Elliot’s FP work with animation; see Fran and his original paper written about it. It had nothing to do with anything so OO-based as events or any other typical OO design patterns for that matter. The basic concept of FRP is very simple, and that is that any system (read: set of functionality) is simply an addition of a set of other functionalities in some linear or parallel order. It is true that MS has twisted this as a marketing ploy, and is (in my opinion) misusing the term… I would certainly give what they are doing a different name, eg. “reflexive” rather than “reactive”. But others may disagree.
Dusan, apologies, I see you did mention the FRP aspect. I would have elaborated on it a bit more. It seems to me that most people who have their heads stuck up their OO-butts don’t really get it. (You can remove this and my previous comment.)
@Nick,
I hope You do not mind I published Your valuable comments. Thanks for persevering through my rant. I simply do not have enough time to rearrange this text, make it shorter, simpler and more effective and easier.
One interesting point You have opened too: the key weakness of “Design Patterns”, as presented by Gamma at all is the OO angle. I have to say that way back then, I too thought class based languages plus OO software design are the end of it all. How wrong I was. It took me the whole 10 years of C++ to realise what is wrong.
I think it is high time somebody comes out with the book titled “Functional Programming Design Patterns”.
Dusan
Hi Dusan,
No problem for publishing my comments, and good to read your response. I feel exactly the same way. I think that many developers trained to OO believe (as you and I once did) that classical OO is the only modular way to code. IMO the most modular code of all is available in functional (or even prototypal OO) languages, because the developer is not forced into a paradigm of combining data with logic — methods with members — which in essence is the first step to breaking true MVC, for instance. The MVC design pattern is a workaround to a fundamental flaw in the OO paradigm.
I’m currently writing a loose framework for MVC game development and have finally come to these realisations in the process, and after a number of years writing custom & framework-based MVC applications.
Best
Nick
Rx/Reactive Extensions is not observer pattern rebranded. It’s a framework for composing async collections (observables) in a way that’s analogues to the way you compose standard collections in .NET.
For eg., say you have a form with four inputs : name, email, website and comment. Using RX to expose the input values each value is typed IObservable and will notify observers when the property changes, standard observer pattern. But, now say you want your submit button to be enabled only when fields have a valid input. Whit RX you can do that simply :
name.Select(v => ValidateName(v)).CombineLatest(
email.Select(v => ValidateEmail(v)).CombineLatest(
site.Select(v => ValidateUrl(v)),
(a, b) => a && b),
(a, b) => a && b)
.DistinctUntilChanged().ObserveOnDispatcher().Subscribe(v => submit.Enabled = v);
Select turns every value coming trough name/email/site observables in to IObservable (map function) and CombineLatest combines two last values from each observable using && operator. I filter out any name/email/site value changes that don’t change the final result (validity) using DistinctUntilChanged.
ObserveOnDispatcher is there to make another point, .NET is multi threaded and all observable events could be coming from different threads, the framework takes care of the locking/synchronization and allows you to simply specify where you wan’t to run your observer. Subscribe creates the observer with the specified callback that updates the “Enabled” property.
The framework also gives other guarantees useful when dealing with multi-threaded/async code (event ordering for eg.)
Trivial example but IMO points to take away are :
* this allows you to compose multiple events in a single place, no need to create multiple handler functions
* no shared state to update, this is a trivial example, in a more complex case the number of things you need to keep track and places you need to update from can literally “explode” (for eg. see drag and drop implementations using RX)
* Javascript doesn’t have threads, locking/synchronization/scheduling is never an issue, threading increases the problem of updating shared state (exponentially :) )
* this is done using standard .NET collection/IEnumerable manipulation syntax – hence the duality and push/pull collections.
The terminology might seem BS to you but from a .NET perspective I can see where they are coming from and even tough they might get a bit overzealous in their videos/blogs when talking about this I can understand them, these are their projects, they look like they are doing something they like and I certainly get like that when I’m doing something I like.
@twiseen, thanks for Your comment. I am slightly confused? You say that “Rx is not Observable pattern re-branded” ? I am not saying it is. But it is at least 75% Observable pattern re-branded. Perhaps “they” should have IReactive instead of IObservable as the key interface :)
Seriously. I said this more than once on this page: I do not care about C# community being happy and congratulating each other on whatever they feel like congratulating. But. I do care a *lot* when they start thinking they can “teach” me/us things I/we know and use last 10+ years, as if they have invented them. I use functional languages + DOM environment and I do not feel C#+Rx are worth my time. And I do especially resent MPV missionaries trying to convert me into the “right faith” of C#.
Side Note: Funny, there is it seems, a curious lack of MVP endorsed F# Rx texts ?
Rx is built for solving composition problems in async message/event handling. When you are dealing with this sort of problems it’s implied that you know what the observer pattern is and I think it’s disrespectful to assume majority of .NET developers don’t know it. And again, that’s not what RX is about, it’s building on top of that pattern.
You say you like functional programming – well then you should be pleased about the RX and LINQ. This is essentially FP approach (IEnumerable/IObservable is a monad after all), the re-branding is done since they cater to the SQL/OO devs but it’s still the same thing integrated in to the rest of the framework. The snarky remark about ‘lambdas’ being there from 60’s is probably missing the point, the only comparable language I’ve found is Java and it’s not going to have lambdas for > 2 years (Java 8 IIRC). So all of the FP techniques C# has been doing for the last 5+ years won’t be viable in Java for another 2+ (this is not gloating, I wish they improve Java – better tools allow better solutions).
FTR I hate fan-boys too, but I like good technology, and I’m perfectly able to separate the BS from it once I get down to the code – IMO RX does bring good things to the table, maybe nothing revolutionary, but useful never the less – something that you might have overlooked – but should not dismiss because of ideological differences or other bs :) It might not be useful to you but ATM it seems you dismissed it before even looking at it beyond “hello world”. I can’t really say – since I don’t know what you do and I haven’t used JS version of RX – YMMV, still your criticisms seems disrespectful and out of context.
BTW. I also use python so I found this remark to be particularly strange
> Using Python or Erlang one does not need additional abstractions to be able to do, elegant multi core solutions or similar “achievements” which are in C# world usually treated as “awesome”.
Are you talking about message passing here ? CPython has a GIL so unless you go to an alternative implementation (Jython/IPython) or message passing/multiple interpreters route you can’t really build multi core solutions. I wouldn’t describe any of those methods as “elegant” and “without additional abstractions” when compared to RX/PLINQ :)
@twiseen, I do appreciate your involvement here. But I do not appreciate what seems as You auto-magically transforming Your opinions into facts. Saying all of this, still Your comments are welcome.
As for me being ‘disrespectful and out of context’, I beg to differ. It is M$FT attitude which is exactly that in this context. Selling us, what is essentially other peoples ideas and work and claiming in a covert way, it is the ‘good thing’ for us, and everybody else, is nothing short of arrogant and disrespectful.
In other words : “… RX does bring good things to the table …”, but please M$FT stay at your table :)
I made no strong factual assertions and used “IMO” to indicate that this is subjective/contextual so I assumed it should be clear without explicitly stating it, after all your entire post is based on subjective opinions and impressions (as it should be on a blog), I’m just adding a different perspective – HTH.
Perhaps slightly out of context.
What is childish on my side is to speak of M$FT as one single entity.
That is one very large company with some very bright technical people working for it.
But some of them are inevitably tasked with selling .NET, C# and similar “goods” … I do not envy them, especially when somebody from the same company drops F# in the middle of it all. It must be really challenging promoting VB.NET, C# and F# in the same time :)
I would suggest that you learn a bit more about Rx. I think you are a little misinformed about what it is. This might be due to poor marketing materials you got your hands on or a misconception you heard somewhere, but I would say that your portrayal of Rx is fairly inaccurate.
While the Observer pattern is involved with the raising and listening of events, Rx is much more than this. If Rx was just a rebranding of what we have today in .NET in the form of events (Observer/Listener pattern implementation), it wouldn’t be useful. What *is* useful is the way that you can compose Observables and schedule them to be executed in different ways.
This is what Rx is about… not the Observer pattern.
If you really want to know the science behind it, there is an excellent set of videos Eric Meijer did talking about the math behind it. The ideas they are implementing are ideas you can find in other languages, like Haskell. Here is one of those videos: http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Brian-Beckman-and-Erik-Meijer-Inside-the-NET-Reactive-Framework-Rx/
If you want to see a pretty good demo of some of the composability and behavior you can do in Rx, I would highly recommend this video by Bart de Smet:
http://channel9.msdn.com/Blogs/codefest/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-blues
And finally, because this idea is important to much more than just C#, you might be interested to check out RxJS, the javascript version of Rx. This is interesting because javascript is a dynamic language and it showcases what you can get from Rx even in a language like that. Here is a video about that: http://channel9.msdn.com/Blogs/Charles/Introducing-RxJS-Reactive-Extensions-for-JavaScript
I hope this was helpful.
@Anderson Imes
Thanks for the balanced comment. I thought I was clear in that I was not happy with RxJS primarily, and than with C# generally.
As I am not happy with anything or anybody working under the assumption that it is OK to simulate Classes in JavaScript. And then in top of that folly starts selling me anything.
As for me being mistaken about Obesrver pattern vs Rx, I beg to differ. It is what Jesse Liberty claims is the “premise of the reactive programming”. Please see the citation above.
As for the “math behind it”, I would like so see an “scientist” presenting an Rx example which does not involve C# or .NET. Then I might start paying attention.
For the time being I think RxJS is firmly in the category “if you can do it that does not mean you should do it”, at least for me.
Also, as someone who seems to like jQuery, I thought you might find this post interesting about someone needing to compose two event streams first using jQuery Deferred (very cool feature of jQuery, in my opinion) and replacing it with Rx.
http://cburgdorf.wordpress.com/2011/03/24/117/
@Dusan
The video I provided on RxJS is presented as part of a series done by the Microsoft Research team and contains almost no C# or .NET discussion other than to draw parallels so that those with C# knowledge or Rx can have a basis for comparison. These are the “mathy” people behind both Rx for .NET and RxJS.
Certainly the source of all observable data in Rx is driven by an Observable, but that is not the *value* that can be derived from Rx. The *value* in Rx is the composability of those Observables.
The “classification” of javascript through the use of prototyping is a supported ECMA standard. Taking full advantage of the featureset of a language seems ideal to me, but I’m not very well-versed in the dangers that prototypes can have on a dynamic language. I’ll have to investigate.
I’d suggest watching that video. It might very well be eye-opening. The demo they build up to isn’t especially practical in terms of line-of-business applications, but it does show off the composability of Observables, which is the take-away.
@Anderson
“Classification” of JavaScript is idiom and and prototyping is a concept1. Contrary to popular belief “class-less” designing and programming is as old as programming languages are2
Researchers producing C++ STL, or F# might agree that having a class is not dangerous etc. What is more dangerous is inheritance gone wrong. Of which unfortunately we are suffering these days everywhere, where there is a central top level class or “Object” from which everything inherits. Java, C#, DOM are most familiar examples.
RxJS is one very naive JavaScript implementation of Rx. But there are many others, where MSFT teams have “simply” made JavaScript code to “look like” C#. Very recent example is WinJS. Part of new W8 WINRT paradigm.
Not using any of the few open source and well proven JavaScript libraries and “creating” class like idioms, is plain wrong. Even some more JavaScript aware MVP’s are saying “it feels wrong”.
There is also a lot of “eye opening” material on JavaScript and a dynamic languages.
1. Lookup Haskell
2. Lookup LISP
@Dusan
Here is a great podcast focusing only on RxJS, interoperability with it and existing frameworks (like jQuery), and interactions with server-side JS technologies, like Node.js.
http://herdingcode.com/?p=252. The guests are those MS Research members I mentioned before.
I’d delete this post if I were you. You’re completely uninformed about the subject matter and appear to be aggressively opposed to rectifying that situation.
@Mark
OK, I will, of course, no problem.