Flying Logic: Just Another Outliner?

Flying Logic: Just Another Outliner?

I am often asked to compare Flying Logic to other packages such as Reasoninglab Rationale and MindMapper. I suppose the main thing that provokes this comparison is that all three are graphically-oriented programs for capturing knowledge. Traditional text-based outliner software is used for capturing knowledge too, but lacks the distinctive visual “boxes and lines” look that Flying Logic and the other packages share.

The main difference is that Flying Logic is not an outliner. What do I mean by this?

Outliners, whether they are traditional text-based ones or more visual ones like Rationale and MindMapper, are based on trees, also called strict hierarchies. If the sort of reasoning you want to do breaks down easily into this structure then outliners are fine, and of course Flying Logic does trees with no problem.

tree.png

A Tree

But Flying Logic is based on a more general structure called the Directed Acyclic Graph (or DAG). Unlike trees where every “child node” has exactly one “parent node,” in a DAG any child can have any number of parents. The only restriction is that a child not (directly or indirectly) be its own parent, a situation called a cycle or loop.

dag.png

A Directed Acyclic Graph (DAG)

In fact, FL allows cycles too, but specially treats the “back edges” that form them. This is useful when modeling so-called “virtuous cycles” or “vicious cycles.”

vicious.png

A Vicious Cycle (back edge in blue)

So Flying Logic is based on DAGs. So what?

Outliners (whether text-based or graphical) are useful when you are simply breaking a thing down into its subparts. For instance, “A degree program consists of a number of courses, each of which consist of a number of assignments.” This is a strict hierarchy. But what if you want to say that a particular course is a prerequisite for several degree programs, and see at a glance what degrees require which courses, and what courses are required by what degrees? Then the “course” entity needs to have several parents, and trees (and outliner software) do not permit this.

When modeling real-life cause-and-effect (such as when using systems thinking techniques like the Theory of Constraints), the need to break away from strict trees becomes even more apparent. Causes can have several effects, and effects can have several causes, or require several conditions, or both. This makes DAGs the most natural choice. But unlike tree-based outlines, which can be easily represented as indented blocks of text, DAGs have no simple expression in pure text without having to redundantly replicate information wherever a child has more than one parent. In other words: for trees, a graphical layout is a nicety, but for DAGs it is a necessity.

Flying Logic also includes features that are specifically aimed at modeling cause-and-effect, including junctors, operators, edge weights, and confidence spinners. Together, these allow various logical and/or mathematical relationships to be expressed, tested, and demonstrated step-by-step, including belief networks and probabilistic networks. (And they stay neatly out of your way when you don’t need them.) Outliners simply don’t do any of that.

Finally, if you look at the screen shot galleries of many graphical outliners, it’s often hard to tell whether more time and effort went into the actual planning work, or into tweaking the plethora of graphics options available. Flying Logic upholds a philosophy of Let the Planner focus on Planning. Since graphic design is not part of the planning process, Flying Logic deliberately avoids adding any graphical options except those that can be justified on the basis of supporting clean, understandable reasoning.