Yet another in the continuing series of "All you need..." (in software, that is) "...is X, and/or Y, and/or, etc.", where X and Y and Z are fundamental alternatives to a procedural paradigm. Sometimes these things are even presented as having the primary purpose and benefit of complexity management, within, and on the terms of, the software: what's not to like? Who could argue?<p>But each proposal founders upon contact with reality. The reality is that people understand processes (insofar as they understand them at all) as checklists; or, a little better, as decision trees; or, a little worse, as flowcharts. NOT as functions operating on data; that is a perspective that is only accessible to those mathematicians and logicians who have been trained in it.<p>Even if it is, in some situations, optimal to implement certain levels of certain automations in a functional paradigm, the procedural paradigm must first be adopted in order to communicate with the eventual users. We must meet them where they are; they are not equipped to move towards us. And it is not only a matter of capturing the implicit flowcharts that underlie the real-world execution and verification of processes; as found, they are full of unmanaged complexity arising from the proliferation of edge cases and of indeterminacy arising from half-understood heuristics. Some of these things are even business-critical: but none of them can be automated. In order to automate the as-found processes, they must be rationalized to remove indeterminacy and then simplified -- typically quite drastically -- so that they can be implemented in a maintainable form. Where the heuristics or the edge cases are, in fact, business-critical, then the advice must be, firmly, to leave the processes in human hands. Machines aren't good at that, and if you try to force them to attempt it, the cost, the duration, and the error rate of the processes will all only go up.