4 ms·
> your Setup() function is going to be 1000 lines long and likely incomprehensible Have you worked on a system that used these principles, and found them to be
by stephen 14y ago
> your Setup() function is going to be 1000 lines long and likely incomprehensible
Have you worked on a system that used these principles, and found them to be inadequate, beyond an off-the-cuff read of this blog post?
I ask because I have built a system like this, and if your nightmare 1,000-line Setup() function is true, then my experience is that implementing the same behavior imperatively would be 2,000+ lines of spaghetti code that is an even worse nightmare.
For behavior that changes on multiple conditions (just like in the OP), declarative programming is a win. Otherwise you end up coding "oh, wait, now do this" is in 2-3 different places, and invariably forget to keep all of them in sync you're making changes.
- to3m 14y agoI've always found such systems intolerably difficult to debug. Is there an option for 1,000 lines of imperative non-spaghetti? I've found that keeping the bulk of UI code in one place is the key to keeping these things manageable. Ideally, each widget's handler should do little more than affect whatever data it needs to affect, then call another function that updates all widgets' states according to the latest data. For stateful sequences of events (e.g., mouse drags) the rx-style approach is a bit more compelling. Imperative code for that stuff is always ugly. But you still seem to have the same problem of debuggability if you use rx, and backing out of a state looks like it might be a bit of a chore. Call me a Philistine, call me a barbarian...