4 ms·

I was pretty enamored of the reactive paradigm until I inherited my first big RX project. Whoof. The amount of stuff I needed to know in order to maintain it wa

I was pretty enamored of the reactive paradigm until I inherited my first big RX project. Whoof. The amount of stuff I needed to know in order to maintain it was just intense. Nobody else liked it, either, so we slowly, over the course of a few months, replaced the reactive bits with more ad-hoc code. The end result was smaller, easier to read and modify, and more performant.

pixelrevision 8y ago
When you start it makes all your code look so declarative and lean but eventually you end up in the same place where events are being sent from all over the place because those are the requirements. Add in fun C++ style stacktraces and it becomes really hard to figure out where issues are originating.
hinkley 8y ago
A failure mode that has become apparent to me as a downside of having too much team stability: it is very easy to design a system that can only be reasoned about once it has been memorized. You need new people to serve as a mirror to really understand the health of the system. There’s a term from compilers that some people have borrowed to describe thinking about code: Local Reasoning. Lots of things can kill local reasoning. Global variables, overuse of delegation, mutation of someone else’s objects, and aggressively event-based systems.
- jhayward 8y ago
  > aggressively event-based systems I'd be interested in reading about your observations on how event-based systems kill local reasoning. Is it simply a bad design that requires the publisher to understand who/what all the subscribers are doing with an event? I've found that designing the semantics of individual events, and constraints on their interpretation, is the hardest part of event based systems so I could see that becoming an issue.
  - hinkley 8y ago
    Simple event systems often aren't too bad. There can be problems with order of receipt (what order do events fired from events get observed?). and side effects, and it can be difficult to teach junior devs how to dig themselves out of a problem. But when the system is using events as message passing mechanism between modules, things eventually tip over into Bedlam. You have events that disappear, or broken events that you can't track back to the source (where is this shit coming from??). The worst problem, the sucking wound I've seen happen a number of times, is when an event starts repeating. Somehow you make an event that causes itself to fire. In a loop, forever until too many pile up and the app stops responding.

pixelrevision 8y ago

When you start it makes all your code look so declarative and lean but eventually you end up in the same place where events are being sent from all over the place because those are the requirements. Add in fun C++ style stacktraces and it becomes really hard to figure out where issues are originating.

hinkley 8y ago

A failure mode that has become apparent to me as a downside of having too much team stability: it is very easy to design a system that can only be reasoned about once it has been memorized. You need new people to serve as a mirror to really understand the health of the system. There’s a term from compilers that some people have borrowed to describe thinking about code: Local Reasoning. Lots of things can kill local reasoning. Global variables, overuse of delegation, mutation of someone else’s objects, and aggressively event-based systems.

jhayward 8y ago
> aggressively event-based systems I'd be interested in reading about your observations on how event-based systems kill local reasoning. Is it simply a bad design that requires the publisher to understand who/what all the subscribers are doing with an event? I've found that designing the semantics of individual events, and constraints on their interpretation, is the hardest part of event based systems so I could see that becoming an issue.
- hinkley 8y ago
  Simple event systems often aren't too bad. There can be problems with order of receipt (what order do events fired from events get observed?). and side effects, and it can be difficult to teach junior devs how to dig themselves out of a problem. But when the system is using events as message passing mechanism between modules, things eventually tip over into Bedlam. You have events that disappear, or broken events that you can't track back to the source (where is this shit coming from??). The worst problem, the sucking wound I've seen happen a number of times, is when an event starts repeating. Somehow you make an event that causes itself to fire. In a loop, forever until too many pile up and the app stops responding.