Slashdot Mirror
'Reactive' Development Turns 2.0
electronic convict writes First there was "agile" development. Now there's a new software movement—called 'reactive' development—that sets out principles for building resilient and failure-tolerant applications for cloud, mobile, multicore and Web-scale systems. ReadWrite's Matt Asay sat down with Jonas Bonér, the author of the Reactive Manifesto (just released in version 2.0), for a discussion of what, exactly, the reactive movement aims to fix in software development and how we get there from here.
I don't think it means what you think it means. Obviously the manifesto is so short on details that it can be interpreted in many ways. I think the failure tolerance is more about e.g. tolerance of losing machines or tolerance of overloading - and that seems to be working.
I have previous experience about J2EE/JEE application servers and they always seemed to have the problem that when overloaded with traffic they might do anything. And after being severely overloaded they often do not recover back to normal. Also people often did not use J2EE session replication, because it was considered a pain.
Now I'm building an app with Scala/Play framework and we don't have user sesssions or the web servers so scaling and server failures are not a problem. Also we just ran some performance / load tests and the servers work fine up to 100% load and then just start to lose some requests. This is much preferrable to the "all bets are off" that I have seen on Tomcat or other servlet containers. Another reactive benefit from the Play server is that it is super easy to use many threads for building a single http reply and this really helps in giving users timely replys.
So while the manifesto is of course marketing, there are some good things in the new ways of doing things.
You have some core principles which make sense in a specific context. You have a book based on these principles but with a good dose of word salad to make it look more powerful. You have preachers hammering it into your head. And you have common people getting brainwashed by something that originally was a good idea, but has been perverted into something that hopefully doesn't damage more than it does good.
Oh, and then there's the Enterprise.
...to get certified!
I don't think reactive is the evolution of agile, as the author in the author implies.
If anyone's really looking for a 21st century successor to Agile/Scrum, I would recommend checking out the "async" manifesto which was written in a manner deliberately parodying the agile manifesto: http://asyncmanifesto.org/
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
Software developers wanted for programming project, must have 10 years experience with Reactive development methodologies.
Obviously the manifesto is so short on details that it can be interpreted in many ways.
Short on detail but long on words. Compare it to the Agile manifesto which has few words, but communicates the ideas very clearly. When you read that, you understand the underlying principles of agile. This manifesto has more words, but still manages to clearly get its idea across.
When it comes to the manifesto linked in the article, as you mention it is short on detail. Specifically, who doesn't want to have a responsive system? Have you ever met anyone who said, "I think I will build a website. I want it to take 15 seconds for the pages to load." Saying you want your site to be responsive is so generic as to be meaningless.
The part that really makes me laugh is the part where they say it will have no bottlenecks. That has been the goal of designers since the day of Von Neumann. He was certain he would design his computer without bottlenecks. Once again, it's something that everyone wants.
The biggest thing they have that isn't generic there is that they require message passing. That seems like a weird requirement to me, but I'm sure they have a reason.
"First they came for the slanderers and i said nothing."
The goal is to promise heaven and earth to the management. Sell bunch of tools to the management, collect handsome consulting fees sell some books etc. By the timethecon job is realized, these guys would be on to their next scam, clueless management would have awarded itself another round of boni, (because everything done by the management deserves a bonus).
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I've been following this reactive programming "movement" and it's all traced back to one guy who has a consultancy in "reactive programming" This is the 4th such reactive programming post that I am aware of on /.. No where else have I seen "reactive programming" and this is the only guy I know of who is pushing it.
In addition, the /. comments are highly ciritical of this "movement"
I call on slashdot to identify what articles are slashvertisements and or are carried on special grounds.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
As far as I can tell, this person (or persons) has discovered something that has a name already: Event-driven programming. It's been around for a very long time. It has many of the benefits of naive multi-threaded coding without the warts. But it introduces warts of its own, with event orderings being the big one.
What Erik Meijer discovered was that an event can be viewed as a sequence. Each occurrence of the event is an "item" of the sequence. What's why he wrote an article called "Your mouse is a database": The mouse is a sequence of multiple event types such as moves, buttons etc.
Once you start to view (and represent) events as "push" sequences interesting things start to happen: Suddenly you can *compose* events in the same way you compose collections/sequences.
Erik Meijer wrote the Active Extensions for .NET which does exactly that. Using LINQ you can transform, aggregate, group, partition, project/map, filter etc events.
Consider, for instance, stock market ticker values: Clearly you can see those as events: When a deal/offer it is an event. Multiple events is a stream/sequence. Now imagine you want to know each time a symbol has "peaked" - i.e. each time 3 consecutive values for any symbol has the maximum as the middle value. With Reactive Extensions and LINQ you would write:
var peaks = stockQuotes.GroupBy(sq => sq.Symbol).SelectMany(g => g.Buffer(3, 1).Where(IsPeak));
where IsPeak is defined as:
bool IsPeak(IList<Quote> b) {
b[0].Rate < b[1].Rate && b[1].Rate > b[2].Rate;
}
Explanation:
1. stockQuotes is the IObservable stream of quotes.
2. GroupBy created a new stream of multiple streams. Each time a new symbol is encountered, a new group will be added (appear in the stream); if the symbol has already been encountered the quote is added to the end of the stream for the symbol.
3. Buffer creates a "sliding" buffers (increments of 1), each with 3 items.
4. Where filters the IObservable so that only "peaks" are let through.
5. SelectMany "flattens" multiple streams into a single stream again, i.e. creates a single stream of quotes regardless of their symbol (group)
Now, this is an IObservable stream with no subscribers (observers) yet. This also means that there is no subscription at stockQuotes. But as soon as you register a subscription like this:
peaks.Subscribe(Peaked)
It starts to invoke the Peaked method with peaks consisting of lists with exactly 3 items each. And this will go on and one.
Now imagine how you would write something like that using events and event handlers? It will probably take 10 times more code and be less readable than the above. (Yes, I know that it is not entirely straightforward if you are not used to RX and LINQ).
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*