So I'll just leave you with this. "In theory, there is no difference between theory and practice. In practice, there is." You've got your theory. Nice theory. Use it for a decade of actual real-world work, and let me know how it works out. I'll be especially interested if any of that work is in embedded.
If you have to know I'd say I have about 15 years of experience in research, gaming, embedded and web. I will say that the pattern I described can be followed in every one of those fields but it's a niche pattern because it is indeed promoted by people who do FP.
I don't know why you focus on embedded, but embedded people tend to follow these patterns the least due mostly to C++. The overall promoted pattern in C++ is to pass references everywhere and it's highly unlikely that someone in that world will follow this pattern because you have to go out of the way to do it and learn about it. It requires a disciplined approach.
The big problem is if you need to slightly modify a bunch of values in an array of 100 objects. It's hard to figure out the right way to do it in a combinator. The common pattern used nowadays is instead of having combinators handle it, have the combinators generate logical instructions to send to the IO function similar to how in web development your stateless servers pass SQL instructions to the SQL server. The IO function processes the instructions and handles the threading, mutation and IO. Here's a library that does this:
https://github.com/google/cpp-frp <---- real world example.
You get the last word, if you want.
Don't back out, I'm not fighting for the last word. I'm having a discussion with you in hopes you can convince me. But you haven't really said anything substantial other than things along the lines of "Trust me I have lots of experience, your stuff is just theory."
If you start introducing the real arguments then this discussion can actually go somewhere.
void handleEvent1() {
if (currentState == state1) {
currentState = state2;
setHardwareState2();
} else {
currentState = state3();
setHardwareState3();
}
}
A bit more realistically, here's an automobile cruise control that uses the same button for "reduce set speed" and "set the speed". (Don't blame me, I've had more than one car with that exact setup).
void buttonXEvent() {
if (cruiseControlEnabled) {
if (cruiseSpeedSet) {
cruiseSpeed--;
} else {
cruiseSpeed = currentSpeed;
cruiseSpeedSet = true;
}
writeSpeedToEngineComputer(currentCruiseSpeed);
} // else do nothing
}
//combinators
CruiseSpeed = int
CruiseSpeed getNextCruiseSpeed(bool cruiseControl, bool cruiseSpeedSet, int cruiseSpeed, int currentSpeed) {
if cruiseControl && cruiseSpeedSet
return cruiseSpeed - 1
elif cruisControl && !cruiseSpeedSet
return currentSpeed
else
return cruiseSpeed
}
bool getNextCruiseSpeedSet(bool cruiseControl, bool cruiseSpeedSet){
return cruiseControl && !cruiseSpeedSet ? true : cruiseSpeedSet
}
//IO functions
void getCurrentSpeed()
bool isCruiseSpeedSet()
void setCruisSpeedSet(bool cruiseSpeedSet)
void writeSpeedToEngineComputer(CruiseSpeed x)
void handleButtonPress(bool cruiseControl, bool cruiseSpeedSet, int cruiseSpeed, int currentSpeed){
speed = getNextCruiseSpeed(cruiseControl, cruiseSpeedSet, cruiseSpeed, currentSpeed)
cruiseSpeedSet = getNextCruiseSpeedSet(cruiseControl, cruiseSpeedSet)
writeSpeedToEngineComputer(speed)
setCruiseSpeedSet(cruiseSpeedSet)
}
Combinators can be reused everywhere.
By the time you implement getCurrentSpeed(), etc., you're going to have a fair amount more code than me. (writeSpeedToEngineComputer() doesn't count, because I need to implement that also.)
Your reason for doing so is, I think, in your last two paragraphs. But this isn't particularly reusable code - I'm not going to use getNextCruiseSpeed() or handleButtonPress() in the windshield wiper controller. It's pretty much tied to the specific use. (There may be a handleButtonPress() in the windshield wiper controller, but I can't reuse this one.)
So you offer me something that is more verbose, based on a benefit that I can't actually benefit from.
(I presume that getCurrentSpeed() returning void was just because of quick typing.)
The other point of this was to improve code modularity in every corner of your code. Why is this good? If all your logic can be shifted around then that means that you can reuse code to anticipate future changes.
The most insidious form of technical debt is unanticipated technical debt. You encounter it when a new requirement makes you realize that you can't reuse segments of your code. You realize that you grouped things together incorrectly. You failed to have the foresight to make your code more modular.
It's a problem people think they can solve in hindsight but they can't in reality because they cannot predict the future so they will inevitably group code incorrectly. And therein lies the problem: grouping. Don't group your code. Make all your logic modular and just organize your code with superficial schemes like namespaces.
The problem with OOP is that the very nature of an object is a grouping. OOP is all about grouping the code around shared mutable variables within a context. You are forced to assume a grouping and you may be right in some cases (like cruisecontrol) but you will inevitably be mistaken in many other cases. This "mistake" is the origin of the most insidious form of technical debt.
The other problem with OOP is that they think that this style of programming is modular. They have no idea how un-modular it is. So they use it extensively with patterns thinking they're improving modularity.
The most modular primitive is the combinator. That is why to prevent technical debt as much as possible, the key is to move as much code as possible into the combinators.