Rethinking Control Flow

Control Flow is a term used when describing the path of program execution. While it is necessary, by definition, control flow should be de-emphasized in declarative programming. Yet, I believe micromanaging control flow still plays an active role in even the most functional programs today.

Consider the following pseudo code

function count (text) {
        words = split(text)
        return length(words)
}
result = count('foo bar baz')
log(result)

Now consider the flow of execution.

Simple enough, we just read from top to bottom (jumping as needed). First count is called, which calls split, then length, returning the result, which is given to log to print.

Now slightly a different question, what does the dataflow look like?

'foo bar baz' -> count ( split -> length ) -> log

Looking at this one liner, this feels like a nice way to understand the execution and flow of data, but it doesn't match up exactly with the top-to-bottom layout. So even despite the lack of control flow operations like loops, conditionals or lambdas, it can take effort to extract and understand the data flow.

To further contrast, the simple arrows show the execution pointer moving down, yet the data is jumping all over the place:

For me, when I'm trying to debug some code, the first thing I try to do is to understand where the data is coming from and where is it going. This allows a divide and conquer approach, that ensures O(log(n)) dev time to find the discrepancy.