Reactive Programming
Jan. 16th, 2014 09:09 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeur[Yes, I do seem to be mostly posting programming-related topics nowadays.]
I just realized that, for all that I've burbled a lot about Scala and Akka and stuff, I don't think I've mentioned the element that ties it all together: The Reactive Manifesto. If you haven't read it yet, I commend it to you: it's not terribly long, and it is *extremely* important.
On the surface, it's not hard to dismiss it as simply a bunch of platitudes, restating a bunch of obvious principles. But when you follow its logic through, you wind up with a pretty important conclusion: the vast majority of software out there does *not* follow these principles, and that's a non-trivial element in why the vast majority of software sucks.
Heck, it's even topical: failure to follow these principles is almost certainly the main reason why the big federal healthcare website melted down so badly. Yes, there were many, many causes of why the problem was hard. But the fact that the site couldn't *cope* with those issues is, I suspect, largely down to old-fashioned design. My biggest headdesk about that entire fiasco was that I, and a number of other folks I know, could almost certainly have designed a system that, while imperfect, would have worked a good deal better from the beginning. Observation of the Reactive principles is precisely why.
Before you attribute this to simply being a Scala marketing tool, keep in mind that it was co-authored by several major players around the field, such as Erik Meijer, late of Microsoft (one of the main people to whom I credit the fact that the .NET stack is the best thing about Microsoft). Indeed, while I have a well-worn cynicism of Microsoft, their better people have been pounding parts of this drum for a decade now. Hence, the Manifesto is technology-neutral -- it's basically a public statement about where software architecture needs to be going, in order to cope with the realities of the modern environment.
So give it a read, and more importantly take the time to think about it seriously. Personally, I may well print out the diagram of the Reactive Traits and pin them on the wall of my desk, as a reminder of how things *should* work...
I just realized that, for all that I've burbled a lot about Scala and Akka and stuff, I don't think I've mentioned the element that ties it all together: The Reactive Manifesto. If you haven't read it yet, I commend it to you: it's not terribly long, and it is *extremely* important.
On the surface, it's not hard to dismiss it as simply a bunch of platitudes, restating a bunch of obvious principles. But when you follow its logic through, you wind up with a pretty important conclusion: the vast majority of software out there does *not* follow these principles, and that's a non-trivial element in why the vast majority of software sucks.
Heck, it's even topical: failure to follow these principles is almost certainly the main reason why the big federal healthcare website melted down so badly. Yes, there were many, many causes of why the problem was hard. But the fact that the site couldn't *cope* with those issues is, I suspect, largely down to old-fashioned design. My biggest headdesk about that entire fiasco was that I, and a number of other folks I know, could almost certainly have designed a system that, while imperfect, would have worked a good deal better from the beginning. Observation of the Reactive principles is precisely why.
Before you attribute this to simply being a Scala marketing tool, keep in mind that it was co-authored by several major players around the field, such as Erik Meijer, late of Microsoft (one of the main people to whom I credit the fact that the .NET stack is the best thing about Microsoft). Indeed, while I have a well-worn cynicism of Microsoft, their better people have been pounding parts of this drum for a decade now. Hence, the Manifesto is technology-neutral -- it's basically a public statement about where software architecture needs to be going, in order to cope with the realities of the modern environment.
So give it a read, and more importantly take the time to think about it seriously. Personally, I may well print out the diagram of the Reactive Traits and pin them on the wall of my desk, as a reminder of how things *should* work...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2014-01-16 03:29 pm (UTC)RxScala? scala-react? Dire? smth else?
(no subject)
Date: 2014-01-16 04:20 pm (UTC)For the UI, honestly, I think the tooling still needs work. I've just started really pushing for Typesafe to take Scala.js seriously, and my current long-term hope is to help them evolve some Typesafe-native frameworks for integrating a Scala.js front end with a Play back end, so that you can get something vaguely like a Lift approach in Play. (I actually chatted with James Ward of Typesafe about that last night, since he was in town giving a talk.) Play already has some of the key elements, like WebSockets -- now, we need an easier way to work with that.
But for now, I'm just hacking in Javascript and jQuery. Fortunately, Querki's UI requirements are fairly easy so far, but that'll change as we go along, and I have plans to gradually evolve the front half of my architecture towards something more consistently reactive...
(no subject)
Date: 2014-01-16 05:56 pm (UTC)(no subject)
Date: 2014-01-16 07:03 pm (UTC)(no subject)
Date: 2014-01-16 05:57 pm (UTC)(no subject)
Date: 2014-01-16 07:04 pm (UTC)(no subject)
Date: 2014-01-16 05:07 pm (UTC)