4 ms·

In my experience the Reactive paradigm rarely serves to solve any of the problems it sets out to, and the root of the problem is here: > The first step to simp

by skohan 8y ago

In my experience the Reactive paradigm rarely serves to solve any of the problems it sets out to, and the root of the problem is here: > The first step to simplify event logic in an application is to come up with a general event interface so that all event handling code can work with a uniform interface. RX proponents seem to make the leap that the problems of software complexity can be solved by wrapping your logic into a highly general abstraction layer which homogenizes everything your code does into streams of events. I'm not entirely sure what this assumption is based on. To look at how this assumption breaks down, just look at the ReactiveX API: what's billed as a general purpose tool consists of a menagerie of observable subtypes and operators built to patch the holes in real-world problem complexity left by the "general case" solution described by this article. Or look at the serpintine call stack in any real-world RX project of any non-trivial complexity. The more I code, the more convinced I am that the best practice is to write software at the lowest level of abstraction possible, as close to your problem domain as possible. Paradigms like RX which seek to magically reduce complexity through generic abstraction at best move that complexity into another layer where it's more obfuscated, and at worst introduce additional complexity.

bunderbunder 8y ago
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.
chooseaname 8y ago
> RX proponents seem to make the leap that the problems of software complexity can be solved by wrapping your logic into a highly general abstraction layer... There is a subset of developers who long for developing "The One" architecture for a given domain. This is the architecture that can accept any change with minimal code changes. The vast majority of these developers tend to be Enterprise devs and are very outspoken about the way software should be developed. I don't believe any of them will ever succeed as once the project becomes unwieldy, they leave for other pastures.
- gerbilly 8y ago
  >I don't believe any of them will ever succeed as once the project becomes unwieldy, they leave for other pastures. On the contrary, this is the formula to success: Outrun Your Mistakes. If you make your code look sufficiently complicated and meta the team will praise you as a genius after you are gone, even as they try to untangle problems that you created.
mpweiher 8y ago
> software complexity ... solved ... streams of events. I think I have an idea how this happened. First, it seems to me that there is a large overlap of the extreme RX proponents with extreme FP proponents, who have been rather messianic in touting FP's ability to solve all software problems. Of course FP doesn't really handle interactive programs well at all, because it is timeless/stateless, simply mapping inputs to outputs. So that's a big hole and a bit of a problem. Enter (synchronous) dataflow programming (Esterel, Lustre, Lucid), which moves time into streams, and voilà, now we can apply FP to this domain as well and everything will now obviously be rainbows and unicorns. Obviously.
- skohan 8y ago
  That's the problem with dogmatism. Functional programming is great, and there are probably a lot of codebases which could be improved by being a bit more functional, but when you take it as a given that "more (X) == better code" and make design decisions based on that rather than the problem you are trying to solve, sooner or later you will start doing things which don't make sense.
  - bunderbunder 8y ago
    Dogmatism, maybe, but I think maybe it's more symptomatic of just having too much book knowledge and not enough hands-on experience. I'm starting to have this experience where I'll advise a more junior programmer to exercise caution about $THING_FROM_BLOGOSPHERE because, while the code examples from the blog post certainly do make things look nice, I can see where it might develop XYZ problem when you try to use it in production code. Typically I'm ignored, because I'm clearly just old-fashioned, and possibly even starting to go senile. Typically, after 6 months or so, you'll see that developer discovering that they're running int XYZ problem. This is all cranked up to 11 with functional programming, because what a lot of newcomers to FP don't fully appreciate is, avid functional programmers are people who love to play with abstractions. Emphasis on the word play. My sense is that a lot of the stuff that people are putting out there is a mix of spitballing new ideas and stuff done in the spirit of RFC 1149. see also: https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html

by skohan 8y ago

bunderbunder 8y ago

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.

chooseaname 8y ago

> RX proponents seem to make the leap that the problems of software complexity can be solved by wrapping your logic into a highly general abstraction layer... There is a subset of developers who long for developing "The One" architecture for a given domain. This is the architecture that can accept any change with minimal code changes. The vast majority of these developers tend to be Enterprise devs and are very outspoken about the way software should be developed. I don't believe any of them will ever succeed as once the project becomes unwieldy, they leave for other pastures.

gerbilly 8y ago
>I don't believe any of them will ever succeed as once the project becomes unwieldy, they leave for other pastures. On the contrary, this is the formula to success: Outrun Your Mistakes. If you make your code look sufficiently complicated and meta the team will praise you as a genius after you are gone, even as they try to untangle problems that you created.

mpweiher 8y ago

> software complexity ... solved ... streams of events. I think I have an idea how this happened. First, it seems to me that there is a large overlap of the extreme RX proponents with extreme FP proponents, who have been rather messianic in touting FP's ability to solve all software problems. Of course FP doesn't really handle interactive programs well at all, because it is timeless/stateless, simply mapping inputs to outputs. So that's a big hole and a bit of a problem. Enter (synchronous) dataflow programming (Esterel, Lustre, Lucid), which moves time into streams, and voilà, now we can apply FP to this domain as well and everything will now obviously be rainbows and unicorns. Obviously.

skohan 8y ago
That's the problem with dogmatism. Functional programming is great, and there are probably a lot of codebases which could be improved by being a bit more functional, but when you take it as a given that "more (X) == better code" and make design decisions based on that rather than the problem you are trying to solve, sooner or later you will start doing things which don't make sense.
- bunderbunder 8y ago
  Dogmatism, maybe, but I think maybe it's more symptomatic of just having too much book knowledge and not enough hands-on experience. I'm starting to have this experience where I'll advise a more junior programmer to exercise caution about $THING_FROM_BLOGOSPHERE because, while the code examples from the blog post certainly do make things look nice, I can see where it might develop XYZ problem when you try to use it in production code. Typically I'm ignored, because I'm clearly just old-fashioned, and possibly even starting to go senile. Typically, after 6 months or so, you'll see that developer discovering that they're running int XYZ problem. This is all cranked up to 11 with functional programming, because what a lot of newcomers to FP don't fully appreciate is, avid functional programmers are people who love to play with abstractions. Emphasis on the word play. My sense is that a lot of the stuff that people are putting out there is a mix of spitballing new ideas and stuff done in the spirit of RFC 1149. see also: https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html