It’s amazing that we were taught about finite state automata and machines, yet for programming large applications, we haven’t necessarily taken that same approach. As you mentioned, all of the coupling and created dependencies of function calls upon other function calls really gets impossibly difficult to debug and analyze as the complexity, functionality, and scale of an application grows. After reading what you wrote, it’s like a new revelation; I’m eager to put this paradigm into practice. I’ve generally lost interest in many of my personal projects simply for the fact that they become so untenable as they’ve grown with dependency upon dependency. The notion of splitting up the code into their proper segments or nodes that do some work or a program of instructions, return their product to a central conductor via a state-tracking data structure is something I plan on using moving forward. Perhaps, I’ll even revisit some of these abandoned projects and try to view the flow of execution under this lens and then restructure operations accordingly.
I’ve been using this pattern in some large production projects, and it’s been a real life saver for me. Like you said, once the code gets large, it’s just too hard to keep track of everything cause it overflows what you can keep in your head effectively. And at that point you just start guessing when you make decisions which inevitably leads to weird bugs. The other huge benefit is it makes it far easier to deal with changing requirements. If you have a graph of steps you’re doing, it’s trivial to add, remove, or rearrange steps. You can visually inspect it, and guarantee that the new workflow is doing what you want it to.
It’s amazing that we were taught about finite state automata and machines, yet for programming large applications, we haven’t necessarily taken that same approach. As you mentioned, all of the coupling and created dependencies of function calls upon other function calls really gets impossibly difficult to debug and analyze as the complexity, functionality, and scale of an application grows. After reading what you wrote, it’s like a new revelation; I’m eager to put this paradigm into practice. I’ve generally lost interest in many of my personal projects simply for the fact that they become so untenable as they’ve grown with dependency upon dependency. The notion of splitting up the code into their proper segments or nodes that do some work or a program of instructions, return their product to a central conductor via a state-tracking data structure is something I plan on using moving forward. Perhaps, I’ll even revisit some of these abandoned projects and try to view the flow of execution under this lens and then restructure operations accordingly.
I’ve been using this pattern in some large production projects, and it’s been a real life saver for me. Like you said, once the code gets large, it’s just too hard to keep track of everything cause it overflows what you can keep in your head effectively. And at that point you just start guessing when you make decisions which inevitably leads to weird bugs. The other huge benefit is it makes it far easier to deal with changing requirements. If you have a graph of steps you’re doing, it’s trivial to add, remove, or rearrange steps. You can visually inspect it, and guarantee that the new workflow is doing what you want it to.