Latest revision as of 09:41, 5 May 2024

Up: Software trouble pages

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

Related

• Problems with classical spreadsheets