Overview
When people first open Divooka, they see a network of interconnected nodes where connections represent data flow.
Even someone who has never seen visual programming or Divooka before can read the titles of the nodes and input parameters and have a pretty good guess at what the program does.
Thus, a key to using Divooka (in the dataflow context) efficiently is understanding the execution runtime - what nodes are active, what the dependency tree is, and how caching works.
As someone who has been using Unreal Engine Blueprint since 2014, the concept of "execution flow" appears natural to me - but when showing this to new users, it became evident that it takes time to tune in and learn to read the diagrams.
We'll take a look at what procedural context is, then briefly analyze why that's the case.
The Procedural Constructs
The procedural context in Divooka provides many constructs that may be familiar to those from traditional programming languages.
An example is shown below:
Common Constructs
Conditional logic is done using the Branch node.
Loops are implemented using the Repeat node.
Iteration is done using the For Each node.
Functions are handled using the Execute Event and Custom Event nodes.
A switch-case structure is implemented using the Switch node.
(Pending image)
Unique Constructs
In addition, Divooka also offers constructs that are unique to it:
Sequence nodes are used to define multiple sequential steps.
Events are entry points defined by the framework (procedural context base type).
Implementation Note
Certain constructs are currently missing:
- Break: to exit a loop prematurely.
Caveats of States
What's more, in procedural context there is the possibility of manipulating state - for example, incrementing a number to be used next time.
Thus, to use the procedural context effectively, users need to learn a good amount of "syntax": control flow, state handling, and more.
The Two Contexts
Given that all of the top 10 most popular programming languages support imperative/procedural programming as the default mode, one might expect this to be the most straightforward paradigm. In reality, that's not the case.
Use the dataflow context for data-centric operations, such as data transformations.
Use the procedural context for logic-centric operations, such as branching and conditional executions.
Unlike procedural context, when using dataflow context, users need to learn only a single syntax: connections represent data flows, and everything (almost) always executes - depending on node activation status. To follow the flow of a program is simply to follow the connections - there's no concern about branches or alternate execution paths.
Conclusion
The procedural context is more complex for several reasons:
- Connections now represent both data and execution flow
- Some nodes can interrupt, diverge from, or selectively execute downstream connections - requiring users to understand exact behaviors to make accurate predictions
- There are many types of flow control nodes, each requiring learning
- State is involved
Part of the reason Divooka started with the dataflow context was exactly to reduce this complexity. However, as programs become more complicated and procedural logic becomes involved, it's not possible to avoid procedural context - in fact, having it is often more convenient than not.
Users must make informed decisions about what to put into procedural context and what to offload to dataflow context.
Top comments (0)