A Few Thoughts on Reactive Programming
A Few Thoughts on Reactive Programming
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
The word fashion is usually used, outside its own world, derogatorily. Hipsters have brought contempt for fashion to a new level. If you think about it, Hipsters, who, while claiming to hold fashion in contempt, have aroused the ire of people for whom the attack is not a defense of fashion, or mediocrity or popularity (the things Hipsters supposedly abhor), but rather a generalized aggression against tastemaking of any sort, but especially tastemaking whose only drive is to avoid being common. In that I find myself siding with the antihipsters, because the whole process of people banding together to adjudicate taste is absurd, and while I am happy to cotton absurdity, and illogic, alogic is a form of mental lice.
At any given time, in any profession, there is always some percentage of the participants who are prone to these types of organizational hysteria. Sadly, in programming, this arc seems to be ascending. Every year we hear about some other tribe who thinks that they‘ve found a burbling spring that will spit out bugfree code and all the craftsmen who trade in their tools for the new creed‘s will skip and whistle their way through work each day. Rails was the kookiest and thankfully that seems to have run its course. But now, alas, reactive is turning into the latest thing. There are a lot of great ideas behind Reactive Programming and if it could be kept pure, it might even be a good hitching post, but it‘s looking instead like it‘s going to be running down the rabbit hole even faster than many of its forebears. Why? Well, as was the case with Spring more than a decade ago, it contains a lot of good ideas, but once logos becomes praxis, those ideas start to serve a new master. And sadly in the case of reactive, those masters appear to have a very narrow point of view.
Is concurrency important? of course it is. Will it be important when/if you have to write a mobile app? probably minimally so. Even if the mobile app is sharing data with other users. Then synchronization will be more important, and there are so few frameworks that have done a good job of making that easy. Apple‘s first attempt with CoreData syncing through iCloud was a huge, unmitigated disaster. My favorite part of the long I/O keynote last year was when the speaker pointed out the developer audience that WhatsApp got all the way to a $19B acquisition without a single backend programmer. (I happened to have seen the Nova episode ‘Decoding Neanderthals‘ this week so excuse me if I am sounding Darwinian.) But frankly, from another perspective, I am just really filing a complaint (something I have been told I am expert at). My complaint, not unlike Jay Z‘s, is that the grease is going to the wrong wheels.
My favorite number of designers on an app team is 0. Face the facts, most of the work, if you could break it down, is going to go into the interface. Now, let‘s expand the definition a bit, and consider the process of adapting the app to the many people who will use it, under different circumstances (I also consider this interface) and the whole thing explodes. Let me turn the screw one more time: apps are finally becoming context-driven and that arc is going to explode over the next decade. The all knowing wizard waiting to be called upon so he can issue his ‘reaction‘ is gong the way of the dodo. The future is Google Now/Apple today and notification extensions, Siri, et al.
How prepared are we, how much grease has the context wheel gotten? Almost none. I bought my first book on context-oriented programming a decade and a half ago. I started thinking about it again because I was working on a watch app. You have a TINY window to communicate through and what you show there MUST be context-sensitive, dependent, adapted. In WatchKit, you have a Glance view in the project (one) and it‘s a storyboard (a==one). The presumption is that you will simply show and hide different groups of things as needed for the various contexts that you want to support. So supposed you want a daytime and night time view. Yeah, your ‘storyboard‘ is going to be a useless jumble of programming clutter that communicates nothing. Had they even given us the ability to define multiple glances and then add some logic as to which one to show, I would feel like I at least got a diaper. But no.
Apple‘s not alone in this. The fact that Google Now is still not open is such a travesty. If I were to assemble my own anti-dynastic theses, that might make it to #1. At least Apple will let anyone provide a Today extension.
Today I was reading a bit about context-oriented programming and found a great scholarly article that talks about using Actors. So I thought ‘I wonder if a soul from the Reactive group has ever mentioned COP (Context-Oriented Programming)...‘ If they have, Google doesn‘t know about it…
Published at DZone with permission of Rob Williams , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.