4 ms·

>35 years professional software engineering, 30 years in embedded. I'm going to guess that you have less. Doesn't change the fact that you're wrong and 35 year

>35 years professional software engineering, 30 years in embedded. I'm going to guess that you have less. Doesn't change the fact that you're wrong and 35 years of programming doesn't ensure that you're a good developer. There are examples of crap code and patterns that have been around perpetually. >Why is state data used everywhere? Because embedded systems often respond in different ways depending on the state of external inputs State being everywhere doesn't preclude it to being segregated from logic. >If those decisions are spread through the bulk of the code, there's really not much left to put in your combinator. And there's no point in trying to add that paradigm to a system that's going to have tons of shared mutable state anyway. The decision is what goes in the combinator. #IO functions. Data getIOFromModuleA() void sendIOToModuleA(Response r) Data getIOFromModuleB() void sendIOToModuleB(Response r) .... # combinators, reuseable in both module A and module B because of segregation from IO and State Decision makeDecision(Data x) Response createResponse(Decision x) It's the same pattern for State. Just replace the word IO with State. Response can be anything, it can be the entire new state of the program. It can represent a delta of a change, it can be a response specific to a module. Also again, all threading commands go into State or IO functions. OOP fails to segregate code this way and if you don't organize your code like this then you have 35 years of experience of navigating someone elses mess or your own.

AnimalMuppet 6y ago
So I said you were inexperienced. You said I was. I listed my experience. You said it was the wrong experience, but conspicuously declined to state your own. 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.
- nendroid 6y ago
  I said it as a minor minor retort. You want the full story? The full story is I don't care for experience. I find experience doesn't correlate with actual skill. Many experienced developers act and seem very inexperienced which is what I said about you: You "seem inexperienced" because you act that way. The very act of bringing up experience is off topic and a sign of lack of maturity. 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. Nothing I said is "theory" in the sense that you put it. These are rare but actual patterns that are used successfully by people in the know. You are not in the "know" despite your experience. As a result for most of your program experience you've just been dealing with and fixing mess after mess after mess.
  - AnimalMuppet 6y ago
    "It is useless to have a conversation with those who will not listen." Neither of us are listening, because we're both sure we're right. So I'm out. You get the last word, if you want.
    - nendroid 6y ago
      Don't be stupid. I'm listening to you. I'm actually responding to you. You say theory is different from the real world so I present you with a real world solution and examples of how it works with embedded specifically. Your job should you choose to continue is to use other real world examples to counter my arguments. That's all, if you convince me it's done, If i convince you it's also done. Until then leaving the discussion before it's resolved is pointless. 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.
      - AnimalMuppet 6y ago
        Fine. void handleEvent1() { if (currentState == state1) { currentState = state2; setHardwareState2(); } else { currentState = state3(); setHardwareState3(); } } You can move state to the boundary, and IO to the boundary, and then... what's left? It was all boundary. 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 } How would you write this in your approach?
        nendroid 6y ago
        //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) } Your example uses free variables extensively. It means that all your logic cannot move outside of the context of the free variable which means they cannot be reused. Even IO functions should not use external context. Combinators can be reused everywhere.

AnimalMuppet 6y ago

So I said you were inexperienced. You said I was. I listed my experience. You said it was the wrong experience, but conspicuously declined to state your own. 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.

nendroid 6y ago
I said it as a minor minor retort. You want the full story? The full story is I don't care for experience. I find experience doesn't correlate with actual skill. Many experienced developers act and seem very inexperienced which is what I said about you: You "seem inexperienced" because you act that way. The very act of bringing up experience is off topic and a sign of lack of maturity. 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. Nothing I said is "theory" in the sense that you put it. These are rare but actual patterns that are used successfully by people in the know. You are not in the "know" despite your experience. As a result for most of your program experience you've just been dealing with and fixing mess after mess after mess.
- AnimalMuppet 6y ago
  "It is useless to have a conversation with those who will not listen." Neither of us are listening, because we're both sure we're right. So I'm out. You get the last word, if you want.
  - nendroid 6y ago
    Don't be stupid. I'm listening to you. I'm actually responding to you. You say theory is different from the real world so I present you with a real world solution and examples of how it works with embedded specifically. Your job should you choose to continue is to use other real world examples to counter my arguments. That's all, if you convince me it's done, If i convince you it's also done. Until then leaving the discussion before it's resolved is pointless. 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.
    - AnimalMuppet 6y ago
      Fine. void handleEvent1() { if (currentState == state1) { currentState = state2; setHardwareState2(); } else { currentState = state3(); setHardwareState3(); } } You can move state to the boundary, and IO to the boundary, and then... what's left? It was all boundary. 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 } How would you write this in your approach?
      - nendroid 6y ago
        //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) } Your example uses free variables extensively. It means that all your logic cannot move outside of the context of the free variable which means they cannot be reused. Even IO functions should not use external context. Combinators can be reused everywhere.