Problems with classical graphical programming
Contents
Problems
Likely the most major problems
Some (not all) older systems do not even allow for grouping functions into bigger ones.
Given no means of function composition that should't even be called a programming language. So let's ignore those.
Meaning of boxes and wires
Typically:
- wires are values and boxes are functions
- wires can't carry functions - because values are implemented to be distinct from functions
- functions are not "first class citizens")
- higher order functions (functions that can take functions as arguments) are not supported
Lack of visual continuity despite being all about visual continuity
When showing the inside of a function the exterior context is typically fully hidden away.
Sometimes a dependency tree mini-map is given, but not the actual code context.
Minor issues - not necessarily bad
- There is no constraint on spacial placement of wires and boxes – introducing an element of additional arbitrary data (that needs to be stored and managed)
- On screen information density is significantly lower than in purely textual programming.
Really bad when it becomes the reason for not showing code context.
Effects to investigate (possibly major effects)
Code abstractions (~input ports) and code applications (~connections to the input ports) are visually conflated.
Hard to explain. See: Annotated lambda diagrams for an example where this is not the case.
Solution attempts
"Flipped graphical programming"
There are experimental systems that flip the role of boxes and wires.
So that wires are functions and boxes are values.
This has it's own problems though. (wiki-TODO: add discussion)
Example experiment PANE (by Joshia Horowitz):
- http://joshuahhh.com/projects/pane/
- https://youtu.be/fIEcXAHy6bU — PANE: Programming with visible data — Joshia Horowitz
Designs that flip the role of boxes and wires are a little closer to spreadsheets.
One gets spreadsheets when changing a few things like so:
- hide the function wires fully
- organize the data boxes in a rigid inflexible grid
- add live data preview
- When editing one specific data box then show the function generating this output. But only for this single box.
Related: Problems with classical spreadsheets
Abstracting over the meaning of boxes and lines
Having higher order functions (and typeclasses / traits / ...)
One can use things like applicative functors and/or monads to add implicit functionality to the meaning of lines.
This is e.g. attempted in the non-classical visual programming language enso (formerly luna).
(wiki-TODO: Add specific example enso language and discussion.)
Reducing boxes to mere annotations of lines by adding more rules on the lines (top down interpretation)
Or rather "bottom up":
Visualize the three basic elements of a fundamental programming language calculus (lambda calculus)
as three distinct types of lines and see what happens.
- Boxes become mere annotations of lines.
- Freedom of placement of lines become strongly restricted because orientation and placement carries meqaning.
- Meaning of lines can become overloaded via applicative functors and/or monads
See: Annotated lambda diagrams
