State — that’s static variables in firmware-speak — is considered harmful by hipster designers. But they are as different from us as two software specialisations can be. They live on the Ethereal Plane. [Why do you think it’s called “Ethernet”? 🙂] They belong to different schools of magick from us, they cast different spells, with different intent, in their world of nets and webs. State introduces problems for them.
The arguments hipsters have put together to vilify state have merit, but many of their objections describe problems with state in the context of their Ethereal Plane. They do not affect us or our firmware. What remains after we discard these context-specific objections is that state represents a hidden parameter passed to every method when it’s called. No programming technique is without its downside, and that is a downside of state.
State is unavoidable in firmware. Our applications contain tasks that are continually executed. In between task invocations, the state of each task is stored. When that task is executed again, its state tells it where it has got to, and (therefore) what to do next. Unless we make radical changes to the way we design — and this is not impossible… — we need state.
Another objection to state is that it makes code more difficult to test. It does, but so does any addition to existing code. Instead of just testing a method once, we have to run each test in every possible state. This is not a reason for us to give up on state, but it is a reason to minimise it. An application with too much state becomes difficult to understand and, eventually, impossible to extend or maintain. Clearly, some caution is appropriate in our use of state. But caution is appropriate to all of our coding, whatever we’re doing. It doesn’t just apply to state.
Hipsters found problems, and traced them to state. At this point I think they adopted the belief that state is bad. Then they searched for justifications for their beliefs, and they found some. That some or all of their arguments are valid doesn’t change what they have done, and are doing. They seek to optimise their working practices for their world, and the work they do, which is eminently sensible. And for them, the bad points of state outweigh the good ones. For us, that is not necessarily the case, and we should resist being carried along with the tide, just because that’s what hipsters are doing.
State is not harmful, but it should be used with care.
“Who cares, wins.”
This blog post is the latest in a series that is longer than I expected it to be. 🙂 Their main (intended) purpose is to stimulate discussion, so please leave a comment. Thanks for dropping by! [Find me on Twitter as @Patternchaser.]
carelesstalkblog 
Following up my twitter comment: while I’m not a FP zealot (or a zealot of any kind) and while I tend to design firmware around an actor model (so based on stateful agents), real-world FP is not about having no side effects (no useful program can be created that way) but to control side effects and make them visible at the type-system level, so that you don’t “accidentally” mix I/O with what was intended to be referentially transparent code (I don’t use “pure functional” because I don’t like to use ethically charged terminology).
A popular approach to deal with effects (and coeffects) is to adopt monadic composition. In practice, even the simplest firmware will call for all kind of effect: reading input, writing output, storing state between calls, and depending on your style (message passing vs sharing) you may even need sw transactional memory. That would probably call for the dreaded stack of monad transformers.
There isn’t much literature on writing firmware using Haskell (not that I know anyway) but quite a few people have tried over time to write device drivers and even OSes using FP. Just looking up writing drivers in Haskell on google should reveal enough sources.
Of course, in practice one should balance the benefits with the cost. While some will claim that you *must* write sw that way, my experience with firmware is that we often end up with complex state machines doing very little in every state, and with that “little” also involving I/O.
I intuitively don’t see a positive trade-off in moving firmware to an FP style, because the referentially transparent portion would be small and largely trivial. But this is just intuition: well-intentioned experiments would be needed, but we don’t see many of those in our discipline :-).
LikeLiked by 1 person
It sounds like you have written firmware using an FP language? Presumably this would be on a high-end firmware platform, with enough memory to support that kind of operation? [I tend to focus on low-end firmware, where 64k RAM is still a dream. But maybe not for too much longer?]
What you’ve written sounds fascinating, but I’m afraid a lot of it (the FP stuff) goes over my head. I find FP interesting, but didn’t think it could be used in firmware. Clearly that isn’t so. Monads and “monadic transformers” are something of a mystery to me. 😦
You’re right that there isn’t much experimentation in firmware. In part that’s justified, because the resource limitations of our hardware platforms tend to mandate C or assembler. [C++ is possible, but still not widely used.] This limits what we can experiment on or with. Perhaps I’m too set in my ways to see what is possible…?
Thanks, Carlo, for introducing something I hadn’t thought possible. Food for thought! 🙂
LikeLike