what the author replaced was a classic "first system"...but he created a classic "second system".
I wish people would just realize that the best route is to solve the problem at hand...and JUST the problem at hand, with the smallest and simplest codebase possible....these tend to be the near-optimal "third systems" that eventually emerge.
Thanks for taking the time to review and comment!
But I have the feeling, that good frameworks still make some stuff easier than others, while supporting arbitrary programming/turing completeness.
For example Cycle.js, which is a structural framework for reactive programming with observables. It's made for front-end developoment, but I can also model REST and WebSocket servers with it, since almost everything can be modeled as a mix of source-streams + (input-data) sink-streams (output-data).
Since it uses observables all over the place, it makes handling these data-streams much easier an clearer, by making them first class citiziens in the app.
true. This is pretty much what i have been doing for 25 years and will be doing for the next like 20.
Reminds me about the time when one guy we had around read a book on finite state machines. It was, dare i say, an eye-opener for him. Since that moment until he parted with us, all what he was doing was FSAs.
Only once you end up having to solve a separate problem that shares common attributes/patterns with the first should you you extract a common framework and rebuild both on it. You have a proven need and you're not just blindly building "someday this could be used for"-type code.
There isn't currently an Adaptor authoring guide, so that would obviously be a good thing. There are some code samples for usage in user guide.
In any event, thanks for giving it a look and taking time to comment.