• importantly, VPLs - "node and edges" ones - are not a solution here: they swap variable names for drawing edges, but the idea stays the same - you can touch anything immediately, regardless of how "far" it is
  • VPLs, understood as "nodes & edges", always (is that true?) provide some sort of infinite canvas to lay functions on, I'm curious if this combination is necessary - can the code still be text (or some other structural approach), while I can still "keep some functions here on the right of that other thing" - basically thinking spatially about my code
    • notable work in this direction is Dark (also featuring the "embodied data" idea): Dark Canvas
  • I like how code is expressed as "layers", borrowing from graphical applications (some other interesting prompts in this direction in VPL Issues:
    export let inner = 0.5;
    export let outer = 0.75;
    export let vertices = 10;
    // ...
      <Slider label="Sides" bind:value={vertices} min={5} max={20} step={1} />
      <Slider label="Inner Radius" bind:value={inner} min={0} max={2} step={0.01} />
      <Slider label="Outer Radius" bind:value={outer} min={0} max={2} step={0.01} />
  • is this related to signal-collect graphs or VPLs?
  • node-and-edge languages (VPLs) are DAGs describing computations - they are best modeled with streams, event emitters, etc.
  • Petri Nets might be interesting when related to VPLs
  • it's interesting to look at "simulator" problems from the point of view of VPLs - visualizing program state/execution is more useful than visualizing the AST - this, again, ties into Solving Things Visually

    What kind of a thinker would you become if you grew up with an active simulator connected, not just to one point of view, but to all the points of view (...) so they could be dynamically tried out and compared?

    — User Interface, a Personal View - Alan Kay

  • most VPLs weaken naming - instead of giving names to things, you make connections between unnamed things
  • VPLs require constant jumping between mouse and keyboard (something I tried solving with DAS-UI)

Secondary notation is poorly developed in the box-and-wire notations we examined, which we believe makes them harder to understand (although as yet, large-scale studies of comprehension have still to be reported). To achieve their aim of making better use of the visual medium, VPLs need facilities for colouring, commenting, grouping, modularizing, etc. (We recommend an explicit 'description level'.) Techniques to reduce the cluttered-wire problem would greatly increase the scope for using spatial layout as a form of communication.

— Usability Analysis of Visual Programming Environments - A "Cognitive Dimensions" Framework

Protoboard nodes by design encapsulate code instead of other nodes, compared to some VPLs where even basic math equations have to use blocks and connections.

Szymon Kaliski © 2022