A (long) time ago, my first job consisted of implementing workflows using the Staffware engine. In short, a workflow comprises tasks; an automated task delegates to code, while a manual task requires somebody to do something and mark it as done. Then, it proceeds to the next task - or tasks. Here’s a sample workflow: The above diagram uses Business Process Model and Notation. You can now design your workflow using BPMN and run it with compatible workflow engines. Time has passed.

Some libraries, frameworks, components, and architectures either encourage statelessness, or make it a requirement. While statelessness has a lot of benefits, it’s unfortunately rarely possible in the real world. In this post, I’d like to detail this stance of mine a bit. State in Functional Programming Functional Programming is based on a set of principles.

With Java 8 streams, it seems Functional Programming has won. Long live statelessness and recursion! Reality is a bit more nuanced: as always in software programming, it depends. I believe that the more tools in your toolbelt, the better it is. When all you have is a hammer, everything looks like a nail. In Functional Programming, every function needs to be pure: output only depends on input, and there are no side-effects.