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.
Building a safety net into your code is a massive security risk. Programs are supposed to break or we wouldn't know something is wrong with them.
Organisations working in disparate domains are independently discovering patterns for building software that look the same.[citation needed]
These systems are more robust, more resilient, more flexible and better positioned to meet modern demands.[citation needed]
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.
Boner.
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!
Next week, doubled over in pain, the lack of determinism is going to look like a big kick in the crotch.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Software developers wanted for programming project, must have 10 years experience with Reactive development methodologies.
There is one, and only one, proven method to success. What? Is? It? It is called The Silver Bullet. Learn. It. And. Be. One. With. God.
just had a look at the manifesto: it's about software architecture and design. i can't see how it should compare to agile, which is about software development metodologies. anyway i'm okay with those 4 principles but don't quite understand what's new here (apart from reading "responsive" in its correct meaning for once!)
but one thing i can say for sure: this one aint gonna fix what's broken in software developement industry either, which is: industry! industry! industry!
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
Reactive programing already exists. Think of it as observer patterns for every variable and operation or as cell programming like you do with spreadsheets. When you update a spreadsheet cell all the formulas that rely on that cell have their values recalculated.
What they describe is more cell processing where each operation has it's own mini CPU and they all send messages to each other. There were theoretical papers about this structure of design long, long ago during the early days of computers. I'm sure it already has a name and was considerably more thought out than what these guys are saying. Actually, scratch that. I finished reading the article and they at least reference some early designs. I'll give them a point for that.
Please stop picking names that already mean something in the same field.
Please stop picking names that already mean something in the same field.
And don't pick names that can't be searched for online.
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.
The Twelve Factor App provides a more thorough treatment of elastic systems design, but generally agrees with the thesis of this document. Perhaps if that document were interactive in some way (open to signature, modification, comment, DVCS citation, etc.), we might have a better measure of its influence in the real world.
If you care about fault-tolerance use Erlang or Elixir languages specifically designed for it. Instead of wasting your time.
...is just someone on a soapbox. That word is enough to make most people turn and walk away.
Too bad readwrite is not reactively resilient.
ARTICLE IS DOWN
This is "ok" at best, but I'd prefer a more practical guideline, and for that Adam Wiggins' 12 Factors are a much better place to start for scalable web systems: http://12factor.net/
and give it a new name. That seems to be the pattern these days, isn't it. The techniques and concepts described in this "Manifesto" are really nothing more than the tenet of systems design since the dawn of the computer age. Yet, he touts it like its some sort of new idea. Same goes for programming languages, frameworks and paradigms - most are rehashes of what came before.
I have been a proponent of using message queues to build asynchronous and distributed system that make building such "responsive" system. We developed a location based system that leveraged ApacheMQ with JMS to facilitate the processing of millions of messages while keeping the response time predictable. That was seven (7) years ago.
Bandwidth and computing resources are finite. We can move processing off to the cloud or to other dedicated processors. But, ultimately, you will have a bottleneck of one or more of the two, bandwidth and computing resources (cores, processors, nodes, whatever). To make a response, large scale system, you need to understand the limitations and, more specifically, queuing theory so that you can build a system that meets the goals of the "manifesto".
If one is looking at programming "responsive" systems in terms of languages (which is not the intent, I think, of the manifesto), you can easily go back to the 1980's and 1990's. There were probably other such environments before then. However, around 1992/3, there was a language for the Macintosh called Prograph (and, Progragh CPX). It was a visual language that was based on "cases" with inputs and outputs. Outputs became available when all the inputs were satisfied - it was very asynchronous. Yes, you still had procedural elements. But, it was designed for parallel processing. Another, so called, "responsive" system is the spreadsheet where cells change based on the values in other cells in a very asynchronous fashion.
I won't state that some of today's "modern" languages don't solve specific problem of earlier languages or have something to offer. But, much of what that is claimed to be modern constructs have been around for years - maybe not as eloquently expressed, but were there nevertheless. This is where a CS degree comes in hand and why people pursue CS at colleges. Wish some people would get that through their heads. The other day, there was a story about how older IT professionals seem to have lost their fire while the "younger" generation is full of it and it's learning something new that makes them better than the old guard. No, older professionals simply say "ho-hum" to the "new" views as it's just a rehash of what they already know. When something revolutionary comes along, the wake up long enough to figure it out and whether it's something that's worth considering vs what HR thinks is the hopping buzzword of the day.
Step 1. Basically have a childish snit in front of Engineers, insult and threaten them with their jobs and reputation. Step 2. Go to a special room to smoke pot. Step 3. Repeat till product is finished. Step 4. Out source project. Step 5. Make good on statements generated in Step 1. Step 6. Profit! Step 7. Go To Step 1.
If reactive programming is anything like reactive armor, I'm all for it.
"Incoming change request!" *BOOM* "Threat neutralized!"
(RTFA? Surely you jest. Programming fads are for kids, certification peddlers, and con-artists^H^H^H^H^H^H^Hsultants.)
Maybe I'm missing something here, but this "reactive" nonsense keeps popping up every few months and I still don't see what's new.
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.
Sadly, most [PHB] managers will interpret it as "be reactive", and thus further lower the quality of substandard content they produce.
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*
Can we please have another recession? I know it will be painful for a lot of honest, hard-working folks; but at least the buzzword factories will get laid off... Oh, no, wait... only honest hard working folks will get laid off. The buzzword factory people will just get slightly browner noses. That might sound like punishment but I think they actually enjoy it. Maybe we can just shoot the tires out of random BMWs. Most buzzword spouters drive that make.
Soapbox mode on.
The truth of the matter is simple and yet very complex: requirements aren't easy to map but neither is it easy to implement. Those that came before us understood this tenet very well. But they didn't have enough history to map the topology of the requirements space. Each methodology we have encountered since the computer was developed has been an interim milestone in our journey of discovery. But the stage is set and the time is at hand to reveal the nature of the requirements space.
Empirically, the truth is that the space has at least 6 orthogonal axes, and on average, each methodology attempts to take a 3 dimensional slice (a space with 3 axes) as it's core and assumes the rest of the space is static and then proceeds to identify surfaces and points within the space as the requirements to be fulfilled leaving the rest as an exercise to the reader. Until we realize that the requirements space requires ALL 6 orthogonal axes and that the problem set itself defines which of the axes is required to solve for the optimal solution, we are destined to repeat the fanatical religious debacles of the previous generations. This is why we produce software developers (artists) rather than engineers, and why we keep using the same personal hammer for every diverse nail we find, and why we keep having high defects rates and produce buggy software. And we forget the number one tenet of discrete math: errors accumulate as they propagate and can only be ignored for so long - a Taylor series does have a finite limit and that limit gets large the number of series that are multiplexed into the problem set being solved.
But there is hope. In the 80's there was a book written that codified how to handle much of this complexity: "Software Engineering - Planning for Change". And in 90's, we saw the GOF write the cornerstone tenet on how to pattern software with repeatable building blocks: "Design Patterns". And in the 00's there was a book that codified how to handle the complexity of the requirements space (albeit with limited orthogonal axes): "Writing Effective Use Cases". But the one book that is missing from everyone's shelf and reading list is the one book that we DO INDEED rely on every day for our mechanical world outside of electronics which codified how to handle the predicate calculus that would let us navigate the partially continuous 6 dimensional requirements space: "Finite State Automata". I just wish I knew where I placed the damn thing. But it is the definitive treatise on how to solve the requirements space for the problem set which when implemented following the tenets of the previous icons, leads to a solution that embodies the truth of the solution - it just works.
One last word. This set of theories is not sufficient by itself - it needs to be supported by visual communication as those used by many practitioners the world over - seeing is believing. And even if the solution is manifold in its complexity - these tools applied judiciously ALWAYS give the right answers REGARDLESS of the 180-degree turns initiated by senior management and REGARDLESS of the methodology used. When we stand on the shoulders of giants, we can only succeed at their discretion and under their tutelage.
Soapbox mode off.
My understanding is that the authors of the "Reactive Manifesto" are all Typesafe guys (i.e. the commercial entity behind the Scala programming language, and the Akka framework that drives Scala's concurrency model). The only people who I ever see tweeting about this are Typesafe guys. The only people who I ever see blogging about it are Typesafe guys. The interview here is with a Typesafe guy. The Coursera class on "Reactive Programming" is taught by a Typesafe guy, using Scala. The only time I've ever heard anything about this mentioned in person was by someone at a Scala meetup.
I'm not trying to bash Scala. I was really excited when it first came out, and tried to introduce it at my last job. The combination of its learning curve, its breaking changes between versions, and the upcoming Java 8 all pretty much doomed its adoption at that shop... but it's still a neat language nevertheless.
However, the "Reactive" thing just seems like the guys behind a particular programming language publishing a "manifesto" of best practices, which exactly fits the way their particular programming language is designed. I don't know... that just seems to me like an astroturf effort to coin a new buzzword, so that your vested interest can be a leader in the space of that new buzzword. Is there any real energy around this which ISN'T coming from the professional Scala community? Do we really need a new buzzword (or "manifesto"!) to describe the longstanding concept of "message-based and event-driven"?
It seems like most of the comments here are from people who haven't connected the dots between this "manifesto" and Typesafe. A lot of people haven't read any of this stuff at all, and think that it's meant to be a methodology , as with the "Agile Manifesto" (no doubt the marketing inspiration for the name). Others have at least skimmed it, and don't see anything new with "message-based and event-driven". I believe that what's new is an effort to replace "message-based and event-driven" with a different buzzword, for which Typesafe's website already has great SEO.
Invert your Fragility training as I thought Anti-Fragile is all the rage now days.