• 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):
  • 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
  • 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)

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 © 2021