It's great to see these software ideas being used in embedded systems. From my limited experience with embedded code, most engineers in the domain treat their software more like hardware. They test it WITH specific hardware and don't abstract it, abstraction being more of a software thing.
I would like to read a blog post about what you're doing. It would also be great to connect it to the other software communities doing similar things with different names.
I think this encountered these ideas in the Java world around 2005, with their strong focus on testing. It's basically "dependency injection" or dependency inversion.
I just did some Googling and found this good overview:
It's very much an idea in the "enterprise" software world. I've never been in that world but it does seem like they are grappling with complex problems and systems, and this architecture has proven itsef in that domain. It's not surprising to me that it's also useful in the embedded domain.
I would say it's just "modularity". If your dependencies are hard-coded, then you have no modularity in your software at all. The whole thing is one big ball of mud which you can either take or leave. "Functions" aren't really modular if they have nontrivial hard-coded dependencies! (i.e. particularly ones that do I/O or depend on state).
Other names:
- capability based security / Object capabilities (WASM is influenced by these ideas, which originated from Eros OS as far as I know. The E language was an influential object capability language.) The idea of "ambient authority" is useful.
- https://news.ycombinator.com/item?id=14523728 -- a thread where Go programmers are rediscovering dependency injection. You can "invert" state or I/O. Those are independent decisions, but the same concept. In my larger programs, I tend to abstract both of them.
- In Haskell, you use State and IO monads. They are parameters, not things you go "looking for".
At its most fundamental, SIMPL is a set of library functions which allow the passing of encapsulated messages between cooperating processes. These processes may be local to one host computer or spread over a network.
I would like to read a blog post about what you're doing. It would also be great to connect it to the other software communities doing similar things with different names.
I think this encountered these ideas in the Java world around 2005, with their strong focus on testing. It's basically "dependency injection" or dependency inversion.
I just did some Googling and found this good overview:
https://gist.github.com/kbilsted/abdc017858cad68c3e7926b0364...
It's very much an idea in the "enterprise" software world. I've never been in that world but it does seem like they are grappling with complex problems and systems, and this architecture has proven itsef in that domain. It's not surprising to me that it's also useful in the embedded domain.
I would say it's just "modularity". If your dependencies are hard-coded, then you have no modularity in your software at all. The whole thing is one big ball of mud which you can either take or leave. "Functions" aren't really modular if they have nontrivial hard-coded dependencies! (i.e. particularly ones that do I/O or depend on state).
Other names:
- capability based security / Object capabilities (WASM is influenced by these ideas, which originated from Eros OS as far as I know. The E language was an influential object capability language.) The idea of "ambient authority" is useful.
- https://news.ycombinator.com/item?id=14523728 -- a thread where Go programmers are rediscovering dependency injection. You can "invert" state or I/O. Those are independent decisions, but the same concept. In my larger programs, I tend to abstract both of them.
- In Haskell, you use State and IO monads. They are parameters, not things you go "looking for".
- Good overview of enterprise world: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a... (Clean architecture, ports and adapters, onion architecture, hexagonal architecture, functional core / imperative shell, etc.)
I think Java eventually went overboard with "DI frameworks", which I never used. I just wire up the dependencies manually in main() and it works fine.
-----
Also, I bought a somewhat obscure many years about dataflow programming and hardware, which I think it somewhat related:
https://www.amazon.com/Programming-SIMPL-Way-John-Collins/dp...
At its most fundamental, SIMPL is a set of library functions which allow the passing of encapsulated messages between cooperating processes. These processes may be local to one host computer or spread over a network.