> 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.
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.
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.
> Of course FP doesn't really handle interactive programs well at all, because it is timeless/stateless
Interesting claim. How is it that people write, for instance, parsers in functional languages if they have no state? What is it that the State monad does?
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.