9 ms·

Having been both an EE (first) and a software engineer, I have noticed this: as an EE, I would never randomly attack a problem with multiple independent FSMs. W

Having been both an EE (first) and a software engineer, I have noticed this: as an EE, I would never randomly attack a problem with multiple independent FSMs. Whereas in the s/w realm, I've seen seasoned professionals, without hesitation, do exactly that. I know from University CS training, that s/w engineers most likely all would recognize that any piece of software would, taken as a whole, constitute a single FSM. But as s/w engineers, we usually turn a blind eye toward that fact, seemingly bc there's too much complexity, we perceive the pieces as independent, and need to divide the problems in order to conquer them. This bears some thinking about. For now, just saying, the difference in perspective is interesting

cube2222 6y ago
The product of multiple independent state machines is in effect a single state machine.
- greenbit 6y ago
  Oh absolutely. Part of what I was getting at was that this larger meta-FSM often 'just happens', w/o really being fully intentionally designed. But of course the product that you actually ship is that meta-FSM, so it's the behavior of that thing that matters. Idk, just woolgathering here anyway. One thing that drives me nuts is when people take a linear sequence of code, chop it into little pieces, give each piece to a thread, sometimes give such threads little pieces of other task sequences, then bodge it all back together with various kinds of thread synchronization methods. What you end up with is almost impervious to analysis. So clearly keeping linear sequences of code intact has advantages. Thinking that maybe by thinking about which assemblages of such sequences form relatively independent FSMs, one might, as a s/w developer, be able to make better decisions about how to organize the larger scale structure of software.
rkangel 6y ago
I disagree with that - as an EE you almost certainly regularly attack a problem with multiple independent state machines. For example - 3 devices hanging off an I2C bus. Each of those devices will be implementing the I2C state-machine to interpret SCK/SDA. It's a question of what abstraction level you are looking at. In a complex system you need multiple components abstracted from each other and high levels of the system. In those cases, the building blocks will have their own state machine. The same is true in software, although in software it's much easier to reach a high level of complexity. Your average protocol stack (be it IP, LTE, or Bluetooth) is composed of a number of separate layers. These communicate between themselves with messages, and update their internal state-machine. This is a great way to model a system. The same is true in 'closer to hardware' land. An FPGA implementation will often include many explicit state machines, and even more implicit ones.
- greenbit 6y ago
  Yeah, from that angle, yes, you'd do that. But within any one of those devices, would you carve the insides into independent FSMs? Probably a 'yes' qualifed with 'if they were very independent problems anyway'. I did say I needed to think about it more. Guess if there were to eventually be a point I'd try to make, it would be that s/w seems to have a tendency to be structured more like an entire complex system, than like nice tight clean self contained state machines. Idk if this has to be so or not, but in recent years with the rise of multicore processing, I've seen a huge gravitation toward splintering s/w into threads, without, seemingly, well planned combination of those threads. It's sort of like if, as an EE you were going to build a whole computer, declared "I'm going to need counters and adders and registers (etc)", and then set about designing great counters and adders etc, but then just lashed them together somewhat haphazardly and kind of just hoped to get the system you wanted.
  - rkangel 6y ago
    Modern software development is about management of complexity. That's why you have abstraction, that's why you have CI, that's why you have automated tests. Having multiple independent state machines isn't necessarily a failure of system thinking. To extend your processor argument, do you think there is only one state machine in (each core of) an x86 processor?
btbuildem 6y ago
Breaking a problem into smaller problems is an effective approach, rarely does it fail.

cube2222 6y ago

The product of multiple independent state machines is in effect a single state machine.

greenbit 6y ago
Oh absolutely. Part of what I was getting at was that this larger meta-FSM often 'just happens', w/o really being fully intentionally designed. But of course the product that you actually ship is that meta-FSM, so it's the behavior of that thing that matters. Idk, just woolgathering here anyway. One thing that drives me nuts is when people take a linear sequence of code, chop it into little pieces, give each piece to a thread, sometimes give such threads little pieces of other task sequences, then bodge it all back together with various kinds of thread synchronization methods. What you end up with is almost impervious to analysis. So clearly keeping linear sequences of code intact has advantages. Thinking that maybe by thinking about which assemblages of such sequences form relatively independent FSMs, one might, as a s/w developer, be able to make better decisions about how to organize the larger scale structure of software.

rkangel 6y ago

I disagree with that - as an EE you almost certainly regularly attack a problem with multiple independent state machines. For example - 3 devices hanging off an I2C bus. Each of those devices will be implementing the I2C state-machine to interpret SCK/SDA. It's a question of what abstraction level you are looking at. In a complex system you need multiple components abstracted from each other and high levels of the system. In those cases, the building blocks will have their own state machine. The same is true in software, although in software it's much easier to reach a high level of complexity. Your average protocol stack (be it IP, LTE, or Bluetooth) is composed of a number of separate layers. These communicate between themselves with messages, and update their internal state-machine. This is a great way to model a system. The same is true in 'closer to hardware' land. An FPGA implementation will often include many explicit state machines, and even more implicit ones.

greenbit 6y ago
Yeah, from that angle, yes, you'd do that. But within any one of those devices, would you carve the insides into independent FSMs? Probably a 'yes' qualifed with 'if they were very independent problems anyway'. I did say I needed to think about it more. Guess if there were to eventually be a point I'd try to make, it would be that s/w seems to have a tendency to be structured more like an entire complex system, than like nice tight clean self contained state machines. Idk if this has to be so or not, but in recent years with the rise of multicore processing, I've seen a huge gravitation toward splintering s/w into threads, without, seemingly, well planned combination of those threads. It's sort of like if, as an EE you were going to build a whole computer, declared "I'm going to need counters and adders and registers (etc)", and then set about designing great counters and adders etc, but then just lashed them together somewhat haphazardly and kind of just hoped to get the system you wanted.
- rkangel 6y ago
  Modern software development is about management of complexity. That's why you have abstraction, that's why you have CI, that's why you have automated tests. Having multiple independent state machines isn't necessarily a failure of system thinking. To extend your processor argument, do you think there is only one state machine in (each core of) an x86 processor?

btbuildem 6y ago

Breaking a problem into smaller problems is an effective approach, rarely does it fail.